El Proceso Unificado es

Iterativo e Incremental

ndice
Diferencias

de lo Iterativo e Incremental
con el Modelo cascada
Planificacin de las iteraciones
Secuenciacin de las iteraciones
El resultado de una iteracin es un
incremento
Las iteraciones sobre el ciclo de vida
Los modelos evolucionan con las
iteraciones
Las iteraciones desafan a la organizacin

En qu se diferencia esto de un
modelo en cascada tradicional?

Cada uno de los flujos de trabajo fundamentales es

una colaboracin entre un conjunto de trabajadores y
artefactos.

Sin embargo, hay coincidencias entre las iteraciones.

Los trabajadores y los artefactos pueden participar en

ms de un flujo de trabajo.

Por ejemplo, el ingeniero de componentes participa

en tres flujos de trabajo: anlisis, diseo e
implementacin. Por ltimo, el flujo de trabajo de la
iteracin se crea superponiendo, uno encima de otro,
un subconjunto elegido de los flujos de trabajo
fundamentales, y aadiendo lo extra, como la
planificacin y el anlisis.

En qu se diferencia esto de un
modelo en cascada tradicional?

Las primeras iteraciones se centran en la comprensin

del problema y de la tecnologa. En la fase de inicio,
las iteraciones se preocupan de producir un anlisis
del negocio. En la fase de elaboracin, las iteraciones
se orientan al desarrollo de la lnea base de la
arquitectura. En la fase de construccin, las
iteraciones se dedican a la construccin del producto
por medio de una serie de construcciones dentro de
cada iteracin, que acaban en un producto preparado
para su distribucin a la comunidad de usuarios. Sin
embargo, como se muestra en la Figura 5.3, todas las
iteraciones siguen el mismo patrn.
Durante la fase de inicio, una iteracin puede
seguir una variante simplificada de los flujos de
trabajo para estudiar problemas particulares
relativos a la tecnologa.

En qu se diferencia esto de un
modelo en cascada tradicional?

Cada iteracin se analiza cuando termina.

Uno de los objetivos es determinar si han aparecido

nuevos requisitos o han cambiado los existentes,
afectando a las iteraciones siguientes.

Durante la planificacin de los detalles de la siguiente

iteracin, el equipo tambin examina cmo afectarn
los riesgos que an quedan al trabajo en curso.

Una funcin que merece un nfasis especial en este

momento son las pruebas de regresin.

Antes de finalizar una iteracin, debemos estar

seguros de que no hemos estropeado ninguna otra
parle del sistema que funcionaba en anteriores
iteraciones.

En qu se diferencia esto de un
modelo en cascada tradicional?

La prueba de regresin es especialmente importante

en un ciclo de vida iterativo e incremental, debido a
que cada iteracin produce una adicin significativa al
incremento previo, al mismo tiempo que una cantidad
importante de cambios.

Debemos sealar que no es prctico llevar a cabo las

pruebas de regresin a tan gran escala cada
construccin de cada iteracin sin las herramientas
de prueba adecuadas.

Los jefes de proyecto no deberan permitir que

comience la siguiente iteracin a menos que se hayan
conseguido los objetivos de la presente.

Si no se hace as, la planificacin tendr que cambial

para adecuarse a la nueva situacin.

Figura 5.3. Cada iteracin constituye una pasada a

travs de los cinco flujos de trabajo fundamentales. Se
inicia con una actividad de planificacin y se concluye
con un anlisis.

Regresar

Planificacin de las iteraciones

En cualquier caso, el ciclo de vida iterativo requiere ms

planificacin y ms reflexin que el mtodo en cascada.

En el modelo en cascada toda la planificacin se hace al

principio, a menudo antes de que se hayan reducido los
riesgos y antes de que se haya asentado la arquitectura
Las planificaciones que se obtienen estn basadas en
mucha incertidumbre y falta de fidelidad.

En contraste, el mtodo iterativo no planifica el

proyecto entero en detalle durante la fase de inicio, slo
da los primeros pasos.

El equipo de proyecto no intenta planificar las fases de

construccin y transicin hasta que se ha establecido
una base de hechos durante la fase de elaboracin.
Naturalmente, hay un plan de trabajo durante las dos
primeras fases, pero no es muy detallado.

Planificacin de las iteraciones

El esfuerzo de planificacin tiene en cuenta

normalmente (excepto al principio del todo del
proyecto)
los
resultados
de
las
iteraciones
precedentes, la seleccin de los casos de uso
relevantes en la nueva iteracin, el estado actual de
los riesgos que afectan a la nueva iteracin, y el
estado de la ltima versin del conjunto de modelos.

