Documentación técnica. Documentación técnica Realización de pruebas de aceptación.

Anotación: Una continuación lógica de la conferencia anterior. Se analiza en detalle el problema de la aplicación práctica de GOST R ISO/IEC 12207 en organizaciones y proyectos. En este sentido, se están estudiando las normas GOST R ISO/IEC 15271 y GOST R ISO/IEC 16326.

De la lección anterior debería quedar claro que implementar GOST R ISO/IEC 12207 es una tarea muy difícil. En primer lugar, ¿no está claro qué significa "implementar GOST R ISO/IEC 12207"? ¿Se puede considerar implementado si algunos de los procesos de la organización coinciden con los procesos de la norma y otros no? ¿Se puede considerar implementada una norma si algunos proyectos se llevan a cabo de acuerdo con ella y otros no? Esta lista de preguntas puede seguir y seguir.

No es casualidad que siguiendo GOST R ISO/IEC 12207, se haya desarrollado específicamente el estándar GOST R ISO/IEC 15271-02 (GOST 15271, 2002), dedicado a la tarea de su implementación, que se denomina “Directrices para la aplicación de GOST R ISO/IEC 12207”. Pasaremos ahora a considerarlo.

Estándar GOST R ISO/IEC 15271

El significado de la norma se revela en su sección introductoria.

"1.2. Usuarios de la norma.

Este estándar puede ser utilizado por entidades (individuos, organizaciones) que deseen aplicar GOST R ISO/IEC 12207 al implementar contratos, independientemente del volumen o complejidad del proyecto, por parte de una organización específica para trabajos de autocontrol o mejora. procesos del ciclo de vida herramientas de software.

Esta norma especifica cómo se puede utilizar GOST R ISO/IEC 12207 en relación con diferentes tipos de software y qué procesos son apropiados para cada caso.

Este estándar complementa GOST R ISO/IEC 12207, que no es solo un documento normativo, sino también un estándar para gestionar un proyecto real. (Por ejemplo, el último caso ocurre cuando GOST R ISO/IEC 12207 es un modelo para realizar parte del trabajo del proceso de mejora). Esta norma debe leerse en su conjunto, pero en casos individuales podrán utilizarse secciones específicas."

El estándar GOST R ISO/IEC 15271 consta de 8 secciones y 4 Apéndices. Las secciones de contenido se denominan de la siguiente manera (numeración extraída del texto):

• 4. Conceptos básicos de desarrollo de GOST R ISO/IEC 12207.
• 5. Implementación de GOST R ISO/IEC 12207.
• 6. Aplicación en proyectos.
• 7. Aplicación en las organizaciones.
• 8. Solicitud modelos de ciclo de vida sistemas.

La Sección 4 está escrita en estilo de comentarios y aclaraciones al texto de GOST R ISO/IEC 12207. Las aclaraciones más importantes se refieren a la interacción de GOST R ISO/IEC 12207 con los estándares corporativos de la organización, la distinción entre los conceptos de " software” y “sistema” y las distinciones resultantes entre procesos relacionados con el software y los sistemas. El concepto se describe en detalle. gestión de la calidad, implementado en GOST R ISO/IEC 12207. En general, la sección da la impresión de una breve descripción conceptual de GOST R ISO/IEC 12207, que recuerda a un libro de texto.

La Sección 5 presenta un enfoque general para la implementación, llamado estrategia de implementación GOST R ISO/IEC 12207. Una estrategia, según el estándar, es "un método de implementación típico que debe seguirse al realizar cambios en las actividades o proyectos de una organización". La estrategia se implementa como un proyecto que consta de pasos obligatorios, descritos de manera informal y sin ninguna conexión con los procesos de la organización. Estos pasos son los siguientes:

• a) desarrollo de un plan de implementación;
• b) aplicación práctica de GOST R ISO/IEC 12207;
• c) brindar apoyo proyecto piloto(s);
• d) formalización del método de implementación;
• e) aprobación del método de implementación.

El desarrollo de un plan de implementación incluye determinar el alcance de aplicación de GOST R ISO/IEC 12207. El alcance puede ser, por ejemplo, un grupo de departamentos o proyectos de una organización. También puede definir el alcance de aplicación como un conjunto de procesos clave para la organización, que serán reemplazados por procesos de GOST R ISO/IEC 12207. El plan de implementación en sí determina la composición de los proyectos llevados a cabo durante la implementación (puede haber Varios de ellos). Ni que decir tiene que a la hora de desarrollar un plan de implementación se determinan los recursos necesarios: económicos, humanos, técnicos, etc.

En la aplicación práctica, como era de esperar, se propone utilizar el proceso de adaptación descrito en el propio GOST R ISO/IEC 12207.

La estrategia en sí no plantea dudas: esta secuencia de pasos puede ser bastante efectiva en condiciones específicas, pero vale la pena señalar que el enfoque formal del proyecto para la implementación de GOST R ISO/IEC 12207 se basa en una comprensión simplificada de la situación real. situación. Teniendo en cuenta que los procesos de una organización (así como su estructura organizativa) cambian constantemente, creo que sería metodológicamente más correcto considerar la implementación de una norma como un proceso continuo, y no como un proyecto de tiempo limitado. Este proceso monitorea los cambios en los procesos de la organización e inicia proyectos individuales, por ejemplo:

• proyectos para la aplicación de GOST R ISO/IEC 12207;
• un proyecto para capacitar a todos los nuevos empleados en los procesos de GOST R ISO/IEC 12207;
• un proyecto para introducir cambios en los procesos implementados en relación con cambios en la estructura organizativa de la organización; etcétera.

El enfoque para la implementación de GOST R ISO/IEC 12207 como un proceso, especialmente si se pretende comenzar con su aplicación en proyectos o departamentos individuales de la organización, permitirá concentrar la responsabilidad del resultado general en manos del propietario del proceso. , permitirá establecer un seguimiento general de los resultados, etc. Evidentemente , a la implementación le debe seguir un apoyo a los procesos implementados, que también se organiza naturalmente como un proceso.

Más detalles sobre el uso de GOST R ISO/IEC 12207 en proyectos se describen en la sección 6 “Aplicación en proyectos”. La norma propone clasificar proyectos y para ello introduce un nuevo concepto: " modelo de ciclo de vida sistemas" (en el Apéndice C se proporciona una lista de modelos típicos). Lo que es un modelo no está definido formalmente. Más adelante, la Sección 8 establece que "el concepto general modelo de ciclo de vida Los sistemas se dividen en etapas (etapas) con la posterior adaptación de cada una de ellas a modelos de ciclo de vida sistema específico" (la siguiente es una lista de etapas). En total, se consideran tres de estos modelos: en cascada, incremental, evolutivo. Se analizan sus ventajas y desventajas, y luego se "superponen" los procesos de GOST R ISO/IEC 12207. en la estructura de los modelos. Como resultado, estos procesos reciben propiedades adicionales, por ejemplo, repetición repetida en el ciclo de vida o superposición de tiempo con otros procesos. Además, la sección contiene muchas recomendaciones de diversos grados de utilidad con respecto a individuos aspectos de los proyectos. He aquí un ejemplo típico.

"6.1.3. Características del sistema

Los subsistemas y elementos de configuración del sistema deben definirse con el nivel de detalle adecuado. Es necesario determinar las características del sistema, especialmente aquellas relacionadas con el software. Al determinar estas características, es necesario tener en cuenta cuáles de ellas son críticas durante el funcionamiento del sistema.

Una lista indicativa de características a nivel de sistema (relacionadas con el software y sujetas a consideración) incluye:

• interfaces entre sistemas e intrasistemas;
• interfaces de usuario;
• el impacto de los errores de software en la protección y sistema de seguridad;
• evaluación de la potencia informática y las limitaciones de tiempo;
• disponibilidad de programas implementados por medios técnicos;
• Disponibilidad de ordenadores adecuados.

