Planificación del ciclo de vida

TODO ESFUERZO DE DESARROLLO DE SOFTWARE atraviesa por un

“ciclo de vida”, el cual consiste en todas las actividades entre el tiempo que la versión
1.0 de un sistema empieza su vida como una idea y el tiempo en que la versión 6.74b
finalmente da su ultimo respiro en la maquina del cliente. Un modelo ciclo de vida es un
modelo en perspectiva de lo que debería pasar entre la primer idea y el ultimo respiro.
Para nuestros propósitos, la función principal de un ciclo de vida es establecer el
orden en que en un proyecto se especifican, prototipos, diseños, implementaciones,
revisiones, pruebas y se realizan otras actividades. Establece el criterio que usaras para
determinar cuando proceder de una tarea a la siguiente. Este capitulo se concentra en
una parte limitada del ciclo de vida, el periodo entre la primer idea y el release inicial.
Puedes usar este foco tanto en un producto nuevo como para actualizaciones de
software ya existente.
El ciclo de vida mas familiar es el bien conocido ciclo de vida en cascada, el
cual tiene unas deficiencias igualmente bien conocidas. Hay otros ciclos de vida
disponibles, en muchos casos son una mejor elección para un desarrollo veloz
comparados al cascada. (El modelo de cascada será descrito en la siguiente sección,
“Cascada pura”.)
Al momento de definir el plan maestro de un proyecto, el ciclo de vida que elijas
tendrá tanta influencia en el éxito del proyecto como cualquier otra decisión de
planificación que tomes. El ciclo de vida apropiado puede hacer más eficiente tu
proyecto y ayudarte a asegurar que cada paso te acerca más a tu meta. Dependiendo del
ciclo de vida que elijas, podes mejorar la velocidad de desarrollo, la calidad, el
seguimiento y control, minimizar el esfuerzo adicional, la exposición al riesgo, o
mejorar las relaciones con los clientes. El ciclo de vida incorrecto puede ser una fuente
constante de demoras, trabajo repetido e innecesario, y frustración. No elegir un ciclo de
vida puede producir los mismos efectos.
Hay muchos ciclos disponibles. En las siguientes secciones, voy a describir los
modelos; y en la sección final, voy a describir como elegir el que mejor se ajuste a tu
proyecto.

Caso de estudio 7-1. Selección del ciclo de vida inadecuado

Los agentes de campo de Giga-Safe estaban reclamando por una actualización a
Giga-Qoute 1.0, para corregir defectos o algunos defectos de la interfaz de usuario. Hill
fue reasignado como líder de proyecto para Giga-Qoute 1.1 después de haber sido
sacado al fin de Giga-Qoute 1.0, y trajo a Randy para aconsejar. Randy es un consultor
que cobra caro y lo conoció en un bar.
“Esto es lo que deberías hacer”, dijo Randy. “Tuviste muchos problemas de
cronograma la vez anterior, entonces esta vez tienes que organizar tu proyecto para ser
un desarrollo veloz. Prototipando es la forma más rápida, entonces debes hacer que tu
equipo haga eso”. Hill pensó que sonaba bien, entonces cuando se junto con el equipo,
les dijo que usaran prototipado.
Mike era el líder técnico en el proyecto, y se sorprendió. “Bill, no entiendo tu
razonamiento”, dijo. “Tenemos seis meses para arreglar un puñado de bugs y hacer
algunos cambios a la UI. ¿Para qué quieres prototipar?”
 “Necesitamos un prototipo para acelerar el proyecto”, dijo Bill. “El Prototipado
