Ciclos de vida para gestionar (no sólo software): cascada, espiral, iterativo, incremental o ágil

Es curioso ver como el concepto “ciclo de vida”, una de las piezas más fundamentales, y transcendentales, de la gestión software (u otros) produce tanta confusión.

En parte, tampoco es de extrañar, debido a que no existe una única terminología al respecto, existen muchas definiciones, conceptos confusos, etc.

No obstante, en este post he querido tocar el tema de los ciclos de vida, porque me parece fundamental y porque encuentro que hay muchas dudas al respecto. Y a sabiendas de que el tema es demasiado profundo para zanjarlo en un post y de que voy a tener que dejar en el mismo sólo conceptos y definiciones sobre las que más consenso hay, sabiendo que hay autores que a muchos de los siguientes les dan otros nombres y los particularizan.

Pero por introducir el tema, y aclararlo en lo que pueda, que no quede. Ahí va…

Cascada

Las fases del ciclo de vida (requisitos, análisis, diseño, etc.) se realizan (en teoría) de manera lineal, una única vez, y el inicio de una fase no comienza hasta que termina la fase anterior.

Su naturaleza es lineal, típica de la construcción de productos físicos (lo comentamos en dos razones por las que fabricar software no es lo mismo que fabricar coches o construir casas), y su principal problema viene de que no deja claro cómo responder cuándo el resultado de una fase no es el esperado.

El ciclo de vida más criticado en los últimos años, la mayoría de las veces, que no todas, con razón. En muchos proyectos su implantación ha sido un fracaso, mientras que hay otros proyectos que van perfectamente de esta manera (aunque cada vez son menos, por como ha ido cambiando la naturaleza de lo que «creamos», que ha ido moviéndose a entornos más cambiantes y de incertidumbre).

Erróneamente a este ciclo de vida se le ha hecho sinónimo de la palabra “proceso”, como comentamos en mitos del Desarrollo Software: Proceso es sinónimo de ciclo de vida en cascada.

Espiral

Para resolver los anteriores problemas, en 1984 Boehm presenta el ciclo de vida en espiral, en el que cada una de las fases del cascada termina con una evaluación de riesgos y un prototipo.

Los prototipos permiten a los usuarios determinar si el proyecto continua, debe volver a fases anteriores, o debe terminar. Sin embargo, las fases son todavía lineales, los requisitos se realizan en la fase de requisitos, el diseño en la fase de diseño, y así sucesivamente.

El ciclo de vida incremental

Cada iteración (una iteración es un periodo de tiempo, no confundir con el ciclo de vida iterativo, que veremos luego, siendo este uno de los principales líos que vienen de definiciones confusas) contiene las fases del cascada estándar, pero cada iteración trabaja sobre un sub conjunto de funcionalidad. La entrega total del proyecto se divide en subsistemas priorizados.

Desarrollar por partes el producto software, para después integrarlas a medida que se completan.

Un ejemplo de un desarrollo puramente incremental puede ser la agregación de módulos en diferentes fases. El agregar cada vez más funcionalidad al sistema.

El ciclo de vida iterativo

En cada ciclo, iteración, se revisa y mejora el producto. Un ejemplo de desarrollo iterativo es aquel basado en refactorizaciones (te dejo el post de introducción a la refactorización), en el que cada ciclo mejora más la calidad del producto.

Es importante señalar que este ciclo no implica añadir funcionalidades en el producto, pero si la revisión y la mejora.

Iterativo e incremental

Incremental = añadir, iterativo = retrabajo, que decía Cockburn.

Se va liberando partes del producto (prototipos) periódicamente, en cada iteración, y cada nueva versión, normalmente, aumenta la funcionalidad y mejora en calidad respecto a la anterior.

Aquí hay un post con más información.

El ciclo de vida iterativo e incremental es una de las buenas prácticas de ingeniería del software más antiguas, su primer uso en el software se data en los 50 (te dejo este post donde hablamos del tema).

Sobre estos dos ciclos de vida te dejo un artículo de Cockburn especialmente aclaratorio.

Además, el ciclo de vida iterativo e incremental es una de las bases de la gestión ágil, más concretamente, con iteraciones cortas en tiempo, de pocas semanas, normalmente un mes y raramente más de dos.

Ciclos de vida de las «metodologías» ágiles

Yendo a una definición de mínimos, sería un ciclo de vida iterativo e incremental, con iteraciones cortas (semanas) y sin que dentro de cada iteración tenga porque haber fases lineales (tipo cascada).

A partir de la anterior, matizaciones, adaptaciones, etc., hay por cada «metodología» ágil que existe.

Quizá el caso más popular es el de Scrum. Hace ya sus años, en el 85, y en la primera presentación oficial de Scrum, Ken Schwaber, uno de sus creadores, hablaba sobre el ciclo de vida de Scrum, y sus diferencias con los anteriores ciclos de vida

Según comenta Ken Schwaber, el ciclo de vida en Cascada y el Espiral cierran el contexto y la entrega al inicio de un proyecto. La principal diferencia entre cascada, espiral e iterativo y los ciclos de vida ágiles, concretamente en Scrum, es que estos últimos asumen que el análisis, diseño, etc., de cada iteración o Sprint son impredecibles. Los Sprints, o iteraciones cortas, no son (o a priori no tienen porque) lineales y son flexibles.

Pero, como comentaba, cada «metodología» de las llamadas ágiles, FDD, Crystal, DSDM, XP, etc., matizará su ciclo de vida.

7 comentarios en “Ciclos de vida para gestionar (no sólo software): cascada, espiral, iterativo, incremental o ágil”

  1. Pingback: Bitacoras.com

  2. El problema principal que veo yo son los clientes que quieren una combinación de sistemas tradicionales y ágiles.
    Más concretamente: los que quieren un presupuesto cerrado pero trabajar con algo parecido a metodologías ágiles y continuamente plantean cambios de requerimientos y cambios de prioridades.
    Yo aun no sé como tratar estos casos que, por otra parte, me parece que se trata de una mezcla de incompetencia y jeta pura y dura.

  3. Buenas tardes
    Estoy haciendo una tesis de ingenieria en Sist. de Información.. mi pregunta es la siguiente:
    El ciclo de vida que se utiliza es en cascada..
    La metodología utilizada puede ser RUP?
    Se puede adaptar Cascada con Proceso Unificado?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba