¿Presentar los principios, ventajas y desventajas de los modelos de procesos de software comunes (en cascada, prototipo, incremental, en espiral)? Si respondes bien obtendrás 200 puntos.

Los modelos de desarrollo típicos incluyen: modelo en cascada, modelo incremental/evolución/iteración (modelo incremental), modelo prototipo (modelo prototipo), modelo en espiral (modelo en espiral), modelo de fuente (modelo de fuente), modelo inteligente modelo (modelo inteligente), modelo híbrido (modelo híbrido)

1. Modelo Build-and-Fix (modelo Build-and-Fix)

Desafortunadamente, muchos productos se desarrollan utilizando un modelo de "cambio a medida que se hace". En este modelo no hay especificaciones ni diseños, y el software se modifica constantemente una y otra vez según lo necesitan los clientes.

En este modelo, los desarrolladores obtienen el proyecto e inmediatamente escriben el programa de acuerdo con los requisitos. Después de pasar la depuración, se genera la primera versión del software. Después de proporcionarlo a los usuarios, si ocurre un error en el programa o el usuario presenta nuevos requisitos, el desarrollador volverá a modificar el código hasta que el usuario esté satisfecho.

Este es un método de desarrollo similar a un taller, que no está mal para escribir programas pequeños de unos pocos cientos de líneas, pero este método no es satisfactorio para cualquier escala de desarrollo. Los principales problemas son:

1) Falta de vínculos de planificación y diseño, la estructura del software está empeorando con modificaciones continuas, imposibilitando continuar con las modificaciones.

2) Ignorar el vínculo de demanda, trae grandes riesgos; desarrollo de software;

3) No se consideran las pruebas ni la mantenibilidad del programa, y ​​no hay documentación, lo que dificulta mucho el mantenimiento del software.

2. Modelo en cascada

En 1970, Winston Royce propuso el famoso "Modelo en cascada". Hasta principios de la década de 1980, era el único modelo que era un modelo de desarrollo de software ampliamente adoptado.

El modelo en cascada divide el ciclo de vida del software en seis actividades básicas: planificación, análisis de requisitos, diseño de software, redacción de programas, pruebas y operación y mantenimiento de software, y estipula sus actividades de arriba hacia abajo e interconectadas. secuencia, como una cascada, cayendo paso a paso.

En el modelo en cascada, varias actividades de desarrollo de software se llevan a cabo de manera estrictamente lineal. La actividad actual acepta los resultados del trabajo de la actividad anterior e implementa el contenido del trabajo requerido. Los resultados del trabajo de la actividad actual deben verificarse. Si se aprueba la verificación, el resultado se utilizará como entrada de la siguiente actividad y se continuará con la siguiente. De lo contrario, se devolverá para su modificación.

El modelo en cascada enfatiza el papel de la documentación y requiere una verificación cuidadosa en cada etapa. Sin embargo, el proceso lineal de este modelo es demasiado ideal y ya no es adecuado para los modelos modernos de desarrollo de software. Casi ha sido abandonado por la industria. Sus principales problemas son:

1) La división de cada etapa. es completamente fijo y las etapas se generan una gran cantidad de documentos durante el proceso, lo que aumenta enormemente la carga de trabajo

2) Dado que el modelo de desarrollo es lineal, los usuarios solo pueden ver los resultados del desarrollo hasta el final; de todo el proceso, aumentando así el riesgo de desarrollo;

3) Es posible que los errores tempranos no se descubran hasta la fase de prueba del desarrollo tardío, lo que puede tener graves consecuencias.

Debemos darnos cuenta de que "lineal" es la forma de pensar más fácil de dominar y aplicar hábilmente para las personas. Cuando las personas se encuentran con un problema complejo "no lineal", siempre hacen todo lo posible para descomponerlo o transformarlo en una serie de problemas lineales simples y luego resolverlos uno por uno. Un sistema de software en su conjunto puede ser complejo, pero una única subrutina siempre es simple y puede implementarse de manera lineal; de lo contrario, el trabajo resultará demasiado agotador. La linealidad es una especie de simplicidad y la simplicidad es belleza. Cuando comprendamos el espíritu de la linealidad, ya no deberíamos aplicar rígidamente la apariencia del modelo lineal, sino que deberíamos hacer uso de él.