es la ultima, y más rápida aproximación, y eso es lo que quiero que usen. ¿Hay algún
problema con eso?”
Un poco susceptible, Mike pensó. “OK”, dijo. “Desarrollaremos un prototipo si
es lo que quieres”.
Mike y otro desarrollo, Sue, fueron a trabajar con el prototipo. Como era casi
idéntico al sistema actual, tomo solo unos pocos días simular el sistema completo.
Al principio de la semana dos, le mostraron el prototipo al líder de los agentes de
campo, A.J. “¡Mierda, no loe puedo decir a mis agentes que esto es todo lo que van a
tener!” exclamó A.J. “¡Hace apenas un poco más del que tenemos ahora! Mis agentes
están chillando por tener algo mejor. Tengo algunas ideas para nuevos reportes acá. Les
voy a mostrar”. Mike y Sue escucharon pacientemente, y después de la reunión Mike
fue con Bill.
“Le mostramos el prototipo a A.J. Quiere agregar algunos reportes, y no aceptara
un no como respuesta. Pero tenemos las manos llenas con el trabajo que supuestamente
ya deberíamos estar haciendo”.
“No veo el problema” dijo Bill. “El es el líder de los agentes de campo. Si dice
que necesitan algunos reportes nuevos, necesitan reportes nuevos. Ustedes tendrán que
encontrar una manera de hacerlos a tiempo”.
“Lo voy a intentar” dijo Mike. “Pero debo decirte que solo hay un 1 por ciento
de chance de que terminemos a tiempo si agregamos esos reportes”.
“Bueno, los tienen que hacer” dijo Bill. “Tal vez ahora que están usando el
prototipado, el trabajo vaya mas rápido de lo que esperan”.
Dos días después, A.J paró en el cubículo de Mike. “Estuve mirando el
prototipo, y creo que necesitamos rediseñar algunas pantallas también, se lo mostré a
algunos de mis agentes ayer en una reunión. Dijeron que te van a llamar con algunas
ideas más. Les di tu número, espero que no te importe. ¡Seguí trabajando así!”.
“Gracias” dijo Mike mientras se recostaba en su silla. Más tarde, le preguntó a
Bill si le podía hablar a A.J sobre los cambio, pero dijo “No”.
Al día siguiente, Mike recibió llamadas de dos agentes que estuvieron en la
reunión. Los dos querían más cambios en el sistema. Durante las dos semanas siguientes
recibió llamadas todos los días, y la lista de cambios se agigantó.
A las 4 semanas de su proyecto de seis semanas, Mike y Sue estimaron que
habían recibido 6 meses de cambios que se suponían tenían que estar hechos en dos
semanas. Mike se junto con Bill otra vez. “Me desilusionaste”, dijo Bill. “Le prometí a
A.J y a los agentes que ibas a hacer los cambios que pidieron. No le estas dando
ninguna chance al prototipazo. Solo esperá que comience a funcionar”.
Ya empezó a funcionar, pensó Mike, y yo soy el que esta siendo pateado. Pero
Bill estaba decidido.
A las ocho semanas, Bill se empezó a quejar que Mike y Sue no estaban
trabajando lo suficiente. A las diez semanas, Bill empezó a aparecer por sus cubículos
dos veces al día para chequear su progreso. Para el final de la semana doce, los agentes
se estaban quejando, y Bill dijo, “Necesitamos entregar algo. Entreguen lo que tienen
ahora”. Como ni los nuevos reportes o las nuevas pantallas estaban terminadas, Mike y
Sue harcodearon el código en desarrollo y entregaron una versión que consistía en
algunas correcciones de bugs y defectos en la UI, más o menos lo que habían
planificado desarrollar y entregar en primer lugar, pero tomó doce semanas en lugar de
seis.

Cascada pura
El abuelo de todos los ciclos de vida es el modelo de cascada. A pesar de que
tiene muchos problemas, sirve como base para otros modelos más efectivos, por eso se
lo describe primero. En el modelo de cascada, un proyecto progresa a través de una
secuencia de pasos ordenados desde la idea inicial hacia la prueba de sistema. El
proyecto tiene una revisión al final de cada fase para determinar está listo para avanzar a
la siguiente, por ejemplo, del análisis de requerimientos a diseño arquitectónico. Si la
revisión determina que el proyecto no está listo para avanzar a la siguiente fase, se
queda en la actual hasta que lo este.
El modelo de cascada esta dirigido por documentos, lo que significa que los
productos que son transportados de una fase a otra son principalmente documentos. En
el modelo de cascada pura, las fases son discontinuas, no se solapan. La Figura 1
muestra el progreso en un modelo de cascada pura.
Este modelo funciona bien en ciclos donde ya tenes una definición estable y
cuando estas trabajando con metodologías bien entendidas. En esos casos el modelo te
ayuda detectar errores en las estapas más tempranas y baratas del proyecto. Provee la
estabilidad a los requerimientos que los desarrolladores siempre ansian. Si estas
construyendo un mantenimiento bien definido de un produicto existente o migrando un
producto existente a otra plataforma, el modelo cascada puede ser la eleccion correcta
para un desarrollo veloz.
Este modelo ayuda a minimizar el esfuerzo de planificación porque puedes
hacerla toda al principio. No provee resultados tangibles en forma de software hasta el
final, pero, para alguien que esta familiarizado con el, la documentación que genera
provee indicadores significativos del progreso.
 Figura 1. El modelo de cascada pura. El modelo de cascada pura el mejor conocido y provee