Termina con la preparacin de la versin interna.

Al trmino de la fase de elaboracin, por tanto, existe

una base para planificar el resto del proyecto y para
poner en marcha un plan detallado para cada
iteracin de la fase de construccin.

Planificacin de las iteraciones

El plan para la primera iteracin estar muy claro.

Las posteriores aparecern en el plan menos

detalladas, y estarn sujetas a modificacin, de
acuerdo con los resultados y con el conocimiento que
se adquiera en las iteraciones anteriores.

De igual forma, debera haber un piar, para la fase de

transicin, pero puede que tenga que ser modificado
a la luz de lo que el equipe aprenda de las iteraciones
de la fase de construccin. Este tipo de planificacin
nos permite un desarrollo iterativo controlado.

Regresar

Secuenciacin de las
iteraciones

La evolucin en la naturaleza sucede sin un plan que la

preceda. ste no es el caso de la iteracin en el desarrollo
de software. Para entendernos, los casos de uso establecen
una meta, y la arquitectura establece un patrn. Con esta
meta y este patrn en mente, los desarrolladores planifican
la secuencia que seguirn en el desarrollo del producto.

Los planificadores tratan de ordenar las iteraciones para

obtener un camino directo en el cual las primeras
iteraciones proporcionan la base de conocimiento para las
siguientes.

Un proceso Iterativo e
Incremental

Las primeras iteraciones del proyecto dan como

resultado un mayor conocimiento de los requisitos,
los problemas, los riesgos, y el dominio de la
solucin, mientras que las siguientes dan como
resultado incrementos aditivos que finalmente
conforman la versin externa, es decir, el producto
para el cliente.

Para los planificadores, el xito fundamental es una

secuencia de iteraciones que siempre avanza, sin
tener que volver nunca a los resultados de una
iteracin previa para corregir el modelo debido a algo
que se descubri en una iteracin posterior.

Figura 5.4. Las iteraciones discurren a lo

largo de los flujos de trabajo desde la captura
de requisitos hasta la prueba.

Secuenciacin de las
iteraciones

Las iteraciones pueden solaparse en el sentido de que

una iteracin est a punto de terminar cuando otra
est comenzando, como se muestra en la Figura 5.4.

La planificacin y el trabajo inicial de la siguiente

iteracin deben comenzar a medida que terminamos
y preparamos para entregar la iteracin anterior.

Recurdese que el final de una iteracin significa que

hemos conseguido una conclusin dentro del equipo
de desarrollo.

Se ha integrado todo el software de la iteracin y

puede crearse la versin interna.

Secuenciacin de las
iteraciones
El

orden en el cual planificamos las

iteraciones depende, en un grado
considerable, de factores tcnicos.
Sin
embargo,
el
objetivo
ms
imprtame es ordenar el trabajo en
secuencia de modo que puedan
desarrollarse antes las decisiones ms
importantes, aqullas que implican
tecnologas,
casos
de
uso
y
arquitecturas nuevas.
Regresar

El resultado de una iteracin es

un incremento

Un incremento es la diferencia entre la versin interna de una

iteracin y la versin interna de la siguiente.

Al final de una iteracin, el conjunto de modelos que representa al

sistema queda en un estado concreto.

Llamamos a este estado la lnea base. Cada modelo ha alcanzado

una lnea base; cada elemento fundamental del modelo est en
un estado de lnea base.

Por ejemplo, el modelo de casos de uso al final de cada iteracin

contiene un conjunto de casos de uso que representan el grado en
que la iteracin ha desarrollado los requisitos.

Algunos de los casos de uso de este conjunto estn terminados,

mientras que otros slo lo estn parcialmente.

A su vez, el modelo de diseo ha llegado a un estado de lnea

base consistente con el modelo de casos de uso.

El resultado de una iteracin es

un incremento

Los subsistemas, interfaces, y realizaciones de casos

de uso del modelo de diseo se encuentran tambin
en lneas base que son mutuamente consistentes
unas con otras.

La organizacin del desarrollo debe mantener

versiones consistentes y compatibles de todos los
artefactos de cada lnea base para poder trabajar de
manera eficiente con muchas de ellas dentro del
proyecto.
Al emplear desarrollo iterativo, nunca es suficiente el
nfasis que podarnos hacer sobre la necesidad de
herramientas eficientes de gestin de configuracin.

El resultado de una iteracin es

un incremento

En un momento dado de la secuencia de iteraciones,

estarn terminados algunos subsistemas.

Estos contendrn toda la funcionalidad requerida, y

