sábado, 8 de enero de 2011

Desarrollo de software en cascada

En un mundo lleno de cambios, en el cual producir con rapidez aplicaciones que satisfagan las necesidades reales del mercado es clave para el éxito, es indispensable pensar y repensar la forma y las herramientas que los equipos que desarrollan software utilizan para trabajar.

Durante muchos años, lo normal era desarrollar software en lo que llamamos "desarrollo en cascada" (waterfall model), que divide el proceso en bloques definidos y donde cada paso depende sólo del paso anterior:
  • Análisis de requisitos
  • Diseño del Sistema
  • Diseño del Programa
  • Codificación / Implementación
  • Pruebas
  • Implantación
  • Mantenimiento
Con los años se han establecido nuevas técnicas que en la mayoría de los casos reducen en cierto grado los problemas producidos por ésta metodología y aumentan la probabilidad de éxito de los proyectos de desarrollo de software. Durante muchos años he tenido que desarrollar software utilizando éste método y ésta es la lista de lo que a mí parecer son sus principales problemas:

  • Malas decisiones, poco uso del aprendizaje: El método obliga a tomar muchas y muy importantes decisiones muy temprano en el proyecto. Las decisiones se toman en el peor momento, cuando menos se sabe del tema y de las tecnologías utilizadas. El costo de cambiar el rumbo tomado es muy alto, pues la información fluye sólo en una dirección (de arriba hacia abajo). Frecuentemente ocurre que cerca del final del proyecto todos los participantes han logrado recién alcanzar un grado suficiente de profundidad en su conocimiento del tema y sus tecnologías como para poder tomar decisiones correctas. Lamentablemente, en ese momento ese conocimiento ya no es requerido.
  • Mala comunicación: El camino de la información es desde arriba hacia abajo (ver lista más arriba). La forma consiste en general en interminables documentos que nadie es capaz de leer ni entender.  La pérdida de información es considerable. Quien describe los requerimientos del sistema no dialoga con quien lo implementa y el testeo ocurre sin conocer al cliente. No es que siempre deba ser así, pero en la mayoría de los casos así ocurre y es difícil revertir esa tendencia.
  • Falta de flexibilidad: Debido a que mucho se define con muchos detalles en un inicio, es muy difícil cambiar la dirección y reaccionar al cambio. En nuestro mundo en el que nuevas tecnologías aparecen a diario y en mercados donde la competencia no duerme es necesario poder reaccionar. Por muy elaborado que sea el plan, si las reglas del juego cambian, habrá que rehacerlo y eso es caro!
  • Responsabilidad diluida: La responsabilidad por un producto no se comparte si cada parte involucrada es únicamente responsable por su trabajo. Los proyectos exitosos no sólo requieren excelentes profesionales que dominen sus áreas, sino que además un equipo en el cual todos trabajan juntos tras un objetivo común.  Si cada quién es responsable sólo por su parte del proceso y no por el resultado común, es difícil producir un buen producto.
La industria del software ha reaccionado a éste fenómeno con movimientos como el desarrollo ágil, que ayudan a subsanar estos problemas. Estoy seguro que el desarrollo en cascada puede ser la solución para uno que otro proyecto de software, pero para la gran mayoría hay alternativas mejores y mi recomendación para todo aquel que gane su vida en la industria del software es que gaste algunos minutos leyendo y pensando acerca de metodologías modernas como por ejemplo Scrum, XP, Kanban, Lean y Feature Driven.

No hay comentarios:

Publicar un comentario