Si un sistema incluye muchos subsistemas o elementos de configuración, deben estar completamente cubiertos por el trabajo a nivel de sistema del proceso de desarrollo. Se deben tener en cuenta todos los requisitos para las interfaces y el montaje (integración) de sistemas. Para un sistema pequeño, una secuencia tan estricta de acciones puede no ser necesaria".

La redacción aproximada y vaga del pasaje anterior es característica de toda la norma en su conjunto.

La parte central del brevísimo apartado 7 “Aplicación en las organizaciones” es el siguiente texto.

"7.2. Posibilidades de aplicación

Las razones por las que GOST R ISO/IEC 12207 se implementa en las organizaciones pueden ser las siguientes:

• comprobar la perfección de un método existente. Este suele ser el caso cuando el método fue desarrollado por la propia organización o seleccionó y modificó un método existente;
• aplicación práctica de este método para prevenir el riesgo asociado con la entrada a nuevos sectores del mercado con requisitos más estrictos asociados con el riesgo potencial;
• desarrollar un nuevo método, por ejemplo para satisfacer las necesidades de una nueva organización. Pueden estar cubiertas las organizaciones creadas mediante una fusión o colaboración empresarial. Esto puede ser necesario para respaldar algunos modelos de procesos para proporcionar un trabajo específico;
• Gestionar la implementación de nuevas tecnologías, como la automatización de procesos manuales o el cambio de los métodos utilizados para implementar un producto de software. GOST R ISO/IEC 12207 establece criterios que pueden usarse para monitorear la excelencia del método relevante antes o después de un cambio en la tecnología;
• evaluación de las capacidades internas de la parte en términos de cumplimiento de los criterios del contrato, por ejemplo, como parte que participa en el proceso competitivo (licitación);
• identificar hitos que pueden conducir al desarrollo de programas más avanzados, como la auditoría de acuerdo con GOST R ISO/IEC 12207 y el uso del proceso de mejora en sí".

Incluso en ausencia total de objeciones de fondo, sigue siendo imposible considerar este texto como una norma. Sobre todo, se parece a un manual de capacitación y probablemente tendrá demanda como tal, pero dicho texto no puede usarse como guía de acción al implementar GOST R ISO/IEC 12207 en una organización.

Finalmente, la sección 8 "Solicitud modelos de ciclo de vida sistemas" contiene definiciones bastante vagas" modelos de ciclo de vida sistemas" y " modelos de ciclo de vida software" e intenta establecer una correspondencia entre ellos. Dado que no existen definiciones precisas, es imposible juzgar los resultados.

En general, el estándar GOST R ISO/IEC 15271 da la impresión de ser un documento puramente auxiliar en relación con GOST R ISO/IEC 12207, adoleciendo de aproximación y una gran cantidad de lugares comunes. No es adecuado para administradores prácticos: hay demasiado razonamiento abstracto y muy poca especificidad. Para los estudiantes y especialistas que estudian los procesos de gestión de TI, carece de una visión amplia del tema (después de todo, está limitado por GOST R ISO/IEC 12207) y está sobrecargado de detalles técnicos innecesarios. Sin embargo, el conocimiento de GOST R ISO/IEC 15271 es útil, ya que muestra la dirección del pensamiento de los especialistas en el campo de la gestión de TI y demuestra dónde y cómo se desarrollan los estándares modernos. Lo consideraría un documento de trabajo provisional, aunque en forma de norma, pero destinado más bien al debate entre una audiencia interesada de especialistas en gestión de TI.

Estándar GOST R ISO/IEC 16326

Otro intento de formalizar el proceso de aplicación de GOST R ISO/IEC 12207 se realizó en la norma GOST R ISO/IEC 16326 “Directrices para el uso de GOST R ISO/IEC 12207 en la gestión de proyectos” (GOST 16326, 2002). Demuestra un intento de unir procesos del ciclo de vida de GOST R ISO/IEC 12207 con procesos de gestión de proyectos del popular libro de referencia metodológico PMBOK 1 PMBOK - Fundamentos de gestión de proyectos(PMBOK, 2009) y la norma ISO 10006 (la versión rusa de la norma está contenida en (GOST 10006, 2005)). Esto se muestra esquemáticamente en la Fig. 4.1 dado en la norma.

