¿Cuáles son las diferencias entre los modelos utilizados por las empresas de software dedicadas al desarrollo de software?

El primer modelo de desarrollo de software que apareció fue el modelo en cascada propuesto por W. Royce en 1970. Este modelo proporciona una secuencia fija, que hace la transición de las actividades del ciclo de vida de la etapa anterior a la siguiente paso a paso, como agua que fluye hacia abajo, y finalmente el producto de software desarrollado se obtiene y se pone en uso. Sin embargo, cuando la informática se extiende a campos como el análisis estadístico y los asuntos comerciales, la mayoría de los programas se escriben en lenguajes de alto nivel (como FORTRAN, COBOL, etc.). El modelo en cascada también tiene deficiencias, como la falta de flexibilidad y la incapacidad de aclarar requisitos que de otra manera no estarían claros a través de actividades concurrentes. Los modelos de desarrollo de software comunes incluyen el modelo de evolución, el modelo en espiral, el modelo de fuente, el modelo inteligente, etc. Edite este párrafo Modelos de desarrollo típicos Los modelos de desarrollo típicos incluyen:

1. Modelo de construcción y reparación;

2. Modelo en cascada

3. Modelo Prototipo;

4. Modelo Incremental (Modelo Incremental);

5. Modelo Espiral;

6. 7. Modelo inteligente (tecnología de cuarta generación (4GL));

8. Modelo híbrido;

modelo 9.RUP;

modelo 10.IPD

1. Modifique el modelo mientras lo hace (modelo de construcción y reparación)

Desafortunadamente, muchos productos se desarrollan utilizando el modelo "arreglar sobre la marcha". En este modelo no hay especificaciones ni diseño, 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 es malo 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, lo que hace imposible continuar con las modificaciones.

(2) Ignorar los vínculos de requisitos, lo que genera grandes riesgos; desarrollo de software;

(3) No se considera la mantenibilidad de las pruebas y los programas, 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, fue el único modelo de desarrollo de software ampliamente adoptado.

En el modelo en cascada, como se muestra en la figura, el ciclo de vida del software se divide en seis actividades básicas, como planificación, análisis de la demanda, diseño de software, redacción de programas, pruebas y operación y mantenimiento del software, y sus Se estipulan actividades automáticas. El orden fijo de arriba a abajo, conectándose entre sí, es 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 de desarrollo de software modernos. Casi ha sido abandonado por la industria. Sus principales problemas son:

(1) La división de cada uno. La etapa es completamente fija. Se genera una gran cantidad de documentos, lo que aumenta en gran medida 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 traerá 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 será 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 y 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 del modelo de prototipo rápido 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 un efecto significativo. La clave para la creación rápida de prototipos es construir prototipos de software lo más rápido posible y luego descartarlos una vez que se determinan las verdaderas necesidades del cliente. 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

También conocido como modelo evolutivo. Al igual que la construcción de un edificio, el software 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 subconjunto de productos ejecutables que satisfacen las 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 los siguientes defectos:

(1) Dado que cada componente se incorpora gradualmente a la arquitectura de software existente, agregar componentes no debe destruir las partes del sistema ya construidas. arquitectura abierta.