Por ejemplo, el modelo incremental es esencialmente un modelo lineal segmentado, mientras que el modelo en espiral es un modelo lineal curvo continuo. También se pueden encontrar sombras del modelo lineal en otros modelos.

3. Modelo de prototipo rápido

El primer paso en el modelo de creación de prototipos rápidos es construir un prototipo rápido que permita a los clientes o futuros usuarios interactuar con el sistema. evalúa el prototipo y refina aún más los requisitos del software a desarrollar. Al ajustar gradualmente el prototipo para satisfacer los requisitos del cliente, los desarrolladores pueden determinar cuáles son las necesidades reales del cliente; el segundo paso se basa en el primero para desarrollar un producto de software que satisfaga al cliente.

Obviamente, el método de creación rápida de prototipos puede superar las deficiencias del modelo en cascada y reducir los riesgos de desarrollo causados ​​por requisitos de software poco claros, y tiene efectos significativos.

La clave para la creación rápida de prototipos es construir prototipos de software lo más rápido posible y, una vez determinadas las verdaderas necesidades del cliente, los prototipos se descartarán. Por lo tanto, la estructura interna del sistema prototipo no es importante. Lo importante es que el prototipo debe construirse rápidamente y luego modificarse rápidamente para reflejar las necesidades del cliente.

4. Modelo Incremental

Al igual que construir un edificio, el software también se construye paso a paso. En el modelo incremental, el software se diseña, implementa, integra y prueba como una serie de componentes incrementales. Cada componente está compuesto por fragmentos de código que proporcionan funciones específicas formadas por múltiples módulos interactivos.

El modelo incremental no ofrece un producto ejecutable completo en cada etapa, sino un producto ejecutable que satisface un subconjunto de necesidades del cliente. Todo el producto se descompone en varios componentes y los desarrolladores entregan el producto componente por componente. La ventaja de esto es que el desarrollo de software puede adaptarse mejor a los cambios y los clientes pueden ver continuamente el software desarrollado, lo que reduce los riesgos de desarrollo. Sin embargo, el modelo incremental también tiene las siguientes desventajas:

1) Dado que cada componente se integra gradualmente en la arquitectura de software existente, agregar componentes no debe destruir las partes del sistema ya construidas, lo que requiere que el software tenga un acceso abierto. arquitectura.

2) Durante el proceso de desarrollo, los cambios en los requisitos son inevitables. La flexibilidad del modelo incremental puede hacer que su capacidad para adaptarse a tales cambios sea mucho mejor que el modelo en cascada y el modelo de creación rápida de prototipos, pero también puede degenerar fácilmente en un modelo que se modifica mientras se realiza, de modo que el control del proceso de software. pierde integridad.

Cuando se utiliza el modelo incremental, el primer incremento suele ser el producto principal que satisface las necesidades básicas. Una vez que el producto principal se entrega a los usuarios, se forma el siguiente plan de desarrollo incremental después de la evaluación, que incluye modificaciones al producto principal y el lanzamiento de algunas características nuevas. Este proceso se repite después de cada lanzamiento incremental hasta que se produce el producto final pulido.

Por ejemplo, utilice el modelo incremental para desarrollar software de procesamiento de textos. Se puede considerar que el primer incremento libera funciones básicas de administración de archivos, edición y generación de documentos, el segundo incremento libera funciones más completas de edición y generación de documentos, el tercer incremento implementa funciones de revisión ortográfica y gramatical, y el cuarto incremento implementa funciones de revisión ortográfica y gramatical. funciones Completar de forma incremental funciones avanzadas de diseño de página.

5. Modelo en espiral

En 1988, Barry Boehm publicó oficialmente el "Modelo en espiral" de desarrollo de sistemas de software, que combinaba el modelo en cascada y el modelo prototipo rápido para enfatizar el análisis de riesgos. que otros modelos ignoran y es particularmente adecuado para sistemas grandes y complejos.

El modelo en espiral realiza varias iteraciones a lo largo de la espiral. Los cuatro cuadrantes de la figura representan las siguientes actividades:

1) Hacer planes: determinar los objetivos del software, seleccionar planes de implementación, aclarar los objetivos. limitaciones del desarrollo del proyecto;

2) Análisis de riesgos: analizar y evaluar las opciones seleccionadas, y considerar cómo identificar y eliminar los riesgos

