Determinando la longitud de cada iteracin

Una iteracin comienza con planeacin y requerimientos, interviene el tamao de la organizacin,

el grado de familiaridad de la organizacin, el nivel de automatizacin que el equipo usa para
administrar el cdigo, distribuir informacin, realizar pruebas; y termina con un despliegue interno
o externo.

Iteraciones +6 meses: Considerar reducir el alcance de la iteracin para reducir su longitud

y asegurar un enfoque claro.
Iteraciones de +12 meses: Crear los riesgos, pues la iteracin se extiende el ciclo de
financiamiento anual. Un proyecto del cual no se ha producido nada corre el riesgo de
perder su financiamiento.
Iteraciones de 1 mes: Las iteraciones ms pequeas son mejores para la fase de
construccin, donde el grado de funcionalidad a incluirse y el grado de novedad son
bajos.
Iteraciones que no necesitan la misma longitud: Su longitud depende de los objetivos. En
cada fase, las iteraciones generalmente son de la misma longitud.

Determinando el nmero de iteraciones

Un proyecto muy simple puede tener slo una iteracin por fase:

Una iteracin en la fase inicial, produciendo quizs un prototipo de prueba de concepto o

una maqueta de interfaz de usuario, o ninguna iteracin en absoluto, por ejemplo, en un
ciclo de evolucin.
Una iteracin en la fase de elaboracin para producir un prototipo arquitectnico.
Una iteracin en la fase de construccin para construir el producto (hasta una liberacin
"beta").
Una iteracin en transicin para terminar el producto (liberacin completa del producto).
Para un proyecto ms sustancial, en su ciclo de desarrollo inicial la norma sera:

Una iteracin en la fase inicial (posiblemente produciendo un prototipo).

Dos iteraciones en la fase de elaboracin; Uno para un prototipo arquitectnico y otro
para la lnea base arquitectnica.
Dos iteraciones en la fase de construccin para exponer un sistema parcial, y madurarlo.
Una iteracin en la fase de transicin para pasar de la capacidad operativa inicial a la
liberacin completa del producto.
Para un proyecto grande, con muchas incgnitas, nuevas tecnologas y similares, puede haber un
caso para:

Una iteracin adicional en la fase inicial, para permitir ms prototipos.

Una iteracin adicional en la fase de elaboracin, para permitir la exploracin de
diferentes tecnologas.
Una iteracin adicional en la fase de construccin debido al gran tamao del producto.
Una iteracin adicional en la fase de transicin para permitir la retroalimentacin
operacional.
Muchas variaciones son posibles dependiendo de los riesgos, el tamao, la complejidad:
 Si el producto est destinado a algn dominio totalmente nuevo
Si se debe desarrollar una nueva arquitectura
Si el producto es grande y complejo

Alineando la Secuencia de Revisin de la Cascada Tradicional con el

Enfoque Iterativo
La secuencia de revisin por defecto para un proyecto de ciclo de vida de una cascada tiene una
sola revisin importante al completar los artefactos importantes, por ejemplo:

Revisin de Requisitos del Sistema (SRR), al completar la especificacin del sistema.

Revisin de especificaciones de software (SSR), al completar la especificacin de requisitos
de software.
Revisin preliminar del diseo (PDR), en la terminacin de las secciones del diseo
arquitectnico de la descripcin del diseo del software.
Revisin crtica del diseo (CDR), en la terminacin de las secciones de diseo detallado de
la descripcin del diseo de software.

En el Proceso Unificado de Educacin (UPEDU), partes de los artefactos equivalentes se revisan a

medida que se completan en cada iteracin, pero los hitos principales (y por lo tanto revisiones)
estn alineados con la finalizacin de las fases, inicio, elaboracin, construccin y transicin.

Esto se hace aqu asumiendo que el esfuerzo relativo que se gastar en requisitos, diseo y
similares ser aproximadamente el mismo en la UPEDU como en el ciclo de vida de la cascada
(ideal), pero que el esfuerzo se distribuir de manera diferente. El resultado es el siguiente:

El SRR (referido principalmente a la Visin) se puede programar al final de la fase inicial.

