Transcript Iterativo e Incremental-4

El Proceso Unificado es Iterativo e
Incremental
Índice







Diferencias de lo “Iterativo e Incremental”
con el Modelo cascada
Planificación de las iteraciones
Secuenciación de las iteraciones
El resultado de una iteración es un
incremento
Las iteraciones sobre el ciclo de vida
Los modelos evolucionan con las
iteraciones
Las iteraciones desafían a la organización
¿En qué se diferencia esto de un
modelo en cascada tradicional?




Cada uno de los flujos de trabajo fundamentales es
una colaboración entre un conjunto de trabajadores y
artefactos.
Sin embargo, hay coincidencias entre las iteraciones.
Los trabajadores y los artefactos pueden participar en
más de un flujo de trabajo.
Por ejemplo, el ingeniero de componentes participa
en tres flujos de trabajo: análisis, diseño e
implementación. Por último, el flujo de trabajo de la
iteración se crea superponiendo, uno encima de otro,
un subconjunto elegido de los flujos de trabajo
fundamentales, y añadiendo lo extra, como la
planificación y el análisis.
¿En qué se diferencia esto de un
modelo en cascada tradicional?

Las primeras iteraciones se centran en la comprensión
del problema y de la tecnología. En la fase de inicio,
las iteraciones se preocupan de producir un análisis
del negocio. En la fase de elaboración, las iteraciones
se orientan al desarrollo de la línea base de la
arquitectura. En la fase de construcción, las
iteraciones se dedican a la construcción del producto
por medio de una serie de construcciones dentro de
cada iteración, que acaban en un producto preparado
para su distribución a la comunidad de usuarios. Sin
embargo, como se muestra en la Figura 5.3, todas las
iteraciones siguen el mismo patrón.
 Durante la fase de inicio, una iteración puede
seguir una variante simplificada de los flujos de
trabajo para estudiar problemas particulares
relativos a la tecnología.
¿En qué se diferencia esto de un
modelo en cascada tradicional?





Cada iteración 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 planificación de los detalles de la siguiente
iteración, el equipo también examina cómo afectarán
los riesgos que aún quedan al trabajo en curso.
Una función que merece un énfasis especial en este
momento son las pruebas de regresión.
Antes de finalizar una iteración, 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 regresión es especialmente importante
en un ciclo de vida iterativo e incremental, debido a
que cada iteración produce una adición significativa al
incremento previo, al mismo tiempo que una cantidad
importante de cambios.
Debemos señalar que no es práctico llevar a cabo las
pruebas de regresión a tan gran escala —cada
construcción de cada iteración— sin las herramientas
de prueba adecuadas.
Los jefes de proyecto no deberían permitir que
comience la siguiente iteración a menos que se hayan
conseguido los objetivos de la presente.
Si no se hace así, la planificación tendrá que cambial’
para adecuarse a la nueva situación.
Figura 5.3. Cada iteración constituye una pasada a
través de los cinco flujos de trabajo fundamentales. Se
inicia con una actividad de planificación y se concluye
con un análisis.
Regresar
Planificación de las iteraciones




En cualquier caso, el ciclo de vida iterativo requiere más
planificación y más reflexión que el método en cascada.
En el modelo en cascada toda la planificación 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
están basadas en mucha incertidumbre y falta de fidelidad.
En contraste, el método iterativo no planifica el proyecto entero en
detalle durante la fase de inicio, sólo da los primeros pasos.
El equipo de proyecto no intenta planificar las fases de construcción y transición hasta que se ha establecido una base de
hechos durante la fase de elaboración. Naturalmente, hay un plan
de trabajo durante las dos primeras fases, pero no es muy
detallado.
Planificación de las iteraciones



El esfuerzo de planificación tiene en cuenta
normalmente (excepto al principio del todo del
proyecto)
los
resultados
de
las
iteraciones
precedentes, la selección de los casos de uso
relevantes en la nueva iteración, el estado actual de
los riesgos que afectan a la nueva iteración, y el
estado de la última versión del conjunto de modelos.
Termina con la preparación de la versión interna.
Al término de la fase de elaboración, por tanto, existe
una base para planificar el resto del proyecto y para
poner en marcha un plan detallado para cada
iteración de la fase de construcción.
Planificación de las iteraciones