3) Ingeniería de implementación: implementar el desarrollo y verificación de software; ;

4) Evaluación del cliente: Evaluar el trabajo de desarrollo, proponer correcciones y formular próximos planes.

El modelo en espiral está impulsado por el riesgo, enfatiza las alternativas y restricciones para respaldar la reutilización del software y ayuda a integrar la calidad del software como un objetivo especial en el desarrollo de productos. Sin embargo, el modelo en espiral también tiene ciertas limitaciones, como las siguientes:

1) El modelo en espiral enfatiza el análisis de riesgos, pero no es fácil para muchos clientes aceptar y creer en este análisis y dar respuestas relevantes, por lo que, Este modelo suele ser adecuado para el desarrollo interno de software a gran escala.

2) Si realizar un análisis de riesgos afectará en gran medida las ganancias del proyecto, entonces realizar un análisis de riesgos no tiene sentido. Por lo tanto, el modelo en espiral solo es adecuado para proyectos de software a gran escala.

3) Los desarrolladores de software deben ser buenos para encontrar posibles riesgos y analizarlos con precisión; de lo contrario, traerá mayores riesgos.

El primer paso en una etapa es determinar el objetivo de esa etapa. Seleccione soluciones y sus limitaciones para lograr estos objetivos y luego analice la estrategia de desarrollo de la solución desde una perspectiva de riesgo, tratando de eliminar varios riesgos potenciales, a veces mediante la construcción de prototipos. Si ciertos riesgos no se pueden eliminar, el programa se finaliza inmediatamente; de ​​lo contrario, se inicia el siguiente paso de desarrollo. Finalmente, evaluar los resultados de esta fase y diseñar la siguiente.

6. Modelo evolutivo

Dirigido principalmente al desarrollo de software donde los requisitos no se pueden definir completamente de antemano. Los usuarios pueden proporcionar los requisitos básicos del sistema a desarrollar y, después de ver los requisitos básicos implementados, pueden proporcionar comentarios de manera efectiva para respaldar el diseño final y la implementación del sistema. Los desarrolladores de software primero desarrollan el sistema central en función de las necesidades del usuario. Una vez que el sistema central se pone en funcionamiento, los usuarios lo prueban, completan su trabajo y presentan requisitos para perfeccionar el sistema y mejorar sus capacidades. Los desarrolladores de software implementan un proceso iterativo de desarrollo basado en los comentarios de los usuarios. El primer proceso de iteración consta de requisitos, diseño, codificación, pruebas, integración y otras etapas, agregando un subconjunto definible y manejable a todo el sistema.

El modelo de desarrollo adopta un método de desarrollo por lotes y ciclos. Cada ciclo desarrolla una parte de las funciones, que se convierten en las nuevas funciones del prototipo de este producto. Como resultado, el diseño continúa evolucionando hacia nuevos sistemas. De hecho, este modelo puede verse como múltiples "modelos en cascada" ejecutados repetidamente.

El "modelo evolutivo" requiere que los desarrolladores tengan la capacidad de descomponer los requisitos de productos del proyecto en diferentes grupos para el desarrollo cíclico y por lotes. Esta agrupación no es estrictamente arbitraria, sino que se basa en un juicio basado en la importancia funcional y el impacto en la estructura subyacente del diseño general. La experiencia indica que la duración adecuada de cada ciclo de desarrollo es de seis a ocho semanas.

7. Modelo de fuente (modelo de fuente, (modelo de vida orientado a objetos, modelo orientado a objetos, OO)))

Modelo de fuente y vida útil estructurada tradicional En comparación, tiene una vida útil más larga. De naturaleza incremental e iterativa, las diversas etapas del ciclo de vida pueden superponerse entre sí y repetirse varias veces, y los períodos de subvida también pueden incorporarse a lo largo de todo el ciclo de vida del proyecto. Al igual que el agua que se pulveriza hacia arriba y vuelve a caer, puede caer en el medio o en el fondo.

8. Modelo inteligente (tecnología de cuarta generación (4GL))