La SSR (que se refiere principalmente a la Especificacin de Requisitos de Software) en
aproximadamente 1/3 de la fase de elaboracin.
La PDR (que se refiere principalmente al Documento de Arquitectura de Software) al final
de la fase de elaboracin.
El CDR (se refera principalmente al Modelo de Diseo) a aproximadamente 1/3 de la fase
de construccin.

Organizacin del proyecto

As como el proceso de software est influenciado por las caractersticas del proyecto, tambin lo
es la organizacin del proyecto. La estructura por defecto presentada aqu (ver la figura siguiente),
tiene que ser adaptada para reflejar los efectos de factores tales como los enumerados:

El contexto empresarial
El tamao del esfuerzo de desarrollo de software
El grado de novedad
Tipo de aplicacin
El Proceso de Desarrollo Actual
Factores Organizativos
Complejidad tcnica y administrativa
 Esta figura es un punto de partida para considerar cmo las funciones y responsabilidades
a nivel de proyecto deben ser asignadas a una estructura de equipos. La figura tambin
sirve para enfatizar que los roles (mostrados en las casillas amarillas) no son individuos,
sino "sombreros" que un individuo (o un equipo) puede usar en el proyecto.

En un proyecto pequeo, es probable que una persona designada como Project Manager
realice todas las actividades del rol de Project Manager, en cuyo caso el equipo de
administracin se unir con el equipo de administracin de software. La seleccin de la
estructura del equipo se ver influida por la naturaleza y el tamao del proyecto, pero
debe ser templada por algunas reglas, en su mayora de sentido comn:

Los equipos pequeos suelen ser ms productivos; Sin embargo, en un proyecto grande
esto tiene que ser equilibrado contra la cantidad de interaccin entre equipos.
Las jerarquas profundas deben ser evitadas.
El lapso de control de cualquier gerente o lder del equipo debe limitarse a siete ms o
menos dos.
La estructura del equipo de desarrollo de software debe ser impulsada por la arquitectura
del software (no viceversa); Una buena arquitectura, con alta cohesin y bajo
acoplamiento entre subsistemas, permitir a los equipos trabajar de manera ms efectiva
en paralelo.
Las pruebas, aparte de la prueba unitaria, deberan idealmente ser realizadas por un
equipo separado del equipo de desarrollo. Tenga en cuenta, sin embargo, que esto puede
no tener sentido econmico en un proyecto muy pequeo.
La estructura debe permitir que todos los equipos e individuos reciban autoridades y
responsabilidades claramente definidas. Esto es particularmente importante si la jerarqua
excede tres niveles. Los gerentes y jefes de equipo en el medio de tales estructuras
necesitan entender lo que se requiere de ellos en el equilibrio de las actividades tcnicas y
de gestin.
La estructura debe soportar las capacidades, la experiencia y las motivaciones del
personal: por ejemplo, si se supone que un solo equipo lleva a cabo el anlisis, el diseo y
 la implementacin, sin ninguna entrega intermedia, necesitar todas las competencias
necesarias. Los analistas calificados no son necesariamente buenos implementadores.
Las estructuras de los equipos no deben ser rgidas: las personas migrarn entre equipos
durante la vida del proyecto y las responsabilidades de los equipos cambiarn conforme el
nfasis del proyecto cambie de fase a fase.

Durante la vida de un proyecto, la organizacin evolucionar para apoyar la estructura de

desglose de trabajo capturada en el plan del proyecto.

Esta evolucin hace hincapi en un conjunto diferente de actividades en cada fase:

El equipo de Comienzo: una organizacin centrada en la planificacin, con suficiente

apoyo de los otros equipos para asegurar que los planes representen un consenso de
todas las perspectivas.
El equipo de Elaboracin: una organizacin enfocada a la arquitectura en la que las
fuerzas motrices del proyecto residen en el equipo de arquitectura de software y son
apoyadas por los equipos de desarrollo de software y de evaluacin de software como
necesario para lograr una base de referencia de arquitectura estable.
El equipo de Construccin: una organizacin equilibrada en la que la mayor parte de la
actividad reside en los equipos de desarrollo de software y evaluacin de software.
El equipo de Transicin: una organizacin centrada en el cliente en la que la
retroalimentacin de uso impulsa las actividades de implementacin.

La migracin entre equipos durante esta evolucin asegurar que el conocimiento y la capacidad
se conserven en el proyecto.