El por qué de que muchos proyectos fracasen I: Waterfall

Es muy típico entre los desarrolladores de software criticar el proceso de desarrollo en cascada o Waterfall utilizando argumentos como: es antiguo, no me gusta o no funciona. Algunos más precavidos suelen decir que bueno, que es aplicable dependiendo del contexto en el que nos encontremos ya que nada es ni blanco ni negro. Estos últimos suelen continuar diciendo que depende de si el cliente tiene claro lo que quiere o no. En cierto modo, este último argumento parece tener sentido salvo por el hecho de que el cliente no suele tener claro al 100% que es lo que realmente quiere, no suele saber lo que realmente necesita (por eso acude a nosotros) y nosotros no entendemos por completo cual es su problema porque no estamos en su piel.

proyectos-desarrollo-software

En la universidad nos enseñaron que un desarrollo en cascada es el modelo de desarrollo más sencillo. Este modelo parte de una estructura lógica y una serie de pasos secuenciales o fases ordenadas en las que no podemos pasar de una fase a otra hasta no haber completado las anteriores. Primero obtenemos los requisitos y analizamos las necesidades de cliente,  continuaremos con una fase de más detalle en la que sacamos los requisitos del software,  la fase de análisis de esos requisitos es la siguiente para posteriormente crear un diseño,  una vez terminado continuamos programando la solución, realizamos pruebas y finalmente corregimos errores. Y una vez implantado el sistema, podemos entrar en una fase de mantenimiento y corrección de incidencias que vayan saliendo.

waterfall

Como veis una estructura totalmente lógica, basada en fases en las que hasta que no se produce la finalización de las mismas no podemos continuar, y ese hecho es lo que hace óptimo y da sentido a este modelo. Esto nos los cuentan en la universidad y también nos dicen que este modelo fue ideado por el Dr. Winston W. Royce. Puede que nos den más detalles, como por ejemplo que este modelo se le ocurrió un día que estaba en el servicio,  se cayó de la taza del váter y se dio un golpe  en la cabeza. Fue justo en ese instante cuando le vino a la mente este modelo de desarrollo como si de una visión se tratara.  A ese profesor deberían retirarle la licencia de conducir, por consumo de sustancias psicotrópicas.

KVmartyLic

También te pudieron contar que existían otro tipo de modelos como el modelo en V (que trataremos en otro post) y el desarrollo en espiral. El modelo en espiral le representaban con una espiral semejante a un garabato y no decían mucho más porque estaba fuera de temario. Recuerdo un profesor que terminaba la explicación diciendo “es lo que hace Microsoft, por eso sacan tantos service packs, para que los clientes detecten los errores, menudos listos” (obviamente, este hombre era linuxero).   Como consecuencia de esa falta de información, un joven universitario y friki pensaría seguramente que si el modelo en cascada fue ideado por El Dr. Royce, el modelo en espiral tenía que haber sido diseñado irremediablemente por el Dr. Who.

doctor who

La realidad es que el Dr. Royce publicó el artículo denominado “Managing the development of large systems” en 1970 tratando de explicar su experiencia personal acerca del desarrollo software en sistemas de gran tamaño. A lo largo del artículo expone un modelo al que no pone nombre y que representa en la Figura número 2 del mismo artículo. Royce habla en ese modelo de una serie de fases que recuerdan sin lugar a duda al modelo en cascada que conocemos actualmente, del que dice que se trata de una aproximación de alto riesgo y destinada al fallo. El artículo propone una solución iterativa e incremental donde la participación del cliente en el proceso de desarrollo es vital como solución a los problemas expuestos usando como base el modelo de la Figura 2. Aquí tenéis la copia  del artículo original de Royce que tras leerla me deja totalmente estupefacto: Managing the development of large systems.

perplexed

Creo profe, que me he perdido. ¿Cómo puede atribuirse a Royce el mérito de algo que estaba criticando en su artículo Original? En los años 80 del siglo pasado se inventaba en la ficción el condensador de fluzo y el Ministerio de Defensa de los estados unidos publicaba su nuevo estándar para desarrollo software, el  DoD-STS-2167 . Tras varias mejoras de este modelo de desarrollo copiando la idea alemana del modelo en V, se estableció el MIL-STD-498 que no deja de ser un modelo en V dividido en varias fases incrementales. La industria, siempre por detrás, fue copiando estos estándares de defensa USA hasta sacar el IEEE 12207. En un informe publicado en 1994 por el Standish Group se decía que en la aplicación de Waterfall en proyectos software de los últimos años, el 31,1% de los proyectos fracasaron y fueron cancelados, el 52,7% tuvieron un sobrecoste en tiempo y/o dinero y el 16,2% de los proyectos tuvieron éxito. A día de hoy, los datos no han mejorado y lo que hemos tenido es un “Waterfall” de derroche de dinero.

money_waterfall

Pero, ¿Qué problema tiene realmente Waterfall?, es un proceso ordenado, secuencial, lógico  y fácil de entender. El proceso en cascada sería eficaz si se dieran los siguientes supuestos:

  • Vemos el futuro y leemos la mente. Es decir, sabemos lo que quiere exactamente el cliente e incluso somos capaces de adelantarnos a lo que él no sabe que quiere. Sabemos lo que va a pasar durante el desarrollo, es decir, podemos predecir el futuro y misteriosamente no nos avergonzamos de decirlo en voz alta.

bola-de-cristal-leitao-bolsa

  • Seguimos el proceso. Es decir, no empezamos a codificar antes de tener todos los requisitos.  Una de las premisas de Waterfall es que no se puede empezar una fase sin cerrar la anterior. En la mayoría de los desarrollos, se solapan las fases empezando a desarrollar antes de que algunas de las fases anteriores se termine, porque evidentemente al no conocer el problema, no se cierran. A pesar de eso y viendo que se nos echa el tiempo encima, empezamos a programar como locos teniendo que volver a cambiar todo con grandes impacto en:
    • Funcionalidad
    • Arquitectura
    • Pruebas
    • Tu salud mental
    • Tu vida familiar
    • Tu mascota

gato cabreado Peque

  • Las pruebas se realizan al final del proceso. Me dirás, “no, si lo he probado y en mi ordenador funciona”. Si hacemos la fase de pruebas al final, esto lo que producirá inevitablemente es que:
    • Se detectarán errores y tendrás que corregirlos.
    • Se detectarán errores en la especificación, tendrás que corregirlos e importante: tendrás que rehacer todas esas partes del sistema que se verán afectadas.
    • Cada error detectado en fases tardías del desarrollo, tendrá un coste mucho más elevado que si lo hubieras detectado sobre el desarrollo. Imagina la cantidad de horas (dinero) de personas que estarán involucradas en cada error detectado.
    • La fase de pruebas, debido a todas estas correcciones, se dilata y obviamente entregaremos fuera de plazo.

      sin dinero en el bolsillo

En definitiva, me pregunto qué hubiera pasado si realmente hubieran hecho caso las advertencias de Royce.  Algunos scrum masters, al hablar de Waterfall me han dicho en alguna ocasión: “¿estás hablando de Waterfall?, ¿por qué estoy perdiendo mi tiempo hablando de eso?”. Sin embargo yo creo, que el saber no ocupa lugar, y saber de lo que estás hablando te pone en un mejor lugar a la hora de hacer críticas constructivas de cualquier cosa, incluso de tus propias creencias, las cuales posiblemente estén equivocadas también.

PDFicono EXTENDIDO

REFERENCIAS:

[1] DOD-STD-2167
[2] The Art of Lean Software Development: A Practical and Incremental Approach
[3] MIL-STD-498
[4] Managing the development of large systems

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s