[TALLER DE MODELAMIENTO DE

SOFTWARE]

RUP

(PROCESO
UNIFICADO

RACIONAL)
RUP (Rational Unified Process) es una secuencia de pasos necesarios para el
desarrollo y/o mantenimiento de gran cantidad de sistemas, en diferentes
reas de aplicacin diferentes organizaciones, diferentes medios de
competencia y en proyectos de tamaos variables (desde el ms bsico al
ms complejo). Actualmente es propiedad de International Business
Machines (IBM) y est basado en un enfoque disciplinado de asignacin de
tareas y responsabilidades dentro de una organizacin de desarrollo con la
finalidad de asegurar la obtencin de un software de alta calidad que
satisfagan la necesidad de los usuarios finales dentro de un calendario y
tiempo predecible.

Tambin se conoce por este nombre al software, tambin desarrollado por

Rational, que incluye informacin entrelazada de diversos artefactos y
descripciones de las diversas actividades.

III A Pgina 1
 [TALLER DE MODELAMIENTO DE
SOFTWARE]

III A Pgina 2
 [TALLER DE MODELAMIENTO DE
SOFTWARE]

QUIN UTILIZA RUP?

Aproximadamente unas 10,000 compaas utilizan el producto RUP. Lo usan
en varias aplicaciones de proyectos grandes y pequeos. Los sectores de la
industria que utilizan productos resultantes de RUP son:

Telecomunicaciones
Transportacin, defensa militar, aeronutica
Manufactura
Servicios financieros
Sistemas integradores

La forma en que cada compaa desarrolladora implementa RUP vara.

Algunas lo toman como una pauta estricta, y la siguen con mucha disciplina.
Otras eligen ver el modelo como una gua que les ofrece recomendaciones
sobre el desarrollo de su software. Ambos enfoques son correctos.

POR QU USAR RUP?

No existen dos proyectos iguales. Cada uno tiene sus prioridades distintas,
as como propios requerimientos y tecnologas. Aun as, en todos nuestros
proyectos buscamos minimizar los riesgos, asegurar resultados predecibles,
y entregar software de alta calidad puntualmente. La metodologa RUP
ayuda a entregar productos personalizados, y con calidad consistente.
Adems, la documentacin del proceso que se da con RUP permite que se
tenga un control visible y organizado de la evolucin del proyecto.

III A Pgina 3
 [TALLER DE MODELAMIENTO DE
SOFTWARE]

1. EL NACIMIENTO DE RUP
Los orgenes de RUP se remontan al modelo espiral original de Barry Boehm.
Ken Hartman, uno de los contribuidores claves de RUP colabor con Boehm
en la investigacin. En 1995 Rational Software compr una compaa sueca
llamada Objectory AB, fundada por Ivar Jacobson, famoso por haber
incorporado los casos de uso a los mtodos de desarrollo orientados a
objetos. El Rational Unified Process fue el resultado de una convergencia de
Rational Approach y Objectory (el proceso de la empresa Objectory AB). El
primer resultado de esta fusin fue el Rational Objectory Process, la primera
versin de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en
jefe Philippe Kruchten.

El primer libro para describir el proceso fue titulado "The Unified Software
Development Process (ISBN 0-201-57169-2)" El Proceso Unificado de
Desarrollo de Software (ISBN 0-201-57169-2), y publicado en 1999 por Ivar
Jacobson, Grady Booch y James Rumbaugh.

Ivar Jacobson Grady Booch

III A Pgina 4
James Rumbaugh
 [TALLER DE MODELAMIENTO DE
SOFTWARE]

2. ELEMENTOS DE RUP

I. DISCIPLINAS: son los 'contenedores' empleados para organizar

todas las actividades durante el ciclo de vida del sistema.

II. ARTEFACTOS: son los elementos de entrada y salida de las

actividades. Es un elemento que el proyecto produce y utiliza para
componer el producto final.

III. FLUJOS DE TRABAJO: constituye la secuencia de actividades que

producen resultados visibles por medio de la integracin de los roles y
las actividades, artefactos y disciplinas.

IV. ROLES: son las personas o entes que estn involucradas en cada
proceso.

III A Pgina 5
 [TALLER DE MODELAMIENTO DE
SOFTWARE]

3. FASES DE RUP

i. Fase de Inicio: Esta fase tiene como propsito definir y acordar el

alcance del proyecto con los patrocinadores, identificar los riesgos
asociados al proyecto, proponer una visin muy general de la
arquitectura de software y producir el plan de las fases y el de
iteraciones posteriores.

ii. Fase de elaboracin: En la fase de elaboracin se seleccionan los

casos de uso que permiten definir la arquitectura base del sistema y
se desarrollaran en esta fase, se realiza la especificacin de los casos
de uso seleccionados y el primer anlisis del dominio del problema,
se disea la solucin preliminar.

iii. Fase de Desarrollo: El propsito de esta fase es completar la

funcionalidad del sistema, para ello se deben clarificar los requisitos
pendientes, administrar los cambios de acuerdo a las evaluaciones
realizados por los usuarios y se realizan las mejoras para el proyecto.

