Descripción del ciclo de vida del programa de un módulo de programa. Ciclo de vida del software (Ciclo de vida del software)

Arroz. 5.2.

Estos aspectos son:

aspecto contractual en el que el cliente y el proveedor celebran relación contractual e implementar procesos de adquisición y suministro;
aspecto de gestión, que incluye las acciones de gestión de las personas que participan en el ciclo de vida del software (proveedor, cliente, desarrollador, operador, etc.);
el aspecto de operación, que incluye las acciones del operador para brindar servicios a los usuarios del sistema;
un aspecto de ingeniería que contiene las acciones del desarrollador o mantenedor de la solución tareas tecnicas asociado con el desarrollo o modificación de productos de software;
aspecto del soporte relacionado con la implementación de procesos de soporte mediante los cuales las mesas de ayuda brindan servicios necesarios a todos los demás participantes en el trabajo. En este aspecto, se puede destacar el aspecto de la gestión de la calidad del software, incluidos los procesos de aseguramiento de la calidad, verificación, certificación, evaluación conjunta y auditoría.

Los procesos organizacionales se realizan a nivel corporativo o a nivel de toda la organización como un todo, sentando las bases para la implementación y mejora continua de los procesos del ciclo de vida del software.

5.6. Modelos y etapas del ciclo de vida del software

El modelo de ciclo de vida del software se entiende como una estructura que determina la secuencia de ejecución y la relación de procesos, acciones y tareas a lo largo del ciclo de vida del software. El modelo de ciclo de vida depende de los detalles, la escala y la complejidad del proyecto y las condiciones específicas en las que se crea y opera el sistema.

La norma ISO/IEC 12207 no propone un modelo de ciclo de vida específico ni métodos de desarrollo de software. Sus disposiciones son comunes a cualquier modelo de ciclo de vida, métodos y tecnologías de desarrollo de software. El estándar describe la estructura de los procesos del ciclo de vida del software, pero no especifica cómo implementar o realizar las actividades y tareas incluidas en estos procesos.

El modelo de ciclo de vida de cualquier software específico determina la naturaleza del proceso de su creación, que es un conjunto de trabajos ordenados en el tiempo, interconectados y unidos en etapas (fases), cuya implementación es necesaria y suficiente para crear un software que cumpla los requisitos especificados.

La etapa (fase) de creación de software se entiende como parte del proceso de creación de software, limitada por un marco de tiempo y que finaliza con el lanzamiento de un producto específico (modelos de software, componentes de software, documentación, etc.), determinado por los requisitos especificados. para esta etapa. Las etapas de la creación de software se distinguen por razones de planificación racional y organización del trabajo, finalizando con los resultados especificados. El ciclo de vida del software generalmente incluye las siguientes etapas:

formación de requisitos de software;
diseño (desarrollo de un proyecto de sistema);
implementación (se puede dividir en sub-pasos: diseño detallado, codificación);
pruebas (se pueden dividir en pruebas e integración independientes y complejas);
puesta en marcha (implementación);
operación y mantenimiento;
desmantelamiento

Algunos expertos introducen una etapa inicial adicional: estudio de factibilidad sistemas Esto se refiere al sistema de software y hardware para el cual se crea, compra o modifica el software.

La etapa de formación de requisitos de software es una de las más importantes y determina en gran medida (¡incluso decisiva!) el éxito de todo el proyecto. El inicio de esta etapa es la recepción de una arquitectura de sistema homologada y homologada con la inclusión de acuerdos básicos sobre la distribución de funciones entre hardware y software. Este documento también debe contener una confirmación de la idea general del funcionamiento del software, incluidos los principales acuerdos sobre la distribución de funciones entre la persona y el sistema.

La etapa de formación de requisitos de software incluye las siguientes etapas.

Planificación del trabajo antes del proyecto. Las principales tareas de la etapa son la definición de objetivos de desarrollo, preliminar evaluación económica proyecto, construyendo un cronograma de trabajo, creando y capacitando un grupo de trabajo conjunto.
Realización de una encuesta de las actividades de una organización automatizada (objeto), en cuyo marco se lleva a cabo una identificación preliminar de los requisitos para el futuro sistema, determinando la estructura de la organización, determinando la lista de funciones objetivo de la organización, analizando la distribución de funciones por departamentos y empleados, identificando interacciones funcionales entre departamentos, flujos de información dentro de los departamentos y entre ellos, objetos externos a la organización e influencias de información externa, análisis de los medios existentes para automatizar las actividades de la organización.

Construcción de un modelo de la actividad de una organización (objeto), que prevé el procesamiento de materiales de encuesta y la construcción de dos tipos de modelos:

Modelo "TAL CUAL" ("tal como está"), que refleja el estado actual de las cosas en la organización en el momento de la encuesta y le permite comprender cómo esta organización, así como identificar cuellos de botella y formular propuestas para mejorar la situación;
Modelo "TO-BE" ("como debería ser"), que refleja la idea de las nuevas tecnologías del trabajo de la organización.

Cada uno de los modelos debe incluir un modelo funcional e informativo completo de las actividades de la organización, así como (si es necesario) un modelo que describa la dinámica del comportamiento de la organización. Tenga en cuenta que los modelos construidos tienen una importancia práctica independiente, independientemente de si la empresa desarrolla e implementa un sistema de información, ya que pueden usarse para capacitar a los empleados y mejorar los procesos comerciales de la empresa.

El resultado de la finalización de la etapa de formación de requisitos de software son las especificaciones de software, las especificaciones funcionales, técnicas y de interfaz, por lo que se confirma su completitud, verificabilidad y factibilidad.

La etapa de diseño incluye los siguientes pasos.

Desarrollo de un proyecto de sistema de software. En esta etapa se da la respuesta a la pregunta "¿Qué debe hacer el futuro sistema?", a saber: la arquitectura del sistema, sus funciones, Condiciones externas funcionamiento, interfaces y distribución de funciones entre los usuarios y el sistema, requerimientos de software y componentes de información, personal y tiempo de desarrollo, plan de depuración de software y control de calidad.

La base del proyecto del sistema son los modelos del sistema diseñado, que se construyen sobre el modelo "TO-BE". El resultado del desarrollo de un proyecto de sistema debe ser una especificación aprobada y confirmada de los requisitos del software: especificaciones funcionales, técnicas y de interfaz, para lo cual se confirma su integridad, verificabilidad y viabilidad.
Desarrollo de un proyecto (técnico) detallado. En esta etapa, se lleva a cabo el diseño del software real, incluido el diseño de la arquitectura del sistema y el diseño detallado. Por lo tanto, se da la respuesta a la pregunta: "¿Cómo construir un sistema para que satisfaga los requisitos?"

El resultado del diseño detallado es el desarrollo de una especificación de software verificada, que incluye:

formación de una jerarquía de componentes de software, interfaces entre módulos para datos y control;
especificación de cada componente de software, nombre, propósito, suposiciones, tamaños, secuencia de llamadas, datos de entrada y salida, erróneos salidas, algoritmos y circuitos lógicos;
formación de estructuras de datos físicos y lógicos hasta el nivel de campos individuales;
elaboración de un plan de distribución de recursos informáticos (tiempo de procesadores centrales, memoria, etc.);
verificación de la integridad, consistencia, factibilidad y validez de los requisitos;
plan preliminar de integración y depuración, guía de usuario y plan de pruebas de aceptación.

La finalización de la etapa de diseño detallado es el punto final

Tema: Modelos clásicos y flexibles de LCPP: definición, descripción, rasgos distintivos, secuencia de etapas. Métodos para elegir un modelo de ZhCPP en el desarrollo de software en diversas áreas temáticas.

Fuente de información https://www.intuit.ru/studies/courses/3632/874/print_lecture/14297

Modelos y etapas del ciclo de vida del software

formación de requisitos de software;
diseño (desarrollo de un proyecto de sistema);
implementación (se puede dividir en sub-pasos: diseño detallado, codificación);
pruebas (se pueden dividir en pruebas e integración independientes y complejas);
puesta en marcha (implementación);
operación y mantenimiento;
desmantelamiento

Algunos expertos introducen una etapa inicial adicional: estudio de factibilidad sistemas Esto se refiere al sistema de software y hardware para el cual se crea, compra o modifica el software.

La etapa de formación de requisitos de software incluye las siguientes etapas.

Planificación del trabajo antes del proyecto. Las tareas principales de la etapa son la definición de objetivos de desarrollo, una evaluación económica preliminar del proyecto, la construcción de un cronograma de trabajo, la creación y capacitación de un grupo de trabajo conjunto.
Realización de una encuesta de las actividades de una organización automatizada (objeto), en cuyo marco se lleva a cabo una identificación preliminar de los requisitos para el futuro sistema, determinando la estructura de la organización, determinando la lista de funciones objetivo de la organización, analizando la distribución de funciones por departamentos y empleados, identificando interacciones funcionales entre departamentos, flujos de información dentro de los departamentos y entre ellos, objetos externos a la organización e influencias de información externa, análisis de los medios existentes para automatizar las actividades de la organización.