El plan para la primera iteración estará muy claro.
Las posteriores aparecerán en el plan menos
detalladas, y estarán sujetas a modificación, de
acuerdo con los resultados y con el conocimiento que
se adquiera en las iteraciones anteriores.
De igual forma, debería haber un piar, para la fase de
transición, pero puede que tenga que ser modificado
a la luz de lo que el equipe aprenda de las iteraciones
de la fase de construcción. Este tipo de planificación
nos permite un desarrollo iterativo controlado.
Regresar
Secuenciación de las
iteraciones

La evolución en la naturaleza sucede sin un plan que la
preceda. Éste no es el caso de la iteración en el desarrollo
de software. Para entendernos, los casos de uso establecen
una meta, y la arquitectura establece un patrón. Con esta
meta y este patrón en mente, los desarrolladores planifican
la secuencia que seguirán 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
solución, mientras que las siguientes dan como
resultado incrementos aditivos que finalmente
conforman la versión 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
iteración previa para corregir el modelo debido a algo
que se descubrió en una iteración posterior.
Figura 5.4. Las iteraciones discurren a lo largo de los
flujos de trabajo desde la captura de requisitos hasta la
prueba.
Secuenciación de las
iteraciones




Las iteraciones pueden solaparse en el sentido de que
una iteración está a punto de terminar cuando otra
está comenzando, como se muestra en la Figura 5.4.
La planificación y el trabajo inicial de la siguiente
iteración deben comenzar a medida que terminamos
y preparamos para entregar la iteración anterior.
Recuérdese que el final de una iteración significa que
hemos conseguido una conclusión dentro del equipo
de desarrollo.
Se ha integrado todo el software de la iteración y
puede crearse la versión interna.
Secuenciación de las
iteraciones
El orden en el cual planificamos las
iteraciones depende, en un grado
considerable, de factores técnicos.
 Sin
embargo,
el
objetivo
más
impórtame es ordenar el trabajo en
secuencia de modo que puedan
desarrollarse antes las decisiones más
importantes, aquéllas que implican
tecnologías,
casos
de
uso
y
arquitecturas nuevas.

Regresar
El resultado de una iteración es
un incremento

Un incremento es la diferencia entre la versión interna de una
iteración y la versión interna de la siguiente.

Al final de una iteración, el conjunto de modelos que representa al
sistema queda en un estado concreto.

Llamamos a este estado la línea base. Cada modelo ha alcanzado
una línea base; cada elemento fundamental del modelo está en
un estado de línea base.

Por ejemplo, el modelo de casos de uso al final de cada iteración
contiene un conjunto de casos de uso que representan el grado
en que la iteración ha desarrollado los requisitos.

Algunos de los casos de uso de este conjunto están terminados,
mientras que otros sólo lo están parcialmente.

A su vez, el modelo de diseño ha llegado a un estado de línea
base consistente con el modelo de casos de uso.
El resultado de una iteración es
un incremento



Los subsistemas, interfaces, y realizaciones de casos
de uso del modelo de diseño se encuentran también
en líneas base que son mutuamente consistentes
unas con otras.
La organización del desarrollo debe mantener
versiones consistentes y compatibles de todos los
artefactos de cada línea 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 gestión de configuración.
El resultado de una iteración es
un incremento



En un momento dado de la secuencia de iteraciones,
estarán terminados algunos subsistemas.
Estos contendrán toda la funcionalidad requerida, y
estarán implementados y probados.
Otros subsistemas están parcialmente terminados, y
otros están todavía vacíos, aunque contendrán
resguardos de forma que puedan funcionar e
integrarse con otros subsistemas. Por tanto, en
términos más precisos, un incremento es la diferencia
entre dos líneas base sucesivas.
El resultado de una iteración es
un incremento





Durante la fase de elaboración, como ya hemos
señalado, construimos la línea 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 mayoría de los
subsistemas e interfaces, les damos forma, es decir,
escribimos el código que los implementa.
Parte de este trabajo se hace antes de obtener la
línea base de la arquitectura, y continúa a lo largo de
todos los flujos de trabajo.
El resultado de una iteración es
un incremento



Sin embargo, la mayor parte de la creación tiene
lugar en las iteraciones de la fase de construcción.
A medida que nos acercamos a la fase de transición,
incrementa el nivel de consistencia entre los modelos
y dentro de ellos.
Construimos incrementos dando forma a los modelos
de manera iterativa, y la integración 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.
Elaboración: arquitectura del ciclo de vida.
Construcción: funcionalidad operativa inicial.
Transición: versión 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
más importantes que influyen en esos modelos, las
relativas a los riesgos, casos de uso, y arquitectura.
Más adelante, deberíamos 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 debería hacer
el producto, la reducción de los peores riesgos, y la
preparación del análisis 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 reúnen iteraciones que dan como resultado los hitos
principales, sobre los cuales la dirección toma decisiones de negocio
importantes. (El número de iteraciones no es fijo, sino que varía para
diferentes proyectos.)
Las iteraciones sobre el ciclo de
vida


