El Origen del Modelo Waterfall o Modelo en cascada
En 1985, el Departamento de Defensa de los Estados Unidos publicó el Estándar 2167 (DoD-STS-2167) que establecía un proceso estandarizado para el desarrollo de software: el modelo en cascada o modelo waterfall de gestión de proyectos.
Este estándar para el desarrollo de software influenciaría a varios otros estándares significativos de la industria, como el JSP-188 (Gran Bretaña), V-Model (Alemania), GAM-T-17 (Francia), entre otros.
El modelo en cascada proponía un enfoque secuencial para el desarrollo de software, donde las diferentes etapas eran seguidas en serie, una detrás de otra: "Requerimientos, Análisis, Diseño, Codificación, Testing y Operación".
El modelo de cascada o Waterfall de gestión de proyectos fue creado por Winston Royce en 1970 a partir de su paper llamado Managing the Development of Large Software Systems. En la página 2 de dicho documento, se puede encontrar la clásica representación del modelo en cascada:
Lo interesante viene inmediatamente después. Winston Royce, conocido como "el Padre de la metodología Waterfall" escribe:
"Creo en este concepto, pero la implementación descrita anteriormente es arriesgada e invita al fracaso. El problema se ilustra en la Figura 4. La fase de prueba que se produce al final del ciclo de desarrollo es el primer evento para el cual el tiempo, el almacenamiento, la transferencias de entrada/ salida, etc, se experimentan en vez de analizarse. Estos fenómenos no son precisamente analizables. No son las soluciones a las ecuaciones de derivadas parciales estándares de la física matemática, por ejemplo. Sin embargo, si estos fenómenos no satisfacen las diversas limitaciones externas, entonces se requiere invariablemente un importante rediseño. Un simple parche o rehacer algo de código aislado no solucionará este tipo de dificultades. Los cambios de diseño requeridos son propensos a ser tan perturbadores que los requisitos de software sobre el que el diseño se basa y que permiten la justificación de todo el resto, son violados. O bien los requisitos deben ser modificados, o se requiere un cambio sustancial en el diseño. En efecto, el proceso de desarrollo ha vuelto al origen y se puede esperar un exceso de hasta el 100% del tiempo y/o costo."
Y aquí la mencionada Figura 4 del paper:
En definitiva, la propuesta de Winston Royce con respecto a la validación del diseño y la incorporación de feedback temprano, en el mismo documento, es la ejecución de un modelo piloto de aproximadamente el 30% de la duración total del proyecto:
"Si el esfuerzo de ejecución es de 30 meses, entonces este desarrollo temprano de un modelo piloto puede ser programado para durar 10 meses."
En la Figura 7 del paper mencionado sobre desarrollo de grandes sistemas con el método Waterfall de cascada, podemos ver la sugerencia de Winston Royce de realizar un prototipo utilizable para la obtención de feedback que alimentaría las fases posteriores:
Las razones de que el método Waterfall no sea aplicable para todos los proyectos
En 2003, Craig Larman y Victor Basili, publican un artículo llamado Iterative and Incremental Development: A Brief History en el IEEE Journal de Junio de ese año, donde citan un fragmento de una entrevista/conversación que mantuvieron con Walker Royce, hijo del ya difunto Winston Royce. En esta conversación, Walker Royce menciona acerca de su padre:
"Él siempre fue un defensor del desarrollo iterativo, incremental, evolutivo. Su artículo describe la cascada como la descripción más simple, pero eso no funcionaría para todos los proyectos, excepto aquellos más sencillos. El resto de su trabajo describe las [prácticas iterativas] en el contexto del modelo de contratación del gobierno de los 60s/70s (un conjunto de serias restricciones)."
Las fallas de la metodología Waterfall en la gestión de proyectos
Ya de vuelta en el Departamento de Defensa (DoD) de los Estados Unidos, en 1987, varios informes del departamento comenzaron a advertir públicamente en contra del Estándar 2167 (DoD-STS-2167) para el desarrollo de software basados en los pobres resultados alcanzados. En 1994 el estándar waterfall del Departamento de Defensa fue reemplazado por el estándar MIL-STD-498. Este nuevo estándar del DoD promueve el no uso del Modelo de Cascada en proyectos no críticos para la seguridad nacional, ya que genera grandes excesos de presupuesto y de costos debido a su enfoque formal y burocrático. El MIL-STD-498 fomenta un enfoque más iterativo para el desarrollo de software y reconoce el hecho de que los requisitos cambian y el diseño es un proceso evolutivo. Lamentablemente, no sucedió lo mismo con el resto de los estándares mundiales que se habían basado en el Estándar 2167.
Craig Larman, en su libro Agile and Iterative Development: A Manager's Guide, menciona lo siguiente:
"En 1996 visité el área de Boston y almorcé con el autor principal del Estándar 2167. Él expresó su pesar por la creación de la norma de la cascada rígida de un solo paso. Dijo haber sido influenciado por el conocimiento común y la práctica de la época, además de otras normas. Que no estaba familiarizado en ese momento con la práctica de desarrollo iterativo realizado en periodos fijos de tiempo (timeboxes) y requerimientos evolutivos, dijo que hubiera hecho una firme recomendación con respecto al desarrollo iterativo e incremental, en lugar de lo que había en el estándar 2167."
Los cambios en el uso de Waterfall
El 28 de Octubre de 2009, el Congreso de los Estados Unidos publicó la Ley de Autorización de Defensa Nacional para el Año Fiscal 2010 (Ley Pública 111-84) en cuya sección 804 enuncia las condiciones que el DoD debe seguir al momento de efectuar contrataciones con respecto a los Sistemas de Información.
Los contratos deben diseñarse de forma tal de incluir:
- (A) la participación temprana y continua del usuario;
- (B) múltiples incrementos, o liberaciones de rápida ejecución, de capacidades funcionales;
- (C) la creación temprana de prototipos sucesivos para apoyar un enfoque evolutivo; y
- (D) un enfoque modular, de sistemas abiertos.
A partir de esta solicitud, el Departamento de Defensa presentó al Congreso de los Estados Unidos el reporte: A New Approach for Delivering Information Technology Capabilities in the Department of Defense. En este documento, comunican los cambios realizados a su proceso de contrataciones de servicios de desarrollo de sistemas informáticos:
Conclusiones: el surgimiento de los métodos ágiles de desarrollo de software como solución a los problemas de Waterfall
La creación del Modelo en Cascada o Modelo Waterfall para la gestión de proyectos es institucionalizado por el Departamento de Defensa de los Estados Unidos como consecuencia de una mala interpretación del trabajo de Winston Royce, donde el autor de Managing the Development of Large Software Systems sugiere que este tipo de enfoque para el desarrollo de software es arriesgado y que invita al fracaso.
Años más tarde, el Departamento de Defensa corrigió este error, pero varios estándares del Gobierno de los Estados Unidos como de Gobiernos Europeos (Gran Bretaña, Alemania, Francia) que habían derivado de este primero, no siguieron el mismo camino.
A partir del año 2010, el Departamento de Defensa se vuelca explícitamente a los modelos ágiles, tanto para desarrollos internos como para contratación de proveedores. Muchos otros organismos significativos están siguiendo sus pasos.
En el año 1994 el Standish Group publicó un estudio conocido como el Comprehensive Human Appraisal for Originating Software (CHAOS Report) donde se encontró la siguiente tasa de éxito en los proyectos de desarrollo de software en general:
- 31.1% de los proyectos fracasaron, fueron cancelados
- 52.7% de los proyectos se excedieron en costos y/o tiempo
- 16.2% de los proyectos fueron exitosos
Recordemos que en 1994 la metodología utilizada para la gestión de proyectos de desarrollo de software era casi exclusivamente el Modelo en Cascada.
Once años más tarde de la aparición del Agile Manifesto, en 2012, el Standish Group publicó su clásico análisis anual de gestión de proyectos de la industria del desarrollo de software, ahora llamado CHAOS Manifesto. Este reporte incluye una comparación entre Waterfall y Agile:
En ese año, indicaría:
"El proceso ágil es el remedio universal para el fracaso en los proyectos de desarrollo de software. Las aplicaciones de software desarrolladas a través del proceso ágil tienen tres veces la tasa de éxito del método en cascada tradicional y un porcentaje mucho menor de demoras y sobrecostos. [...] El software debería ser construido en pequeños pasos iterativos, con equipos pequeños y enfocados."