estarn implementados y probados.

Otros subsistemas estn parcialmente terminados, y

otros estn todava vacos, aunque contendrn
resguardos de forma que puedan funcionar e
integrarse con otros subsistemas. Por tanto, en
trminos ms precisos, un incremento es la diferencia
entre dos lneas base sucesivas.

El resultado de una iteracin es

un incremento

Durante la fase de elaboracin, como ya hemos

sealado, construimos la lnea base de la
arquitectura.
Identificamos los casos de uso que tienen un impacto
significativo
sobre
la
arquitectura,
y
los
representamos como colaboraciones.
sta es la forma en que identificamos los subsistemas
y las interfaces por lo menos, los que son
interesantes para la arquitectura.
Una vez que hemos identificado la mayora de los
subsistemas e interfaces, les damos forma, es decir,
escribimos el cdigo que los implementa.
Parte de este trabajo se hace antes de obtener la
lnea base de la arquitectura, y contina a lo largo de
todos los flujos de trabajo.

El resultado de una iteracin es

un incremento

Sin embargo, la mayor parte de la creacin tiene

lugar en las iteraciones de la fase de construccin.

A medida que nos acercamos a la fase de transicin,

incrementa el nivel de consistencia entre los modelos
y dentro de ellos.

Construimos incrementos dando forma a los modelos

de manera iterativa, y la integracin del ltimo
incremento se convierte en el sistema final.

Regresar

Las iteraciones sobre el ciclo de

vida
Cada

una de las cuatro fases termina con un

hito principal, como se muestra en la Figura
5.5. :

Inicio: objetivos del ciclo de vida.

Elaboracin: arquitectura del ciclo de vida.
Construccin: funcionalidad operativa inicial.
Transicin: versin del producto.

Las iteraciones sobre el ciclo de

vida

El objetivo de cada hito principal es garantizar que los

diferentes modelos de flujo de trabajo evolucionan de
manera equilibrada durante el ciclo de vida del
producto.

Entendemos equilibrada en el sentido de que se

toman pronto dentro del ciclo de vida las decisiones
ms importantes que influyen en esos modelos, las
relativas a los riesgos, casos de uso, y arquitectura.

Ms adelante, deberamos ser capaces de continuar el

trabajo con niveles de detalle crecientes obteniendo
una mayor calidad.

Las iteraciones sobre el ciclo de

vida

Los objetivos fundamentales de la fase de inicio son

el establecimiento del mbito de lo que debera hacer
el producto, la reduccin de los peores riesgos, y la
preparacin del anlisis del negocio inicial, que
indique que merece la pena realizar el proyecto desde
la perspectiva del negocio.

Dicho de otra forma, pretendemos establecer los

objetivos del ciclo de vida para el proyecto.

Figura 5.5. Las fases renen iteraciones que dan como

resultado los hitos principales, sobre los cuales la direccin
toma decisiones de negocio importantes. (El nmero de
iteraciones no es fijo, sino que vara para diferentes
proyectos.)

Las iteraciones sobre el ciclo de

vida

Los objetivos fundamentales de la fase de elaboracin

son obtener la lnea base de la arquitectura, capturar
la mayora de los requisitos, y reducir los siguientes
peores riesgos, es decir, establecer la arquitectura del
ciclo de vida. Al final de esta fase, somos capaces de
estimar los costes y las fechas y de planificar la fase
de construccin con algn detalle. En este momento,
deberamos ser capaces de hacer nuestra apuesta.

Los objetivos fundamentales de la fase de

construccin son el desarrollo del sistema entero, la
garanta de que el producto puede comenzar su
transicin a los clientes, es decir, que tiene una
funcionalidad operativa inicial.

Las iteraciones sobre el ciclo de

vida

El objetivo fundamental de la fase de transicin es

garantizar que tenemos un producto preparado para su
entrega a la comunidad de usuarios. Durante esta fase
del desarrollo, se ensea a los usuarios a utilizar el
software.
Dentro de cada fase hay hitos menores, en concreto, los
criterios aplicables a cada iteracin.
Cada iteracin produce resultados, artefactos del
modelo. Por tanto, al final de cada iteracin, Tendremos
un nuevo incremento del modelo de casos de uso, del
modelo de anlisis, del modelo de diseo, del modelo de
despliegue, del modelo de implementacin, y del modelo
de pruebas.
El nuevo incremento se integrar con el resultado de la
anterior iteracin, obteniendo una nueva versin del
conjunto de modelos.

Las iteraciones sobre el ciclo de

vida

Al llegar a los hitos secundarios, los jefes y los

