El flujo de trabajo de iteración

genérico.

Introducción

• Se mostrara el patrón genérico que caracteriza a todas las iteraciones de las 4 fases. El objetivo de cada iteración cambia para acomodarse a los objetivos particulares de cada fase.

• Fases del flujo de trabajo genérico:

• Planificación: un punto clave de la planificación es administración de riesgos

• Requisitos

• Análisis

• Diseño

• Implementación

• Prueba

• Evaluación

La necesidad de equilibrio

• Es necesario equilibrar y sincronizar en todo momento las secuencias de actividades que se llevan a cabo en un proceso de desarrollo para controlar así las complejidades de estas actividades.

• Dentro de cada iteración el proyecto se esfuerza en alcanzar un equilibrio entre las secuencias de actividad que se ejecutan a lo largo de la iteración. La tarea de un proyecto es seleccionar las cosas correctas en las que trabajar en cada secuencia de actividad. Determinar un equilibrio de las secuencias de actividades es también importante para asegurar que son de una importancia parecía de forma que pueda asignárseles una prioridad y sincronizarlas con facilidad.

• Un fallo en este punto se convierte en un desastre en el ciclo de vida del proyecto

• En cada iteración se deben comprender estas secuencias de actividades diferentes con el objetivo de buscar el equilibrio entre ellas

Las fases son la primera división del trabajo

Las fases de inicio, elaboración, construcción y transición se dividen en una o más iteraciones

• La fase de inicio establece la viabilidad• Se establece el análisis de negocio

• Se busca el porcentaje de casos de uso necesarios para fundamentar el análisis de negocio inicial.

• Para esto se siguen cuatro pasos

• Delimitar el ámbito del sistema propuesto

• Describir o esbozar una propuesta de la arquitectura del sistema en especial de las partes nuevas. Esta versión de la arquitectura consiste en una de las primeras versiones de los modelos. El objetivo es hacer que se vea creíble que se pueda crear un arquitectura estable

• Identificar riesgos críticos (los que afectan a la capacidad de construir el sistema) y determinar si existe alguna forma de mitigarlos. En esta etapa se desentiende de cualquier riesgo no critico

• Demostrar a usuarios y clientes que el sistema propuesto es capaz de solventar sus problemas. Se puede construir un prototipo en la fase de inicio que muestre las ideas básicas del nuevo sistema

• Se continua en esta fase hasta que desarrollar el sistema sea rentablemente económico

• La intensión de esta fase es minimizar los gastos en tiempo de planificación, esfuerzo y fondos

• La fase de elaboración se centra en la factibilidad• El resultado de esta fase es crear una arquitectura estable que guie al

sistema en su vida futura

• También se lleva a cabo una estimación de costes con gran precisión

• Con estos dos grandes objetivos el equipo hace lo siguiente:

• Se crea una línea base para la arquitectura que cubra la funcionalidad del sistema significativa. Esta línea base no solo demuestra que podemos construir una arquitectura estable sino que encierra a la arquitectura

• Identifica los riesgos significativos.

• Especifica los niveles a alcanzar por los atributos de calidad como fiabilidad y tiempos de respuesta

• Recopila casos de uso para aproximadamente el 80% de los requisitos funcionales

• Prepara una propuesta de planificación cubierta, personal necesario y costes

• La fase de construcción construye el sistema• El objetivo general de esta fase es la construcción de un producto

listo para ser distribuido como versión beta y ser sometido a pruebas

• Una de las grandes ventajas de construir software utilizando un enfoque de múltiples fases y un desarrollo iterativo e incremental es que nos permite equilibrar la asignación de recursos y de tiempo

• Actividades de esta fase:

• Extensión de la identificación, descripción y realización de casos de uso a todos los casos de uso

• La finalización del análisis, del diseño, de la implementación y la prueba

• Mantenimiento de la integridad de la arquitectura

• Monitorización de riesgos críticos y su mitigación en caso de ser necesario

• La fase de transición se mete dentro del entorno del usuario• Comienza con la entrega de una versión beta

• Entre las actividades de transición se incluyen

• Preparar las actividades

• Aconsejar al cliente sobre la actualización del entorno

• Preparar manuales y otros documentos

• Ajustar el software para que funcione en el entorno del usuario

• Corregir bugs

• Modificar el software al detectar problemas

• La fase de transición termina con la entrega de un producto terminado

• Antes de entregarlo los lideres llevan a cabo un estudio del sistema con los siguientes objetivos

• Encontrar, discutir, evaluar y registrar las “lecciones aprendidas” para referencias futuras

• Registrar asuntos útiles para la entrega o versión siguiente

La iteración genérica

