Fases y objetivos de un ciclo vital
Desde la perspectiva de la gestión, el ciclo vital del software de Rational Unified Process (RUP) se descompone en
cuatro fases secuenciales, cada una concluida por uno de los objetivos principales; cada fase es esencialmente un
periodo de tiempo entre dos objetivos importantes. Al final de cada fase se lleva a cabo una valoración para determinar
si los objetivos de la fase se han alcanzado. Una valoración satisfactoria permite que el proyecto continúe a la fase
siguiente.
Planificar las fases
Todas las fases no son idénticas en términos de planificación y esfuerzo. Aunque esto varía considerablemente
dependiendo del proyecto, un ciclo inicial de desarrollo típico para un proyecto de tamaño medio debe anticipar la
distribución siguiente entre el esfuerzo y la planificación:
que puede ilustrarse como
Esta distribución puede variar. Por ejemplo, las herramientas que generan código y los guiones de prueba pueden reducir
la fase de construcción. Asimismo, para un ciclo de evolución, las fases iniciales y de elaboración son
considerablemente menores, porque ya se ha establecido una visión básica y una arquitectura.
Planificar las estrategias
En esta sección, se introducen diversos patrones de ciclo vital que corresponden a perfiles de proyecto comunes.
Patrón de ciclo vital: incremental
"La estrategia incremental determina las necesidades del usuario y define los requisitos del sistema y, a continuación,
realiza el resto del desarrollo en una secuencia de compilaciones. La primera compilación incorpora partes de las
funciones planificadas, la siguiente compilación añade más funciones y así sucesivamente hasta que se completa el
sistema." [DOD94]
Las iteraciones siguientes son características:
-
una breve iteración inicial para establecer el ámbito y la visión, y para definir el caso de negocio
-
una única iteración de la elaboración, durante la que se definen los requisitos y se establece la arquitectura
-
varias iteraciones de construcción, durante las que se ejecutan los guiones de uso y se sustancia la
arquitectura
-
varias iteraciones de transición para migrar el producto a la comunidad de usuarios
Esta estrategia es adecuada cuando:
-
El dominio del problema es familiar.
-
Se entienden bien los riesgos.
-
El equipo del proyecto tiene mucha experiencia.
Patrón de ciclo vital: evolutivo
"La estrategia evolutiva difiere de la incremental en el reconocimiento de que las necesidades del usuario no se
comprenden por completo y que no pueden definirse todos los requisitos de entrada, sino que se van redefiniendo en cada
compilación sucesiva." [DOD94]
Las iteraciones siguientes son características:
-
una breve iteración inicial para establecer el ámbito y la visión, y para definir el caso de negocio
-
varias iteración de elaboración, durante las que se perfeccionan los requisitos en cada iteración
-
una única iteración de construcción, durante las que se ejecutan los guiones de uso y se amplía la arquitectura
-
varias iteraciones de transición para migrar el producto a la comunidad de usuarios
Esta estrategia es adecuada cuando:
-
El dominio del problema es nuevo o no es conocido.
-
El equipo del proyecto no tiene mucha experiencia.
Algunos autores también establecen fases en las entregas de funcionalidades incrementales al cliente [GIL88]. Esto puede ser necesario en casos de fuertes presiones con los plazos de
comercialización, en los que la entrega temprana de ciertas funciones clave puede suponer beneficios comerciales
significativos.
En términos del enfoque de iteración y fase, la fase de transición empieza al principio y es la que más iteraciones
tiene. Esta estrategia precisa de una arquitectura muy estable, que es difícil de adquirir en un ciclo de desarrollo
inicial, para un sistema "sin precedentes".
Las iteraciones siguientes son características:
-
una breve iteración inicial para establecer el ámbito y la visión, y para definir el caso de negocio
-
una única iteración de la elaboración, durante la que se establece la línea base de una arquitectura estable
-
una única iteración de construcción, durante la que se ejecutan los guiones de uso y se sustancia la
arquitectura
-
varias iteraciones de transición para migrar el producto a la comunidad de usuarios
Esta estrategia es adecuada cuando:
Patrón de ciclo vital: "Diseño grande"
El enfoque de cascada tradicional puede verse como un caso degenerado en el que sólo hay una iteración en la fase de
construcción. Se denomina "diseño grande" en [DOD94]. En la práctica,
es difícil evitar las iteraciones adicionales en la fase de transición.
Las iteraciones siguientes son características:
-
una breve iteración inicial para establecer el ámbito y la visión, y para definir el caso de negocio
-
una iteración de construcción única y muy larga, durante la que se ejecutan los guiones de uso y se sustancia
la arquitectura
-
varias iteraciones de transición para migrar el producto a la comunidad de usuarios
Esta estrategia es adecuada cuando:
-
un pequeño incremento de funcionalidad bien definida se añade a un producto muy estable
-
la nueva funcionalidad está bien definida y se comprende bien
-
El equipo tiene mucha experiencia, tanto en el dominio del problema como con el producto existente
En la práctica, son pocos los proyectos que siguen una única estrategia. A menudo, se emplea una forma híbrida,
un poco de evolución al principio, un poco de compilaciones incrementales y varias entregas. Entre las ventajas del
modelo de iteración de fases está que le permite adecuar un enfoque híbrido, simplemente aumentando la longitud y el
número de iteraciones en fases concretas:
-
Para los dominios de problemas complejos o desconocidos, en los que hay un alto grado de exploración: aumente
el número y la longitud de las iteraciones de la fase de elaboración.
-
Para los problemas más complejos de desarrollo, en los que la traducción del diseño al código es compleja:
aumente el número y la longitud de las iteraciones en la fase de construcción.
-
Para entregar software en una serie de releases incrementales: aumente el número y la longitud de las
iteraciones en la fase de transición.
Moverse de un ciclo al siguiente
Un pase por las cuatro fases es un ciclo de desarrollo; cada pase por las cuatro fases produce una
generación del software. A menos que el producto "muera", irá evolucionando hacia su siguiente generación
repitiendo la misma secuencia de fases de inicio, elaboración, construcción y transición, pero esta vez con un distinto
énfasis en las distintas fases. Estos ciclos subsiguientes se denominan ciclos de evolución. A medida que el
producto pasa por diversos ciclos, se van produciendo nuevas generaciones.
Los ciclos de evolución pueden desencadenarse por mejoras sugeridas por el usuario, cambios en el contexto del usuario,
cambios en la tecnología subyacente, reacción a la competencia, etc. Los ciclos de evolución suelen tener unas fases
inicial y de elaboración mucho más cortas, ya que la definición del producto y de la arquitectura básicos los
determinan ciclos de desarrollo anteriores. Las excepciones a esta norma son los ciclos de evolución en los
que se produce una redefinición significativa del producto o de la arquitectura.
|