Construcción de un modelo de la actividad de una organización (objeto), que prevé el procesamiento de materiales de encuesta y la construcción de dos tipos de modelos:

un modelo "AS-IS" ("tal cual") que refleja el estado actual de la organización en el momento de la encuesta y le permite comprender cómo funciona la organización, así como identificar cuellos de botella y formular propuestas para mejorar la situación;
Modelo "TO-BE" ("como debería ser"), que refleja la idea de las nuevas tecnologías del trabajo de la organización.

La etapa de diseño incluye los siguientes pasos.

Desarrollo de un proyecto de sistema de software. En esta etapa, se da la respuesta a la pregunta "¿Qué debe hacer el futuro sistema?", a saber: la arquitectura del sistema, sus funciones, condiciones externas de operación, interfaces y distribución de funciones entre los usuarios y el sistema, requisitos para Se determinan componentes de software e información, composición de ejecutantes y plazos de desarrollo, plan de depuración de software y control de calidad.

La base del proyecto del sistema son los modelos del sistema diseñado, que se construyen sobre el modelo "TO-BE". El resultado del desarrollo de un proyecto de sistema debe ser una especificación aprobada y confirmada de los requisitos del software: especificaciones funcionales, técnicas y de interfaz, para lo cual se confirma su integridad, verificabilidad y viabilidad.
Desarrollo de un proyecto (técnico) detallado. En esta etapa, se lleva a cabo el diseño del software real, incluido el diseño de la arquitectura del sistema y el diseño detallado. Por lo tanto, se da la respuesta a la pregunta: "¿Cómo construir un sistema para que satisfaga los requisitos?"

El resultado del diseño detallado es el desarrollo de una especificación de software verificada, que incluye:

formación de una jerarquía de componentes de software, interfaces entre módulos para datos y control;
especificación de cada componente de software, nombre, propósito, suposiciones, tamaños, secuencia de llamadas, datos de entrada y salida, erróneos salidas, algoritmos y circuitos lógicos;
formación de estructuras de datos físicos y lógicos hasta el nivel de campos individuales;
elaboración de un plan de distribución de recursos informáticos (tiempo de procesadores centrales, memoria, etc.);
verificación de la integridad, consistencia, factibilidad y validez de los requisitos;
plan preliminar de integración y depuración, guía de usuario y plan de pruebas de aceptación.

La culminación de la etapa de diseño detallado es el control de punta a punta del proyecto o análisis de bloques críticos del proyecto.

Etapa de implementación – ejecución de las siguientes obras.

Desarrollo de una especificación detallada verificada para cada subrutina (un bloque de no más de 100 comandos fuente de un lenguaje de alto nivel).

Las especificaciones externas deben contener la siguiente información:
- nombre del módulo: se indica el nombre utilizado para llamar al módulo (para un módulo con varias entradas, debe haber especificaciones separadas para cada entrada);
- función - define la función o funciones realizadas por el módulo;
- lista de parámetros (número y orden) pasados al módulo;
- parámetros de entrada: una descripción exacta de todos los datos devueltos por el módulo (se debe determinar el comportamiento del módulo bajo cualquier condición de entrada);
- efectos externos (impresión de un mensaje, lectura de una petición del terminal, etc.).
Diseño de lógica de módulos y programación de módulos (codificación).
Comprobación de la corrección de los módulos.
Pruebas de módulos.
Descripción de la base de datos hasta el nivel de parámetros individuales, símbolos y bits.
Plan de pruebas de aceptación.
Guía del usuario.
Plan preliminar de integración y depuración. El contenido de las etapas posteriores coincide básicamente con los procesos correspondientes del ciclo de vida del software. En general etapas tecnológicas asignados sobre la base de consideraciones de planificación y organización del trabajo razonables y racionales. En la figura se muestra una posible variante de la relación y etapas de trabajo con los procesos del ciclo de vida del software.

Arroz. una.

Tipos de modelos de ciclo de vida del software

Modelo de cascada (ciclo de vida clásico)

Este modelo debe su aparición a W. Royce (1970). El modelo tiene otro nombre: una cascada (cascada). La peculiaridad del modelo es que la transición a la siguiente etapa se lleva a cabo solo después de que el trabajo en la etapa anterior se haya completado por completo; No se proporcionan devoluciones a etapas completadas.

Arroz. 2.

Los requisitos para el PS desarrollado, determinados en las etapas de formación y análisis, están estrictamente documentados en forma de TOR y se fijan durante toda la duración del desarrollo del proyecto. Cada etapa finaliza con el lanzamiento de un conjunto completo de documentación (TOR, EP, TP, RP), suficiente para que otro equipo de desarrollo continúe con el desarrollo. El criterio de calidad del desarrollo con este enfoque es la precisión en el cumplimiento de las especificaciones de los TOR. Los desarrolladores se enfocan en lograr valores óptimos especificaciones PS desarrollado: rendimiento, cantidad de memoria ocupada, etc.

Ventajas modelo de cascada:

en cada etapa, se forma un conjunto completo de documentación del proyecto que cumple con los criterios de integridad y consistencia;
las etapas del trabajo realizado en una secuencia lógica le permiten planificar el momento de la finalización de todo el trabajo y los costos correspondientes.

El enfoque en cascada ha demostrado su eficacia en la construcción de PS, para los cuales todos los requisitos se pueden formular completa y claramente desde el comienzo del proyecto. Mientras todo esto esté controlado por normas y varias comisiones estatales de aceptación, el esquema funciona bien.

Defectos modelo de cascada:

la identificación y eliminación de errores se lleva a cabo solo en la etapa de prueba, que puede extenderse significativamente;
los proyectos reales a menudo requieren una desviación de la secuencia estándar de pasos;
el ciclo se basa en la formulación exacta de los requisitos iniciales para el PS, en realidad, al comienzo del proyecto, los requisitos del cliente están definidos solo parcialmente;
los resultados del trabajo están disponibles para el cliente solo después de la finalización del proyecto.

Modelo iterativo del ciclo de vida de PS

Con el crecimiento de los proyectos comerciales, quedó claro que no siempre es posible elaborar el diseño del futuro sistema en detalle, ya que muchos aspectos de su funcionamiento en áreas dinámicas de actividad (negocio) cambian mientras se crea el sistema. Fue necesario cambiar el proceso de desarrollo para garantizar que se hicieran las correcciones necesarias después de completar cualquier etapa de desarrollo. Así apareció el modelo iterativo del ciclo de vida del PS, denominado modelo con control intermedio o modelo con repetición cíclica de fases.

Arroz. 3.

En un modelo iterativo, las deficiencias de diseño y programación pueden eliminarse posteriormente volviendo parcialmente a la etapa anterior. Cuanto menor sea la tasa de detección de errores, más caro será solucionarlo. Si el costo de los esfuerzos requeridos para detectar y eliminar errores en la etapa de escribir el código se toma como uno, entonces el costo de identificar y eliminar un error en la etapa de requisitos será de 5 a 10 veces menor, y el costo de identificar y eliminar eliminar un error en la etapa de mantenimiento será 20 veces menos.

Arroz. cuatro

En tal situación, la etapa de formulación de requisitos, redacción de especificaciones y creación de un plan de sistema es de gran importancia. Los arquitectos de software son personalmente responsables de todos los cambios posteriores a las decisiones de diseño. El volumen de documentación asciende a miles de páginas, el número de reuniones de aprobación es enorme. Muchos proyectos nunca abandonan la etapa de planificación, cayendo en la parálisis de análisis. Uno de formas posibles Las excepciones a tales situaciones son el protoboarding (creación de prototipos).

Prototipos

A menudo, el cliente no puede formular requisitos para la entrada, el procesamiento o la salida de datos para un futuro producto de software. El desarrollador puede dudar de la idoneidad del producto para el sistema operativo, en forma de diálogo con el usuario, o de la eficacia del algoritmo. En tales casos, es recomendable utilizar prototipos. El objetivo principal de la creación de prototipos es eliminar la incertidumbre en los requisitos del cliente. El modelado (creación de prototipos) es el proceso de creación de un modelo del producto requerido.

El modelo puede tomar las siguientes formas.

Maqueta en papel (diagrama dibujado a mano del diálogo hombre-máquina) o maqueta basada en PC.
Un diseño de trabajo que implementa algunas de las funciones requeridas.
Un programa existente cuyas características necesitan ser mejoradas.

Como se muestra en la figura, la creación de prototipos se basa en iteraciones repetidas en las que participan el cliente y el desarrollador.

Arroz. 5.

La secuencia de acciones para la creación de prototipos se muestra en la figura. La creación de prototipos comienza con la recopilación y especificación de requisitos para el sistema de software que se está creando. El desarrollador y el cliente definen conjuntamente los objetivos del software, establecen qué requisitos se conocen y cuáles se deben redefinir. Luego se realiza el diseño rápido. Se centra en las características que deberían ser visibles para el usuario. El diseño rápido conduce a la construcción de un diseño. El diseño es evaluado por el cliente y se utiliza para aclarar los requisitos del software. Las iteraciones continúan hasta que el diseño revela todos los requisitos del cliente y permite al desarrollador comprender lo que se debe hacer.