buena velocidad de desarrollo en algunas circunstancias. Otros modelos, sin embargo,
usualmente proveen más velocidad

El modelo de cascada funciona bien en los proyectos que son bien entendidos
pero complejos, porque podes beneficiarte de abordar la complejidad de una manera
ordenada. Funciona bien cuando la calidad domina al costo y el tiempo. La eliminación
de cambios de idea a la mitad elimina una gran fuente de errores potenciales.
El modelo de cascada funciona especialmente bien si tenemos un staff débil o
sin experiencia, porque provee al proyecto con una estructura que ayuda a minimizar el
esfuerzo desperdiciado.
Las desventajas de este modelo, provienen de la dificultad de podes especificar
completamente los requerimientos al principio del proyecto, antes de que el diseño se
haya hecho y el código se haya escrito.
Los desarrolladores se quejan que los usuarios no saben lo que quieren, pero
supongamos que los roles fueran invertidos. Imagínate tratando de especificarle tu auto
a un ingeniero automotriz. Le decís que querés un motor, chasis, ventanas, volante,
acelerador, freno, freno de mano, asientos, y así. Pero ¿podes acordarte de todo lo que
un ingeniero automotriz necesita para construir tu auto?
Supongamos que te olvidas de especificar que necesitas luces de reversa, que se
encienden cuando el auto va hacia atrás. El ingeniero se va por seis meses y vuelve con
auto sin luces de reversa. Le decís, “Me olvide de decirte que el auto tiene que tener
luces de reversa, que se prendan automáticamente cuando pongo la marcha atrás”.
El ingeniero se vuelve loco. “¿Sabes lo que va a costar conectar un cable de la
caja de cambios a la parte de atrás? ¡Tenemos que rediseñar el panel de cola, poner un
cable para la luz de stop y otro sensor para la caja, esto va a tomar semanas, o meses!
¿Por qué no me lo dijiste al principio?
Pensás, “parecía un cambio simple”…
Es un error comprensible ¿no? Un auto es algo complicado para que alguien
novato lo especifique. Muchos softwares también lo son, y la gente que tiene la tarea de
especificarlos no son expertos en computadora por lo general. Pueden olvidarse cosas
que parecían simples hasta que ven el producto funcionando. Si estás usando un modelo
de cascada, olvidarse algo puede ser un error muy caro. No te darás cuenta hasta que
llegues a la prueba de sistema y veas que un requerimiento estaba mal o faltaba.
Entonces, el primer gran problema del modelo de cascada es que no es flexible.
Tenés que especificar completamente los requerimientos al principio del proyecto. Lo
cual puede ser meses o años antes de que tengas un software funcionando. Esto burla las
necesidades de los negocios modernos, en los cuales el dinero va a los desarrolladores
que pueden implementar la mayor cantidad de funcionalidad al final del proyecto.
Como dice Roger Sherman de Microsoft, la meta por lo general no es lograr lo que
dijiste al principio del proyecto, sino lo máximo que sea posible con el tiempo y los
recursos disponibles.
Algunas personas criticaron el modelo de cascado por no permitir volver atrás
para corregir los errores. Esto no es tan así. Como sugiere la Figura 1, volver atrás está
permitido, pero es difícil. Una vista diferente del modelo que puede poner esto en una
mejor perspectiva es el ciclo de vida del salmón (Figura 2).
Se te permite nadar hacia arriba, ¡pero el esfuerzo te puede matar! Al final del
diseño arquitectónico, participaste en tantos eventos que declararon que estabas al final
de esa fase. Realizaste una revisión de diseño, y firmaste la copia oficial del documento
de arquitectura. Si descubrís una falla durante la codificación y depuración, es difícil
nada hacia arriba para mejorar la arquitectura.
 Figura 2. Otra representación del modelo de cascada., ciclo de vida del salmón, No es
imposible volver atrás pero, es difícil.

El modelo de cascada tiene otras deficiencias. Algunas herramientas, métodos, y