Los objetivos fundamentales de la fase de elaboración
son obtener la línea base de la arquitectura, capturar
la mayoría 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 construcción con algún detalle. En este momento,
deberíamos ser capaces de hacer nuestra apuesta.
Los objetivos fundamentales de la fase de
construcción son el desarrollo del sistema entero, la
garantía de que el producto puede comenzar su
transición 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 transición es
garantizar que tenemos un producto preparado para su
entrega a la comunidad de usuarios. Durante esta fase
del desarrollo, se enseña a los usuarios a utilizar el
software.
 Dentro de cada fase hay hitos menores, en concreto, los
criterios aplicables a cada iteración.
 Cada iteración produce resultados, artefactos del
modelo. Por tanto, al final de cada iteración, Tendremos
un nuevo incremento del modelo de casos de uso, del
modelo de análisis, del modelo de diseño, del modelo de
despliegue, del modelo de implementación, y del modelo
de pruebas.
 El nuevo incremento se integrará con el resultado de la
anterior iteración, obteniendo una nueva versión del
conjunto de modelos.

Las iteraciones sobre el ciclo de
vida

Al llegar a los hitos secundarios, los jefes y los
desarrolladores
deciden
cómo
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 versión interna,
al final de una iteración) es un paso planificado hacia el hito
principal al final de la fase.

La distinción entre hitos principales y secundarios se hace
esencialmente en el nivel de gestión. 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 dirección evalúa lo que han
conseguido los desarrolladores.

Cada transición al pasar un hito principal representa por
tanto una decisión de gestión 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 análisis hacía el
diseño, la implementación y la prueba.
Las iteraciones sobre el ciclo de
vida


Estas divisiones ayudan a la dirección y a otros
usuarios implicados a evaluar lo hecho durante las
fases de bajo coste de inicio y elaboración antes de
tomar la decisión de comprometerle con la fase de
construcción de alto coste.
Un proyecto de desarrollo de software puede dividirse
aproximadamente en dos trozos: las fases de inicio y
elaboración y las fases de construcción y transición.
Durante las fases de inicio y elaboración, construirnos
el análisis del negocio, atenuamos los peores riesgos,
creamos la línea base de la arquitectura, y
planificamos el resto del proyecto con una alta
precisión. Este trabajo lo realiza un equipo pequeño,
de bajo coste.
Las iteraciones sobre el ciclo de
vida




Después, el proyecto pasa a la fase de construcción
donde el objetivo es la economía de escala.
En este momento, el número de personas en el
proyecto aumenta.
Desarrollan el grueso de la funcionalidad del sistema
construyendo sobre la arquitectura cuya línea base se
obtuvo durante la fase de elaboración. Reutilizan el
software existente tanto como es posible.
Aunque cada iteración discurre a lo largo de los flujos
de
trabajo
de
requisitos,
análisis,
diseño,
implementación 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 elaboración, la
mayoría del esfuerzo se dedica a la captura
de requisitos y a un análisis y diseño
preliminares.
Durante la construcción el énfasis pasa al
diseño detallado, la implementación, y la
prueba.
Aunque no se muestra en la Figura 5.6, las
primeras fases tienen una gran carga de
gestión de proyecto y de preparación del
entorno de desarrollo para el proyecto.
Regresar
Los modelos evolucionan con
las iteraciones



Las iteraciones construyen los modelos resultantes
incremento por incremento.
Cada iteración añade algo más a cada modelo, a
medida que la iteración fluye a lo largo de requisitos,
análisis, di seño, implementación y prueba.
Algunos de estos modelos, como el de casos de uso,
reciben más ¿tención en las primeras fases, mientras
que otros, como el de implementación, la reciben
durante la fase de construcción, como muestra el
gráfico 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 más importantes
del modelo de casos de uso ©, el modelo de análisis
(A), el modelo de diseño (D), así como algo de los
modelos de distribución (D), implementación (I), y
prueba
(P).
La
mayoría
del
material
de
implementación es preliminar en esta etapa. Como
muestra la Figura 5.7, aún queda mucho trabajo por
hacer.
Figura 5.7. El trabajo en todos los modelos continúa en todas las fases,
como se indica con el relleno creciente de los modelos. La fase de
construcción finaliza con un conjunto de modelos (casi) completo. Sin
embargo, estos modelos necesitan ajustes durante la transición a medida que
se distribuyen en la comunidad de usuarios.
Los modelos evolucionan con
las iteraciones