La ventaja de la creación de prototipos es la capacidad de garantizar que se definan los requisitos completos del sistema. Desventajas de diseño:

el cliente puede tomar el diseño del producto;
el desarrollador puede confundir el diseño con el producto.

Las deficiencias deben ser explicadas. Cuando el cliente ve una versión funcional del PS, deja de darse cuenta de que en la búsqueda de una versión funcional del PS, muchos problemas de calidad y comodidad de acompañamiento sistemas Cuando el desarrollador le cuenta esto al cliente, la respuesta puede ser indignación y demanda de una rápida transformación del diseño en un producto que funcione. Esto afecta negativamente la gestión del desarrollo de software.

Arroz. 6.

Por otro lado, para obtener rápidamente un diseño que funcione, el desarrollador a menudo hace ciertos compromisos. Por ejemplo, se pueden usar lenguajes de programación inapropiados o sistema operativo. Para una demostración simple, se puede usar un algoritmo ineficiente (simple). Después de un tiempo, el desarrollador se olvida de las razones por las que estas herramientas no son adecuadas. Como resultado, una opción seleccionada lejos de ser ideal se integra en el sistema.

Antes de mirar otros modelos de ciclo de vida de software que han reemplazado modelo de cascada, debemos detenernos en las estrategias para diseñar sistemas de software. Es la estrategia de diseño de software la que determina en gran medida el modelo del ciclo de vida del software.

Estrategias de diseño de software

Hay tres estrategias para construir sistemas de software:

paso único (estrategia en cascada discutida anteriormente): una secuencia lineal de pasos de diseño;
estrategia incremental. Al comienzo del proceso, se determinan todos los requisitos del usuario y del sistema, el resto de la construcción se lleva a cabo como una serie de versiones. La primera versión implementa algunas de las funciones planificadas, la siguiente versión implementa funciones adicionales, y así sucesivamente hasta obtener el sistema completo;
estrategia evolutiva. El sistema también se construye como una serie de versiones, pero no todos los requisitos se definen al comienzo del proceso. Los requisitos se especifican como resultado del desarrollo de versiones. Las características de las estrategias de diseño de software de acuerdo con los requisitos del estándar IEEE/EIA 12207 se muestran en la Tabla 1.

modelo incremental

El modelo incremental es un ejemplo clásico de una estrategia de diseño incremental. Combina elementos de un modelo de cascada secuencial con una filosofía de diseño iterativo (propuesta por B. Boehm como una mejora modelo de cascada). Cada secuencia de línea aquí genera un incremento de software suministrado. Por ejemplo, el software de procesamiento de textos en el primer incremento (versión) implementa funciones básicas de procesamiento, edición y documentación de archivos; en el segundo incremento: capacidades de edición y documentación más sofisticadas; en el 3er incremento - revisión ortográfica y gramatical; en el cuarto incremento: capacidades de diseño de página.

El primer incremento da como resultado un producto base que implementa los requisitos básicos (sin embargo, muchos requisitos auxiliares siguen sin cumplirse). El plan para el próximo incremento implica modificar el producto base para proporcionar características y funcionalidades adicionales.

Por su naturaleza, el proceso incremental es iterativo, pero a diferencia del protoboarding, el modelo incremental proporciona un producto de trabajo en cada incremento.

En la figura se muestra un diagrama de un modelo de ciclo de vida de software de este tipo. Una de las implementaciones modernas del enfoque incremental es la programación extrema (centrada en incrementos muy pequeños de funcionalidad).

Arroz. 7.

Modelo de ciclo de vida de software en espiral

modelo espiral es un ejemplo clásico de una estrategia de diseño evolutivo. El modelo (autor B. Boehm, 1988) se basa en las mejores propiedades del ciclo de vida clásico y la creación de prototipos, a lo que se agrega un nuevo elemento: el análisis de riesgos, que está ausente en estos paradigmas. El modelo define cuatro actividades representadas por los cuatro cuadrantes de la espiral.

Arroz. ocho.

La planificación es la definición de metas, opciones y restricciones.
Análisis de riesgos: análisis de opciones y reconocimiento/selección de riesgos.
La ingeniería es el siguiente nivel de desarrollo de productos.
Evaluación: evaluación por parte del cliente de los resultados del diseño actual.

Aspecto integrador modelo espiral es obvio cuando se considera la dimensión radial de la hélice. Con cada iteración, más y más versiones completas PD. En el primer giro de la espiral, se definen los objetivos iniciales, las opciones y las limitaciones, se reconoce y analiza el riesgo. Si el análisis de riesgos muestra la incertidumbre de los requisitos, la creación de prototipos utilizada en el cuadrante de diseño viene en ayuda del desarrollador y el cliente.

El modelado se puede utilizar para identificar aún más los requisitos problemáticos y refinados. El cliente evalúa el trabajo de ingeniería (diseño) y hace propuestas de modificaciones (cuadrante de evaluación del cliente). La siguiente fase de planificación y análisis de riesgos se basa en las sugerencias de los clientes. En cada ciclo a través de la espiral, los resultados del análisis de riesgo se forman en forma de "continuar, no continuar". Si el riesgo es demasiado grande, el proyecto puede detenerse.

En la mayoría de los casos, la espiral continúa y cada paso empuja a los desarrolladores hacia un modelo de sistema más general. Cada bucle en la espiral requiere una construcción (cuadrante inferior derecho), que puede implementarse mediante un diseño o un ciclo de vida clásico. Tenga en cuenta que la cantidad de actividades de desarrollo (que ocurren en el cuadrante inferior derecho) aumenta a medida que se aleja del centro de la espiral.

Estas acciones están numeradas y tienen el siguiente contenido:

– recopilación de requisitos iniciales y planificación del proyecto;
– el mismo trabajo, pero basado en las recomendaciones del cliente;
– análisis de riesgos basado en los requisitos iniciales;
– análisis de riesgos basado en la respuesta del cliente;
– transición a un sistema integrado;
– diseño inicial del sistema;
- el siguiente nivel del diseño;
– sistema diseñado;
- Evaluación por parte del cliente.

Ventajas modelo espiral:

más realista (en forma de evolución) refleja el desarrollo software;
le permite tener en cuenta explícitamente el riesgo en cada etapa de la evolución del desarrollo;
incluye un paso de enfoque sistemático en la estructura de desarrollo iterativo;
utiliza la simulación para reducir el riesgo y mejorar el producto de software.

Defectos modelo espiral:

novedad comparativa (no hay suficientes estadísticas sobre la efectividad del modelo);
mayores requisitos para el cliente;
Dificultades en el seguimiento y gestión del tiempo de desarrollo.

El modelo de proceso de desarrollo en espiral es el más común en la actualidad. Sus variantes más famosas son RUP (Rational Unified Process) de Rational y MSF (Microsoft Solution Framework). UML (Lenguaje de modelado unificado) se utiliza como lenguaje de modelado. Se supone que la creación del sistema se lleva a cabo de forma iterativa, moviéndose en espiral y pasando por las mismas etapas, en cada turno para refinar las características del futuro producto. Parecería que ahora todo está bien: solo se planifica lo que se puede prever, se desarrolla lo que se planifica y los usuarios comienzan a familiarizarse con el producto de antemano, teniendo la oportunidad de realizar los ajustes necesarios.

Sin embargo, esto requiere fondos muy grandes. De hecho, si antes era posible crear y disolver grupos de especialistas según las necesidades, ahora todos ellos deben participar constantemente en el proyecto: arquitectos, programadores, probadores, instructores, etc. Además, los esfuerzos de varios grupos deben sincronizarse para para reflejar de manera oportuna las decisiones de diseño y realizar los cambios necesarios.

Proceso racional unificado

Racional proceso unificado(Rational Unified Process, RUP) es una de las mejores metodologías de desarrollo de software. Basado en la experiencia de muchos exitosos proyectos de software, RUP le permite crear sistemas de software complejos basados en métodos de desarrollo industrial. Los requisitos previos para el desarrollo de RUP se originaron a principios de la década de 1980. en la corporación Rational Software. A principios de 2003, Rational adquirió IBM. Uno de los principales pilares en los que se apoya RUP es el proceso de creación de modelos utilizando el lenguaje de modelado unificado (UML).

RUP es una de las metodologías de desarrollo de software en espiral. La metodología es mantenida y desarrollada por Rational Software. La base de conocimiento común utiliza el lenguaje de modelado unificado (UML) como lenguaje de modelado. El desarrollo de software iterativo e incremental en RUP implica dividir un proyecto en varios proyectos que se ejecutan secuencialmente, y cada iteración de desarrollo está claramente definida por un conjunto de objetivos que se lograrán al final de la iteración. La iteración final asume que el conjunto de objetivos de la iteración debe coincidir exactamente con el conjunto de objetivos especificado por el cliente del producto, es decir, se deben cumplir todos los requisitos.