actividades tiene fases del ciclo de cascada; es difícil acomodarlas en el las fases
separadas del modelo. Para un desarrollo veloz, el modelo de cascada puede prescribir
una cantidad excesiva de documentación. Si estas tratando de tener flexibilidad,
actualizar la especificación se vuelve una tarea de tiempo completo. El modelo genera
muy pocos signos visibles de progreso antes del final. Esto puede crear la percepción de
un desarrollo lento, aunque no sea cierto. A los clientes les gusta tener seguridades
tangibles de que su proyecto va a estar terminado a tiempo.
En resumen, Las debilidades del modelo de cascada pura lo vuelven poco acorde
para desarrollos rápidos. Incluso en los casos en que las ventajas superan a las
desventajas, las cascadas modificadas pueden funcionar mejor.

Code-and-Fix
El modelo code-and-fix, es un modelo que rara vez es útil, pero dista mucho de
ser común, entonces me gustaría discutirlo. Si no has elegido explícitamente otro ciclo
de vida, probablemente estés usando code-and-fix. Si no has hecho mucha planificación,
sin dudas estas usando code-and-fix. Combinado con un cronograma chico, code-and-
fix se convierte en la aproximación code-like-hell descrita antes.
Cuando usas code-and-fix empiezas con una idea general de lo que vas a hacer.
Tal vez tengas una especificación formal, o tal vez no. Después usas cualquier
combinación de diseño informal, codificación, depuración y metodologías de prueba
hasta que tu producto este listo para se lanzado. La Figura 3 muestra este proceso.
 Figura 3. El modelo code-and-fix. Code-and-fix es un modelo
informal que es de uso común porque es simple, no porque
funcione bien.

Este modelo tiene dos ventajas, Primero no tiene sobrecarga: no desperdicias

tiempo planificando, documentando, con QA, o con cualquier otra actividad que no sea
codificar. Como saltas directamente al código, podes mostrar signos de progreso
inmediatamente. Segundo, solo se requiere poca de experiencia: cualquiera que haya
escrito un programa esta familiarizado con el code-and-fix. Cualquiera lo puede usar.
Para proyectos chicos que vas a tirar un poco después de que sean construidos,
este modelo puede ser útil, para programas que sirvan como prueba de concepto, para
demos o para prototipos desechables.
Para cualquier tipo de proyecto que no sea chico, este modelo es peligroso.
Puede que no tenga sobrecarga, pero tampoco provee medios para medir progreso; solo
codificas hasta que este terminado. No provee medios para medir la calidad o identificar
riesgos. Si faltando un cuarto del camino descubrís que todo el diseño esta mal, no tenés
otra alternativa que tirar todo y volverlo a hacer. Otros modelos te hubieran obligado a
encontrar ese error antes, cuando hubiera sido mas barato corregirlo.
Al final, este ciclo de vida no tiene lugar en un proyecto de desarrollo veloz,
excepto para los ya indicados antes.

Espiral
Al otro extremo de la sofisticación esta el modelo en espiral. Este es un modelo
orientado a riesgos que divide el proyecto en miniproyectos. Cada miniproyecto mitiga
uno o más de los riesgos más importantes hasta que todos hayan sido mitigados. El
concepto de “riesgo” es definido de manera muy amplia en este contexto, y puede
referirse a requerimientos poco entendidos, arquitectura poco entendida, problemas de
performance potenciales, problemas con la tecnología de base, y más. Después que los
riesgos más importantes hayan sido mitigados, el espiral termina como un ciclo de vida
en cascada. La Figura 4 ilustra el modelo en espiral.
La Figura 4 es un diagrama complicado, y vale la pena estudiarlo. La idea básica
detrás del mismo es que empezas en una escala menor en el medio de la espina,
exploras los riesgos, haces un plan para manejarlos y luego te preparas para la próxima
iteración. Sacas una capa del rollo, te aseguras que es lo que querías y empezas a
trabajar en capa siguiente.
Cada iteración involucra los seis pasos que están en negrita afuera del límite de
la espiral:
1. Determinar objetivos, alternativas y restricciones
2. Identificar y resolver riesgos
 3. Evaluar alternativas
4. Desarrollar los entregables para cada iteración, y verificar que estén bien
5. Planificar la próxima iteración
6. Prepararse para la próxima iteración (si decides que vas a tener una)
En el modelo de espiral, las iteraciones del principio son las más baratas. Gastas
menos desarrollando el concepto que desarrollando los requerimientos, y menos
desarrollando los requerimientos que desarrollando el diseño, implementando el
producto y probándolo.
No tomes el diagrama literalmente tanto como fue pensado. No es importante
que tengas exactamente cuatro vueltas alrededor del espiral, y tampoco es importante
que lleves a cabo los seis pasos exactamente como están indicados, aunque ese es un
buen orden. Puedes modificar cada iteración para que se ajusten a las necesidades de tu
proyecto.

