Modelos de ciclo de vida Clásicos o Modelos secuenciales lineales

Un modelo de proceso se puede definir como una estrategia (también conocida como paradigma de ingeniería de software), que incluye capas de procesos, métodos y herramientas y fases generales del desarrollo de software.

Proporciona la base para controlar las diversas actividades necesarias para desarrollar y mantener software. Además, ayuda al equipo de desarrollo de software a facilitar y comprender las actividades involucradas en el proyecto.

El modelo de proceso para la ingeniería de software depende de la naturaleza y aplicación del proyecto de software. Por lo tanto, se debe definir un modelo de proceso para cada proyecto de software.

IEEE Define un modelo de proceso como "un marco que abarca los procesos, actividades y tareas involucradas en el desarrollo, operación y mantenimiento de un producto de software, que abarca todo el ciclo de vida del sistema desde la definición de los requisitos hasta el final del uso".

El modelo de proceso refleja los objetivos de desarrollo de software, tales como el desarrollo de productos de alta calidad y calendarios de reunión.

Además, proporciona un marco flexible para mejorar el proceso.

Otras ventajas del modelo de proceso de software 

Para lograr una comunicación efectiva: Mejora la comprensión y proporciona una base específica para la ejecución del proceso.

Facilitar la reutilización de procesos: El desarrollo de procesos es una actividad costosa y que requiere mucho tiempo. Por lo tanto, los equipos de desarrollo de software utilizan procesos existentes para diferentes proyectos.

Eficiente: Debido a que el modelo de proceso se puede usar repetidamente, el proceso reutilizable proporciona todos los métodos efectivos para implementar el proceso de desarrollo de software.

Facilitar la gestión de procesos: Un modelo de proceso proporciona un marco para definir los criterios y métricas del estado del proceso para el desarrollo de software.

Por lo tanto, una gestión eficaz es esencial para proporcionar una descripción clara de la planificación de los proyectos de software.

Cada modelo de proceso de desarrollo de software toma requisitos como entrada y entrega un producto como salida. Sin embargo, un proceso debe detectar la etapa en la que ocurren los defectos.

Esto requiere Verificación y Validación (VV) del producto después de cada fase del ciclo de vida del desarrollo del software.

Verificar Es el proceso de evaluación del producto al final de cada fase para comprobar si se cumplen los requisitos. Además, es el proceso de establecimiento de procedimientos y métodos, que proporciona los resultados esperados.

IEEE Define la verificación como "el proceso de determinar si los requisitos y, en última instancia, un sistema o producto de software tal como está construido son satisfactorios para su uso específico previsto".

Por lo tanto, la verificación verifica la funcionalidad del software con suficiente precisión de acuerdo con su especificación de requisitos.

Varios modelos de proceso son:

• El modelo de cascada
• El modelo de prototipo
• El modelo en espiral
• El modelo incremental
• El modelo de caja de tiempo
• El modelo RAD
• El modelo V
• El modelo de construcción y reparación
• El modelo de método formal.

Modelo de cascada

El modelo de cascada (también conocido como modelo clásico del ciclo de vida) es un enfoque secuencial para el desarrollo de software que sigue una secuencia lineal desde el análisis de los requisitos hasta el diseño, la codificación, las pruebas, la integración, la implementación y el mantenimiento. Por lo tanto, el modelo también se llama Modelo de temporización lineal.

El modelo es fácil de entender y representa un proceso fácil de administrar y medir. El modelo de cascada consta de diferentes fases, cada una con sus diferentes objetivos.

Una vez que se completa una fase, el desarrollo de software pasa a la siguiente fase. Cada etapa modifica productos intermedios para desarrollar nuevos productos como salida. El nuevo producto se convierte en la entrada para el siguiente proceso.

Como se mencionó anteriormente, el modelo de cascada consta de varias etapas, que se enumeran a continuación:

Tipos de Modelo de cascada