El proceso implica la evolución de modelos; una iteración del ciclo de desarrollo corresponde únicamente a una versión particular del modelo de software. Cada una de las iteraciones contiene controles. ciclo de vida del software: análisis y diseño (modelado), implementación, integración, pruebas, implementación. En este sentido, RUP es una implementación modelo espiral, aunque a menudo se representa en forma de tabla gráfica.

Esta figura muestra dos dimensiones: el eje horizontal representa el tiempo y muestra los aspectos temporales del ciclo de vida del proceso; el eje vertical representa las disciplinas que definen la estructura física del proceso. Puede ver cómo el énfasis en el proyecto cambia con el tiempo. Por ejemplo, las primeras iteraciones dedican más tiempo a los requisitos; en iteraciones posteriores, se dedica más tiempo a la implementación. El eje horizontal está formado por períodos de tiempo: iteraciones, cada una de las cuales es un ciclo de desarrollo independiente; el propósito del ciclo es aportar algún refinamiento tangible predeterminado al producto final que sea útil desde el punto de vista de las partes interesadas.

Arroz. 9.

A lo largo del eje del tiempo, el ciclo de vida se divide en cuatro fases principales.

Inicio (Inicio) - la formación del concepto del proyecto, una comprensión de lo que estamos creando, una idea del producto (visión), el desarrollo de un plan de negocios (caso de negocios), la preparación de un programa prototipo o una solución parcial. Esta es la fase de recopilación de información y análisis de requisitos, definiendo la imagen del proyecto en su conjunto. El objetivo es conseguir apoyo y financiación. En la iteración final, el resultado de esta etapa son los términos de referencia.
Diseño, desarrollo (Elaboración) - aclaración del plan, comprensión de cómo lo creamos, diseño, planificación acción necesaria y recursos, detallando características. La etapa finaliza con una arquitectura ejecutable, cuando se toman todas las decisiones arquitectónicas y se tienen en cuenta los riesgos. Una arquitectura ejecutable es un software en ejecución que demuestra la implementación de importantes decisiones arquitectónicas. En la iteración final, este es un proyecto técnico.
Implementación, creación del sistema (Construcción) es la etapa de expansión de la funcionalidad del sistema embebido en la arquitectura. En la iteración final, este es un borrador de trabajo.
Implementación, despliegue (Transición). Creación de la versión final del producto. Fase de implementación del producto, entrega del producto a un usuario específico (replicación, entrega y capacitación).

El eje vertical consta de disciplinas, cada una de las cuales se puede describir con más detalle en términos de las tareas realizadas, los roles responsables de las mismas, los productos que se ingresan a las tareas y se liberan durante su ejecución, etc.

A lo largo de este eje se encuentran las disciplinas clave del ciclo de vida de RUP, que a menudo se denominan procesos en ruso, aunque esto no es del todo cierto desde el punto de vista de esta metodología, soportada por herramientas de IBM (y/o de terceros).

El análisis y modelado de negocios ( Business modeling ) proporciona la implementación de los principios del modelado para estudiar el negocio de la organización y acumular conocimiento sobre él, optimizar los procesos comerciales y tomar decisiones sobre su automatización parcial o total.
La gestión de requisitos se trata de tomar información de las partes interesadas y transformarla en un conjunto de requisitos que definen el contenido del sistema que se está desarrollando y detallan las expectativas de lo que debe hacer el sistema.
Análisis y diseño (Análisis y diseño) cubre los procedimientos para transformar los requisitos en descripciones intermedias (modelos) que representan cómo se deben implementar estos requisitos.
La implementación cubre el desarrollo de código, las pruebas a nivel de desarrollador y la integración de componentes, subsistemas y todo el sistema de acuerdo con las especificaciones establecidas.
Las pruebas se dedican a evaluar la calidad del producto que se está creando.
La implementación cubre las operaciones que tienen lugar en la entrega de productos a los clientes y la puesta a disposición de los usuarios finales.
La gestión de configuración y gestión de cambios (Configuration management) se dedica a sincronizar productos intermedios y finales y gestionar su desarrollo durante el proyecto y encontrar problemas ocultos.
Project Management se dedica a la planificación de proyectos, la gestión de riesgos, el seguimiento del progreso del proyecto y la evaluación continua de indicadores clave.
El entorno de gestión (Entorno) incluye elementos de la formación del entorno de desarrollo. sistema de informacion y apoyo a las actividades del proyecto.

Dependiendo de las especificaciones del proyecto, se puede utilizar cualquier herramienta de IBM Rational, así como herramientas de terceros. El RUP recomienda seguir seis prácticas para el desarrollo exitoso de proyectos: desarrollo iterativo; gestión de requerimientos; uso de arquitecturas modulares; modelado visual; control de calidad; seguimiento de cambios.

Una parte integral de RUP son los artefactos (artefact), los precedentes (precedente) y los roles (rol). Los artefactos son algunos de los productos del proyecto que se generan o utilizan en él cuando se trabaja en el producto final. Los casos de uso son secuencias de acciones realizadas por el sistema para producir un resultado observable. De hecho, cualquier resultado del trabajo de un individuo o de un grupo es un artefacto, ya sea un documento de análisis, un elemento de modelo, un archivo de código, un script de prueba, una descripción de un error, etc. Ciertos especialistas son responsables de creando uno u otro tipo de artefacto. Así, RUP define claramente las responsabilidades - roles - de cada miembro del equipo de desarrollo en una u otra etapa, es decir, cuándo y quién debe crear tal o cual artefacto. Todo el proceso de desarrollo de un sistema de software se considera en RUP como un proceso de creación de artefactos, desde documentos de análisis iniciales hasta módulos ejecutables, manuales de usuario, etc.

Para el soporte informático de los procesos RUP, IBM ha desarrollado una amplia gama de herramientas:

Rosa Racional-CASO- herramienta de modelado visual sistemas de información, que tiene la capacidad de generar elementos de código. Una edición especial del producto, Rational Rose RealTime, le permite obtener un módulo ejecutable en la salida;
Rational Requisite Pro es una herramienta de administración de requisitos que le permite crear, estructurar, priorizar, rastrear y controlar los cambios de requisitos que ocurren en cualquier etapa del desarrollo de los componentes de la aplicación;
Rational ClearQuest es un producto de gestión de cambios y seguimiento de errores que se integra estrechamente con las herramientas de gestión de pruebas y requisitos y proporciona un entorno único para vincular todos los errores y documentos entre sí;
Rational SoDA es un producto para generar automáticamente documentación de proyectos que le permite establecer un estándar corporativo para los documentos internos de la empresa. También es posible llevar la documentación a los estándares existentes (ISO, CMM);
Rational Purify, Rational Quantify Rational PureCoverage, herramientas de prueba y depuración;
Rational Visual Quantify es una herramienta de medición del rendimiento para desarrolladores de aplicaciones y componentes C/C++, Visual Basic y Java; ayuda a identificar y eliminar cuellos de botella en el rendimiento del software;
Rational Visual PureCoverage: detecta automáticamente áreas de código que no se prueban;
Rational ClearCase es un producto de gestión de configuración de software (Software Configuration Management, SCM de Rational) que permite el control de versiones de todos los documentos del proyecto. Se puede utilizar para mantener varias versiones de proyectos al mismo tiempo, cambiando rápidamente entre ellas. Rational Requisite Pro admite actualizaciones y realiza un seguimiento de los cambios en los requisitos para el equipo de desarrollo;
Herramienta de prueba de equipo SQA automatización de pruebas;
Rational TestManager es un sistema de gestión de pruebas que reúne todas las herramientas, artefactos, scripts y datos relacionados con las pruebas;
Rational Robot: una herramienta para crear, modificar y ejecutar automáticamente pruebas;
SiteLoad, SiteCheck: herramientas para probar el rendimiento y los enlaces rotos de los sitios web;
Rational PerformanceStudio: mida y prediga las características de rendimiento de los sistemas.

Este conjunto de productos se mejora y amplía constantemente. Por ejemplo, el producto reciente IBM Rational Software Architect (RSA) es parte de IBM Software Development Platform, un conjunto de herramientas que respaldan el ciclo de vida de desarrollo del sistema de software. El producto IBM Rational Software Architect está diseñado para crear modelos de sistemas de software que se están desarrollando utilizando el lenguaje de modelado unificado UML 2.0, principalmente modelos de la arquitectura de la aplicación que se está desarrollando. Sin embargo, RSA combina la funcionalidad de productos de software como Rational Application Developer, Rational Web Developer y Rational Software Modeler, lo que permite a los arquitectos y analistas crear varias vistas del sistema de información en desarrollo utilizando el lenguaje UML 2.0 y a los desarrolladores realizar tareas de desarrollo. J2EE, XML, servicios web, etc.

Siguiendo los principios de RUP, Rational Software Architect te permite crear los modelos necesarios dentro de los flujos de trabajo de disciplinas como:

análisis y modelado de negocios (modelado de negocios);
gestión de requisitos (Requisitos);
análisis y diseño (Análisis y Diseño);
implementación (Implementación).