Arroz. 4.1.

La gama de usuarios de la norma se define con bastante precisión en la sección 1.1.

"1.1. Rango de usuarios

Este estándar está destinado a entidades que utilizan o planean utilizar GOST R ISO/IEC 12207 en proyectos de software, independientemente de su alcance, productos creados, metodología, volumen o complejidad. El estándar está destinado principalmente a administradores de proyectos responsables del cumplimiento de los procesos de gestión con GOST R ISO/IEC 12207:

• administradores responsables de la organización y la mejora continua procesos del ciclo de vida software según GOST R ISO/IEC 12207;
• administradores responsables de la aplicación procesos del ciclo de vida software según GOST R ISO/IEC/12207 a nivel de diseño;
• organizaciones o personas que son subcontratistas en la implementación de CPS ( Gestión de proyectos de software. -AB).

Las consideraciones para individuos incluyen:

• involucrado en proyectos de software, pero no AP ( Administradores de Proyectos. -AB);
• que son administradores de proyectos no software, pero asociados con software AP."

El texto principal relativamente breve (la sección 6 "Guía" ocupa sólo 9 páginas de un total de 35) es un comentario secuencial sobre el proceso 7.1 "Gestión" de GOST R ISO/IEC 12207 desde el punto de vista del PMBOK. El estilo del comentario es informal, los argumentos son en su mayoría de naturaleza consultiva. El comentario no va más allá del sentido común y no contiene nada nuevo. En general, esta es una lectura útil para los directores de proyectos (en la terminología de los traductores, "administradores"), pero nada más.

El Apéndice A es una tabla grande que muestra las conexiones entre los procesos principales de GOST R ISO/IEC 12207 y las actividades del proceso de "Gestión" llamado desde ellos. Todos estos enlaces están contenidos en el cuerpo del estándar GOST R ISO/IEC 12207; combinarlos en una tabla no agrega ninguna información nueva.

El Apéndice B es exactamente la misma tabla que vincula las áreas de proceso y los procesos individuales del PMBOK con las actividades del proceso de "Gestión" de GOST R ISO/IEC 12207.

En el Apéndice C se proporciona una tabla similar, donde se utilizan grupos de procesos en el sentido del PMBOK en lugar de áreas. Los Apéndices B y C en realidad resumen todo lo que se dijo en la sección 6 de la norma. No está claro por qué fue necesario presentar esto en forma de tablas. Estas tablas no proporcionan ninguna información adicional, lo que demuestra sólo el hecho de que existen conexiones entre el PMBOK y GOST R ISO/IEC 12207. Sin embargo, el estado de ambos Anexos es "referencia", por lo que es posible que no hayan tenido ningún valor independiente.

Otra tabla resumen se presenta en el Apéndice D. Muestra las relaciones entre tres fuentes: GOST R ISO/IEC 12207, PMBOK y el estándar ISO 10006. Observo de inmediato que este último se tradujo al ruso recién en 2005; como consecuencia, la terminología utilizada en el Anexo D de la norma GOST R ISO/IEC 16326 2002 difiere de la anterior. Como en casos anteriores, el significado de presentar estas relaciones en forma tabular compacta no está claro. Además, el volumen total de los Apéndices A-D excede en más del doble el volumen de la sección principal 6 “Manual”.

En mi opinión, GOST R ISO/IEC 16326-2002 no difiere en forma y propósito de GOST R ISO/IEC 15271-2002. Ambos adolecen de un exceso de razonamiento correcto “en general” y basado únicamente en el sentido común. Estos argumentos son obvios para cualquiera que tenga experiencia práctica en gestión de proyectos y difícilmente parecen razonables para quienes no la tienen. A diferencia de GOST R ISO/IEC 15271-2002, el estándar GOST R ISO/IEC 16326-2002 es más formal, pero el significado práctico del formalismo propuesto no está claro.