El modelo inteligente tiene un conjunto de herramientas (como consulta de datos, generación de informes, procesamiento de datos, definición de pantalla, código generación, funciones gráficas de alto nivel y hojas de cálculo, etc.), cada herramienta permite a los desarrolladores definir ciertas características del software en un alto nivel y genera automáticamente el código fuente para este software definido por los desarrolladores. Este enfoque requiere compatibilidad con el lenguaje de cuarta generación (4GL). 4GL se diferencia de la tercera generación de lenguajes su característica principal es que la interfaz de usuario es extremadamente amigable, incluso los programadores no profesionales no capacitados pueden usarlo para escribir programas; es un lenguaje de programación declarativo, interactivo y no procedimental. 4GL también presenta un código de programa eficiente, suposiciones predeterminadas inteligentes, una base de datos completa y un generador de aplicaciones. Los 4GL populares actualmente en el mercado (como Foxpro, etc.) tienen las características anteriores en distintos grados.

Sin embargo, actualmente 4GL se limita principalmente al desarrollo de aplicaciones pequeñas y medianas para sistemas de información de transacciones.

9. Modelo híbrido (modelo híbrido)

El modelo de desarrollo de procesos también se denomina modelo híbrido (modelo híbrido) o metamodelo (metamodelo), que combina varios modelos diferentes. modelos en uno Un modelo híbrido que permite que un proyecto se desarrolle por el camino más eficiente es el modelo de desarrollo de procesos (o modelo híbrido). De hecho, algunas organizaciones de desarrollo de software utilizan varios métodos de desarrollo diferentes para formar sus propios modelos híbridos.

Ventajas y desventajas del modelo

El sistema basado en documentos del modelo en cascada puede no satisfacer las necesidades del cliente

El enfoque del modelo de creación rápida de prototipos en satisfacer las necesidades del cliente puede conducir a un diseño deficiente del sistema y baja eficiencia, difícil de mantener

El desarrollo de modelos incrementales proporciona retroalimentación temprana y es fácil de mantener. Requiere una arquitectura abierta, lo que puede conducir a un diseño deficiente y baja eficiencia

Modelo en espiral. Los analistas de riesgos basados ​​en riesgos deben tener experiencia y estar completamente capacitados

====================

OOA (objeto- Análisis orientado) El modelo consta de 5 niveles (capa temática, capa de clase de objeto, capa de estructura, capa de atributos y capa de servicio) y cinco actividades (identificar clase de objeto, identificar estructura, definir tema, definir atributos y definir servicio). En este método se definen estructuras entre dos clases de objetos, una se llama estructura de clasificación y la otra se llama estructura de ensamblaje. La estructura de clasificación es la denominada relación general y especial. La estructura del conjunto refleja la relación entre el todo y las partes de los objetos.

OOA debe identificar conexiones de instancia mientras define atributos. La conexión de instancia es la relación de mapeo entre una instancia y otra instancia. Al definir servicios, identifique las conexiones de mensajes. Cuando un objeto necesita enviar un mensaje a otro objeto, existe una conexión de mensaje entre ellos.

Los 5 niveles y 5 actividades en OOA continúan a través del proceso OOD (Diseño Orientado a Objetos). El modelo OOD consta de 4 partes. Son la parte del dominio del problema de diseño, la parte de interacción persona-computadora de diseño, la parte de gestión de tareas de diseño y la parte de gestión de datos de diseño.

Booch cree que el desarrollo de software es un proceso en espiral ascendente. En cada ciclo de la espiral, hay cuatro pasos: identificar clases y objetos, determinar su significado, identificar las relaciones entre ellos y describir la interfaz e implementación de cada clase.

La tecnología de modelado de objetos OMT define tres modelos, que son el modelo de objetos, el modelo dinámico y el modelo funcional. OMT utiliza estos tres modelos para describir el sistema. El método OMT tiene 4 pasos: análisis, diseño del sistema, diseño de objetos e implementación. Cada paso del método OMT utiliza estos tres modelos, y cada paso los refina y expande continuamente.

El modelo de objetos describe el sistema incluyendo la estructura estática de los objetos, las relaciones entre objetos, las propiedades de los objetos y las operaciones de los objetos. Además de objetos, clases y herencia, el modelo de objetos OMT también tiene conceptos como cadenas, asociaciones, generalizaciones, agregaciones y módulos.

Los modelos dinámicos se utilizan para describir las características del sistema relacionadas con la transformación de valores: funciones, asignaciones, restricciones y dependencias funcionales. Los modelos funcionales se representan mediante diagramas de flujo de datos.