Además, Rational Software Architect admite la tecnología de desarrollo basado en modelos (MDD), que le permite modelar software en varios niveles de abstracción con trazabilidad.

MSF (Marco de soluciones de Microsoft)

En 1994, en un esfuerzo por sacar el máximo provecho de los proyectos de TI, Microsoft publicó un conjunto de directrices para diseñar, desarrollar, implementar y mantener de forma eficaz soluciones basadas en su tecnología. Este conocimiento se basa en la experiencia adquirida por Microsoft al trabajar en grandes proyectos de desarrollo y mantenimiento de software, la experiencia de los consultores de Microsoft y lo mejor que la industria de TI ha acumulado hasta la fecha. Todo ello se presenta en forma de dos áreas de conocimiento interrelacionadas y bien complementarias: Microsoft Solutions Framework (MSF) y Microsoft Operations Framework (MOF).

Cabe señalar que Microsoft ha desarrollado metodologías basadas en los métodos generales de MSF para aplicaciones aplicadas y especializadas. Además, Microsoft certifica expertos específicamente para el conocimiento aplicado en la aplicación de MSF (por ejemplo, certificación MCTS 74-131 para experiencia en metodología de gestión de proyectos). Antes de conocer los métodos de MSF, primero debe determinar qué aplicación de MSF tiene en mente.

Las variantes de aplicación más populares de MSF desarrolladas por Microsoft son:

metodología para la implementación de soluciones en el campo de la gestión de proyectos;
Metodología de gestión de proyectos TI basada en MSF y metodologías Agile.

La importancia de las variantes aplicadas de MSF se destaca por el hecho de que, en la "versión pura", Microsoft no utiliza la metodología MSF en sí misma en sus proyectos de TI. Los proyectos de Microsoft Consulting Services utilizan una metodología híbrida entre MSF y Agile. A pesar de las significativas diferencias externas entre las versiones aplicadas de MSF desarrolladas por expertos de Microsoft, la base de los métodos de MSF sigue siendo común y refleja enfoques metodológicos comunes para la gestión iterativa de proyectos.

MOF está diseñado para proporcionar a las organizaciones que crean soluciones de TI de misión crítica basadas en productos y tecnologías de Microsoft orientación técnica sobre cómo lograr su confiabilidad, disponibilidad, comodidad de acompañamiento(soportabilidad) y manejabilidad (manejabilidad). MOF aborda temas relacionados con la organización del personal y los procesos; tecnologías y gestión en condiciones de entornos de TI complejos (complejos), distribuidos (distribuidos) y heterogéneos (heterogéneos). MOF se basa en las mejores prácticas recopiladas en la Biblioteca de Infraestructura de TI (ITIL) recopiladas por la Agencia Central de Computación y Telecomunicaciones, una agencia del gobierno del Reino Unido.

Crear una solución empresarial dentro del tiempo y el presupuesto asignados requiere una base metodológica comprobada. MSF proporciona metodologías comprobadas para planificar, diseñar, desarrollar e implementar soluciones de TI exitosas. Con su flexibilidad, escalabilidad y ausencia de pautas rígidas, MSF puede satisfacer las necesidades de organizaciones o equipos de proyectos de cualquier tamaño. La metodología MSF consta de principios, modelos y disciplinas para la gestión de personal, procesos, elementos tecnológicos y temas relacionados con todos estos factores que son típicos para la mayoría de los proyectos. MSF consta de dos modelos y tres disciplinas. Se detallan en 5 documentos técnicos. Es mejor comenzar a estudiar MSF con modelos (modelo de equipo de proyecto, modelo de proceso) y luego pasar a disciplinas (disciplina de gestión de proyectos, disciplina de gestión de riesgos, disciplina de gestión de la formación).

El modelo de proceso de MSF representa una metodología general para el desarrollo e implementación de soluciones de TI. La peculiaridad de este modelo es que, debido a su flexibilidad ya la ausencia de procedimientos rígidos impuestos, se puede aplicar en el desarrollo de una gama muy amplia de proyectos de TI. Este modelo combina las propiedades de dos modelos de producción estándar: cascada (cascada) y espiral (espiral). El modelo de proceso en MSF 3.0 ha sido aún más innovador: cubre todo el ciclo de vida de una solución, desde su inicio hasta su implementación. Este enfoque ayuda a los equipos de proyectos a centrarse en el valor comercial de la solución, ya que ese valor se vuelve real solo después de que se completa la implementación y el producto está en uso.

El proceso de MSF se centra en "hitos": los puntos clave del proyecto, que caracterizan el logro dentro de su marco de cualquier resultado significativo (intermedio o final). Este resultado puede evaluarse y analizarse, lo que significa responder a las preguntas: "¿El equipo del proyecto llegó a un entendimiento inequívoco de los objetivos y el alcance del proyecto?", "¿Está suficientemente preparado el plan de acción?", "¿Cumple el producto la especificación aprobada?", "¿La solución satisface las necesidades del cliente? etc.

El modelo de proceso de MSF tiene en cuenta los requisitos del proyecto en constante cambio. Procede del hecho de que el desarrollo de una solución debe consistir en ciclos cortos que crean movimiento hacia adelante desde las versiones más simples de la solución hasta su forma final.

Las características del modelo de proceso de MSF son:

un enfoque de fase e hito;
enfoque iterativo;
un enfoque integrado para la creación e implementación de soluciones.

El modelo de proceso incluye fases principales del proceso de desarrollo tales como:

desarrollo de conceptos (Envisioning);
planificación (Planificación);
desarrollo (En desarrollo);
estabilización (Estabilización);
implementación (desplegar).

Además, hay una gran cantidad de hitos intermedios que muestran el logro de ciertos avances en el transcurso del proyecto y desglosan grandes segmentos de trabajo en secciones más pequeñas y observables. Para cada fase del modelo de proceso, MSF define:

qué (qué artefactos) es el resultado de esta fase;
en qué está trabajando cada uno de los grupos de roles en esta fase.

Dentro de MSF, el código, la documentación, los diseños, los planos y otros materiales de trabajo generalmente se crean de manera iterativa. MSF recomienda comenzar a desarrollar una solución creando, probando e implementando su funcionalidad principal. Luego, se agregan más y más funciones a la solución. Esta estrategia se denomina estrategia de control de versiones. Si bien una sola versión puede ser suficiente para proyectos más pequeños, se recomienda que no pierda la oportunidad de crear varias versiones para una sola solución. Con la creación de nuevas versiones, la funcionalidad de la solución evoluciona.

Un enfoque iterativo del proceso de desarrollo requiere el uso de documentación flexible. Los documentos vivos deben cambiar a medida que el proyecto evoluciona junto con los cambios en los requisitos del producto final. MSF ofrece una serie de plantillas de documentos estándar que son artefactos de cada etapa del desarrollo del producto y se pueden utilizar para planificar y controlar el proceso de desarrollo.

Una solución no tiene valor comercial hasta que se implementa. Por esta razón, el modelo de proceso de MSF contiene todo el ciclo de vida de la creación de una solución, incluida su implementación, hasta el momento en que la solución comienza a generar valor.

en ingeniería eléctrica). Este estándar define la estructura del ciclo de vida, que contiene los procesos, actividades y tareas que se deben realizar durante la creación del PS.

En este estándar PS (o software) se define como un conjunto programas de computador, procedimientos y posiblemente documentación y datos asociados. El proceso se define como un conjunto de acciones interrelacionadas que transforman algunos datos de entrada en datos de salida (G. Myers llama a esto traducción de datos). Cada proceso se caracteriza por ciertas tareas y métodos para su solución. A su vez, cada proceso se divide en un conjunto de acciones, y cada acción se divide en un conjunto de tareas. Cada proceso, acción o tarea es iniciado y ejecutado por otro proceso según sea necesario, y no hay secuencias de ejecución predeterminadas (por supuesto, mientras se mantienen las conexiones de datos de entrada).

Cabe señalar que en la Unión Soviética, y luego en Rusia, la creación de software (software) inicialmente, en los años 70 del siglo pasado, estaba regulada por los estándares GOST ESPD (Sistema Unificado para Documentación de Programas - GOST 19.XXX serie), que se centraron en la clase relativamente programas simples pequeño volumen creado por programadores individuales. En la actualidad, estas normas se encuentran desactualizadas conceptual y formalmente, su vigencia ha caducado y su uso es inadecuado.

Procesos de creación sistemas automatizados(AS), que también incluye software, están regulados por GOST 34.601-90 " Tecnologías de la información. Conjunto de normas para sistemas automatizados. Etapas de creación", GOST 34.602-89 "Tecnología de la información. Conjunto de normas para sistemas automatizados. Tarea técnica para la creación de un sistema automatizado" y GOST 34.603-92 "Tecnología de la información. Tipos de pruebas de sistemas automatizados". Sin embargo, muchas disposiciones de estos estándares están desactualizadas, mientras que otras no se reflejan lo suficiente como para ser utilizadas para proyectos serios para la creación de PS. Por lo tanto, es recomendable utilizar estándares internacionales modernos en desarrollos nacionales.