Desde el punto de vista de la aplicación práctica en el diseño de procesos de negocio relacionados con TI, ambos estándares son en gran medida inútiles. Por otro lado, pueden tener demanda al implementar proyectos complejos que incluyen, junto con un estudio de las prácticas de gestión de TI, un análisis de la gestión de proyectos y gestión de la calidad.

Además de los discutidos anteriormente, GOST R ISO/IEC 12207 ha dado lugar a una serie de estándares que detallan los contenidos en él. procesos del ciclo de vida. Estos incluyen, por ejemplo, GOST R ISO/IEC 15910-2002 "El proceso de creación de documentación de usuario para software" (GOST 15910, 2002) y GOST R ISO/IEC 14764-2002 "Mantenimiento de software" (GOST 14764, 2002) . Algunas normas ISO similares aún no se han traducido al ruso; Es probable que en el futuro aumente el número de normas GOST R ISO en ruso directamente relacionadas con GOST R ISO/IEC 12207.

Línea base según GOST R ISO/IEC 12207-2010

o, que han sido revisados ​​​​formalmente y posteriormente sirven como base para un mayor desarrollo, y que solo pueden modificarse mediante cambios oficiales y controlados [de la cláusula 4.6 de GOST R ISO/IEC 12207-2010]

Validación según GOST R ISO/IEC 12207-2010

Confirmación (basada en la presentación de evidencia objetiva) de que se ha llevado a cabo la finalidad o aplicación prevista. Nota: La validación en contexto es un conjunto de acciones que garantizan y brindan confianza de que es capaz de realizar su propósito, actual y futuro [de la cláusula 4.54 de GOST R ISO/IEC 12207-2010]

Verificación según GOST R ISO/IEC 12207-2010

Confirmación (basada en el suministro de evidencia objetiva) de que los requisitos especificados se han cumplido en su totalidad. NOTA La verificación en contexto es un conjunto de acciones que compara un resultado del ciclo de vida con las características requeridas para ese resultado. Los resultados del ciclo de vida pueden ser (pero no se limitan a) requisitos especificados, descripción y directamente [de la cláusula 4.55 de GOST R ISO/IEC 12207-2010]

Garantía de calidad según GOST R ISO/IEC 12207-2010

Todas las actividades planificadas y sistemáticas llevadas a cabo dentro del marco y demostradas de manera adecuada para brindar la confianza adecuada de que el cliente está completamente satisfecho. Notas:

1. Existen garantías de calidad tanto internas como externas:
   1. aseguramiento interno de la calidad: dentro de los límites del aseguramiento de la calidad brinda confianza;
   2. Aseguramiento de Calidad Externo: En situaciones contractuales, el aseguramiento de calidad brinda confianza a otros.
2. Algunas actividades de garantía de calidad y garantía de calidad están interrelacionadas.
3. A menos que los requisitos de calidad satisfagan plenamente las necesidades, el aseguramiento de la calidad no puede proporcionar la garantía necesaria.

[de la cláusula 4.34 GOST R ISO/IEC 12207-2010]

5.2.2 Resumen de los procesos del ciclo de vida

Hay dos divisiones de procesos importantes en esta norma. La Sección 6 proporciona el contexto del sistema para operar un producto o servicio de software independiente, o un sistema de software. La Sección 7 contiene procesos de software específicos para su uso en la implementación de un producto o servicio de software que es algún elemento de un sistema más grande.

Para ayudar en el uso simultáneo de esta Norma Internacional, los procesos correspondientes de la Cláusula 6 reciben las mismas designaciones de subcláusula.

En general, el conjunto de procesos presentados en esta norma se adapta al software o insumos a los resultados de los procesos previstos. Muchos procesos son similares a las implementaciones de procesos específicos de software, pero conservan diferencias importantes basadas en objetivos, resultados y audiencias. Los usuarios tanto de este estándar como de este estándar deben asegurarse de revisar las explicaciones y notas de cada proceso específico.

