El desarrollo de software es un proceso complejo que requiere de planificación y ejecución de diversas tareas interconectadas temporalmente, para enfrentar este desafío, existen varios modelos que nos ayudan en el desarrollo. El modelo de desarrollo de software más conocido es el método «Waterfall». En este artículo, analizaremos por qué se utiliza el enfoque Waterfall para desarrollar software, su historia, cómo y cuándo se comenzó a utilizar, y si es conveniente seguir usándolo.
El nacimiento
Modelo para el desarrollo de grandes proyectos. Según Royce, el uso podría ser riesgoso.
El modelo «Waterfall» para el desarrollo de software fue popularizado por Winston W. Royce en 1970. Royce propuso este modelo secuencial en un artículo llamado «Managing the Development of Large Software Systems» publicado en la revista IEEE. Aunque Royce no recomendó específicamente el uso, este modelo se convirtió en una metodología popular para el desarrollo de software debido a su simplicidad y claridad en cuanto a la estructura del proyecto. A partir de entonces, muchas empresas y organizaciones adoptaron el enfoque Waterfall para el desarrollo de software.
En su documento original, Royce sugirió 7 fases fundamentales del modelo: Requisitos de los sistemas, Requisitos de Software, Análisis, Diseño de programa, Codificación, Pruebas y Operación. En este modelo, cada fase comienza solo cuando la anterior está completa sin ninguna superposición entre las diferentes etapas.
Royce sugería que para proyectos pequeños se podía utilizar un enfoque donde solo intervenían 2 fases, Análisis y Codificación, no obstante, para el desarrollo de grandes proyectos de software, Royce reflexionaba sobre el uso del modelo extendido (figura de la izquierda), pero creía que su implementación era riesgosa, entre los problemas que analizó estaba la posibilidad de generar un 100% de retraso en el cronograma y/o costos producto de alguna modificación de los requerimientos iniciales o un cambio importante en el diseño, por lo que la desaconsejó, declarando lo siguiente...
Dr. Winston Royce, 1970
«Creo en este concepto, pero la implementación descrita anteriormente es arriesgada e invita al fracaso»
Para solventar estos problemas, la propuesta de Royce era mucho más compleja y contenía numerosos bucles de retroalimentación de un estado a estados anteriores. En otras palabras, era de naturaleza iterativa y afirmó que deberíamos hacer cada paso del proceso al menos dos veces, completar el diseño antes del inicio del análisis y la codificación, que las pruebas deben ser planificadas, controladas y monitoreas y algo sumamente importante, se debe involucrar al cliente de manera formal, si ha consultado el Manifiesto Ágil, le resultará familiar.
Modelo Original Propuesto por Royce.
Como dato curioso, Royce nunca utilizó el termino «Waterfall». El primer uso del término puede haber sido un artículo de 1976 de Bell y Thayer donde haciendo referencia al articulo de Royce, lo denominan de esa manera.
La masificación
U.S. Air Force photo/ Air Force Tech. Sgt. Teri Eicher
Según el libro «Software Engineering: A Practitioner’s Approach» de Roger S. Pressman, en 1985, el Departamento de Defensa de los Estados Unidos (DoD) solicitó a sus proveedores que para desarrollar software, adoptaran el estándar denominado DOD-STD-2167A» , un estándar con claro sesgo hacia el desarrollo bajo «Waterfall», según los expertos.
Cabe destacar, que en esa época, el DoD era el principal cliente de la industria de software de defensa de Estados Unidos.
El DoD consideró que el enfoque «Waterfall» proporcionaba una estructura clara para el desarrollo de software y les permitía gestionar los proyectos con mayor eficacia. Esta política del DoD fue un factor importante en la popularización dentro de la industria del software.
Sin embargo, las estadísticas recopiladas de varios años después demostraron que la utilización del estándar DOD-STD-2167A tuvo una baja tasa de éxito. El principal problema fue la comprensión insuficiente de las fortalezas y debilidades del modelo «Waterfall», así como sus interpretaciones erróneas. «Waterfall» demostró ser conveniente y eficiente para pequeños proyectos de software permitiendo que los equipos gestionar los proyectos con mucha facilidad, sin embargo, para grandes proyectos, podría ser totalmente diferente, por no decir, una invitación a fracasar, como predijo Royce.
El Futuro
Chaos Report 2020 Beyond Infinity – Standish Group
El problema general con «Waterfall» es que espera que tengamos más conocimientos previos de los que podemos aprender mientras trabajamos, asumiendo que los requisitos cambiarán poco o no lo harán y que el cliente se mantendrá consistente en todo el ciclo de vida.
Adicionalmente, en el modelo no se entrega ningún producto o alguna versión parcial hasta que se haya completado todo el proceso. Por lo tanto, el valor que se libera puede ser menor de lo que imaginamos porque la solución óptima puede haber cambiado desde que la imaginamos por primera vez.
El Standish Group es una organizacional internacional de asesoría en investigación de TI, ha estado analizando los resultados de proyectos de tecnología durante más de 25 años. Su primer reporte salió en 1994 y desde entonces, más de 50.000 proyectos de tecnología se han agregado a la base de datos.
En el último reporte del 2020, llamado Chaos 2020 Beyond Infinity , muestra una minúscula reducción en las tasas de falla de «Waterfall» con respecto al informe de 2015, es decir, poco ha cambiado; Los proyectos desarrollados con agilidad tienen 3 veces más probabilidades de éxito y los proyectos desarrollados con «Waterfall» 3 veces más probabilidades de fallar. En otras palabras, una invitación a fallar, como predijo Royce.
Conclusiones
Con el auge de Agile y sus excelentes resultados en el desarrollo de software, la popularidad y uso de «Waterfall» se ha reducido enormemente. El modelo «Waterfall» no es perfecto, que duda cabe, sin embargo, los expertos coinciden que para obtener éxito, es necesario comprender las condiciones que nos pueden permitir conseguir resultados satisfactorios. Las recomendaciones suelen ser los siguientes puntos.
- El proyecto es pequeño.
- El proyecto es de bajo presupuesto.
- La definición y el alcance del producto son estables.
- Todos los requisitos son claros y fijos.
- Los clientes no harán cambios importantes durante el proceso y participarán activamente.
¿Y tú? ¿Has utilizado Waterfall? ¿Cómo te ha ido? Comenta o comparte 👍
Fuentes:
- Royce, W. W. (1970). Managing the Development of Large Software Systems. IEEE WESCON.
- Boehm, B. W. (1988). A Spiral Model of Software Development and Enhancement. IEEE Computer, 21(5), 61-72.
- Pressman, R. S. (2010). Software Engineering: A Practitioner’s Approach. McGraw-Hill.
- Bell, T.E., & Thayer, T.A. (1976). Software requirements: Are they really a problem?. International Conference on Software Engineering.
