El Proceso Unificado es El Proceso Unificado es Iterativo e IncrementalIterativo e Incremental

ÍndiceÍndiceDiferencias de lo “Iterativo e Incremental”

con el Modelo cascada

Planificación de las iteracionesSecuenciación de las iteracionesEl resultado de una iteración es un increm

entoLas iteraciones sobre el ciclo de vidaLos modelos evolucionan con las iteracion

esLas iteraciones desafían a la organización

¿En qué se diferencia esto de un ¿En qué se diferencia esto de un modelo en cascada tradicional? 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 par ticipar 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 ¿En qué se diferencia esto de un modelo en cascada tradicional? 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 ¿En qué se diferencia esto de un modelo en cascada tradicional? 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 ¿En qué se diferencia esto de un modelo en cascada tradicional? 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 Figura 5.3. Cada iteración constituye una pasada a través de los cinco flujos de trabajo fundamentales. Se través de los cinco flujos de trabajo fundamentales. Se inicia con una actividad de planificación y se concluye inicia con una actividad de planificación y se concluye con un análisis.con un análisis.

Regresar

Planificación de las iteracionesPlanificació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 cons trucció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 iteracionesPlanificació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 iteracionesPlanificació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 Secuenciación de las iteracionesiteraciones La evolución en la naturaleza sucede sin un plan que la

preceda. Éste no es el caso de la itera ció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 Un proceso Iterativo e Incremental 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 Figura 5.4. Las iteraciones discurren a lo largo de los flujos de trabajo desde la captura largo de los flujos de trabajo desde la captura de requisitos hasta la prueba.de requisitos hasta la prueba.

Secuenciación de las Secuenciación de las iteracionesiteraciones 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 Secuenciación de las iteracionesiteracionesEl 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 El resultado de una iteración es un incrementoun 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 El resultado de una iteración es un incrementoun 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 El resultado de una iteración es un incrementoun 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 El resultado de una iteración es un incrementoun 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 El resultado de una iteración es un incrementoun 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 Las iteraciones sobre el ciclo de vidade vidaCada 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 Las iteraciones sobre el ciclo de vidade 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 Las iteraciones sobre el ciclo de vidade 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 Figura 5.5. Las fases reúnen iteraciones que dan como resultado los hitos principales, sobre los cuales la dirección resultado los hitos principales, sobre los cuales la dirección toma decisiones de negocio importantes. (El número de toma decisiones de negocio importantes. (El número de iteraciones no es fijo, sino que varía para diferentes iteraciones no es fijo, sino que varía para diferentes proyectos.)proyectos.)

Las iteraciones sobre el ciclo Las iteraciones sobre el ciclo de vidade 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 Las iteraciones sobre el ciclo de vidade 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 Las iteraciones sobre el ciclo de vidade 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 Las iteraciones sobre el ciclo de vidade 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, Figura 5.6. El énfasis se desplaza en las iteraciones, desde la captura de requisitos y el análisis hacía el desde la captura de requisitos y el análisis hacía el diseño, la implementación y la prueba.diseño, la implementación y la prueba.

Las iteraciones sobre el ciclo Las iteraciones sobre el ciclo de vidade vida Estas divisiones ayudan a la dirección y a otros

usuarios implicados a evaluar lo hecho du rante 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 ini cio 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 Las iteraciones sobre el ciclo de vidade 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 Las iteraciones sobre el ciclo de vidade vidaDurante 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 Los modelos evolucionan con las iteracioneslas 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 Los modelos evolucionan con las iteracioneslas 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, 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 como se indica con el relleno creciente de los modelos. La fase de construcción finaliza con un conjunto de modelos (casi) completo. Sin construcción finaliza con un conjunto de modelos (casi) completo. Sin embargo, estos modelos necesitan ajustes durante la transición a medida que embargo, estos modelos necesitan ajustes durante la transición a medida que se distribuyen en la comunidad de usuarios.se distribuyen en la comunidad de usuarios.

Los modelos evolucionan con Los modelos evolucionan con las iteracioneslas 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 Los modelos evolucionan con las iteracioneslas 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 al gunos ajustes.

Regresar

Las iteraciones desafían a la Las iteraciones desafían a la organizaciónorganizació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 Las iteraciones desafían a la organizaciónorganizació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 Las iteraciones desafían a la organizaciónorganizació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 Las iteraciones desafían a la organizaciónorganizació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 Las iteraciones desafían a la organizaciónorganizació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