• En el proceso unificado de desarrollo, los flujos de trabajo fundamentales no ocurren solo una vez sino que se repiten en cada iteración como flujos de trabajo iterativos.

• La iteración genérica consiste en los cinco flujos de trabajo: requisitos, análisis, diseño, implementación y prueba e incluye también planificación y evaluación.

Los trabajadores participan en los flujos de trabajo

• Las actividades particulares realizadas dentro de los círculos de cada flujo podrían variar dependiendo de la posición de la iteración dentro del proceso de desarrollo completo.

El planificar precede al hacer

• Cuando comenzamos con la fase de inicio sabemos tres cosas:

• Vamos a llevar a cabo el proyecto en una serie de iteraciones en cuatro fases

• Tenemos la información sobre el sistema propuesto que nuestros predecesores recopilaron

• Tenemos nuestra propia información básica sobre el dominio y sobre sistemas similares en los que trabajamos en el pasado.

• Partiendo de esta información hemos de planear el proyecto y cada iteración. En primer lugar, describimos como planear las fases y las iteraciones y como evaluar cada iteración.

Planear las cuatro fases

Debemos reducir las indicaciones del Proceso Unificado a términos concretos:

• Asignaciones de tiempo. Decidimos cuanto tiempo asignar a cada fase y la fecha en la que cada fase ha de haber sido completada

• Hitos principales. Una fase termina cuando ha sido alcanzado el criterio actual.

• Iteraciones por fase. Dentro de cada fase el trabajo se lleva a cabo a lo largo de varias iteraciones

• Plan de proyecto. El plan de proyecto esboza un “mapa de carretera” global, que cubre la planificación, las fechas y criterios de los objetivos principales y la división de las fases en iteraciones.

Además de la iteración misma, se debe cubrir lo siguiente:• Ajustar el proceso unificado al proyecto y seleccionar

herramientas para automatizar el proceso

• Empezar a reunir a gente con el talento necesario para el proyecto

• Crear las relaciones que dan lugar a un equipo efectivo

• Entender el dominio, que a menudo es desconocido para el equipo

• Percibir la naturaleza del proyecto

• Familiarizar el equipo con las herramientas apropiadas para el proceso y el proyecto

Plan de iteracionesCada fase está formada por una o más iteraciones. La planificación de las iteraciones se da por los siguientes pasos:

• Planificación de la iteración: decidimos cuánto tiempo puede requerir cada iteración y su fecha de terminación

• Contenido de iteración: lo que ha de hacerse más en detalle• Los casos de uso que tienen que ser completados

• Los riesgos técnicos que han de ser identificados

• Los cambios que han sufrido los requisitos o los defectos que pueden haber sido corregidos

• Los subsistemas que han de ser implementados parcial o completamente

El plan de iteración actual está completamente detallado. Los detalles de iteraciones posteriores pueden estar limitados por el conocimiento disponible en ese momento:

• Hitos secundarios

• Plan de iteración

El número de iteraciones planeado para cada fase depende de la complejidad del sistema propuesto. Habrá más iteraciones y sus duraciones variaran dependiendo del tamaño del sistema, entre una semana y tres meses por cada iteración.

Pensar a largo plazo

• Durante el largo periodo de tiempo que el sistema puede durar, este puede presenciar grandes cambios.

• No es conveniente construir una arquitectura rígida para el sistema si es posible prever que esta cambiara en el futuro, pero tampoco se quiere introducir una flexibilidad innecesaria en el sistema, es decir, una flexibilidad que no será utilizada nunca.

Planear los criterios de evaluación

Las iteraciones son cortas comparadas con los proyectos tradicionales. Por lo que se establecen objetivos claves de cada iteración. Para completar esos objetivos, se establecen criterios que indican la compleción de la iteración. Por ejemplo:

• Requisitos funcionales expresados en forma de casos de uso

• Requisitos no funcionales que acompañan a los casos de uso a los que se refieren

• Requisitos adicionales. Es decir, requisitos no funcionales que no son específicos de un caso de uso concreto.

Los riesgos influyen en la planificación del proyecto.

• El modo en que se planifica el desarrollo de un nuevo sistema está influenciado en gran medida por los riesgos que se perciben. Uno de los primeros pasos de la fase de inicio es crear una lista de riesgos.

• Conforme se va realizando el trabajo inicial, se va apreciando cuáles serán los riesgos críticos.

Administrar la lista de riesgos

• El propósito de la lista de riesgos es que todos vean los riesgos para poder ser guiados por ellos y hacer algo con ellos.

• Esta lista incluye:

• Descripción: comienza con una breve descripción y se añaden detalles conforme se va aprendiendo