De acuerdo con la norma ISO/IEC 12207, todos los procesos del ciclo de vida del software se dividen en tres grupos (Fig. 5.1).

Arroz. 5.1.

En los grupos se definen cinco procesos principales: adquisición, suministro, desarrollo, operación y mantenimiento. Ocho subprocesos aseguran la ejecución de los procesos principales, a saber documentación, gestión de la configuración, aseguramiento de la calidad, verificación, validación, evaluación conjunta, auditoría, resolución de problemas. Los cuatro procesos organizativos proporcionan gobernanza, construcción de infraestructura, mejora y aprendizaje.

5.2. Los principales procesos del ciclo de vida del PS.

El proceso de adquisición consiste en las actividades y tareas del cliente que compra el software. Este proceso cubre las siguientes actividades:

iniciación de la adquisición;
preparación de propuestas de aplicación;
preparación y ajuste del contrato;
supervisión de las actividades del proveedor;
aceptación y finalización del trabajo.

El inicio de la adquisición incluye las siguientes tareas:

determinación por parte del cliente de sus necesidades en la adquisición, desarrollo o mejora del sistema, productos de software o servicios;
tomar una decisión con respecto a la adquisición, desarrollo o mejora del software existente;
comprobar la disponibilidad de la documentación necesaria, garantías, certificados, licencias y soporte en caso de adquirir un producto de software;
elaboración y aprobación del plan de adquisición, incluyendo requisitos del sistema, tipo de contrato, responsabilidades de las partes, etc.

Las ofertas deben contener:

Requisitos del sistema;
lista de productos de software;
términos de adquisición y acuerdo;
limitaciones técnicas (por ejemplo, en el entorno operativo del sistema).

Las ofertas se envían a un proveedor seleccionado oa varios proveedores en caso de licitación. Un proveedor es una organización que celebra un contrato con un cliente para suministrar un sistema, software o servicio de software en los términos especificados en el contrato.

La preparación y ajuste del contrato incluye las siguientes tareas:

determinación por parte del cliente del procedimiento de selección de un proveedor, incluidos los criterios para evaluar las propuestas de posibles proveedores;
selección de un proveedor específico a partir del análisis de propuestas;
preparación y conclusión contratos con proveedores;
hacer cambios (si es necesario) al contrato en el proceso de su implementación.

Las actividades del proveedor son supervisadas de acuerdo con las acciones estipuladas en los procesos de evaluación y auditoría conjunta. Durante el proceso de aceptación, se preparan y realizan las pruebas necesarias. La finalización del trabajo bajo el contrato se lleva a cabo en caso de satisfacción de todas las condiciones de aceptación.

El proceso de entrega cubre las actividades y tareas realizadas por un proveedor que suministra a un cliente un producto o servicio de software. Este proceso incluye los siguientes pasos:

iniciación de la entrega;
preparar una respuesta a las ofertas;
preparación del contrato;
planificación del trabajo por contrato;
ejecución y control contrato de trabajo y su evaluación;
entrega y terminación de obras.

El inicio del suministro consiste en la consideración por parte del proveedor de las propuestas de oferta y la decisión de aceptar los requisitos y condiciones establecidos u ofrecer los suyos propios (acordados). La planificación incluye las siguientes tareas:

tomar una decisión por parte del proveedor con respecto a la realización del trabajo por sí mismo o con la participación de un subcontratista;
desarrollo por parte del proveedor de un plan de gestión del proyecto que contenga estructura organizativa proyecto, división de responsabilidad, requerimientos técnicos al entorno y recursos de desarrollo, gestión de subcontratistas, etc.

El proceso de desarrollo prevé las actividades y tareas realizadas por el desarrollador y cubre el trabajo de creación de software y sus componentes de acuerdo con los requisitos especificados. Esto incluye la preparación del diseño y la documentación operativa, la preparación de los materiales necesarios para las pruebas de rendimiento y calidad de los productos de software, materiales necesarios para organizar la formación del personal, etc.

El proceso de desarrollo incluye los siguientes pasos:

trabajo de preparatoria;
análisis de los requisitos del sistema;
diseño de la arquitectura del sistema;
análisis de requisitos de software;
diseño de arquitectura de software;
diseño de software detallado;
codificación y prueba de software;
integración de software;
pruebas de cualificación de software;
Integración de sistema;
prueba de calificación del sistema;
instalación de software;
aceptación del software.

El trabajo preparatorio comienza con la selección de un modelo de ciclo de vida de software adecuado a la escala, importancia y complejidad del proyecto. Las actividades y tareas del proceso de desarrollo deben ser consistentes con el modelo elegido. El desarrollador debe seleccionar, adaptarse a las condiciones del proyecto y utilizar los estándares, métodos y métodos acordados con el cliente. herramientas de desarrollo, así como elaborar un plan de trabajo.

El análisis de los requisitos del sistema implica la definición de sus funcionalidad, requisitos personalizados, requisitos de fiabilidad, seguridad, requisitos de interfaces externas, rendimiento, etc. Los requisitos del sistema se evalúan en función de criterios de viabilidad y verificabilidad durante las pruebas.

El diseño de la arquitectura del sistema consiste en determinar los componentes de su equipo (hardware), software y operaciones realizadas por el personal que opera el sistema. La arquitectura del sistema debe cumplir con los requisitos del sistema y los estándares y prácticas de diseño aceptados.

El análisis de requisitos de software implica determinar las siguientes características para cada componente de software:

funcionalidad, incluidas las características de rendimiento y el entorno operativo del componente;
interfaces externas;
especificaciones de confiabilidad y seguridad;
requisitos ergonómicos;
requisitos para los datos utilizados;
requisitos de instalación y aceptación;
requisitos para la documentación del usuario;
Requisitos para la operación y el mantenimiento.

Los requisitos del software se evalúan con base en los criterios de cumplimiento de los requisitos para el sistema en su conjunto, factibilidad y verificabilidad durante las pruebas.

El diseño de la arquitectura de software incluye las siguientes tareas para cada componente de software:

transformación de los requisitos del software en una arquitectura que define la estructura del software y la composición de sus componentes a un alto nivel;
desarrollo y documentación de interfaces de programas para software y bases de datos (DB);
desarrollo de una versión preliminar de la documentación del usuario;
desarrollo y documentación de requisitos previos para pruebas y plan de integración de software.

El diseño detallado del software incluye las siguientes tareas:

descripción de los componentes del software y las interfaces entre ellos a un nivel inferior, suficiente para la codificación y las pruebas posteriores;
desarrollar y documentar un diseño de base de datos detallado;
actualizar (si es necesario) la documentación del usuario;
desarrollo y documentación de requisitos de prueba y un plan para probar componentes de software;

La codificación y prueba de software incluye las siguientes tareas:

codificar y documentar cada componente del software y la base de datos, así como preparar un conjunto de procedimientos de prueba y datos para probarlos;
probar cada componente del software y la base de datos para verificar el cumplimiento de sus requisitos, seguido de la documentación de los resultados de las pruebas;
actualización de la documentación (si es necesario);
actualizar el plan de integración de software.

La integración de software prevé el ensamblaje de los componentes de software desarrollados de acuerdo con el plan de integración y prueba para los componentes agregados. Para cada uno de los componentes agregados, se desarrollan conjuntos de pruebas y procedimientos de prueba para probar cada una de las competencias en pruebas de aptitud posteriores. requisito de cualificación es un conjunto de criterios o condiciones que deben cumplirse para calificar software conforme a sus especificaciones y listo para usar en el campo.

El desarrollador lleva a cabo las pruebas de calificación del software en presencia del cliente (

El proceso de operación cubre las actividades y tareas de la organización del operador que opera el sistema. El proceso de operación incluye los siguientes pasos.

Trabajo preparatorio, que incluye la realización de las siguientes tareas por parte del operador:
1. planificar actividades y trabajos realizados durante la operación y establecer estándares operativos;
2. determinación de procedimientos para la localización y resolución de problemas surgidos durante la operación.
Pruebas operativas realizadas para cada próxima edición del producto de software, después de lo cual esta edición se transfiere a la operación.
El funcionamiento real del sistema, que se realiza en el entorno previsto para ello de acuerdo con la documentación del usuario.
análisis de problemas y solicitudes de modificación de software (análisis de mensajes sobre un problema que ha surgido o una solicitud de modificación, evaluación de la escala, costo de la modificación, efecto resultante, evaluación de la viabilidad de la modificación);
modificación de software (hacer cambios en los componentes y la documentación del producto de software de acuerdo con las reglas del proceso de desarrollo);
verificación y aceptación (en términos de la integridad del sistema que se modifica);
transferencia de software a otro entorno (conversión de programas y datos, operación paralela de software en el entorno antiguo y nuevo durante un cierto período de tiempo);
desmantelamiento del software por decisión del cliente con la participación de la entidad explotadora, el servicio de mantenimiento y los usuarios. Al mismo tiempo, los productos de software y la documentación están sujetos a archivo de acuerdo con el contrato.

Ciclo vital software (SW): un período de tiempo que comienza desde el momento en que se toma una decisión sobre la necesidad de crear un producto de software y finaliza en el momento de su retiro completo de la operación. Este ciclo es el proceso de construcción y desarrollo de software.

Etapas del ciclo de vida:

2. Diseño

3. Implementación

4. Montaje, prueba, prueba

5. Introducción (lanzamiento)

6. Escolta

Hay 2 casos de producción de software: 1) el software se hace para un cliente específico. En este caso, debe convertir la tarea aplicada en una de programación. Es necesario entender cómo funciona el entorno que necesita ser automatizado (análisis de procesos de negocio). Como resultado, aparece una especificación de documentación del requisito, que indica qué tareas se deben realizar. resuelto y en qué condiciones. este trabajo esta hecho Analizador de sistemas(analista de procesos de negocio).

