El modelo en cascada es un enfoque clásico en el desarrollo de software que describe un método de desarrollo lineal y secuencial. Consta de cinco a siete fases, cada fase está definida por diferentes tareas y objetivos, por lo que la totalidad de las fases describe el ciclo de vida del software hasta su entrega. Una vez finalizada una fase, sigue el siguiente paso de desarrollo y los resultados de la fase anterior pasan a la siguiente fase.

Antecedentes

El modelo en cascada (o waterfall model en inglés) fue el primer método ampliamente utilizado en la industria del software. Como enfoque tradicional, no es repetitivo en contraste con los modelos ágiles con sprints simples, pero puede ser complementado con bucles de retroalimentación y loopbacks. Todavía se utiliza hoy en día en varias versiones si los requisitos y características de un software pueden ser claramente definidos durante la fase conceptual.

Información general

La primera mención de un modelo en fases se remonta a Winston Royce. En su ensayo “Managing the Development of Large Software Systems” (Gestión del desarrollo de grandes sistemas de software) describió un método de desarrollo para grandes proyectos de software, que se divide en fases ya en 1970. También criticó este enfoque y propuso una alternativa que se asemeja a la creación de prototipos. Royce se refería al “Nine Phase Stage-Wise Model” de Herbert Benington, publicado en 1956. Mientras que Benington preveía nueve fases, Royce las redujo a siete. El término modelo en cascada no fue utilizado por ninguno de los dos. Su uso se basa en un libro de 1976, que trata principalmente de los requisitos para software[1]

Cómo funciona

El modelo original en cascada consta de siete fases sucesivas:[2]

• Requisitos del sistema: La primera fase se ocupa de los requisitos que no están relacionados con el producto digital en sí, sino más bien con aspectos relevantes para la empresa como el precio y la disponibilidad. Aquí también se especifican los aspectos de documentación y seguridad. En general, aquí se mencionan los requisitos no funcionales.
• Requisitos de software: Los requisitos funcionales del software se definen en la segunda fase. La pregunta sobre lo que el software debe ser capaz de hacer se responde aquí y se aclara en “especificaciones”, que también incluye los resultados de la primera fase.
• Análisis de requerimientos: En la fase de análisis de requisitos, las funciones del software se diseccionan y estructuran de modo que los elementos funcionales individuales y las unidades funcionales puedan separarse entre sí. El análisis de necesidades tiene por objeto examinar la viabilidad e importancia de las funciones. Los resultados de esta fase son las especificaciones que contienen los requisitos que hay que desarrollar.
• Diseño de programas: El diseño técnico se implementa ahora con la ayuda de estas especificaciones de requisitos. Los componentes de esta fase también incluyen decisiones sobre la arquitectura de la información y las tecnologías aplicadas, tales como lenguajes de programación, bibliotecas de clases y secuencias de programas. El resultado del diseño del programa se registra generalmente en diagramas que describen el comportamiento teórico del software.
• Implementación: Durante la implementación, las estructuras y los flujos de trabajo se implementan teniendo en cuenta las condiciones marco y los objetivos sistémicos. El diseño de software se convierte en un programa directamente relacionado con un sistema operativo, uno o más lenguajes de programación y la infraestructura. El resultado suele ser un software operativo, a menudo en versión beta.
• Probando: La fase de implementación es seguida por la prueba de todos los componentes de software, módulos y todo el sistema. También se comprueba la integración en sistemas operativos específicos. Si se producen errores y conflictos, deben repararse inmediatamente. Esto podría dar lugar a un aumento de los costes globales, ya que los posibles errores pueden atribuirse a diferentes fases y no siempre se producen en la fase anterior.
• Lanzamiento: El software se implementa después de la aceptación por parte del cliente. Las actualizaciones y el mantenimiento pueden ser necesarios antes de que el producto entre en una tienda o se entregue al cliente.

Varios equipos y expertos trabajan en estas etapas. Los contratistas, la gestión de proyectos y los desarrolladores senior suelen participar hasta la fase de implementación. Después de la implementación, los desarrolladores hacen el trabajo, por lo que las pruebas del software se manejan frecuentemente por separado, por ejemplo, por laboratorios de pruebas independientes. Expertos en marketing y servicios participan en parte en su lanzamiento. En las grandes empresas y corporaciones, se utiliza el método SDLC modificado y estructurado con mayor precisión (ciclo de vida de desarrollo del sistema), que se basa en el modelo en cascada.[3]. Existen también otras versiones de este modelo que, por ejemplo, introducen elementos repetitivos en forma de bucles para detectar y corregir errores y fallos en fases anteriores.

Beneficios / Desventajas

Algunas ventajas y desventajas del modelo en cascada:[4][5][6]

Ventajas

• Debido a la estructura lógica del modelo, a menudo se pueden evitar errores conceptuales.
• El modelo conduce a una extensa documentación técnica, que es un alivio para los nuevos programadores y desarrolladores y también es útil en la fase de prueba.
• El progreso del proyecto puede ser monitoreado usando metas.
• El coste total puede estimarse con relativa precisión si no hay conflictos.

Desventajas

• Los conflictos, bugs y errores de programación a veces conducen a un aumento de los costes y a una cantidad considerable de tiempo. Lo mismo se aplica si los clientes no están satisfechos.
• Las especificaciones que se hacen inicialmente son a menudo difíciles de entender para los clientes porque son más abstractas de lo que se supone que el software debe hacer.
• specialmente en proyectos subcontratados, esto puede ser una desventaja decisiva, ya que la fecha de lanzamiento debe posponerse y el mercado puede haber cambiado durante este tiempo.
• La entrega del software lleva más tiempo porque los departamentos no trabajan simultáneamente y cada fase sólo puede comenzar cuando se ha completado la fase anterior.

Importancia para la programación

El modelo en cascada es uno de los modelos de proceso más conocidos en el desarrollo de software. Se ha utilizado con éxito durante décadas, pero ahora sólo se utiliza para proyectos más pequeños en los que las especificaciones son claras. Los inconvenientes antes mencionados, sin embargo, también llevaron a los analistas y desarrolladores a diseñar modelos alternativos llamados desarrollo ágil de software[7]. El principal problema del modelo en cascada es que los cambios y revisiones no están necesariamente previstos por las secuencias lógicas. La retroalimentación de los clientes, testers o probadores e ingenieros durante el desarrollo, está en parte ausente, y la integración del software en un sistema existente tiene lugar en un big bang. Estos inconvenientes pueden evitarse modificando las fases del proyecto, como es el caso del Modelo en Espiral. Pero desde hace algunos años, los métodos ágiles que utilizan otros elementos estructurales son mucho más populares (por ejemplo, los roles y sprints con Scrum o los principios extremos de programación). Por regla general, son más económicos, conducen a resultados más rápidos y son más transparentes para los clientes.

Referencias

[1] [2] [3] [4] [5] [6] [7]