(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 combina el modelo en cascada y el modelo de creación rápida de prototipos. análisis ignorado por otros modelos y es particularmente adecuado para sistemas grandes y complejos.

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

(1) Desarrollar un plan: determinar los objetivos del software y seleccionar una implementación. planificar, aclarar las 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 del 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 limitaciones 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, por lo tanto, dar respuestas relevantes. , 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 buscar posibles riesgos y analizarlos con precisión; de lo contrario, traerá mayores riesgos.

Una etapa primero determina los objetivos de la etapa, las opciones para lograr estos objetivos y sus limitaciones, y luego analiza la estrategia de desarrollo del programa desde una perspectiva de riesgo, tratando de eliminar varios riesgos potenciales, a veces a través de Prototipo de construcción para completar. 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 de fuente (también llamado modelo de vida orientado a objetos, modelo OO)

En comparación con el tiempo de vida estructurado tradicional, el modelo de fuente tiene una naturaleza más incremental e iterativa. Las etapas del ciclo de vida pueden superponerse e iterarse varias veces, y los períodos de subvida también pueden integrarse a lo largo del 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.

7. 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 método requiere el soporte del 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.

8. 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. 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. Comparación de varios modelos Cada organización de desarrollo de software debe elegir un modelo de desarrollo de software que sea adecuado para la organización y debe cambiarlo con las características específicas del producto que se está desarrollando actualmente para reducir las deficiencias del modelo seleccionado y aprovechar al máximo sus ventajas.

Modelo 9.RUP

El modelo RUP (Rational Unified Process) es un conjunto de modelos de procesos de desarrollo propuestos por Rational. Es un proceso de negocio común para la ingeniería de software orientada a objetos. Describe una serie de procesos de ingeniería de software relacionados que tienen la misma estructura, es decir, la misma arquitectura de proceso. RUP proporciona un método estandarizado para asignar tareas y responsabilidades dentro de una organización de desarrollo, con el objetivo de garantizar que el software de alta calidad que satisfaga las necesidades del usuario final se desarrolle dentro de un cronograma y presupuesto predecibles. RUP tiene dos ejes, uno es la línea de tiempo, que es dinámico. El otro eje es el eje del flujo de trabajo, que es estático. En el cronograma, RUP se divide en cuatro etapas: etapa inicial, etapa de refinamiento, etapa de construcción y etapa de lanzamiento. El concepto de iteración se utiliza en cada etapa. En el eje del flujo de trabajo, RUP ha diseñado seis flujos de trabajo principales y tres flujos de trabajo de soporte principales. El eje del flujo de trabajo principal incluye: flujo de trabajo de modelado de negocios, flujo de trabajo de requisitos, flujo de trabajo de análisis y diseño, flujo de trabajo de implementación y flujo de trabajo de prueba y flujo de trabajo de publicación. Los flujos de trabajo de soporte principales incluyen: flujo de trabajo del entorno, flujo de trabajo de gestión de proyectos y flujo de trabajo de gestión de cambios y configuración. RUP reúne las mejores prácticas en el desarrollo de software moderno y proporciona un formato flexible para adaptarse a las necesidades de diversos proyectos y organizaciones. Como modelo de negocio, tiene plantillas y guías de procesos muy detalladas. Sin embargo, debido a que el modelo es relativamente complejo, se requiere un costo relativamente alto para dominarlo. En particular, impone exigencias relativamente altas a los directores de proyectos.

Tiene las siguientes características:

(1) Iteración incremental, cada iteración sigue el modelo en cascada para controlar y resolver riesgos en la etapa inicial;

( 2) La complejidad del modelo requiere que los directores de proyectos tengan sólidas capacidades de gestión.

10.Modelo IPD

El proceso IPD (Desarrollo Integrado de Productos) es un conjunto de procesos integrados de desarrollo de productos propuestos por IBM. Es muy adecuado para proyectos de desarrollo complejos a gran escala, especialmente. involucrando Un proyecto que combina software y hardware.

IPD parte de la perspectiva de todo el producto, y el proceso considera de manera integral todo, desde la ingeniería de sistemas, la investigación y el desarrollo (hardware, software, diseño industrial estructural, pruebas, desarrollo de datos, etc.), fabricación, desde finanzas hasta marketing, adquisiciones, soporte técnico, etc. Todos los procesos. Es un proceso de principio a fin.

El proceso IPD se divide en seis etapas (etapa de concepto, etapa de planificación, etapa de desarrollo, etapa de verificación, etapa de lanzamiento y etapa de ciclo de vida) y cuatro puntos de revisión de decisiones (etapa de revisión de decisiones). puntos de revisión de decisiones de la fase de planificación, puntos de revisión de decisiones de disponibilidad y puntos de revisión de decisiones de final de vida útil) y seis puntos de revisión técnica.

El proceso IPD es un modelo por etapas con sombras del modelo en cascada. Este modelo descompone un sistema grande y complejo y reduce los riesgos mediante el uso de procesos integrales y complejos. Hasta cierto punto, este modelo utiliza los costos de proceso para mejorar la calidad de todo el producto y ganar participación de mercado. Dado que este proceso no define un mecanismo para la reversión del proceso, este proceso no es adecuado para proyectos con requisitos que cambian con frecuencia. Y para algunos proyectos pequeños, este proceso no es muy adecuado.