2) El software se desarrolla para el mercado. Necesidad de llevar a cabo investigación de mercado y encontrar qué producto no está en el mercado. Esto viene con mucho riesgo. El objetivo es desarrollar una especificación de requisitos.

Diseño

El objetivo es determinar la estructura general (arquitectura) del software. El resultado es una especificación de software. Este trabajo lo realiza el programador del sistema.

Implementación

Escribir código de programa. La implementación incluye desarrollo, pruebas y documentación.

Montaje, prueba, prueba

Montaje de todo lo que se hace por diferentes programadores. Pruebas de todo el paquete de software. Depuración: encontrar y eliminar las causas de los errores. Prueba - aclaración de características técnicas. Como resultado, se garantiza que el programa funcione.

Introducción (lanzamiento)

Implementación: cuando trabajan para un cliente. Incluye la configuración del programa en casa del cliente, la formación del cliente, las consultas, la eliminación de errores y deficiencias evidentes. El software debe enajenarse: el usuario puede trabajar con el software sin la participación del autor.

Lanzamiento: cuando el software se desarrolla para el mercado. Comienza con la fase de prueba beta. resp. versión - versión beta. Las pruebas alfa son pruebas realizadas por personas de la misma organización que no participaron en el desarrollo del software. La prueba beta es la producción de varias copias del software y su envío a clientes potenciales. El objetivo es probar el desarrollo de software una vez más.

Si se lanza al mercado un software fundamentalmente nuevo, entonces son posibles varias pruebas beta. Después de la prueba beta, el lanzamiento de la versión comercial.

Escolta

Eliminación de errores observados durante el funcionamiento. Haciendo pequeñas mejoras. Acumulación de propuestas para el desarrollo de la próxima versión.

Modelos de ciclo de vida

1. Cascada ("cascada", modelo en cascada)

2. Prototipos

En primer lugar, no se desarrolla el producto de software en sí, sino su prototipo que contiene la solución a los principales problemas que enfrentan los desarrolladores. Después de completar con éxito el desarrollo del prototipo, el producto de software real se desarrolla de acuerdo con los mismos principios. El prototipo le permite comprender mejor los requisitos para el programa que se está desarrollando. Usando el prototipo, el cliente también puede formular sus requisitos con mayor precisión. El desarrollador tiene la oportunidad de presentar los resultados preliminares de su trabajo al cliente con la ayuda de un prototipo.

3. Modelo iterativo

La tarea se divide en subtareas y se determina el orden de su implementación, de modo que cada subtarea posterior amplíe las capacidades del software. El éxito depende esencialmente de qué tan bien se dividan las tareas en subtareas y cómo se elija el orden. Ventajas: 1) la posibilidad de participación activa del cliente en el desarrollo, tiene la oportunidad de aclarar sus requisitos en el curso del desarrollo; 2) la capacidad de probar piezas desarrolladas recientemente junto con otras desarrolladas previamente, esto reducirá el costo de la depuración compleja; 3) durante el desarrollo, puede comenzar a implementar en partes.

Deberíamos empezar por definirCiclo de vida del software(Software Life Cycle Model) es un período de tiempo que comienza desde el momento en que se toma la decisión de crear un producto de software y finaliza en el momento en que se retira completamente del servicio. Este ciclo es el proceso de construcción y desarrollo de software.

Modelos de ciclo de vida del software

El ciclo de vida se puede representar en forma de modelos. Actualmente los más comunes son:en cascada, incremental (modelo por etapas con control intermedio ) y espiralmodelos de ciclo de vida.

modelo en cascada

modelo en cascada(ing. modelo de cascada) es un modelo del proceso de desarrollo de software, cuyo ciclo de vida parece un flujo que pasa secuencialmente a través de las fases de análisis de requisitos, diseño. implementación, pruebas, integración y soporte.

El proceso de desarrollo se implementa utilizando una secuencia ordenada de pasos independientes. El modelo establece que cada paso subsiguiente comienza después de la finalización del paso anterior. En todos los pasos del modelo, se realizan procesos y trabajos auxiliares y organizativos, incluida la gestión de proyectos, la evaluación y la gestión de la calidad, la verificación y certificación, la gestión de la configuración y el desarrollo de la documentación. Como resultado de la finalización de los pasos, se forman productos intermedios que no se pueden cambiar en los pasos posteriores.

El ciclo de vida se divide tradicionalmente en los siguientesetapas:

Análisis de requerimientos,
Diseño,
Codificación (programación),
Prueba y depuración,
Operación y mantenimiento.

Ventajas del modelo:

estabilidad de los requisitos a lo largo del ciclo de vida del desarrollo;
en cada etapa, se forma un conjunto completo de documentación del proyecto que cumple con los criterios de integridad y consistencia;
la certeza y comprensibilidad de los pasos del modelo y la sencillez de su aplicación;
las etapas de trabajo realizadas en una secuencia lógica le permiten planificar el tiempo de finalización de todo el trabajo y los recursos correspondientes (monetarios, materiales y humanos).

Desventajas del modelo:

la complejidad de formular claramente los requisitos y la imposibilidad de su cambio dinámico durante el ciclo de vida completo;
poca flexibilidad en la gestión de proyectos;
subsecuencia estructura lineal proceso de desarrollo, como resultado de volver a los pasos anteriores para resolver los problemas emergentes conduce a un aumento de los costos y la interrupción del horario de trabajo;
inadecuación del producto intermedio para su uso;
imposibilidad de modelado flexible de sistemas únicos;
detección tardía de problemas relacionados con la construcción debido a la integración simultánea de todos los resultados al final del desarrollo;
participación insuficiente del usuario en la creación del sistema, al principio (durante el desarrollo de requisitos) y al final (durante las pruebas de aceptación);
los usuarios no pueden estar convencidos de la calidad del producto desarrollado hasta el final de todo el proceso de desarrollo. No tienen la oportunidad de evaluar la calidad, porque no pueden ver el producto terminado del desarrollo;
el usuario no tiene la oportunidad de acostumbrarse gradualmente al sistema. El proceso de aprendizaje ocurre al final del ciclo de vida, cuando el software ya se puso en funcionamiento;
cada fase es un requisito previo para la ejecución de acciones posteriores, lo que hace que dicho método sea una opción arriesgada para sistemas que no tienen análogos, porque. no se presta a un modelado flexible.

Es difícil implementar el modelo de ciclo de vida en cascada debido a la complejidad de desarrollar PS sin volver a los pasos anteriores y cambiar sus resultados para eliminar los problemas emergentes.

Alcance del modelo en cascada

La limitación del alcance del modelo en cascada está determinada por sus deficiencias. Su uso es más efectivo en los siguientes casos:

al desarrollar proyectos con claras e inalterablesciclo vital requisitos comprensibles por implementación y metodologías técnicas;
al desarrollar un proyecto enfocado a construir un sistema o producto del mismo tipo que el desarrollado previamente por los desarrolladores;
al desarrollar un proyecto relacionado con la creación y lanzamiento nueva versión un producto o sistema existente;
al desarrollar un proyecto relacionado con la transferencia de un producto o sistema existente a una nueva plataforma;
cuando se realizan proyectos grandes que involucran varios equipos de desarrollo grandes.

modelo incremental

(modelo por etapas con control intermedio)

modelo incremental(ing. incremento- aumentar, incrementar) implica el desarrollo de software con una secuencia lineal de etapas, pero en varios incrementos (versiones), es decir con mejoras planificadas del producto mientras el ciclo de vida del desarrollo de software llegue a su fin.

El desarrollo de software se lleva a cabo en iteraciones con ciclos. retroalimentación entre etapas. Los ajustes entre etapas permiten tener en cuenta la influencia mutua real de los resultados de desarrollo en varias etapas, el tiempo de vida de cada una de las etapas se extiende durante todo el período de desarrollo.

Al comienzo del trabajo en el proyecto, se determinan todos los requisitos básicos para el sistema, divididos en más y menos importantes. Posteriormente, el desarrollo del sistema se realiza de forma incremental, de forma que el desarrollador pueda utilizar los datos obtenidos durante el desarrollo del software. Cada incremento debe agregar cierta funcionalidad al sistema. En este caso, la liberación comienza con los componentes con la prioridad más alta. Cuando las partes del sistema estén definidas, tome la primera parte y comience a detallarla usando el proceso más apropiado para esto. Al mismo tiempo, es posible refinar los requisitos para otras partes que se han congelado en el conjunto actual de requisitos de este trabajo. Si es necesario, puede volver a esta parte más tarde. Si la pieza está lista, se entrega al cliente, quien puede utilizarla en su obra. Esto permitirá al cliente aclarar los requisitos para los siguientes componentes. Luego desarrollan la siguiente parte del sistema. Los pasos clave en este proceso son simplemente implementar un subconjunto de requisitos de software y refinar el modelo en una serie de versiones sucesivas hasta que se implemente todo el software.

El ciclo de vida de este modelo es típico para el desarrollo de complejos y sistemas complejos para lo cual existe una visión clara (tanto por parte del cliente como del desarrollador) de cuál debe ser el resultado final. El desarrollo de la versión se lleva a cabo por varias razones:

la falta de capacidad del cliente para financiar inmediatamente todo el costoso proyecto;
la falta de los recursos necesarios para que el desarrollador implemente un proyecto complejo en poco tiempo;
requisitos para la implementación y el desarrollo por etapas del producto por parte de los usuarios finales. La introducción de todo el sistema a la vez puede provocar rechazo entre sus usuarios y solo “ralentizar” el proceso de transición a las nuevas tecnologías. Hablando en sentido figurado, simplemente pueden “no digerir una pieza grande, por lo que debe triturarse y darse en partes”.

Ventajas y limitacionesde este modelo (estrategia) son los mismos que los de la cascada (modelo clásico del ciclo de vida). Pero a diferencia de la estrategia clásica, el cliente puede ver los resultados antes. Ya basado en los resultados del desarrollo e implementación de la primera versión, puede cambiar ligeramente los requisitos para el desarrollo, abandonarlo o sugerir el desarrollo de más producto perfecto con un nuevo contrato.

ventajas:

se reducen los costos incurridos debido a los requisitos cambiantes del usuario, el reanálisis y la recopilación de documentación se reducen significativamente en comparación con el modelo en cascada;
es más fácil obtener comentarios del cliente sobre el trabajo realizado: los clientes pueden expresar sus comentarios sobre las piezas terminadas y pueden ver lo que ya se ha hecho. Porque las primeras partes del sistema son el prototipo del sistema como un todo.
el cliente tiene la capacidad de adquirir y dominar rápidamente el software; los clientes pueden obtener beneficios reales del sistema antes de lo que sería posible con el modelo en cascada.

Desventajas del modelo:

los gerentes deben medir constantemente el progreso del proceso. en el caso de un desarrollo rápido, no vale la pena crear documentos para cada cambio mínimo de versión;
la estructura del sistema tiende a deteriorarse cuando se agregan nuevos componentes; los cambios constantes alteran la estructura del sistema. Para evitar esto, se requiere tiempo y dinero adicionales para la refactorización. Una estructura deficiente hace que el software sea difícil y costoso de modificar posteriormente. Y el ciclo de vida del software interrumpido conduce a pérdidas aún mayores.

El esquema no permite tener en cuenta rápidamente los cambios emergentes y las aclaraciones de los requisitos del software. La coordinación de los resultados de desarrollo con los usuarios se lleva a cabo solo en los puntos planificados después de la finalización de cada etapa del trabajo, y los requisitos generales para el software se fijan en forma de una tarea técnica durante todo el tiempo de su creación. Así, los usuarios a menudo reciben software que no satisface sus necesidades reales.

modelo espiral

Modelo espiral:Ciclo de vida: en cada giro de la espiral, se crea la siguiente versión del producto, se especifican los requisitos del proyecto, se determina su calidad y se planifica el trabajo del próximo giro. Atención especial se da a las etapas iniciales de desarrollo - análisis y diseño, donde se comprueba y justifica la viabilidad de determinadas soluciones técnicas mediante la creación de prototipos.

Este modelo es un proceso de desarrollo de software que combina el diseño y la creación de prototipos por etapas para combinar los beneficios de los conceptos de abajo hacia arriba y de arriba hacia abajo, enfatizando fases iniciales Ciclo de vida: análisis y diseño.Rasgo distintivo Este modelo supone una especial atención a los riesgos que afectan a la organización del ciclo de vida.

En las etapas de análisis y diseño, se comprueba la viabilidad de las soluciones técnicas y el grado de satisfacción de las necesidades del cliente mediante la creación de prototipos. Cada vuelta de la espiral corresponde a la creación de un fragmento viable o versión del sistema. Esto le permite aclarar los requisitos, objetivos y características del proyecto, determinar la calidad del desarrollo y planificar el trabajo del próximo giro de la espiral. Por lo tanto, los detalles del proyecto se profundizan y concretan de manera consistente y, como resultado, se selecciona una opción razonable que cumple con los requisitos reales del cliente y se lleva a la implementación.

Ciclo de vida en cada vuelta de la espiral: se pueden aplicar diferentes modelos del proceso de desarrollo de software. El resultado final es un producto terminado. El modelo combina las capacidades de un modelo de creación de prototipos ymodelo de cascada. El desarrollo por iteraciones refleja el ciclo en espiral objetivamente existente de creación de sistemas. La finalización incompleta del trabajo en cada etapa le permite pasar a la siguiente etapa sin esperar la finalización completa del trabajo en la etapa actual. la tarea principal- tan pronto como sea posible, mostrar a los usuarios del sistema un producto viable, activando así el proceso de aclaración y complementación de requisitos.

Ventajas del modelo:

le permite mostrar rápidamente a los usuarios del sistema un producto viable, activando así el proceso de aclarar y complementar los requisitos;
permite cambios en los requisitos durante el desarrollo de software, lo cual es típico para la mayoría de los desarrollos, incluidos los estándar;
el modelo prevé la posibilidad de un diseño flexible, ya que incorpora las ventajas del modelo en cascada, y al mismo tiempo se permiten iteraciones sobre todas las fases del mismo modelo;
le permite obtener un sistema más confiable y estable. A medida que el software evoluciona, se encuentran y corrigen errores y debilidades en cada iteración;
este modelo permite a los usuarios participar activamente en la planificación, análisis de riesgos, desarrollo, así como en la realización de actividades de evaluación;
reducir el riesgo del cliente. El cliente puede completar el desarrollo de un proyecto poco prometedor con pérdidas financieras mínimas;
La retroalimentación de los usuarios a los desarrolladores se realiza con alta frecuencia y al principio del modelo, lo que garantiza que el producto deseado sea de alta calidad.

Desventajas del modelo:

si el proyecto es de bajo riesgo o pequeño, el modelo puede ser costoso. La evaluación de riesgos después de cada espiral es costosa;
El ciclo de vida del modelo tiene una estructura complicada, por lo que su aplicación por parte de desarrolladores, administradores y clientes puede resultar difícil;
la espiral puede continuar indefinidamente, ya que la respuesta de cada cliente a la versión creada puede generar un nuevo ciclo, lo que retrasa la finalización del proyecto;
un gran número de ciclos intermedios puede dar lugar a la necesidad de tramitar documentación adicional;
el uso del modelo puede ser costoso e incluso inasequible, porque tiempo. el gasto en planificación, reorientación, realización de análisis de riesgos y creación de prototipos puede ser excesivo;
puede ser difícil definir objetivos e hitos que indiquen la preparación para continuar el proceso de desarrollo en el próximo y

El principal problema del ciclo espiral es determinar el momento de transición a la siguiente etapa. Para solucionarlo, se introducen límites de tiempo para cada una de las etapas.ciclo vital y la transición procede de acuerdo con el plan, incluso si no se completa todo el trabajo planificado.Planificaciónproducido sobre la base de datos estadísticos obtenidos en proyectos anteriores y experiencia personal desarrolladores

Alcance del modelo espiral

El uso del modelo en espiral es recomendable en los siguientes casos:

al desarrollar proyectos utilizando nuevas tecnologías;
al desarrollar series nuevas productos o sistemas;
al desarrollar proyectos con cambios significativos esperados o adiciones a los requisitos;
para la implementación de proyectos a largo plazo;
al desarrollar proyectos que requieran demostración de la calidad y versiones de un sistema o producto en un corto período de tiempo;
al desarrollar proyectos. para lo cual es necesario calcular los costes asociados a la evaluación y resolución de riesgos.

5.6. Modelos y etapas del ciclo de vida del software

Modelos y etapas del ciclo de vida del software

Tipos de modelos de ciclo de vida del software

Modelo de cascada (ciclo de vida clásico)

Modelo iterativo del ciclo de vida de PS

Prototipos

Estrategias de diseño de software

modelo incremental

Modelo de ciclo de vida de software en espiral

Proceso racional unificado

MSF (Marco de soluciones de Microsoft)

5.2. Los principales procesos del ciclo de vida del PS.

Modelos de ciclo de vida del software

modelo en cascada

Alcance del modelo en cascada

modelo incremental

modelo espiral

Alcance del modelo espiral

Contenido relacionado: