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 etapa está definida por distintos 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 etapa, sigue el paso siguiente de desarrollo y los resultados de la etapa anterior pasan a la próxima etapa.
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. Aún se usa hoy en día en varias versiones si los requerimientos y características de un software pueden ser claramente definidos durante la etapa 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» (Administració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. Además 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, difundido 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 requerimientos para software[1]
Cómo funciona
El modelo original en cascada consta de siete fases sucesivas:[2]
- Requerimientos del sistema: La primera etapa se ocupa de los requerimientos 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í además se especifican los aspectos de documentación y seguridad. En general, aquí se mencionan los requerimientos no funcionales.
- Requerimientos de software: Los requerimientos funcionales del software se definen en la segunda etapa. La pregunta sobre lo que el software debe ser capaz de hacer se responde aquí y se aclara en «especificaciones», que además incluye los resultados de la primera etapa.
- Análisis de requisitos: En la etapa de análisis de requerimientos, las funciones del software se diseccionan y estructuran de modo que los items funcionales individuales y las unidades funcionales puedan separarse entre sí. El análisis de necesidades tiene por objeto evaluar la viabilidad e importancia de las funciones. Los resultados de esta etapa son las especificaciones que contienen los requerimientos que existen que desarrollar.
- Diseño de programas: El diseño técnico se implementa ahora con la ayuda de estas especificaciones de requerimientos. Los componentes de esta etapa además 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 de forma directa relacionado con un sistema operativo, uno o más lenguajes de programación y la infraestructura. El resultado suele ser un software operativo, frecuentemente en versión beta.
- Probando: La etapa de implementación es seguida por la prueba de todos los componentes de software, módulos y todo el sistema. Además se comprueba la incorporación en sistemas operativos específicos. Si se producen errores y conflictos, deben repararse inmediatamente. Esto podría dar lugar a un incremento de los costes globales, dado que los posibles errores pueden atribuirse a distintos fases y no siempre se producen en la etapa anterior.
- Lanzamiento: El software se implementa posteriormente 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 administración de proyectos y los desarrolladores senior suelen participar hasta la etapa de implementación. Posteriormente de la implementación, los desarrolladores hacen el trabajo, por lo que las pruebas del software se manejan habitualmente de forma separada, 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 usa 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]. Hay además otras versiones de este modelo que, por ejemplo, introducen items 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, frecuentemente 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 además es útil en la etapa de prueba.
- El progreso del proyecto puede ser monitoreado utilizando metas.
- El coste total puede estimarse con relativa precisión si no existen conflictos.
Desventajas
- Los conflictos, bugs y errores de programación a veces conducen a un incremento 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 frecuentemente difíciles de entender para los clientes porque son más abstractas de lo que se supone que el software tiene que hacer. Sobre todo en proyectos subcontratados, esto puede ser una desventaja decisiva, dado 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 etapa sólo puede empezar cuando se ha completado la etapa anterior.
Importancia para la programación
El modelo en cascada es uno de los modelos de procedimiento más conocidos en el desarrollo de software. Se ha utilizado con éxito durante décadas, pero ahora sólo se usa para proyectos más pequeños en los que las especificaciones son claras. Los inconvenientes antes mencionados, no obstante, además 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 a lo largo del desarrollo, está en parte ausente, y la incorporació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 usan otros items estructurales son mucho más populares (por ejemplo, los roles y sprints con Scrum o los principios extremos de programación). Por norma general, son más económicos, conducen a resultados más rápidos y son más transparentes para los clientes.
Enlaces web
- Definición del modelo en cascada
- Qué es el Modelo Cascada en las pruebas de software y cuáles son las ventajas y desventajas del Modelo Cascada
