¿Cuál es el mecanismo de trabajo y la metodología de la supervisión de TI durante la etapa de análisis de la demanda de construcción del proyecto?

En principio, se deben respetar las capacidades de gestión y análisis del proyecto del contratista, el trabajo específico no debe ser en profundidad y no se debe interferir con la autonomía del contratista. Sin embargo, si existen grandes brechas y deficiencias durante el proceso de cooperación del proyecto, para garantizar el buen desarrollo del proyecto, el supervisor debe fortalecer las capacidades de gestión y análisis del proyecto, y adherirse a los métodos y medios de absorción, asimilación y implementación en operaciones específicas.

2. El papel del progreso necesita análisis y supervisión.

El análisis de requisitos es el comienzo de un proyecto y la piedra angular de su construcción. El 80% de los proyectos que fracasaron en el pasado se debieron a análisis de requisitos poco claros. Por tanto, uno de los factores clave para el éxito del proyecto es el dominio del análisis de necesidades. El riesgo general del proyecto se manifiesta en análisis de demanda poco claros y procesos comerciales irrazonables. Los usuarios no están acostumbrados o no quieren utilizar el software del contratista, o es difícil de utilizar, lo que provoca el fracaso de los proyectos. Por lo tanto, como empresa de supervisión externa, es necesario recordar a los contratistas y clientes la importancia del análisis de la demanda y adoptar los medios y métodos necesarios para realizar la investigación de la demanda. Al mismo tiempo, los supervisores también deberían realizar una investigación en profundidad de las necesidades específicas. Sólo de esta manera podremos comprender verdaderamente las necesidades y direcciones de los usuarios y tener voz y voto en la definición de funciones futuras y el alcance del desarrollo.

2.1. ¿Por qué los supervisores consultores deberían centrarse en el análisis de las necesidades de seguimiento?

Debido a la particularidad del proyecto y la amplia cobertura de la industria, así como al alto riesgo del análisis de requisitos, la importancia del análisis de requisitos en todo el ciclo de desarrollo de software es evidente y Es realmente difícil hacer las cosas. La dificultad se debe básicamente a las siguientes razones:

(1) Los clientes no conocen los requisitos; (2) Los propios requisitos cambian con frecuencia (3) Los analistas o clientes tienen malentendidos; .

2.1.1 Los clientes no pueden explicar claramente sus necesidades.

Algunos clientes simplemente tienen una idea vaga de sus necesidades y, por supuesto, no pueden explicar sus necesidades específicas. Por ejemplo, muchos departamentos, agencias y unidades en todo el país están construyendo redes y sistemas de aplicaciones. La mayoría de los líderes de los clientes y el personal de la oficina no saben cómo utilizar las redes informáticas y carecen de conocimientos y expertos en construcción de TI sistemática. En este punto, se le pedirá al analista de sistemas de software que visualice los requisitos para ellos. Existe un cierto grado de subjetividad en los requisitos del proyecto, lo que crea riesgos potenciales para la construcción del proyecto.

2.2.2 Los propios requisitos cambian con frecuencia.

Basado en la experiencia histórica pasada, a medida que los clientes comprendan la construcción de información y mejoren su nivel comercial, propondrán nuevos requisitos y cambios en los requisitos del proyecto en diferentes etapas y períodos. De hecho, ningún software en la historia ha cambiado sus requisitos menos de tres veces, por lo que debemos aceptar el hecho de que "los requisitos cambiarán". Por lo tanto, al analizar los requisitos, debemos tomar precauciones antes de que sucedan y tratar de analizar claramente qué requisitos. son estables y cuáles son factibles. Para diseñar un sistema, el núcleo del software se basa en requisitos estables y deja margen para el cambio. El supervisor consultor desempeña un papel intermediario, justo e imparcial en la definición de las funciones del análisis de requisitos y, por lo tanto, también debe participar en la preparación del análisis de requisitos, ayudando así al cliente y al contratista a definir los límites funcionales del sistema de "qué hacer". " y "qué no hacer".

2.1.3 Analistas o clientes mal entendidos.

No todos los analistas de sistemas de software pueden ser generalistas, y mucho menos expertos en la industria. Diferentes analistas pueden tener diferentes interpretaciones de las necesidades expresadas por los clientes. Si el analista se equivoca, es posible que se desperdicien esfuerzos de desarrollo futuros. Recuerdo un chiste: "Un espía alienígena acecha en la Tierra para espiar información. Escribe un informe a su jefe: "Los coches dominan la Tierra. Beben gasolina y ruedan sobre cuatro ruedas. Tiene una voz fuerte y sus ojos pueden emitir luces brillantes por la noche. .....Curiosamente, hay parásitos llamados "humanos" que viven en el coche, y estos parásitos controlan completamente el coche. Por lo tanto, la especificidad del conocimiento de los analistas también puede conducir a malentendidos y fallas en el análisis de requisitos. En este momento, es necesario consultar a la empresa supervisora ​​sobre la base del plan de investigación de demanda real del proyecto y recordarle al contratista que fortalezca la comprensión empresarial y preste atención a las habilidades de comunicación.

