El modelo de cascada ( en inglés , modelo de cascada , a veces traducido como el modelo "Cascada" ) es un modelo de proceso de desarrollo de software en el que el proceso de desarrollo parece un flujo que pasa secuencialmente a través de las fases de análisis de requisitos, diseño, implementación, prueba, integración y soporte. . Un artículo publicado por W. W. Royce en 1970 se cita a menudo como fuente del nombre ; a pesar de que el propio Royce utilizó un modelo de desarrollo iterativo .
En un artículo de 1970, Royce describió en concepto lo que ahora se llama el "modelo en cascada" y discutió las deficiencias de este modelo. En el mismo lugar, mostró cómo este modelo puede ser refinado a un modelo iterativo.
En el modelo de cascada original, las siguientes fases iban en este orden:
Siguiendo el modelo de cascada, el desarrollador se mueve de una etapa a otra de manera estrictamente secuencial. Primero, la etapa de "definición de requisitos" se completa por completo, lo que da como resultado una lista de requisitos de software. Una vez que los requisitos están completamente definidos, hay una transición al diseño, durante la cual se crean documentos que describen en detalle para los programadores el método y el plan para implementar estos requisitos. Una vez que el diseño se completa por completo, los programadores implementan el proyecto resultante. La siguiente etapa del proceso es la integración de componentes individuales desarrollados por diferentes equipos de programadores. Una vez completada la implementación y la integración, el producto se prueba y se depura; en esta etapa, se eliminan todas las deficiencias que aparecieron en las etapas anteriores de desarrollo. Después de eso, se implementa el producto de software y se brinda su soporte: la introducción de nuevas funciones y la eliminación de errores.
Por lo tanto, el modelo en cascada implica que la transición de una fase de desarrollo a otra ocurre solo después de la finalización completa y exitosa de la fase anterior, y que no hay transiciones hacia atrás o hacia adelante o superposición de fases.
Sin embargo, existen modelos en cascada modificados (incluido el de Royce) que tienen variaciones pequeñas o incluso significativas en el proceso descrito.
La metodología del modelo en cascada a menudo se critica por su falta de flexibilidad y por considerar que la gestión formal de proyectos es un fin en sí mismo a expensas del tiempo, el costo y la calidad. Sin embargo, cuando se gestionaban proyectos grandes, la formalización solía ser de gran valor, ya que podía reducir drásticamente muchos de los riesgos del proyecto y hacerlo más transparente . Por lo tanto, incluso en la versión 3 del PMBOK , solo se fijó formalmente la metodología del "modelo en cascada" y no se propusieron opciones alternativas conocidas como gestión iterativa de proyectos .
Desde la cuarta versión del PMBOK , se ha llegado a un compromiso entre los metodólogos comprometidos con la gestión de proyectos formal y progresiva, con los metodólogos que confían en métodos iterativos flexibles . Así, a partir de 2009, formalmente, el Project Management Institute (PMI) ofrece como estándar una versión híbrida de la metodología de gestión de proyectos, combinando tanto las ventajas de la metodología Waterfall como los logros de los metodólogos iterativos.
| Desarrollo de software | |
|---|---|
| Proceso | |
Conceptos de alto nivel | |
| Direcciones |
|
| Metodologías de desarrollo | |
| Modelos |
|
Figuras notables |
|