Los procesos de acuerdos definen las actividades necesarias para desarrollar acuerdos entre dos organizaciones. Si se implementa un proceso de adquisición, proporciona los medios para realizar negocios con el proveedor de los productos proporcionados para su uso en el sistema operativo, servicios de soporte del sistema o elementos del sistema desarrollados como parte del proyecto. Si se implementa un proceso de entrega, proporciona los medios para llevar a cabo un proyecto en el que el resultado es un producto o servicio entregado a la parte adquirente.

Por lo tanto, los procesos de acuerdo dados en este estándar están dirigidos a procesos de acuerdo de software de .

Los procesos de soporte de proyectos organizacionales gestionan la capacidad de las organizaciones para adquirir y entregar productos o servicios a través del inicio, el soporte y la gestión del proyecto. Estos procesos proporcionan los recursos y la infraestructura necesarios para respaldar los proyectos y garantizar que se cumplan los objetivos organizacionales y los acuerdos establecidos. No pretenden ser un conjunto completo de procesos comerciales que implementan la gestión de las actividades comerciales de una organización.

Los procesos de apoyo organizacional del proyecto incluyen:

a) proceso de gestión del modelo de ciclo de vida;

B) proceso de gestión de infraestructura;

c) proceso de gestión de la cartera de proyectos;

d) proceso de gestión de recursos humanos;

e) proceso de gestión de la calidad.

En general, los procesos de soporte organizacional de proyectos previstos en esta norma son procesos enfocados al software del correspondiente conjunto de procesos en .

En esta norma se elige el proyecto como base para describir los procesos relacionados con la planificación, evaluación y control. Los principios asociados a estos procesos se pueden aplicar a cualquier área de la gestión organizacional.

Hay dos categorías de procesos de proyecto. Los procesos de gestión de proyectos se utilizan para planificar, ejecutar, evaluar y gestionar el progreso de un proyecto. Los procesos de apoyo al proyecto garantizan que se cumplan los objetivos de gestión especializados. Ambas categorías de procesos de proyecto se describen a continuación.

Los procesos de gestión de proyectos se utilizan para crear y desarrollar planes de proyectos, evaluar el progreso real y el progreso con respecto a los planes y gestionar el progreso del proyecto hasta su finalización. Los procesos de gestión de proyectos individuales se pueden invocar en cualquier momento del ciclo de vida y en cualquier nivel de la jerarquía del proyecto en respuesta a los planes del proyecto o la ocurrencia de eventos imprevistos. Los procesos de gestión de proyectos se aplican con un nivel de rigor y formalización dependiendo del riesgo y complejidad del proyecto:

a) proceso de planificación del proyecto;

b) el proceso de gestión y evaluación del proyecto.

Los procesos de apoyo al proyecto forman un conjunto específico de tareas destinadas a lograr objetivos de gestión específicos. Todos estos procesos son obvios en la gestión de cualquier actividad iniciada, descendiendo desde la organización en su conjunto hasta un proceso separado del ciclo de vida y sus tareas:

a) proceso de gestión de decisiones;

b) proceso de gestión de riesgos;

c) proceso de gestión de la configuración;

d) proceso de gestión de la información;

e) proceso de medición.

En general, los procesos de soporte de proyectos presentados en esta norma son idénticos a los procesos de soporte de proyectos dados en , con la excepción de algunas diferencias en la forma de su presentación. En algunos casos, los procesos de soporte de software pueden tener relaciones con los procesos de soporte de proyectos.

Los procesos técnicos se utilizan para definir los requisitos del sistema, transformar los requisitos en un producto útil, permitir la copia continua del producto (cuando sea necesario), aplicar el producto, proporcionar los servicios requeridos, mantener la prestación de esos servicios y retirar el producto de la circulación cuando no se utiliza en la prestación del servicio.