• Prioridad: se le asigna una prioridad al riesgo. Puede ser crítico, significativo o rutinario

• Impacto: indica que partes del proyecto o del sistemas se verán afectadas por el riesgo

• Monitor: indica quien es el responsable del seguimiento de un riesgo persistente

• Responsabilidad: indica que individuo o unidad de la organización es responsable de eliminar el riesgo

• Contingencia: indica lo que ha de hacerse en caso de que el riesgo se materialice.

• Una de las razones por las que se sigue un desarrollo iterativo es porque el equipo no puede centrarse en todo al mismo tiempo; los riesgos se ordenan por nivel de seriedad o por su influencia en el desarrollo y son resueltos en orden.

• La lista de riesgos no es estática. Crece conforme se descubren nuevos riesgos y decrece cuando los riesgos son eliminados o cuando pasamos a un punto del desarrollo en que un riesgo particular no puede materializarse.

Los riesgos influyen en el plan de iteración:

• Durante la fase de inicio se identifican los riesgos críticos y el equipo intenta mitigarlos. Exploran su naturaleza hasta el punto de preparar un plan de iteración.

• Además de las influencias que pueden tener los riesgos más serios sobre el éxito de un proyecto, todos los riegos tienen algún impacto en la planificación, el coste o la calidad.

• Algunos de estos riesgos pueden ser lo suficientemente serios como para prolongar la planificación o incrementar el esfuerzo más allá del esfuerzo planeado.

• En algunos casos puede que un riesgo tenga poco impacto sobre la planificación o el coste pero afecte negativamente a otros factores, como la calidad o el rendimiento.

Planificar la acción sobre los riesgos

• El principio general es tener un plan de acción a seguir sobre los riesgos. Las fases y las iteraciones dentro de las fases proporcionan el medio para planificar las acciones sobre los riesgos.

• Cuando no existe un esfuerzo consciente para actuar pronto sobre los riesgos, estos se manifiestan usualmente al final de la planificación, mientras se realizan las pruebas de integración del sistema.

• En el enfoque iterativo la construcción de prototipos, construcciones y artefactos descubre desde la primera fase los riesgos mientras hay aun tiempo para tratarlos.

Asignación de prioridades a los casos de uso.

• Cada iteración en el proceso unificado de desarrollo está guiada por un conjunto de casos de uso o por un conjunto de escenarios a través de los casos de uso.

• Las prioridades son asignadas a los casos de uso según deberían ser estos considerados en las iteraciones. Estos son clasificados a lo largo de varias iteraciones. El resultado de la clasificación es una lista ordenada de casos de uso.

• Ordenamos los casos de uso de acuerdo con el riesgo que conllevan. Colocamos los riegos que identificamos en una lista de riegos, y transformamos cada uno de estos riesgos en un caso de uso que mitigara el riesgo cuando sea implementado. Ese caso de uso será introducido entonces en la posición que le corresponde dentro de la clasificación de casos de uso de acuerdo con su nivel de riesgo.

• En las primeras iteraciones dedicamos los casos d uso con mayor prioridad a los riesgos relacionados con el ámbito del sistema y con la arquitectura. En las últimas iteraciones seleccionamos nuevos casos de uso para completar la arquitectura ya seleccionada con más funcionalidad.

Riesgos específicos de un producto particular:

• Es necesario identificar los riegos técnicos uno por uno, pues el tratar con ellos no es formalmente parte del proceso. Con esto queremos decir que el proceso proporciona un lugar específico en que tratar con cierto tipo de riesgo. Los riesgos que no son formalmente parte del proceso requieren ser tratados uno por uno y mitigarlos antes de que su presencia afecte el proceso de desarrollo.

Riesgo de no conseguir la arquitectura correcta:

• El no establecer una arquitectura flexible es uno de los riesgos más serios. Este riesgo es considerado explícitamente durante las fases de inicio y de elaboración (ya que estas fases tratan con la arquitectura puramente)

• Mediante los casos de uso críticos determinamos cuales son los casos de uso más importantes para conseguir una arquitectura correcta.

Otras categorías de casos de uso:

• Secundarios: estos casos de uso sirven de apoyo para los casos de uso críticos

• Auxiliares: estos casos de uso no son claves para la arquitectura o para los riesgos críticos. Son solo para completar los casos de uso importantes

• Opcionales: con aquellos con los que podría ser necesario trabajar si afectan la arquitectura al estar presentes

Necesitamos tener una alta cobertura de los casos de uso que puedan afectar la arquitectura. Tener esta alta cobertura es importante, no solo para encontrar la arquitectura sino para asegurar que podemos predecir con precisión los costes de desarrollo del producto en el primer ciclo.

