Metodologia RUP

Rational Unified Process (RUP)
Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de
la metodología, características principales y estructura del proceso. RUP es un producto comercial
desarrollado y comercializado por Rational Software, una compañía de IBM.

Historia
La Figura 1 ilustra la historia de RUP. El antecedente más importante se ubica en1967 con la
Metodología Ericsson (Ericsson Approach) elaborada por Ivar Jacobson, una aproximación de
desarrollo basada en componentes, que introdujo el concepto de Caso de Uso. Entre los años de
1987 a 1995 Jacobson fundó la compañía Objectory AB y lanza el proceso de desarrollo Objectory
(abreviación de Object Factory).

Figura 1: Historia de RUP
Posteriormente en 1995 Rational SoftwareCorporation adquiere Objectory AB y entre 1995 y 1997
se desarrolla Rational Objectory Process (ROP) a partir de Objectory 3.8 y del Enfoque Rational
(Rational Approach) adoptando UML como lenguaje de modelado.
Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y James Rumbaugh, Rational
Software desarrolló e incorporó diversos elementos para expandir ROP, destacándose especialmenteel flujo de trabajo conocido como modelado del negocio. En junio del 1998 se lanza Rational
Unified Process.

Características esenciales
- 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 fragmentode 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 Figura2.

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, luegola 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 quepermite 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 el caso de RUP además de utilizar los Casos de Uso para guiar el proceso se presta especial
atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente
impactada ante cambios posterioresdurante la construcción y el mantenimiento.
Cada producto tiene tanto una función como una forma. La función corresponde a la funcionalidad
reflejada en los Casos de Uso y la forma la proporciona la arquitectura. Existe una interacción entre
los Casos de Uso y la arquitectura, los Casos de Uso deben encajar en la arquitectura cuando se
llevan a cabo y la arquitectura debe permitir el desarrollode todos los Casos de Uso requeridos,

actualmente y en el futuro. Esto provoca que tanto arquitectura como Casos de Uso deban
evolucionar en paralelo durante todo el proceso de desarrollo de software.
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...