desarrolladores
deciden
cmo
continuar
en
las
subsiguientes iteraciones, de la forma que hemos explicado
en las secciones anteriores.

Al llegar a los hitos principales del final de las fases, los

jefes toman decisiones cruciales de tipo continuar/no
continuar y determinan el calendario, el presupuesto, y los
requisitos.

Un hito secundario (en el momento de una versin interna,

al final de una iteracin) es un paso planificado hacia el hito
principal al final de la fase.

La distincin entre hitos principales y secundarios se hace

esencialmente en el nivel de gestin. Los desarrolladores
tratan los riesgos de manera iterativa y construyen
artefactos de software hasta alcanzar el hito principal.

Las iteraciones sobre el ciclo de

vida

En cada hito principal, la direccin evala lo que han

conseguido los desarrolladores.

Cada transicin al pasar un hito principal representa por

tanto una decisin de gestin importante y el compromiso
de financiar el trabajo de (por lo menos) la siguiente fase
de acuerdo al plan.

Figura 5.6. El nfasis se desplaza en las iteraciones,

desde la captura de requisitos y el anlisis haca el
diseo, la implementacin y la prueba.

Las iteraciones sobre el ciclo de

vida

Estas divisiones ayudan a la direccin y a otros

usuarios implicados a evaluar lo hecho durante las
fases de bajo coste de inicio y elaboracin antes de
tomar la decisin de comprometerle con la fase de
construccin de alto coste.

Un proyecto de desarrollo de software puede dividirse

aproximadamente en dos trozos: las fases de inicio y
elaboracin y las fases de construccin y transicin.
Durante las fases de inicio y elaboracin, construirnos
el anlisis del negocio, atenuamos los peores riesgos,
creamos la lnea base de la arquitectura, y
planificamos el resto del proyecto con una alta
precisin. Este trabajo lo realiza un equipo pequeo,
de bajo coste.

Las iteraciones sobre el ciclo de

vida

Despus, el proyecto pasa a la fase de construccin

donde el objetivo es la economa de escala.

En este momento, el nmero de personas en el

proyecto aumenta.

Desarrollan el grueso de la funcionalidad del sistema

construyendo sobre la arquitectura cuya lnea base se
obtuvo durante la fase de elaboracin. Reutilizan el
software existente tanto como es posible.

Aunque cada iteracin discurre a lo largo de los flujos

de
trabajo
de
requisitos,
anlisis,
diseo,
implementacin y prueba, las iteraciones tienen
nfasis diferentes en las distintas fases, como se
muestra en la Figura 5.6.

Las iteraciones sobre el ciclo de

vida
Durante

las fases de inicio y elaboracin, la

mayora del esfuerzo se dedica a la captura
de requisitos y a un anlisis y diseo
preliminares.
Durante la construccin el nfasis pasa al
diseo detallado, la implementacin, y la
prueba.
Aunque no se muestra en la Figura 5.6, las
primeras fases tienen una gran carga de
gestin de proyecto y de preparacin del
entorno de desarrollo para el proyecto.
Regresar

Los modelos evolucionan con

las iteraciones

Las iteraciones construyen los modelos resultantes

incremento por incremento.

Cada iteracin aade algo ms a cada modelo, a

medida que la iteracin fluye a lo largo de requisitos,
anlisis, di seo, implementacin y prueba.

Algunos de estos modelos, como el de casos de uso,

reciben ms tencin en las primeras fases, mientras
que otros, como el de implementacin, la reciben
durante la fase de construccin, como muestra el
grfico de la Figura 5.7.

Los modelos evolucionan con

las iteraciones

En la fase de inicio, el equipo crea quiz las partes de

los modelos que son necesarias para soportar un
prototipo que sirva como prueba de concepto.

Estas partes incluyen los elementos ms importantes

del modelo de casos de uso , el modelo de anlisis
(A), el modelo de diseo (D), as como algo de los
modelos de distribucin (D), implementacin (I), y
prueba
(P).
La
mayora
del
material
de
implementacin es preliminar en esta etapa. Como
muestra la Figura 5.7, an queda mucho trabajo por
hacer.

Figura 5.7. El trabajo en todos los modelos contina en todas las fases, como
se indica con el relleno creciente de los modelos. La fase de construccin
finaliza con un conjunto de modelos (casi) completo. Sin embargo, estos
modelos necesitan ajustes durante la transicin a medida que se distribuyen
en la comunidad de usuarios.

Los modelos evolucionan con

las iteraciones

En la fase de elaboracin, el rea sombreada, que

