El Origen

En 1985, el Departamento de Defensa de los Estados Unidos publicó el Estándar 2167 (DoD-STS-2167)1 que establecía un proceso estandarizado para el desarrollo de software: el modelo en cascada.

Este estándar 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 Origen del Origen

Este estándar se basó en un paper llamado "Managing the Development of Large Software Systems"2, escrito en 1970 por Winston Royce.

En la página 2 de dicho paper, se puede encontrar la clásica representación del modelo en cascada:

Waterfall

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:

Waterfall Failure

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 paper, es la ejecución de un piloto de aproximadamente el 30% del 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, podemos ver la sugerencia de Winston Royce de realizar un prototipo utilizable para la obtención de feedback que alimentaría las fases posteriores:

Waterfall: Do It Twice

El mal entendido

En 2003, Craig Larman y Victor Basili, publican un artículo llamado "Iterative and Incremental Development: A Brief History"3 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)."

Volviendo al Estándar del DoD

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 2167 basados en los pobres resultados alcanzados. En 1994 el estándar waterfall del Departamento de Defensa fue reemplazado por el estándar MIL-STD-4984. 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 2167.

Craig Larman, en uno de sus libros5, 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."

El DoD Hoy

El 28 de Octubre de 2009, el congreso de los Estados Unidos publicó la Ley Pública 111-846 (Ley de Autorización de Defensa Nacional para el Año Fiscal 2010) 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 emitió el reporte al congreso "A New Approach for Delivering Information Technology Capabilities in the Department of Defense"7.

En este reporte, comunican los cambios realizados a su proceso de contrataciones de servicios de desarrollo de sistemas informáticos:

Sec. 804 - Guiding Principles

Conclusiones

La creación del modelo en cascada (waterfall) es institucionalizado por el Departamento de Defensa de los Estados Unidos como consecuencia de una mala interpretación del trabajo de Winston Royce, "Managing the Development of Large Software Systems", donde el autor sugiere que este tipo de enfoque para el desarrollo de software es arriesgado y que invita al fracaso.

Años más tarde, el DoD corrige 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 "CHAOS Report"8 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 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 Manifesto9.

En este reporte incluye una comparación entre Waterfall y Agile:

Waterfall vs. 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."

.



Referencias

1. DoD-STS-2167 - http://www.product-lifecycle-management.com/download/DOD-STD-2167A.pdf
2. Managing the Development of Large Software Systems - http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
3. Iterative and Incremental Development: A Brief History - http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf
4. MIL-STD-498 - http://en.wikipedia.org/wiki/MIL-STD-498
5. Larman C., "Agile and Iterative Development: A Manager's Guide", 2003
6. National Defense Authorization Act For Fiscal Year 2010 - http://www.gpo.gov/fdsys/pkg/PLAW-111publ84/pdf/PLAW-111publ84.pdf
7. A New Approach for Delivering Information Technology Capabilities in the Department of Defense - http://www.afei.org/WorkingGroups/section804tf/Documents/OSD_Sec_804_Report.pdf
8. The CHAOS Report (1994), Standish Group - http://www.standishgroup.com/sample_research/chaos_1994_1.php
9. Standish Group, CHAOS Manifesto, 2011


Dime lo que piensas. Por favor, deja un comentario más adelante (y luego dale click a ese botón de 'Me gusta'!)

Seguir leyendo


Comentarios

comments powered by Disqus