Dispositivo modelo en cascada
El modelo de cascada, también conocido como Waterfall, es uno de los enfoques más conocidos para el desarrollo de software. El autor del modelo es Winston Royce. En 1970, describió la esencia de su innovación en un artículo detallando sus ventajas y desventajas. En el mismo lugar, explicó cómo se puede refinar este modelo a un modelo iterativo. Inicialmente, en el modelo en cascada, las etapas de desarrollo van en el siguiente orden:
- Definición y coordinación de requisitos;
- aprobación del proyecto;
- Codificación;
- Creación de una versión de trabajo del producto de software;
- Pruebas y depuración;
- Instalación de software;
- Apoyo.
De acuerdo con el modelo de cascada, la ejecución de acciones por parte del desarrollador ocurre secuencialmente, punto por punto. Para empezar, se está trabajando para determinar y acordar los requisitos de software en forma de una lista a completar.
Después de eso, hay una transición a la creación y aprobación del proyecto, como resultado de lo cual se escribe la documentación que describe cómo implementar los requisitos de software previamente acordados.
Si se completa el diseño, los desarrolladores asumen la implementación. Luego viene la fusión del código: la integración de partes individuales del proyecto, en las que trabajaron varios miembros del equipo.
El siguiente paso es probar y depurar el producto. Los errores encontrados anteriormente se corrigen aquí.
Finalmente, el programa está instalado y soportado. Implica realizar, si es necesario, cambios en la funcionalidad y eliminar los errores encontrados.
El modelo en cascada asume que puede pasar a la siguiente etapa de desarrollo de forma estrictamente secuencial, solo después de completar la tarea anterior. No se prevé la posibilidad de reversión o inconsistencia en las fases.
Ventajas y desventajas
De vez en cuando, el modelo de cascada es criticado por su falta de flexibilidad. A muchos no les gusta porque en él prima el objetivo de la gestión de proyectos, mientras que el cumplimiento de los plazos, el coste y la calidad del desarrollo son mucho más importantes.
Sin embargo, cuando se trata de grandes proyectos, entonces la gestión suele ser más importante en ellos, ya que esto reduce los riesgos del proyecto y mejora la transparencia en el trabajo.
A pesar de las deficiencias, la tercera versión del PMBOK especifica formalmente solo la metodología del "modelo en cascada". No se ofrecen otras opciones, incluida la gestión iterativa de proyectos.
Ventajas del modelo de cascada:
- El desarrollo del equipo es más fácil de controlar. El cliente está familiarizado con lo que los programadores están trabajando actualmente, puede cambiar los plazos y el presupuesto del proyecto.
- El costo de desarrollo se aprueba en la primera etapa. Después de acordar todas las etapas de implementación, el producto de software se escribe continuamente.
- No se necesitan probadores experimentados. Para la fase de prueba, puede utilizar la documentación del programa.
Desventajas del modelo de cascada:
- Dado que las pruebas comienzan en la etapa de finalización del desarrollo, si se descubre un error, costará más arreglarlo que en la etapa inicial. Después de todo, los evaluadores encontrarán un error solo cuando el desarrollador ya haya terminado de escribir el código y los redactores, la documentación.
- El cliente se familiariza con el producto terminado una vez que se completa el desarrollo. En consecuencia, puede evaluar el producto solo cuando esté casi completamente listo. Si no le gusta el resultado, el costo del presupuesto del proyecto aumentará notablemente debido a la necesidad de corrección.
- Cuanta más documentación técnica, más tiempo se tarda en completar el trabajo. Tal documentación requiere más cambios y aprobaciones.
"Cascada" se usa a menudo en proyectos en las industrias médica y aeroespacial, donde ya existe una amplia base de documentos, sobre la base de los cuales es posible elaborar requisitos para un nuevo software.
Cuando se usa el modelo en cascada, lo principal es escribir requisitos detallados. Durante la prueba, no debería resultar que haya un error en algún lugar que tenga un efecto perjudicial en todo el proyecto.