denota el trabajo terminado, avanza de manera
bastante significativa.
Al final de esta fase, sin embargo, mientras que el
equipo ha capturado ms menos un 80 por ciento
de los requisitos (U) y del modelo de despliegue (la
segunda D), se ha incorporado al sistema menos
del 10 por ciento en cuanto a implementacin (I) y
prueba (P).
Los modelos de casos de uso y de implantacin deben
estar as de avanzados tras la fase de elaboracin. De
otro modo, no conocemos suficientemente bien los
requisitos ni las precondiciones de implementacin
(incluida la arquitectura) como para planificar con
precisin la fase de construccin5.

Los modelos evolucionan con

las iteraciones

La fase de construccin termina con la mayora de las

partes C, A, D, D, I y T, como era de esperar, ya que
el criterio de finalizacin es tener una implementacin
completa del sistema preparada para su transicin a
la comunidad de usuarios.

Ms adelante, a medida que se pasa el sistema a su

uso operativo en la fase de transicin, tendrn lugar
correcciones secundarias y algunos ajustes.

Regresar

Las iteraciones desafan a la

organizacin

Muchas organizaciones de software tienden a lanzarse a

escribir cdigo porque son las lneas de cdigo lo que los
jefes tienen en cuenta.

Tienden a resistirse al cambio, debido a que el cambio

disminuye la cuenta del cdigo. No estn interesadas en
reutilizar el anlisis, el diseo o el cdigo, porque sus jefes
slo tienen en cuenta el cdigo nuevo.

En el Captulo 4, indicamos que los modelos de casos de

uso y de anlisis haban alcanzado un menor nivel de
avance J final de la fase de elaboracin de lo que indica la
Figura 5.7.

La razn de esta discrepancia es que en el Captulo 4 nos

centrbamos exclusivamente en la arquitectura, y no
considerbamos qu otro trabajo deba hacerse (es decir,
comprender ms los casos de uso para ser capaces de
hacer un anlisis del negocio).

Las iteraciones desafan a la

organizacin

El pasar a un desarrollo iterativo desafa las prcticas

de estas organizaciones. Requiere un cambio de
actitud. El nfasis de la organizacin debe pasar de
contar lneas de cdigo a reducir los riesgos y a crear
la lnea base de funcionalidad para la arquitectura.

Los jefes deben tener una mirada nueva sobre lo que

miden.

Debern demostrar por sus acciones que miden el

progreso en trminos de los riesgos tratados, los
casos de usos preparados, y los componentes que
realizan esos casos de uso.

De otro modo, los desarrolladores pronto volvern a

aquello a lo cual estaban acostumbrados, las lneas
de cdigo.

Las iteraciones desafan a la

organizacin

La aplicacin del mtodo iterativo e incremental tiene

algunas consecuencias importantes:

Para crear el anlisis del negocio en la fase de inicio,

la organizacin se ha centrado en la reduccin de
riesgos crticos y en demostrar una prueba de
concepto.

Para hacer una apuesta que merezca la pena para el

negocio al trmino de la fase de elaboracin, la
organizacin debe saber qu va a contratar para
desarrollo (representado por la lnea base de la
arquitectura unida a los requisitos), y debe tener
confianza en que no contiene riesgos ocultos (es
decir, costes
insuficientemente
examinados
y
posibilidades de salirse del calendario).

Las iteraciones desafan a la

organizacin

Para minimizar los costes, los defectos, y el tiempo de

salida al mercado, la organizacin debe emplear
componentes reutilizables (resultado del desarrollo
temprano de la arquitectura, basado en el estudio del
dominio sobre el que se sita el sistema propuesto).

Para evitar el retraso en la entrega, el sobrepasar los

costes, y el obtener un producto de baja calidad, la
organizacin debe hacer primero la parte difcil.

Para evitar construir un producto fuera de plazos, la

organizacin no puede decir no a todos los cambios
tozudamente.

La tcnica por fases, iterativa, permite acomodar los

cambios en el desarrollo hasta mucho ms adelante
en la secuencia del desarrollo.

Las iteraciones desafan a la

organizacin

El desarrollo iterativo e incremental requiere no slo

una nueva forma de gestionar los proyectos, sino
tambin herramientas que soporten este nuevo
mtodo.

Es prcticamente imposible tratar con todos los

artefactos del sistema que estn sujetos a cambios
concurrentemente en cada construccin y en cada
incremento sin el apoyo de las herramientas.

Una organizacin que afronte esta forma de

desarrollo necesita el soporte de herramientas para
los
diferentes flujos de trabajo, as como
herramientas para gestin de la configuracin y
control de versiones.
Regresar