Los procesos técnicos definen las actividades que permiten implementar funciones organizativas y de diseño para optimizar los beneficios y reducir los riesgos resultantes de las decisiones y acciones técnicas. Estas actividades permiten que los productos y servicios tengan las características de puntualidad y disponibilidad, rentabilidad, funcionalidad, confiabilidad, mantenibilidad, productividad, adaptabilidad y otras características de calidad requeridas por las organizaciones adquirentes y de soporte. También permite que los productos y servicios cumplan con las expectativas o requisitos del derecho civil, incluidos factores de salud, seguridad y ambientales.

Los procesos técnicos constan de los siguientes procesos:

a) determinar los requisitos de los titulares de derechos (un caso especial del proceso de determinación de los requisitos de los titulares de derechos indicado en);

b) análisis de requisitos del sistema (un caso especial del proceso de análisis de requisitos);

C) diseño de la arquitectura del sistema (un caso especial del proceso de diseño de la arquitectura indicado en);

D) proceso de implementación (un caso especial del proceso de implementación de elementos del sistema dado y desarrollado más detalladamente en la Sección 7 de esta norma como proceso de implementación de software);

e) el proceso de integración del sistema (un caso especial del proceso de integración indicado en);

f) el proceso de prueba de calificación del sistema (un proceso que contribuye a lograr los resultados del proceso de verificación dado en );

G) el proceso de instalación del software (el proceso que contribuye a lograr los resultados del proceso de transferencia descrito en);

H) proceso de soporte de aceptación de software (el proceso que contribuye al logro de los resultados del proceso de transferencia descrito en );

i) el proceso de operación del software (un caso especial del proceso de operación indicado en);

j) proceso de mantenimiento del software (un caso especial del proceso de mantenimiento indicado en );

k) el proceso de retirada del software de la circulación (un caso especial del proceso de retirada y cancelación indicado en).

En general, los procesos técnicos presentados en esta norma son casos especiales orientados al software o contribuciones a los resultados de los procesos técnicos presentados en . La mayoría de ellos son similares a los procesos de implementación de software, pero conservan diferencias importantes; por ejemplo, el análisis de requisitos del sistema y el análisis de requisitos de software parten de diferentes posiciones iniciales y tienen diferentes propósitos.

Los procesos de implementación de software se utilizan para crear un elemento (componente) del sistema específico en forma de herramienta de software. Estos procesos transforman comportamientos, interfaces y restricciones de implementación específicos en acciones que dan como resultado un elemento del sistema que satisface los requisitos derivados de los requisitos del sistema.

Un proceso especial es el proceso de implementación de software, que expresa una característica específica del software del proceso de implementación indicado en.

El proceso de implementación del software incluye varios procesos especiales de nivel inferior:

a) el proceso de análisis de los requisitos de software;

B) proceso de diseño de arquitectura de software;

c) proceso detallado de diseño de software;

d) proceso de diseño de software;

e) proceso de integración de software;

f) proceso de prueba de calificación del software.

Los procesos de soporte de software proporcionan un conjunto de actividades específicamente enfocadas destinadas a ejecutar un proceso de software especializado. Cualquier proceso de soporte ayuda al proceso de implementación del software en su conjunto con un propósito distinto, contribuyendo al éxito y la calidad del proyecto de software. Hay ocho procesos de este tipo:

a) proceso de gestión de la documentación del software;

b) proceso de gestión de la configuración del software;

c) proceso de garantía de calidad del software;

d) proceso de verificación del software;

e) proceso de validación del software;

f) proceso de auditoría de software;

g) proceso de auditoría de software;

H) el proceso de resolución de problemas en software.

El grupo de procesos de reutilización de software consta de tres procesos que respaldan la capacidad de una organización para reutilizar componentes de software a través de los límites del proyecto. Estos procesos son únicos porque, por su naturaleza, se utilizan fuera de los límites de cualquier proyecto específico.

Los procesos de reutilización de software son:

a) proceso de diseño de dominio;

b) proceso de gestión de reutilización de activos;

C) el proceso de gestión de la reutilización de programas.

1) Le permite implementar cualquier modelo de ciclo de vida.- esto es posible, porque El estándar proporciona una forma de definir el orden de ejecución de procesos y tareas, en el que un proceso puede llamar a otro proceso o partes de él.

