Barrapunto

A riesgo de repertirme (otra vez) y de que nadie parezca escuchar: O hablamos de la metodología en cascada original y nos ceñimos a ella (y tenemos en cuenta lo que *no* indica) o hablamos de otra metodología distinta (Métrica3 o la que mejor te parezca) y entonces las virtudes y defectos son las propias de esa metodología.

Y si ahora, con la definición de metodología en la mano, te parece que la cascada no es una metodología, lo dices y en paz: Podremos estar o no de acuerdo, pero al menos no estaremos mareando la perdiz inútilmente.

Por cierto, yo también tengo una cita de la Wikipedia [wikipedia.org] (en inglés): "Generally speaking, methodology does not describe specific methods despite the attention given to the nature and kinds of processes to be followed in a given procedure or in attaining an objective. When proper to a study of methodology, such processes constitute a constructive generic framework; thus they may be broken down in sub-processes, combined, or their sequence changed.[4] As such, methodology may entail a description of generic processes, philosophical concepts or theories related to a particular discipline or field of inquiry" (resaltados míos). Aunque no creo que convertir esto en una competición de citas lleve a ningún lado.

Yo no me estoy refiriendo a otra cosa que no sea la Metodología en Cascada "original". Si vamos a la aceptada como primera descripción formal de esta metodología, presentada por Winston W. Royce en "Managing the Development of Large Software Systems", destaca la importancia de documentar "exhaustivamente" todas y cada una de las fases, incluso a costa de paralizar todo el proceso de desarrollo hasta que no se haya completado la documentación. Ésa es la "burocracia" a la que me refería yo, sin consierar ni métrica3 ni nada parecido (que nunca he nombrado).

Éso sí, si relajamos la exigencia de la documentación, igual tenemos algo más "ágil" y adecuado para desarrollos medios. Pero entonces no estamos hablando de la metodología original.