RUP

 METODOLOGIA RUP


               XP Xtreme Programming                          RUP Rational Unified Process      

Rational Unified Process (RUP)

CARACTERÍSTICAS ESENCIALES

Los autores de RUP destacan que el proceso de software propuesto por RUP tiene tres características esenciales: está dirigido por los Casos de Uso, está centrado en la arquitectura, y es iterativo e incremental.

PROCESO DIRIGIDO POR CASOS DE USO

Los Casos de Uso son una técnica de captura de requisitos que fuerza a pensar en términos de importancia para el usuario y no sólo en términos de funciones que seria bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor añadido. Los Casos de Uso representan los requisitos funcionales del sistema.

En RUP los Casos de Uso no son sólo una herramienta para especificar los requisitos del sistema. También guían su diseño, implementación y prueba. Los Casos de Uso constituyen un elemento integrador y una guía del trabajo como se muestra en la Figura 2.

 

Figura 2: Los Casos de Uso integran el trabajo

Los Casos de Uso no sólo inician el proceso de desarrollo sino que proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo.

Como se muestra en la Figura 3, basándose en los Casos de Uso se crean los modelos de análisis y diseño, luego la implementación que los lleva a cabo, y se verifica que efectivamente el producto implemente adecuadamente cada Caso de Uso. Todos los modelos deben estar sincronizados con el modelo de Casos de Uso.

 

Figura 3: Trazabilidad a partir de los Casos de Uso

 

PROCESO CENTRADO EN LA ARQUITECTURA

La arquitectura de un sistema es la organización o estructura de sus partes más relevantes, lo que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo.

En la Figura 4 se ilustra la evolución de la arquitectura durante las fases de RUP. Se tiene una arquitectura más robusta en las fases finales del proyecto. En las fases iniciales lo que se hace es ir consolidando la arquitectura por medio de vaselinas y se va modificando dependiendo de las necesidades del proyecto.

 

Figura 4: Evolución de la arquitectura del sistema

Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el diseño por lo que la arquitectura se representa mediante varias vistas que se centran en aspectos concretos del sistema, abstrayéndose de los demás

 

Figura 5: Los modelos se completan, la arquitectura no cambia drásticamente

 

PROCESO ITERATIVO E INCREMENTAL

El equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy parecido al equilibrio de la forma y la función en el desarrollo del producto, lo cual se consigue con el tiempo. Para esto, la estrategia que se propone en RUP  es tener un proceso iterativo e incremental en donde el trabajo se divide en partes más pequeñas o mini proyectos.

 

Figura 6: Una iteración RUP

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en los distintas actividades. En la Figura 7 se muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se

Encuentre el proyecto RUP.

Figura 7: Esfuerzo en actividades según fase del proyecto

Las primeras iteraciones (en las fases de Inicio y Elaboraciónón) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una base de la arquitectura.

Durante la fase de inicio las iteraciones hacen ponen mayor énfasis en actividades modelado del negocio y de requisitos.

En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura.

En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones.

Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementación de la nueva versión del producto.

En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.

Como se puede observar en cada fase participan todas las disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una disciplina varía.

RUP identifica 6 best practices con las que define una forma efectiva de trabajar para los equipos de desarrollo de software.

GESTIÓN DE REQUISITOS

RUP brinda una guía para encontrar, organizar, documentar, y seguir los cambios de los requisitos funcionales y restricciones. Utiliza una notación de Caso de Uso y escenarios para representar los requisitos.

DESARROLLO DE SOFTWARE ITERATIVO

Desarrollo del producto mediante iteraciones con hitos bien definidos, en las cuales se repiten las actividades pero con distinto énfasis, según la fase del proyecto.

DESARROLLO BASADO EN COMPONENTES

La creación de sistemas intensivos en software requiere dividir el sistema en componentes con interfaces bien definidas, que posteriormente serán ensamblados para generar el sistema. Esta característica en un proceso de desarrollo permite que el sistema se vaya creando a medida que se obtienen o se desarrollan sus componentes.

MODELADO VISUAL (USANDO UML)

UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos de un sistema software. Es un estándar de la OMG (http://www.omg.org). Utilizar herramientas de modelado visual facilita la gestión de dichos modelos, permitiendo ocultar o exponer detalles cuando sea necesario. El modelado visual también ayuda a mantener la consistencia entre los artefactos del sistema: requisitos, diseños e implementaciones. En resumen, el modelado visual ayuda a mejorar la capacidad del equipo para gestionar la complejidad del software.

ESTRUCTURA DEL PROCESO

El proceso puede ser descrito  en dos dimensiones o ejes [RSC98]:

Eje horizontal: Representa el tiempo y es considerado el eje de los aspectos dinámicos del proceso. Indica las características del ciclo de vida del proceso expresado en términos de fases,  iteraciones e hitos. Se puede observar  en la Figura 8 que RUP consta de cuatro fases: Inicio, Elaboración, Construcción y Transición. Como se mencionó anteriormente cada fase se subdivide a la vez en iteraciones. 

Eje vertical: Representa los aspectos estáticos del proceso. Describe el proceso en términos de componentes de proceso, disciplinas, flujos de trabajo, actividades, artefactos y roles.

 

Figura 8: Estructura de RUP

 

ESTRUCTURA DINÁMICA DEL PROCESO. FASES E ITERACIONES

RUP se repite a lo largo de una serie de ciclos que constituyen la vida de un producto. Cada ciclo concluye con una generación del producto para los clientes. Cada ciclo consta de cuatro fases: Inicio, Elaboración, Construcción y Transición. Cada fase se subdivide a la vez en iteraciones, el número de iteraciones en cada fase es variable.

Figura 9: Ciclos, releases, baseline

Cada fase se concluye con un hito bien definido, un punto en el tiempo en el cual se deben tomar ciertas decisiones críticas y  alcanzar las metas clave antes de pasar a la siguiente fase, ese hito principal de cada fase se compone de hitos menores que podrían ser los criterios aplicables a cada iteración. Los hitos para cada una de las fases son:

Lifecycle Objectives, Elaboración - Lifecycle Architecture, Construcción

Initial Operational Capability, Transición - Product Release. Las fases y sus respectivos hitos se ilustran en la Figura 10.

figura 10: fases e hitos en rup

La duración y esfuerzo dedicado en cada fase es variable dependiendo de las características del proyecto. Sin embargo, la Figura 11 ilustra porcentajes frecuentes al respecto. Consecuente con el esfuerzo señalado, la Figura 12 ilustra una distribución típica de recursos humanos necesarios a lo largo del proyecto.

	Inicio	Elaboración	Construcción	Transición
Esfuerzo	5 %	20 %	65 %	10%
Tiempo Dedicado	10 %	30 %	50 %	10%

Figura 11: Distribución típicas de esfuerzo y tiempo

 

Figura 12: Distribución típica de recursos humanos

 

ESTRUCTURA ESTÁTICA DEL PROCESO,ROLES, ACTIVIDADES, ARTEFACTOS Y FLUJOS DE TRABAJO

Un proceso de desarrollo de software define quién hace qué, cómo y cuándo. RUP define cuatro elementos los roles, que responden a la pregunta ¿Quién?, las actividades que responden a la pregunta ¿Cómo?, los productos, que responden a la pregunta ¿Qué? y los flujos de trabajo de las disciplinas que responde a la pregunta ¿Cuándo? (ver Figura 13 y 14)  [RSC98].

 

Figura 13: Relación entre roles, actividades, artefactos

 

Figura 14: Detalle de un workflow mediante roles, actividades y artefactos roles

Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de individuos trabajando juntos como un equipo. Una persona puede desempeñar diversos roles, así como un mismo rol puede ser representado por varias personas.

Las responsabilidades de un rol son tanto el llevar a cabo un conjunto de actividades como el ser el dueño de un conjunto de artefactos [MMA].

RUP define grupos de roles, agrupados por participación en actividades relacionadas. Estos grupos son [RSC02]:

Analistas:

·       Analista de procesos de negocio.

·       Diseñador del negocio.

·       Analista de sistema.

·       Especificador de requisitos.

Desarrolladores:

·       Arquitecto de software.

·       Diseñador

·       Diseñador de interfaz de usuario

·       Diseñador de cápsulas.

·       Diseñador de base de datos.

·       Implementador.

·       Integrador.

Gestores:

·       Jefe de proyecto

·       Jefe de control de cambios.

·       Jefe de configuración.

·       Jefe de pruebas

·       Jefe de despliegue

·       Ingeniero de procesos

·       Revisor de gestión del proyecto

·       Gestor de pruebas.

Apoyo:

·       Documentador técnico

·       Administrador de sistema

·       Especialista en herramientas

·       Desarrollador de cursos

·       Artista gráfico

Especialista en pruebas:

·       Especialista en Pruebas (tester)

·       Analista de pruebas

·       Diseñador de pruebas

Otros roles:

·       Stakeholders.

·       Revisor

·       Coordinación de revisiones

·       Revisor técnico

·       Cualquier rol

ACTIVIDADES

Una actividad en concreto es una unidad de trabajo que una persona que desempeñe un rol puede ser solicitado a que realice. Las actividades tienen un objetivo concreto, normalmente expresado en términos de crear o actualizar algún producto.

ARTEFACTOS

Un producto o artefacto es un trozo de información que es producido, modificado o usado durante el proceso de desarrollo de software. Los productos son los resultados tangibles del proyecto, las cosas que va creando y usando hasta obtener el producto final [MMA].

Un artefacto puede ser cualquiera de los siguientes [RSC02]:

·       Un documento, como el documento de la arquitectura del software.

·       Un modelo, como el modelo de Casos de Uso o el modelo de diseño.

·       Un elemento del modelo, un elemento que pertenece a un modelo como una clase, un Caso de Uso o un subsistema.

UNA CONFIGURACIÓN RUP PARA PROYECTO PEQUEÑO

En este apartado se describe una posible configuración de RUP para un proyecto pequeño. Por las características del proyecto, se han incluido muy pocos artefactos, roles y actividades de la metodología, manteniendo los más esenciales. Dicha configuración está basada en la siguiente selección de artefactos:

ENTREGABLES DEL PROYECTO

A continuación se describen brevemente cada uno de los artefactos que se generarán y usarán durante el proyecto.

1.    FLUJOS DE TRABAJO

Se utilizarán Diagramas de Actividad para modelar los Flujos de Trabajo (workflows) del área problema, tanto los actuales (previos a la implantación de nuevo sistema) como los propuestos, que serán soportados por el sistema desarrollado

2.    CARACTERÍSTICAS DEL PRODUCTO SOFTWARE

Es una lista de las características principales del producto, deseables desde una perspectiva de las necesidades del cliente.

3.    MODELO DE CASOS DE USO

El modelo de Casos de Uso presenta la funcionalidad del sistema y los actores que hacen uso de ella. Se representa mediante Diagramas de Casos de Uso.

4.    MODELO DE ANÁLISIS Y DISEÑO

Este modelo establece la realización de los casos de uso en clases y pasando desde una representación en términos de análisis (sin incluir aspectos de implementación) hacia una de diseño (incluyendo una orientación hacia el entorno de implementación). Está constituido esencialmente por un Diagrama de Clases y algunos Diagramas de Estados para las clases que lo requieran.

5.    MODELO DE IMPLEMENTACIÓN

Este modelo es una colección de componentes y los subsistemas que los contienen. Estos componentes incluyen: ficheros ejecutables, ficheros de código fuente, y todo otro tipo de ficheros necesarios para la implantación y despliegue del sistema.

6.    MODELO DE PRUEBAS

Para cada Caso de Uso se establecen pruebas de Aceptación que validarán la correcta implementación del Caso de Uso. Cada prueba es especificada mediante un documento que establece las condiciones de ejecución, las entradas de la prueba, y los resultados esperados.

 

Figura 15. Trazabilidad entre artefactos.

Las relaciones de trazabilidad son enlaces entre artefactos que establecen cómo se generan unos a partir de otros. Esto permite por ejemplo asegurar la cobertura de los requisitos o determinar el posible impacto de los cambios. En la Figura 15 se ilustran los modelos y artefactos utilizados, indicando las relaciones de trazabilidad entre ellos, lo cual se resume a continuación:

• Se modelarán los procesos de negocio de la situación actual utilizando Diagramas de Actividad para representar Flujos de Trabajo Actuales. Esto se complementará mediante un Glosario que establecerá la terminología.

• El modelo de procesos de la solución propuesta incluirá Flujos de Trabajo Propuestos junto con una lista de Características del Producto Software.

• Los requisitos serán establecidos mediante un Modelo de Casos de Uso que incluirá Diagramas de Casos de Uso, Prototipos de Interfaces de Usuario y Especificaciones de Casos de Uso.

• El Modelo de Pruebas incluirá las Pruebas de Aceptación establecidas para cada Caso de Uso.

• El Modelo de Análisis y Diseño establecerá el particionamiento interno del sistema. Estará compuesto por un Diagrama de Clases y algunos Diagramas de Estados. Las clases determinarán la estructura y las operaciones necesarias para implementar las funcionalidades descritas en los Casos de Uso. Los Diagramas de Estados detallarán el comportamiento para las clases que lo requieran.

• A partir del Diagrama de Clases, y considerando las clases que requieran persistencia, se derivará el Modelo Lógico Relacional, representado mediante Diagramas de Tablas.

• En el Modelo de Implementación se organizarán las operaciones de las clases en términos de componentes de dicha arquitectura. Esto se representará mediante Diagramas de Componentes.

• La implementación del Modelo Lógico Relacional y de los componentes de la aplicación constituirán el Producto, el cual se complementará con el Manual de Instalación y el Manual de Usuario.