III A Pgina 6
 [TALLER DE MODELAMIENTO DE
SOFTWARE]

iv. Fase de Transicin: El propsito de esta fase es asegurar que el

software est disponible para los usuarios finales, ajustar los errores y
defectos encontrados en las pruebas de aceptacin, capacitar a los
usuarios y proveer el soporte tcnico necesario. Se debe verificar que
el producto cumpla con las especificaciones entregadas por las
personas involucradas en el proyecto.

III A Pgina 7
 [TALLER DE MODELAMIENTO DE
SOFTWARE]

4. ARTEFACTOS
RUP en cada una de sus fases realiza una serie de artefactos que sirven
para comprender mejor tanto el anlisis como el diseo del sistema.

1. Inicio:

Documento Visin
Especificacin de Requisitos

2. Elaboracin:

Diagramas de caso de uso

3. Construccin: Documento Arquitectura que trabaja con las

siguientes vistas:

A. Vista Lgica

o Diagrama de clases
o Modelo E-R (Si el sistema as lo requiere)

B. Vista de Implementacin

o Diagrama de Secuencia
o Diagrama de estados
o Diagrama de Colaboracin

C. Vista Conceptual

o Modelo de dominio Vista fsica

o Mapa de comportamiento a nivel de hardware.

III A Pgina 8
 [TALLER DE MODELAMIENTO DE
SOFTWARE]

5. CARACTERSTICAS DE
RUP
Forma disciplinada de asignar tareas y responsabilidades (quin hace
qu, cundo y cmo)

Pretende implementar las mejores prcticas en Ingeniera de

Software

Desarrollo iterativo

Administracin de requisitos:
Esta prctica permite documentar, agilizar, mejorar los
requerimientos obtenidos para el desarrollo de un software, es
sin duda una metodologa que ayuda a insertar nuevos
cambios a un sistema de informacin (actualizaciones).

Uso de arquitectura basada en componentes:

Como es de saberse, antes de realizar el desarrollo completo

de un aplicativo, es necesario realizar un modelo a escala del
mismo, pues bien, el RUP ofrece herramientas basadas en los
componentes del sistema a implementar, dando va al
modelamiento seguro del mismo.

Control de cambios

Modelado visual del software

El RUP permite mostrar en una GUI el modelo de software

desarrollado, permitiendo al desarrollador mostrar errores y
poder corregirlos, sin duda, la interfaz grfica da vida al
sistema y es ella quien me permite realizar modificaciones.

Verificacin de la calidad del software

El verificar la calidad del producto realizado, es una prctica

que sustenta el desarrollo del mismo, el RUP, como
herramienta colaboradora, ofrece formas de diseo,
implementacin, ejecucin, entre otras del software, antes de
que ste sea implementado. En pocas palabras, permite
realizar testing al aplicativo.

Describir la organizacin, documentacin, funcionalidad y

restricciones de un software.

III A Pgina 9
 [TALLER DE MODELAMIENTO DE
SOFTWARE]

Documentar y registrar las decisiones que se tomen para el

desarrollo de un software.

Implementar los diferentes diagramas de UML, dando paso a la

reduccin de tiempo a la hora de desarrollar un software.

Controlar los Cambios realizados al Software:

El RUP adems de ofrecer herramientas para el desarrollo y

anlisis, permite tambin suministrar recursos que sean
ajustables a los posibles cambios que pueda sufrir el software,
ya sea de actualizacin o innovacin del mismo.

III A Pgina 10
 [TALLER DE MODELAMIENTO DE
SOFTWARE]

6. VENTAJAS

Reduce riesgos del proyecto.

Integra desarrollo con mantenimiento.
Requiere conocimientos del proceso y de UML.
Progreso visible en las etapas tempranas.
Permite evaluar tempranamente los riesgos en lugar de descubrir
problemas en la integracin final del sistema.
Facilita la reutilizacin del cdigo teniendo en cuenta que se realizan
revisiones en las primeras iteraciones lo cual adems permite que se
aprecien oportunidades de mejoras en el diseo.

7. DESVENTAJAS
Pretende prever y tener todo el control de antemano.
Modelo genera trabajo adicional.
Genera muchos costos.
No recomendable para proyectos pequeos.
RUP es generalmente mal aplicado en el estilo cascada.
Por el grado de complejidad puede no resultar muy adecuado.

III A Pgina 11
 [TALLER DE MODELAMIENTO DE
SOFTWARE]

8. CONCLUSIONES

Se puede concluir que RUP como herramienta colaboradora en el desarrollo

de software, aumenta la visin de desarrollo del proceso de un proyecto.

RUP es un proceso que permite prever los cambios que un software pueda
tener de acuerdo a los requerimientos y avances que se tengan, brindando
objetivos ms amplios y una visin global de requerimientos. RUP es aquel
proceso que da paso al cambio en las etapas del desarrollo de software,
mostrando otros campos que mejoren y optimicen el desarrollo del mismo.

III A Pgina 12