La estructura estática del RUP y las iteraciones solapadas

Autor: Lic. Carlos Galindo González, y Dr. Ramiro Pérez Vázquez

Tecnología e internet

12-02-2009

El problema del software se reduce a la dificultad que afrontan los desarrolladores para coordinar las múltiples cadenas de trabajo de un gran proyecto de software.

El Proceso Unificado de Desarrollo (RUP) es una solución a este problema porque:

• Proporciona una guía para organizar las actividades de un equipo.
• Dirige las tareas de cada desarrollador por separado y las del equipo como un todo.
• Especifica los artefactos a desarrollar.
• Ofrece criterios para el control, la medición de los productos y actividades del proyecto.

RUP utiliza el UML para preparar los esquemas del software y esta basado en componentes de software interconectados entre si a través de interfaces bien definidas. Tiene como características principales que es dirigido por casos de uso, centrado en la arquitectura y es iterativo e incremental. Es práctico subdividir el trabajo en partes más pequeñas o mini-proyectos donde cada uno resulta en un incremento o versión del producto.

El ciclo de vida un proyecto consta de cuatro fases: concepción, elaboración, construcción y transición. Cada fase termina con un hito donde se dispone de un conjunto de artefactos (documentos, modelos, código ejecutable, etc), su objetivo más importante es que los directores del proyecto pueden tomar decisiones para continuar a la siguiente fase. Al finalizar las fases del ciclo de vida se termina una versión del producto.

En la fase de concepción se desarrolla una descripción del producto final a partir de una buena idea y se presenta el análisis del negocio para el producto.

Durante la fase de elaboración se especifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura del sistema. Al final de esta fase el director esta en disposición de planificar las actividades y estimar los recursos necesarios para terminar el proyecto.

En la fase de construcción se crea el producto, la arquitectura crece hasta convertirse en sistema completo y ya contiene todos los casos de uso acordados.

En la fase de transición se realizan las pruebas del sistema con un número reducido de usuarios para detectar defectos y deficiencias. Los desarrolladores corrigen errores e introducen mejoras propuestas.

Cada fase puede tener varias iteraciones y cada iteración puede abracar varios procesos del flujo de trabajo.

Los grupos de desarrollo de software trabajando de una forma iterativa tienen algunos miembros que sobrepasan la planificación y logran un conjunto de metas hechas para iteraciones posteriores. La técnica de iteraciones solapadas puede ser beneficiosa si es comprendida y manipulada de forma correcta.

Iteraciones estándar l1, l2 y l3, ocurren de forma secuencial de izquierda a derecha, ocurriendo de forma secuencial hacia abajo en cada iteración (Requirements, Design, Code and Test).

Estas iteraciones pueden solaparse como muestra el siguiente gráfico:

En el siguiente a continuación se aprecia las iteraciones solapadas controladas por la técnica de time-boxes:

Esta técnica de iteraciones solapadas tiene los siguientes riesgos:

• Incrementa el trabajo.
• Incrementa el costo de cancelación de un proyecto.
• Disminución de la moral.
• Impacto en el proceso de mejora.
• Mentalidad de disciplina.
• El peligro de la cascada.

Para evitar las iteraciones solapadas en el proyecto se puede utilizar al personal en:

• Dos proyectos.
• Múltiples roles.
• Aceptar la situación de pérdida de tiempo.
• Reducir el tamaño del grupo.

Las iteraciones solapadas pueden ser de gran ayuda, pero debe tener un riguroso control para que no se conviertan en un arma de doble filo, para ello se deben seguir estas dos importantes reglas:

• No permitir solapamiento de iteraciones durante la elaboración, si en la construcción.
• Durante la construcción no permitir ir más allá de una iteración.

Referencias bibliográficas:

• Philippe Kruchten. “The Racional Unified Process: An introduction”. Addison – Wesley. 2000.

• Barry Boehm. “Get ready for Agile Methods , with care”. Computer, pp. 64 – 69, 2002.