Mayo 05 2009

¿Cómo debió ser el Desarrollo en Cascada?

Categoría: MetodologíasJuan @ 2:09 pm

Sí, lo admito, todo este tiempo y todavía no había leído el artículo al que se le da la autoría del llamado “desarrollo en cascada”. Hasta hace un par de días.

El artículo en cuestión se titula “Managing the Development of Large Software Systems” y su autor es el Dr. Winston W. Royce. Este artículo, como se ha dicho anteriormente, es el que se toma como el origen del desarrollo en cascada aunque este nombre no se menciona en el artículo y está citado más de 1200 según el Sr. Google.

Para mi asombro, el artículo es muy diferente de lo que esperaba porque en realidad NO propone el desarrollo en cascada (tal y como lo conocemos) como la panacea para el desarrollo del software sino que el autor lo presenta en la primera mitad del artículo como un acercamiento grandioso. Sin embargo, después, el autor trata de encontrar sus problemas y dar soluciones en la segunda mitad.

Waterfall model

-fuente: http://en.wikipedia.org/wiki/File:Waterfall_model.png-

Por ejemplo, el autor dice cosas como las que siguen sobre el típico desarrollo en cascada (ver imagen):

I believe in this concept, but the implementation described above is risky and invites failure.
[Creo en este concepto, pero la implementación descrita más arriba es arriesgada e invita al fallo.]

o esta otra

The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required.
[El cambio requerido en el diseño es probablemente tan perjudicial que los requerimientos en los que se ha basado el diseño y los que proporcionan el fundamento de todo son violados. O los requerimientos deben ser modificados, o un cambio substancial en el diseño es requerido.]

… entre muchas otras.

Royce hace visible algunos de los problemas que tiene el desarrollo en cascada y da soluciones para mejorar el proceso en lo que queda de artículo (segunda mitad). Resumiendo y siendo muy breve, el autor da cinco pasos o mejoras para atajar los problemas. Éstas son:

  1. Incluir una etapa de diseño del programa entre las fases de requerimientos y análisis.
  2. Documentar mucho y bien.
  3. Hacerlo dos veces (iterar el proceso siendo la primera iteración una simulación)
  4. Planificar, controlar y monitorizar las pruebas. Es decir, poner énfasis en la calidad.
  5. Implicar al usuario. Royce, además, dice que la implicación debe ser formal, profunda y continua.

No sé qué os parece a vosotros pero el punto 3 y el 5 se han quedado por el camino (y en muchos casos el 4 que es lo primero que se recorta si se va ajustado de tiempo) y estos, precisamente, ¿no os recuerdan a algo? :-)

Recomiendo que leais el artículo original si podéis y tenéis tiempo. Realmente merece la pena.

Etiquetas:


Sep 11 2008

Video, cascada vs. ágil

Categoría: Metodologías, VideosJuan @ 8:18 am

Una pena que este video esté sólo en inglés :-( pero para aquellos que lo entiendan merece la pena verlo.

Es entretenido, graciosillo y un buen resumen/comparacíon entre las metodologías en cascada y las ágiles. Además, la musiquilla es pegadiza.

Etiquetas: ,