El flujo de trabajo

de iteracin
genrico.

Introduccin
Se mostrara el patrn genrico que caracteriza a todas las iteraciones de las 4 fases.

El objetivo de cada iteracin cambia para acomodarse a los objetivos particulares de

cada fase.
Fases del flujo de trabajo genrico:
Planificacin: un punto clave de la planificacin es administracin de riesgos
Requisitos
Anlisis
Diseo
Implementacin
Prueba
Evaluacin

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 iteracin el proyecto se esfuerza en alcanzar un equilibrio entre las
secuencias de actividad que se ejecutan a lo largo de la iteracin. 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 tambin
importante para asegurar que son de una importancia pareca de forma que pueda
asignrseles 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 iteracin se deben comprender estas secuencias de actividades diferentes
con el objetivo de buscar el equilibrio entre ellas

Las fases son la primera divisin del trabajo

Las fases de inicio, elaboracin, construccin y transicin se dividen en una o ms

iteraciones
La fase de inicio establece la viabilidad
Se establece el anlisis de negocio
Se busca el porcentaje de casos de uso necesarios para fundamentar el anlisis 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
versin de la arquitectura consiste en una de las primeras versiones de los modelos. El objetivo es hacer
que se vea creble que se pueda crear un arquitectura estable

Identificar riesgos crticos (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 bsicas del nuevo sistema

Se continua en esta fase hasta que desarrollar el sistema sea rentablemente econmico
La intensin de esta fase es minimizar los gastos en tiempo de planificacin, esfuerzo y fondos

 La fase de elaboracin se centra en la factibilidad

El resultado de esta fase es crear una arquitectura estable que guie
al sistema en su vida futura

Tambin se lleva a cabo una estimacin de costes con gran precisin

Con estos dos grandes objetivos el equipo hace lo siguiente:
Se crea una lnea base para la arquitectura que cubra la funcionalidad
del sistema significativa. Esta lnea 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 planificacin cubierta, personal necesario y

costes

 La fase de construccin construye el sistema

El objetivo general de esta fase es la construccin de un producto
listo para ser distribuido como versin beta y ser sometido a
pruebas

Una de las grandes ventajas de construir software utilizando un

enfoque de mltiples fases y un desarrollo iterativo e incremental
es que nos permite equilibrar la asignacin de recursos y de
tiempo
Actividades de esta fase:
Extensin de la identificacin, descripcin y realizacin de casos de uso a
todos los casos de uso

La finalizacin del anlisis, del diseo, de la implementacin y la prueba

Mantenimiento de la integridad de la arquitectura
Monitorizacin de riesgos crticos y su mitigacin en caso de ser necesario

 La fase de transicin se mete dentro del entorno del usuario

Comienza con la entrega de una versin beta
Entre las actividades de transicin se incluyen
Preparar las actividades
Aconsejar al cliente sobre la actualizacin 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 transicin 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 versin siguiente

La iteracin genrica
En el proceso unificado de desarrollo, los flujos de trabajo
fundamentales no ocurren solo una vez sino que se repiten
en cada iteracin como flujos de trabajo iterativos.
La iteracin genrica consiste en los cinco flujos de
trabajo: requisitos, anlisis, diseo, implementacin y
prueba e incluye tambin planificacin y evaluacin.

Los trabajadores participan en los flujos de

trabajo

Las actividades particulares realizadas dentro de los

crculos de cada flujo podran variar dependiendo de la
posicin de la iteracin 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 informacin sobre el sistema propuesto que nuestros
predecesores recopilaron
Tenemos nuestra propia informacin bsica sobre el dominio y sobre
sistemas similares en los que trabajamos en el pasado.
Partiendo de esta informacin hemos de planear el proyecto y cada
iteracin. En primer lugar, describimos como planear las fases y las
iteraciones y como evaluar cada iteracin.

Planear las cuatro fases

Debemos reducir las indicaciones del Proceso Unificado a trminos
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 planificacin, las fechas y criterios de los objetivos principales y la
divisin de las fases en iteraciones.

Adems de la iteracin 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 iteraciones
Cada fase est formada por una o ms iteraciones. La planificacin de las iteraciones se da por los
siguientes pasos:

Planificacin de la iteracin: decidimos cunto tiempo puede requerir cada iteracin y su

fecha de terminacin
Contenido de iteracin: lo que ha de hacerse ms en detalle
Los casos de uso que tienen que ser completados
Los riesgos tcnicos 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 iteracin actual est completamente detallado. Los detalles de iteraciones posteriores
pueden estar limitados por el conocimiento disponible en ese momento:
Hitos secundarios
Plan de iteracin
El nmero de iteraciones planeado para cada fase depende de la complejidad del sistema
propuesto. Habr ms iteraciones y sus duraciones variaran dependiendo del tamao del sistema,
entre una semana y tres meses por cada iteracin.

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 rgida 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 evaluacin
Las iteraciones son cortas comparadas con los proyectos tradicionales. Por lo que
se establecen objetivos claves de cada iteracin. Para completar esos objetivos, se
establecen criterios que indican la complecin de la iteracin. Por ejemplo:
Requisitos funcionales expresados en forma de casos de uso
Requisitos no funcionales que acompaan a los casos de uso a los que se
refieren
Requisitos adicionales. Es decir, requisitos no funcionales que no son especficos
de un caso de uso concreto.

Los riesgos influyen en la planificacin 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 cules sern los riesgos crticos.

Administrar la lista de riesgos

El propsito 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:
Descripcin: comienza con una breve descripcin y se aaden detalles conforme se va
aprendiendo
Prioridad: se le asigna una prioridad al riesgo. Puede ser crtico, significativo o rutinario
Impacto: indica que partes del proyecto o del sistemas se vern afectadas por el riesgo
Monitor: indica quien es el responsable del seguimiento de un riesgo persistente
Responsabilidad: indica que individuo o unidad de la organizacin 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 esttica. 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 iteracin:

Durante la fase de inicio se identifican los riesgos crticos y el equipo intenta
mitigarlos. Exploran su naturaleza hasta el punto de preparar un plan de iteracin.
Adems de las influencias que pueden tener los riesgos ms serios sobre el xito
de un proyecto, todos los riegos tienen algn impacto en la planificacin, el coste o
la calidad.
Algunos de estos riesgos pueden ser lo suficientemente serios como para
prolongar la planificacin o incrementar el esfuerzo ms all del esfuerzo
planeado.
En algunos casos puede que un riesgo tenga poco impacto sobre la planificacin o
el coste pero afecte negativamente a otros factores, como la calidad o el
rendimiento.

Planificar la accin sobre los riesgos

El principio general es tener un plan de accin 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 planificacin,
mientras se realizan las pruebas de integracin del sistema.
En el enfoque iterativo la construccin de prototipos, construcciones
y artefactos descubre desde la primera fase los riesgos mientras hay
aun tiempo para tratarlos.

Asignacin de prioridades a los casos de uso.

Cada iteracin en el proceso unificado de desarrollo est guiada por un conjunto de casos de uso o
por un conjunto de escenarios a travs de los casos de uso.
Las prioridades son asignadas a los casos de uso segn deberan ser estos considerados en las
iteraciones. Estos son clasificados a lo largo de varias iteraciones. El resultado de la clasificacin 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
posicin que le corresponde dentro de la clasificacin 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 ms
funcionalidad.

Riesgos especficos de un producto particular:

Es necesario identificar los riegos tcnicos uno por uno,

pues el tratar con ellos no es formalmente parte del
proceso. Con esto queremos decir que el proceso
proporciona un lugar especfico 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 ms serios. Este riesgo es considerado
explcitamente durante las fases de inicio y de elaboracin
(ya que estas fases tratan con la arquitectura puramente)
Mediante los casos de uso crticos determinamos cuales
son los casos de uso ms importantes para conseguir una
arquitectura correcta.

Otras categoras de casos de uso:

Secundarios: estos casos de uso sirven de apoyo para los casos de uso crticos
Auxiliares: estos casos de uso no son claves para la arquitectura o para los
riesgos crticos. Son solo para completar los casos de uso importantes
Opcionales: con aquellos con los que podra 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 precisin 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
elaboracin. 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
tambin parte del proceso. Al final de la fase de elaboracin queremos
estar seguro de que estamos construyendo el sistema correcto.
La primera parte de la solucin es hacer el flujo de trabajo de los
requisitos bien. La segunda parte es, basndose en las iteraciones
iniciales, construir el sistema que quieren los usuarios y obtener
informacin 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 tpico tiene este aspecto:

El ciclo de desarrollo inicial de un proyecto de tamao
medio puede tener una distribucin inicial de esfuerzo y
planificacin como la siguiente:

Los proyectos ms grandes tienen mayores

necesidades
Al tener que realizar un mayor nmero de iteraciones, se
tendr que poner ms tiempo y esfuerzo en las fases de
inicio y de elaboracin:

Una nueva lnea de productos requiere

experiencia
Para sistemas nuevos o difciles el equipo ha de adquirir
ms informacin de la que posee. La fuente natural de esta
informacin 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 comn cuando se comienza el trabajo en una nueva
lnea 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 pequeo, cuesta dinero
En el caso de una organizacin fabricante de software que produce un producto para vender,
los fondos son parte de los gastos generales y como tales, estn bajo el control de la direccin
En el caso de una organizacin 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 compaa, de los fondos transferidos a ella por el cliente o de los fondos
asignados a ella por la alta direccin de la empresa.
En el caso de una organizacin fabricante de software que produce un producto para una
corporacin 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. Adems de los fondos, el llevarlas a cabo requiere la colaboracin del cliente. Esta
cooperacin tambin cuesta dinero.

Evaluar las iteraciones y las fases

Para conocer los beneficios de del trabajo iterativo se debe evaluar el trabajo.
Esta evaluacin la hace el jefe de proyecto y se hace no solo para evaluar las
iteraciones sino tambin para:
Reconsiderar el plan de iteracin
Modificar el proceso

Los objetivos son dos

Examinar lo que ha sido realizado en trminos del criterio de evaluacin actual
Comprar los progresos realizados con el plan de iteracin

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 todava no tena disponible
toda la informacin relevante. A lo largo de la iteracin podra haberse descubierto necesidades
adicionales. Por lo tanto los evaluadores podran tener que cambiar los criterios
La siguiente iteracin
Luego de obtener un hito principal, sobre la base de la evaluacin, el jefe de proyecto hace lo
siguiente:
Determina que el trabajo est listo para pasar a la siguiente iteracin
Si se necesita rehacer algn trabajo, asigna en que iteracin debera realizarse
Planea en detalle la siguiente iteracin
Actualiza el plan de iteraciones
Actualiza la lista de riesgos y el plan de proyecto
Compara el coste y la planificacin de la iteracin con los planeados
Evolucin del conjunto de modelos
Los modelos crecen a travs 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 trminos de un estado del sistema entero que evoluciona a un estado ms avanzado del sistema
entero. Cada iteracin representa un avance en el estado del sistema completo, el cual se refleja en el
movimiento gradual hacia la complecin del conjunto de modelos. Considerar el grado en que esta
evolucin ha progresado en cada evaluacin ser un indicador importante para el grupo evaluador