Ciclo vital de RUP
En esta página se describen las fases y objetivos de un ciclo vital de un proyecto RUP típico.
Relaciones
Descripción principal

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:

  principio elaboración construcción transición
Esfuerzo ~5 % 20 % 65 % 10%
Planificación 10 % 30 % 50 % 10%

que puede ilustrarse como

Transición Construcción Elaboración Principio Pulse una fase si desea más

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

Diagrama descrito en el texto adjunto.

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

Diagrama descrito en el texto adjunto.

Esta estrategia es adecuada cuando:

  • El dominio del problema es nuevo o no es conocido.
  • El equipo del proyecto no tiene mucha experiencia.

Patrón de ciclo vital: entrega incremental 

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

Diagrama descrito en el texto adjunto.

Esta estrategia es adecuada cuando:

  • El dominio del problema es familiar:

    • la arquitectura y los requisitos pueden estabilizarse al principio del ciclo de desarrollo
    • el problema tiene un grado bajo de novedad
  • El equipo tiene mucha experiencia.
  • Los releases incrementales de funcionalidad tienen un gran valor para el cliente.

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

Diagrama descrito en el texto adjunto.

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

Patrón de ciclo vital: estrategias híbridas

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.

Gráfico de diagrama de desarrollo inicial

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.