Sistema/Información Modelado de ingeniería: Esta fase establece los requisitos para todas las partes del sistema.

El software es parte de un sistema más grande al que se asigna un subconjunto de estos requisitos. Esta vista del sistema es necesaria cuando el software interactúa con otras partes del sistema, incluido el hardware, las bases de datos y las personas.

La ingeniería de sistemas implica la recopilación de requisitos a nivel del sistema, mientras que la ingeniería de información incluye la recopilación de requisitos en el nivel en el que se toman todas las decisiones sobre la estrategia comercial.

Análisis de la demanda:

Esta fase se centra en los requisitos del software a desarrollar. Identifica los procesos a incorporar durante el desarrollo de software.

Para especificar los requisitos, las especificaciones de los usuarios deben entenderse claramente y sus requisitos deben analizarse.

Esta fase implica la interacción entre los usuarios y los ingenieros de software y produce lo que se conoce como Especificación de Requerimientos de Software (SRS) documentación.

Diseño:

Esta fase determina el proceso detallado de desarrollo del software después de analizar los requisitos. Toma los requisitos de software definidos por el usuario y los traduce en representaciones de software.

En esta fase, el foco está en encontrar soluciones a los problemas definidos en la fase de análisis de requisitos. Los ingenieros de software se ocupan principalmente de las estructuras de datos, los detalles algorítmicos y las representaciones de la interfaz.

Codificación:

Esta fase se enfoca en la traducción de diseños a lenguajes de programación utilizando estilos y pautas de codificación. El objetivo es crear programas que sean fáciles de leer y comprender.

Para lograrlo, es necesario que todos los programas escritos estén documentados de acuerdo con la especificación.

Prueba:

Una vez completada la fase de codificación, es importante verificar que el software desarrollado cumple con los requisitos del usuario.

Esta es la fase de pruebas, que se enfoca en verificar que el software funciona de manera eficiente con un mínimo de errores. Se prueba tanto la lógica interna como la funcionalidad externa del software.

Es importante destacar que la prueba es una actividad de varias fases que enfatiza la verificación y validación del software.

Implementación y mantenimiento:

En la fase de implementación y mantenimiento, el software se entrega a los usuarios como un programa completamente funcional.

Una vez que el usuario acepta e implementa el software, pueden surgir cambios en el entorno externo, como la actualización del sistema operativo o la adición de nuevos periféricos.

También pueden haber cambios en los usuarios y dominios tecnológicos. Esta fase se enfoca en modificar el software, corregir errores y mejorar su rendimiento.

Ventajas y desventajas del modelo de cascada:

Las diversas ventajas y desventajas asociadas con el modelo de cascada se pueden enumerar en una tabla. Este modelo es un enfoque secuencial para el desarrollo de software que se basa en fases bien definidas y separadas.

Entre las ventajas se encuentran la claridad de los objetivos y la facilidad de seguimiento del progreso. Sin embargo, este modelo no es adecuado para proyectos grandes y complejos, ya que puede ser inflexible y no permite cambios de requisitos.

También puede haber retrasos significativos en el proceso de desarrollo debido a la naturaleza secuencial del modelo.

Ventaja

• relativamente fácil de entender
• Cada etapa del desarrollo procede secuencialmente.
• Permite un control administrativo donde se establece un cronograma con plazos para cada fase de desarrollo.
• Ayuda a controlar la programación, el presupuesto y la documentación.

Desventajas

• Los requisitos deben especificarse antes de proceder con el desarrollo.
• Los cambios de requisitos en las últimas fases del modelo en cascada no se pueden completar. Esto significa que una vez que el software está en versión beta, es difícil incorporar cambios en una etapa tan avanzada.
• Mientras se desarrolla el software, no hay participación del usuario y una versión funcional del software.
• No hay gestión de riesgos involucrada.
• Se supone que los requisitos son estables y fijos a lo largo de la duración del proyecto.