MetodoPesadesRUP

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 en 1967con 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 Software Corporationadquiere 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 especialmente
el flujo detrabajo 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 fragmento de funcionalidad delsistema 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 deUso 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 acabo, 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 todoslos 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 posteriores durante la construcción y el mantenimiento.
Cadaproducto 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 desarrollo de todos los Casos de Uso requeridos,

actualmente yen 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 hace es ir
consolidando la arquitectura por medio de...