Figura 4. El modelo en espiral. En el modelo de espiral, empezas con poco y vas expandiendo
el alcance del proyecto. Solo expandís el alcance después de reducir los riesgos a un nivel
aceptable.

Podes combinar el modelo con otros ciclos de vida en muchas formas. Podes
empezar tu proyecto con una serie de iteraciones para reducir el riesgo; luego que los
hayas reducido a un nivel aceptable, podes finalizar el desarrollo con un cascada o otros
no basados en riesgos. Podes incorporar otros ciclos de vida como iteraciones dentro del
espiral. Por ejemplo, si uno de los riesgos es que no estés seguro que los requerimientos
de performance sean factibles, podes incluir una iteración de prototipazo para investigar
si es posible cumplir los objetivos.
 Una de las desventajas más importantes del modelo en espiral es que costo se
incrementa como el riesgo se reduce. Cuanto mas dinero y tiempo gastes, estarás
tomando menos riesgos, que exactamente lo que querés es un proyecto de desarrollo
veloz.
El modelo en espiral provee como mínimo tanto control de administración como
el cascada. Tenés hitos al final de cada iteración. Como el modelo esta orientando a
riegos, te provee indicaciones tempranas de cualquier riesgo insuperable. Si el proyecto
no se puede hacer por alguna razón, te darás cuanta rápido, y no te costará mucho.
La única desventaja de este modelo es que es complicado. Requiere conciencia,
tención y conocimiento para administrarlo. Puede ser difícil definir el objetivo, o los
hitos que te dicen si podes agregar otra capa. En algunos casos el desarrollo es tan
derecho y los riesgos del proyecto son tan pocos que no es necesaria la flexibilidad y la
administración de riesgos que provee el espiral.

Cascadas modificadas
Las actividades identificadas en el modelo de cascada pura son intrínsecas al
desarrollo de software. No se pueden evitar. Tiene que llegar a una idea de alguna
manera, y tenés que obtener los requerimientos de alguna manera. No tenés que usar el
modelo de cascada para obtener los requerimientos, pero tenés que usar algo. De la
misma forma, no se puede evitar la arquitectura, el diseño o la codificación.
La mayoría de las debilidades de la cascada pura no son culpa de estas
actividades sino de tratar esas actividades como actividades separadas y secuenciales.
Entonces se puede corregir esas debilidades con algunas relativamente pequeñas
modificaciones. Podes modificarlo de manera que las fases se solapen, podes reducir el
énfasis en la documentación o facilitar la vuelta atrás.

Sashimi (Cascada con Fases Solapadas)

Peter DeGrace describe una de las modificaciones a la cascada como el “modelo
sashimi”. El nombre proviene de una forma japonesa de desarrollar hardware y se
refiere a la forma japonesa de presentar el pescado cortado en rodajas, con las rodajas
solapándose con las otras. (El hecho que este modelo se relaciones con pescados no
significa que este relacionado con el del salmón). La Figura 5 muestra mi versión de
cómo el modelo sashimi se ve para el software.
 Figura 5. El modelo sashimi. Podes superar algunas
limitaciones del modelo cascada al solapar sus etapas, pero
la aproximación crea nuevos problemas.

El modelo tradicional de cascada permite un mínimo solapamiento entre fases, al

final de la revisión de fase. Este modelo siguiere un grado más fuerte de solapamiento,
por ejemplo, podes estar bien en el diseño arquitectónico y a mitad de camino en el
diseño detallado para considerar que el análisis de requerimientos esta terminado. Creo
que es una aproximación razonable para muchos proyectos, los cuales tienden a ganar
entendimientos importantes a medida que avanzan.
En el modelo de cascada pura, la documentación ideal es la que un equipo le
puede entregar a otro completamente separado entre dos fases. La pregunta es ¿Por qué?
Si podes contar con el mismo personal entre cada fase no necesitas tanta
documentación. Podes seguir una cascada modificada y reducir sustancialmente la
documentación requerida.
El modelo sashimi no carece de programas. Como hay un solapamiento entre
fases, los hitos son más ambiguos, y es más difícil medir el progreso con precisión.
Realizar actividades en paralelo puede llevar a la incomunicación, suposiciones
erróneas, e ineficiencia. Si estás trabajando en un proyecto chico y bien definido, algo
mas cercano a la cascada pura puede ser el modelo más eficiente.