Notas de estudio de "Modelado y diseño de software" (3) - modelo y proceso del ciclo de vida del software
1. El modelo en cascada es el primer modelo de ciclo de vida del software ampliamente utilizado.
1.1 Modelo de ciclo de vida en cascada
El modelo de cascada es un modelo de proceso idealizado, que estipula que la siguiente etapa solo puede iniciarse después de la finalización de cada etapa. Además, un proyecto pasa de una etapa a la siguiente sin iteración ni repetición.
1.2 Limitaciones del Modelo Cascada
(1) Como factor clave en un proyecto de desarrollo de software, los requisitos del software no pueden probarse hasta que se desarrolle un sistema funcional y se demuestre a los usuarios finales.
(2) Solo puede obtener un sistema que funcione más adelante en el ciclo de vida.
1.3 Prototipo desechable
Ayuda a aclarar las necesidades del usuario. Se puede utilizar para determinar si determinados algoritmos son lógicamente correctos o para determinar si cumplen los objetivos de rendimiento.
1.4 Prototipo evolutivo mediante desarrollo incremental
Es una forma de desarrollo incremental en la que el prototipo evoluciona gradualmente desde un sistema ejecutable en varios pasos intermedios hasta un sistema entregable. Este método se puede usar para determinar si el sistema cumple con los objetivos de rendimiento y se usa para probar componentes críticos cubiertos en el diseño. Además, el riesgo de desarrollo se reduce al extender la implementación durante un período de tiempo más largo.
1.5 Combinación de prototipo desechable y desarrollo incremental
Un sistema de trabajo en forma de prototipo evolutivo se puede obtener antes.
Nota: La calidad del software debe tenerse en cuenta desde el principio, no debe agregarse como una ocurrencia tardía. En particular, la arquitectura del software debe diseñarse cuidadosamente y todas las interfaces deben especificarse.
1.6 Modelo espiral
es un modelo de proceso impulsado por el riesgo. Destinado a cubrir otros modelos de ciclo de vida.
Contiene 4 cuadrantes:
(1) Definir los objetivos, los métodos candidatos y las restricciones . Un plan detallado para este ciclo: identificación de objetivos y varios métodos candidatos para alcanzarlos.
(2) Analizar los riesgos . Llevar a cabo una evaluación detallada de los riesgos actuales del proyecto; planificar las actividades que se realizarán para mitigar los riesgos.
(3) Desarrollar productos . Realice el desarrollo de productos, como el análisis de requisitos, el diseño o la codificación.
(4) Planificar el próximo ciclo . Evalúe los resultados de este ciclo y comience a planificar el próximo ciclo.
1.7 Proceso unificado de desarrollo de software
Un proceso de software basado en casos de uso que utiliza notación UML. USDP/RUP es un proceso de desarrollo de software basado en UML.
1.7.1 USDP
Contiene 5 flujos de trabajo principales y 4 etapas. USDP es iterable.
Los artefactos se definen como información producida, modificada o utilizada por un proceso.
Un flujo de trabajo se define como una secuencia de actividades que produce un resultado observable.
Una etapa se define como el período de tiempo entre dos hitos durante el cual se cumple un conjunto de objetivos de desarrollo predefinidos, se completan algunos artefactos y se toma la decisión de pasar a la siguiente etapa.
Cada flujo de trabajo y sus productos:
(1) Demanda . El producto del flujo de trabajo de requisitos es el modelo de caso de uso.
(2) Análisis . El producto del flujo de trabajo de análisis es el modelo de análisis.
(3) Diseño . Los productos del flujo de trabajo de diseño son el modelo de diseño y el modelo de implementación.
(4) Darse cuenta . El producto del flujo de trabajo de implementación es el modelo de implementación.
(5) PRUEBA . El producto del flujo de trabajo de prueba es el modelo de prueba.
Las etapas del ciclo de vida de USDP son las siguientes:
(1) Inicial . En la fase de Inicio, las ideas iniciales se desarrollan a un nivel suficiente para demostrar la capacidad de pasar a la fase de Elaboración.
(2) Refinamiento . En la fase de Elaboración se define la arquitectura del software.
(3) Estructura . Durante la fase de construcción, se desarrolla un producto de software que se puede lanzar a los usuarios.
(4) ENTREGA . Durante la fase de entrega, el software se entrega al usuario.
2. Verificación y validación del diseño
Confirmación de programas . El objetivo es garantizar que el equipo de desarrollo de software "construya el sistema correcto".
Validación de programas . El objetivo es garantizar que el equipo de desarrollo de software "construya el sistema correctamente".
2.1 Garantía de calidad del software
Se refiere a una serie de actividades para asegurar la calidad de los productos de software. Un objetivo importante es la verificación y validación del software.
La revisión técnica del software puede ser de gran ayuda para la verificación y validación del software.
2.2 Análisis de rendimiento del diseño de software
Es necesario analizar el rendimiento del diseño del software para evaluar si el diseño cumple con los objetivos de rendimiento antes de implementar el sistema.
Los métodos para evaluar diseños de software utilizan modelos de colas y modelos de simulación.
Para sistemas paralelos , las redes de Petri se pueden usar para modelar y analizar diseños paralelos.
Un enfoque descrito en (Gomaa 2000) es analizar el rendimiento de los diseños en tiempo real mediante el uso de la teoría de programación en tiempo real .
3. Actividades en el ciclo de vida del software
Las actividades de ingeniería de software realizarán los siguientes pasos:
3.1 Análisis y especificación de requisitos
Identificar y analizar las necesidades de los usuarios.
3.2 Diseño de arquitectura
Una arquitectura de software separa la estructura general del sistema de los detalles de implementación interna de los componentes individuales describiendo los componentes y cómo están conectados.
3.3 Diseño detallado
Defina los detalles algorítmicos de cada componente del sistema.
3.4, codificación
Codifique cada componente utilizando el lenguaje de programación elegido para el proyecto.
4. Pruebas de software
Las pruebas de software se realizan en varias fases.
Las pruebas unitarias y las pruebas de integración son métodos de prueba de " caja blanca " que requieren un conocimiento interno del software.
La prueba del sistema es un método de prueba de " caja negra " basado en la especificación de requisitos de software y no necesita comprender la estructura interna del software.
4.1 Pruebas unitarias
Indica que los componentes individuales se prueban individualmente antes de combinarlos con otros componentes.
método _ Directrices de cobertura de prueba.
Los criterios de cobertura de prueba incluyen cobertura de estado de cuenta y cobertura de sucursal .
4.2 Pruebas de integración
Los componentes individuales que se han probado se combinan gradualmente en grupos de construcción más complejos, y luego estos componentes se prueban hasta que se combinan en un sistema de software completo y se prueban las interfaces entre los componentes.
4.3 Prueba del sistema
El proceso de probar un sistema integrado de hardware y software para verificar que el sistema cumple con los requisitos especificados.
Es necesario probar varias características de un sistema de software:
pruebas funcionales . Determinar que el sistema realiza las funciones descritas en la especificación de requisitos.
Pruebas de carga (estrés) . Determine si el sistema será capaz de manejar la carga grande y variable planeada cuando esté funcionando.
Pruebas de rendimiento . El sistema de prueba cumple con los requisitos para responder a los eventos.
4.4 Prueba de aceptación
La prueba de aceptación la realiza la organización usuaria o sus representantes antes de aceptar el sistema, generalmente durante la fase de instalación del usuario.
5. Resumen
El desarrollo de software se describe desde la perspectiva del ciclo de vida del software, donde se describen y comparan brevemente diferentes tipos de modelos de ciclo de vida del software, también conocidos como modelos de proceso de software. También se analizan los roles de la verificación y validación del diseño y las pruebas de software.
6. Practica
( 1 ) ¿Qué es el ciclo de vida del software? Un enfoque por fases para desarrollar software.
(2) ¿Qué es el modelo de ciclo de vida en cascada? Un modelo de proceso en el que cada fase se completa antes de que comience la siguiente fase.
( 3 ) ¿Cuál de las siguientes representa una limitación del modelo de ciclo de vida en cascada? A menos que se desarrolle un sistema utilizable, no es adecuado para probar los requisitos del software.
( 4 ) ¿Cuál de los siguientes métodos puede superar las limitaciones señaladas en la pregunta anterior: desechar el prototipo?
( 5 ) ¿Qué es la creación de prototipos evolutivos? Desarrollo de software por fases
(6) ¿Cuál es el método enfatizado por el modelo espiral - desarrollo impulsado por el riesgo?
(7) ¿Cuál es el objetivo de la validación del software? Construir un sistema correcto
(8) ¿Cuál es el objetivo de la verificación del software? Construir el sistema correctamente.
(9) ¿Qué es una prueba de "caja blanca"? Una prueba que utiliza el conocimiento interno del sistema.
( 10 ) ¿Qué es una prueba de "caja negra"? Una prueba que no utiliza el conocimiento interno del sistema.