Es necesario cubrir alrededor del 80% de los casos de uso en la fase de elaboración. Es decir, entender los casos de uso y su impacto sobre el sistema.

Riesgo de no conseguir los requisitos correctos:

• Es un riesgo serio no conseguir que un sistema haga lo que los usuarios quieren realmente que haga. Las formas de tratar este riesgo son también parte del proceso. Al final de la fase de elaboración queremos estar seguro de que estamos construyendo el sistema correcto.

• La primera parte de la solución es hacer el flujo de trabajo de los requisitos bien. La segunda parte es, basándose en las iteraciones iniciales, construir el sistema que quieren los usuarios y obtener información sobre él tan pronto como sea posible. Solo podremos estar seguros de que hemos construido el sistema correcto a partir del uso real.

Recursos necesitados

Un proyecto típico tiene este aspecto:

• El ciclo de desarrollo inicial de un proyecto de tamaño medio puede tener una distribución inicial de esfuerzo y planificación como la siguiente:

Los proyectos más grandes tienen mayores necesidades

Al tener que realizar un mayor número de iteraciones, se tendrá que poner más tiempo y esfuerzo en las fases de inicio y de elaboración:

Una nueva línea de productos requiere experiencia

Para sistemas nuevos o difíciles el equipo ha de adquirir más información de la que posee. La fuente natural de esta información son las personas informadas en el campo del sistema propuesto. Incluso cuando se dispone de requisitos detallados, el equipo necesita estas entrevistas para encontrar la arquitectura y centrarse en los riesgos.

Un fallo común cuando se comienza el trabajo en una nueva línea de productos es intentar hacerlo sin “reutilizar el conocimiento “es decir, sin reutilizar a la gente experimentada

El pago del coste de los recursos utilizados

Mantener el equipo que trabaja en las dos primeras fases, aunque sea pequeño, cuesta dinero

• En el caso de una organización fabricante de software que produce un producto para vender, los fondos son parte de los “gastos generales “y como tales, están bajo el control de la dirección

• En el caso de una organización fabricante de software que produce un producto para un cliente dentro de la misma empresa, el coste de las primeras dos fases es parte de los “gastos generales” de la compañía, de los fondos transferidos a ella por el cliente o de los fondos asignados a ella por la alta dirección de la empresa.

• En el caso de una organización fabricante de software que produce un producto para una corporación distinta, el coste de las dos primeras fases puede venir de sus gastos generales propios.

En las primeras dos fases se lleva a cabo un trabajo importante y realizarlos lleva tiempo y dinero. Además de los fondos, el llevarlas a cabo requiere la colaboración del cliente. Esta cooperación también cuesta dinero.

Evaluar las iteraciones y las fases Para conocer los beneficios de del trabajo iterativo se debe evaluar el trabajo. Esta evaluación la hace el jefe de proyecto y se hace no solo para evaluar las iteraciones sino también para:

• Reconsiderar el plan de iteración

• Modificar el proceso

Los objetivos son dos• Examinar lo que ha sido realizado en términos del criterio de evaluación actual

• Comprar los progresos realizados con el plan de iteración

Criterios no alcanzados, puede implicar:• Modificar o extender el modelo de casos de uso

• Modificar o extender la arquitectura

• Modificar o extender los subsistemas desarrollados hasta entonces

• Buscar otros riesgos

• Incorporar ciertas habilidades al equipo

Los criterios mismos

• El equipo puede haber establecido los criterios en un momento en que todavía no tenía disponible toda la información relevante. A lo largo de la iteración podría haberse descubierto necesidades adicionales. Por lo tanto los evaluadores podrían tener que cambiar los criterios

La siguiente iteración

• Luego de obtener un hito principal, sobre la base de la evaluación, el jefe de proyecto hace lo siguiente:

• Determina que el trabajo está listo para pasar a la siguiente iteración

• Si se necesita rehacer algún trabajo, asigna en que iteración debería realizarse

• Planea en detalle la siguiente iteración

• Actualiza el plan de iteraciones

• Actualiza la lista de riesgos y el plan de proyecto

• Compara el coste y la planificación de la iteración con los planeados

Evolución del conjunto de modelos

Los modelos crecen a través de las fases. En las primeras iteraciones unos modelos van por delante de otros. En lugar de que un modelo evolucione casi independientemente del siguiente modelo pensamos en términos de un estado del sistema entero que evoluciona a un estado más avanzado del sistema entero. Cada iteración representa un avance en el estado del sistema completo, el cual se refleja en el movimiento gradual hacia la compleción del conjunto de modelos. Considerar el grado en que esta evolución ha progresado en cada evaluación será un indicador importante para el grupo evaluador