2.2 ¿Cómo realiza la empresa de supervisión de consultoría el análisis de la demanda?

El análisis de necesidades no comienza con pistas como el razonamiento detectivesco. Primero debemos comprender el panorama general y luego llegar a los detalles.

Un sistema de software de aplicación (marcado como S) puede cubrir una amplia gama y puede clasificarse en diferentes dominios de problemas (marcados como D), correspondiendo cada dominio de problema a un subsistema de software.

S = { D1, D2, D3,... Dn }

El dominio del problema Di consta de varios problemas (denotados como p), cada problema corresponde a uno de los subsistemas Soft componentes.

Di = { P1, P2, P3,... Pm }

El problema Pj tiene varios comportamientos (o funciones, denotados como F), y cada comportamiento corresponde a un componente de software Implementar la interfaz.

Pj = { F1, F2, F3,... Fk }

La especificación de requisitos escrita según la estructura de la Figura 4.1 es adecuada para líderes que solo quieren conocer la macro Requisitos y tecnologías que necesitan conocer los detalles del personal. Al escribir una especificación de requisitos, también debemos prestar atención a dos cuestiones:

(1) Es mejor indicar el "por qué" para cada requisito, de modo que los programadores puedan comprender la esencia del requisito y elegir el La tecnología más adecuada para lograrlo.

(2) La declaración de demanda no debe ser ambigua, y mucho menos inconsistente. Si hay ambigüedades o inconsistencias, se debe volver a analizar el requisito.

2.3 Metodología de análisis de la demanda de empresas de consultoría y supervisión

Con base en la experiencia pasada de ingeniería, se cree básicamente que el método de trabajo del análisis de la demanda debe ubicarse en las "tres etapas" (también conocido como el "método de los tres pasos").

Primera: “Entrevista”. Esta etapa es la entrevista y comunicación con los líderes y personal empresarial de usuarios específicos. El objetivo principal es básicamente comprender las necesidades y tendencias específicas de nuestros usuarios desde una perspectiva macro, y comprender información específica, práctica y objetiva, como la estructura organizacional existente, los procesos comerciales, el entorno de hardware, el entorno de software y los sistemas operativos existentes. Establezca buenos canales y métodos de comunicación, y lo mejor es designar a la persona interfaz para este proyecto de acuerdo con departamentos y comités funcionales específicos.

Medios de implementación: entrevistas y cuestionarios.

Salida: informe de investigación e informe de proceso de negocio.

La tercera etapa: "Confirmación", basada en los resultados de las dos etapas anteriores, se lleva a cabo el refinamiento del proceso específico y la confirmación de los elementos de datos. En esta etapa, el contratista debe proporcionar un sistema prototipo, un informe claro del proceso comercial y una tabla de elementos de datos, y ser capaz de describir claramente los objetivos de diseño del proceso comercial del sistema a los usuarios. Los usuarios pueden ver informes de procesos comerciales, tablas de elementos de datos; operar sistemas de demostración proporcionados por el contratista para proporcionar comentarios y firmar informes y documentos que han sido revisados.

La implementación significa: visitar (auditar y confirmar) y enviar el informe del proceso comercial y la lista de elementos de datos;

Salida: informe de análisis de la demanda, elementos de datos, informe del proceso comercial, prototipo. Comentarios del sistema (los últimos tres pueden unificarse en el informe de análisis de la demanda y enviarse a los usuarios y supervisores para su confirmación y archivo).

En general, las tres etapas del análisis de la demanda son partes importantes que no pueden ignorarse en la investigación de la demanda. La implementación y adopción del enfoque de tres fases o tres pasos también proporciona a los usuarios y contratistas una garantía de éxito del proyecto. Por supuesto, durante el proceso de construcción del sistema, especialmente después de adoptar el modelo de desarrollo iterativo, el análisis de la demanda continuará en la mejora de la demanda posterior, que se encuentra básicamente en las dos últimas etapas.

Para obtener más información sobre licitaciones de ingeniería/servicios/adquisiciones y para mejorar la tasa de adjudicación de ofertas, puede hacer clic en la parte inferior del sitio web oficial de servicio al cliente para realizar una consulta gratuita: /#/? fuente=bdzd