2) Proporciona la máxima flexibilidad– muchos procesos y tareas están diseñados de tal manera que puedan adaptarse de acuerdo con proyectos de SI específicos. La adaptación se reduce a eliminar procesos, actividades y tareas que no son aplicables a un proyecto específico.

3) La norma no contiene fundamentalmente una descripción de métodos de acción específicos., especialmente espacios en blanco, soluciones o documentación, solo describe la arquitectura de los procesos del ciclo de vida del software, pero no especifica en detalle cómo realizar o implementar las tareas incluidas en los procesos.

4) El estándar contiene muy pocas descripciones sobre el diseño de bases de datos.- esto está justificado, porque diferentes SI y diferentes sistemas de software no sólo pueden usar tipos específicos de bases de datos, sino que tampoco pueden usar bases de datos en absoluto.

5) El valor de la norma es que contiene conjuntos de tareas, características de calidad, criterios de evaluación, etc., brindando una cobertura integral de soluciones de diseño.

6) Aunque la norma no prescribe el uso de un modelo de ciclo de vida específico o método de desarrollo, sí determina que las partes del proyecto son responsables de lo siguiente:

selección de un modelo de ciclo de vida para el proyecto que se está desarrollando;

adaptación de procesos y tareas de la norma al modelo seleccionado;

selección y aplicación de métodos de desarrollo de software;

Realizar actividades y tareas propias de un proyecto de software determinado.

GOST 34 estándares complejos.

Fue concebido como un conjunto integral de documentos intersectoriales interconectados.

Objetos de estandarización: sistemas automatizados de diversos tipos y todo tipo de sus componentes.

Los estándares GOST establecen etapas y fases de trabajo para crear un sistema automatizado, pero no prevén explícitamente procesos de un extremo a otro que tienen lugar durante la implementación del ciclo de vida.

Según GOST, el desarrollo de un sistema automatizado se divide en los siguientes pasos y etapas:

Nivel 1 formación de requisitos para los oradores:

Etapa a: inspección de la instalación y justificación de la necesidad de desarrollar un sistema automatizado;

Etapa b: formación de los requisitos del cliente para un sistema automatizado;

Etapa c: elaboración de un informe sobre el trabajo realizado y elaboración de una solicitud para el desarrollo de especificaciones técnicas.

Etapa 2 desarrollo de conceptos:

a: estudio del objeto;

b: realizar las investigaciones necesarias;

c: desarrollo de opciones para el concepto de central nuclear que cumpla con los requisitos del cliente;

d: elaboración de un informe sobre el trabajo realizado.

Etapa 3 desarrollo y aprobación de especificaciones técnicas para la creación de centrales nucleares..

Etapa 4 desarrollo de un diseño preliminar de la central nuclear:

a: desarrollo de soluciones de diseño preliminares para todo el sistema en su conjunto y para sus componentes individuales;

b: desarrollo de documentación.

Etapa 5 desarrollo de proyectos tecnicos:

a: desarrollo de soluciones de diseño para todo el sistema y sus partes;

b: desarrollo de documentación para el sistema automatizado y subsistemas incluidos en el mismo;

c: desarrollo y ejecución de documentación para el suministro de productos para la finalización de centrales nucleares o desarrollo y ejecución de requisitos técnicos para el desarrollo de estos productos.

Etapa 6 desarrollo de documentacion tecnica:

a: desarrollo de documentación de trabajo para la parte del sistema;

b: desarrollo o adaptación de software.

Etapa 7poner en funcionamiento el sistema desarrollado:

a: preparar el objeto de automatización para la implementación de AS;

b: formación del personal;

c: equipar los altavoces con software y hardware;

d: trabajos de instalación;

d: puesta en servicio;

e: pruebas preliminares;

g: operación de prueba;

h: pruebas de aceptación.

Etapa 8 escolta:

a: realización del trabajo de acuerdo con las obligaciones de garantía;

b: servicio posgarantía.