Metodología de desarrollo de software (I) – Modelo en Cascada

Desde que salí de la carrera en 2004, me contaron que los proyectos de software se hacían de una determinada manera. En su día, ni me planteé su nombre ni si era adecuado o había otras opciones. Según fue pasando el tiempo, viví las evidencias de que el método que había conocido no era muy acertado a menudo.

De lo que me estaban hablando era del modelo de desarrollo de software en cascada o waterfall. Se trataba de hacer encajar todo en un flujo preestablecido de fases: análisis, diseño, implementación, pruebas, despliegue y mantenimiento, donde no se puede avanzar a la siguiente si la anterior no se encuentra totalmente terminada. Cuando te lo cuentan, y más sin experiencia en el sector, uno lo da por válido. Sin embargo, cuando uno ve una y otra vez que las planificaciones no se cumplen en la mayoría de los casos y que el llamado jefe de proyecto montaba en cólera cuando la previsión de tiempos en cada fase o subfase trastocaba su valioso diagrama de Gantt, o que había que retroceder de fase por necesidad, empecé a sospechar que algo no se estaba haciendo bien. Y no era porque el equipo no supiera hacer su trabajo.

 

Datos empíricos que hacen pensar

Una cifra interesante que conocí hace tiempo es que el 84% de los proyectos de IT fracasan (Standish Report Chaos) por alguna razón relacionada con la metodología. El último informe actualizado que he conocido al respecto habla del 71% de fracaso, lo cual significa que por lo menos en algo vamos mejorando, aunque queda mucho margen de mejora. Siempre hay un hueco entre lo planeado y lo ejecutado, por eso no tiene sentido hacer cuadrar el desarrollo de un proyecto en un corsé rígido.

 

 

Si congeláramos las especificaciones de un sistema y lo hiciéramos independiente del tiempo y de influencias externas como el mercado o las necesidades del área de negocio, por ejemplo, este modelo quizás podría funcionar. Sin embargo, en desarrollo de software mi experiencia me dice que es una utopía, lo único constante es el cambio. Por eso, emplear tiempo en documentar y cerrar las especificaciones de un proyecto, y más cuando es un proyecto grande, no tiene mucho sentido, porque probablemente cambiarán. Menos mal que de esto ya se dieron cuenta algunos eruditos informáticos y crearon el agile manifesto.

En resumen, es una invitación a dejar de planear y documentar, ocupándose mejor de tener software funcionando lo antes posible (como mencionan también los principios lean), que responda a lo que el cliente ha validado, con una actitud de ser flexible y resolutivo frente a cualquier tipo de cambio que pueda venir, primando la colaboración entre personas en lugar de esforzarse en seguir un proceso determinado preestablecido.

Del mismo informe Chaos Report me llama la atención esta información:

 

¿Es tan evidente que para la ejecución de proyectos de IT no debemos seguir utilizando modelos de desarrollo del siglo pasado? Parece que las pruebas que vienen de nuestra experiencia personal se corroboran con los datos de miles de proyectos involucrados en este estudio.

 

Aspectos a favor y en contra del modelo en cascada

A modo de resumen, trato de aportar pros y contras del modelo en cascada, ya que esta metodología es útil en algunos casos.

Pros:

  • Fácil de entender y gestionar, dada la rigidez del modelo.
  • Las fases son completadas por orden y de forma secuencial, haciendo su puesta en práctica un proceso sencillo.
  • Puede funcionar bien para proyectos pequeños donde las especificaciones se pueden cerrar con más facilidad y donde los cambios de alcance o dirección no sean probables.
  • Es muy adecuado para proyectos donde el coste del error es muy grande: diseñar un avión, enviar un cohete a la luna, un tren de alta velocidad, etc.

 

Contras:

  • No se obtiene software funcionando hasta el final del ciclo de desarrollo.
  • Existen altos niveles de riesgo e incertidumbre, ya que el modelo no se adapta a los cambios que puedan venir. No se pueden incorporar fácilmente cambios.
  • No es un buen modelo para proyectos complejos donde el alcance no se puede cerrar fácilmente o se prevé que las circunstancias puedan alterar el producto desarrollado.
  • Es complicado tener una idea del avance del proyecto en cada fase.
  • No se pueden prever o identificar cuellos de botella o impedimentos con tiempo suficiente para abordarlos de cara al éxito del proyecto.

 

Contribuyo con este artículo a un trabajo de investigación recurrente y necesario en ASPgems sobre los modelos de desarrollo de software que iré nutriendo periódicamente.