En la fase de elaboración, 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 más ó 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 implementación (I) y
prueba (P).
Los modelos de casos de uso y de implantación deben
estar así de avanzados tras la fase de elaboración. De
otro modo, no conocemos suficientemente bien los
requisitos ni las precondiciones de implementación
(incluida la arquitectura) como para planificar con
precisión la fase de construcción5.
Los modelos evolucionan con
las iteraciones


La fase de construcción termina con la mayoría de las
partes C, A, D, D, I y T, como era de esperar, ya que
el criterio de finalización es tener una implementación
completa del sistema preparada para su transición a
la comunidad de usuarios.
Más adelante, a medida que se pasa el sistema a su
uso operativo en la fase de transición, tendrán lugar
correcciones secundarias y algunos ajustes.
Regresar
Las iteraciones desafían a la
organización

Muchas organizaciones de software tienden a lanzarse a
escribir código porque son las líneas de código lo que los
jefes tienen en cuenta.

Tienden a resistirse al cambio, debido a que el cambio
disminuye la cuenta del código. No están interesadas en
reutilizar el análisis, el diseño o el código, porque sus jefes
sólo tienen en cuenta el código nuevo.

En el Capítulo 4, indicamos que los modelos de casos de
uso y de análisis habían alcanzado un menor nivel de
avance J final de la fase de elaboración de lo que indica la
Figura 5.7.

La razón de esta discrepancia es que en el Capítulo 4 nos
centrábamos exclusivamente en la arquitectura, y no
considerábamos qué otro trabajo debía hacerse (es decir,
comprender más los casos de uso para ser capaces de
hacer un análisis del negocio).
Las iteraciones desafían a la
organización




El pasar a un desarrollo iterativo desafía las prácticas
de estas organizaciones. Requiere un cambio de
actitud. El énfasis de la organización debe pasar de
contar líneas de código a reducir los riesgos y a crear
la línea base de funcionalidad para la arquitectura.
Los jefes deben tener una mirada nueva sobre lo que
miden.
Deberán demostrar por sus acciones que miden el
progreso en términos de los riesgos tratados, los
casos de usos preparados, y los componentes que
realizan esos casos de uso.
De otro modo, los desarrolladores pronto volverán a
aquello a lo cual estaban acostumbrados, las líneas
de código.
Las iteraciones desafían a la
organización



La aplicación del método iterativo e incremental tiene
algunas consecuencias importantes:
Para crear el análisis del negocio en la fase de inicio,
la organización se ha centrado en la reducción de
riesgos críticos y en demostrar una prueba de
concepto.
Para hacer una apuesta que merezca la pena para el
negocio al término de la fase de elaboración, la
organización debe saber qué va a contratar para
desarrollo (representado por la línea 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 desafían a la
organización




Para minimizar los costes, los defectos, y el tiempo de
salida al mercado, la organización debe emplear
componentes reutilizables (resultado del desarrollo
temprano de la arquitectura, basado en el estudio del
dominio sobre el que se sitúa el sistema propuesto).
Para evitar el retraso en la entrega, el sobrepasar los
costes, y el obtener un producto de baja calidad, la
organización debe “hacer primero la parte difícil”.
Para evitar construir un producto fuera de plazos, la
organización no puede decir no a todos los cambios
tozudamente.
La técnica por fases, iterativa, permite acomodar los
cambios en el desarrollo hasta mucho más adelante
en la secuencia del desarrollo.
Las iteraciones desafían a la
organización



El desarrollo iterativo e incremental requiere no sólo
una nueva forma de gestionar los proyectos, sino
también herramientas que soporten este nuevo
método.
Es prácticamente imposible tratar con todos los
artefactos del sistema que están sujetos a cambios
concurrentemente en cada construcción y en cada
incremento sin el apoyo de las herramientas.
Una organización que afronte esta forma de
desarrollo necesita el soporte de herramientas para
los
diferentes flujos de trabajo, así como
herramientas para gestión de la configuración y
control de versiones.
Regresar