METODOLOGIA RUP

PRESENTADO POR:
Nicols Cosme Fernndez
Juan Camilo Pabn Rivas
Jeison Fernando Ramos Sarria

PRESENTADO A:
Ing. Wilson Ortega

UNIVERSIDAD DEL CAUCA

INFORMATICA III
POPAYAN
2016

1. INTRODUCCION
La Ingeniera de software, se vale y establece a partir de una serie de modelos que establecen y
muestran las distintas etapas y estados por los que pasa un producto software, desde su
concepcin inicial, pasando por su desarrollo, puesta en marcha y posterior mantenimiento,
hasta la retirada del producto. A estos modelos se les denomina modelos de ciclo de vida del
software.

2. DEFINICION
El Proceso Racional Unificado es un proceso de desarrollo de software desarrollado por la
empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje Unificado de
Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, diseo,
implementacin y documentacin de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas
adaptables al contexto y necesidades de cada organizacin. Originalmente se dise un proceso
genrico y de dominio pblico, el Proceso Unificado, y una especificacin ms detallada.

3. HISTORIA
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 primer resultado de esta fusin fue el Rational Objectory Process, la primera versin de RUP,
fue puesta en el mercado en 1998.
4. PRINCIPIOS DE DESARROLLO
La Filosofa del RUP est basado en 6 principios claves que son los siguientes:
Adaptar el proceso: El proceso deber adaptarse a las necesidades del cliente ya que es muy
importante interactuar con l. Las caractersticas propias del proyecto. El tamao del mismo, as
como su tipo o las regulaciones que lo condicionen, influirn en su diseo especfico. Tambin
se deber tener en cuenta el alcance del proyecto.
Equilibrar prioridades: Los requisitos de los diversos participantes pueden ser diferentes,
contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los
deseos de todos. Gracias a este equilibrio se podrn corregir desacuerdos que surjan en el futuro.
Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de un modo interno,
en etapas iteradas. En cada iteracin se analiza la opinin de los inversores, la estabilidad y
calidad del producto, y se refina la direccin del proyecto as como tambin los riesgos
involucrados.

Colaboracin entre equipos: El desarrollo de software no lo hace una nica persona sino
mltiples equipos. Debe haber una comunicacin fluida para coordinar requisitos, desarrollo,
evaluaciones, planes, resultados, etc.
Enfocarse en la calidad: El control de calidad no debe realizarse al final de cada iteracin, sino
en todos los aspectos de la produccin. El aseguramiento de la calidad forma parte del proceso
de desarrollo y no de un grupo independiente.
Elevar nivel de abstraccin: Este principio dominante motiva el uso de conceptos reutilizables
tales como patrn del software, lenguajes 4GL o esquemas (frameworks) por nombrar algunos.
Estos se pueden acompaar por las representaciones visuales de la arquitectura, por ejemplo
con UML.

5. PRINCIPALES CARACTERISTICAS.

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

Uso de arquitectura basada en componentes

Control de cambios

Modelado visual del software

Verificacin de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar
centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los
productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el cdigo fuente,
etc.) y roles (papel que desempea una persona en un determinado momento, una persona
puede desempear distintos roles a lo largo del proceso).

6. CICLO DE VIDA RUP

El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado ensamblando
los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e
iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en
nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en las
distintas actividades:

Fase de inicio: Durante esta fase de inicio las iteraciones se centran con mayor nfasis en las
actividades de modelamiento de la empresa y en sus requerimientos. Esta fase se centra mas en
buscar o planear todo lo que la empresa requiera para luego utilizar sus recursos mejorando
y dndole una visin de lo que se espera plantear en el proyecto.

Fase de elaboracin: Durante esta fase de elaboracin,se centran al desarrollo de los casos de
uso tomando como base la de diseo, como lo dice la elaboracin lleva una serie
de requerimientos una serie de pasos ; el modelo de la organizacin, el anlisis y el diseo se
van acumulando las actividades y para empezar una parte de implementacin
mediante desarrollo de la fase de inicio que va a ser orientada a la base de la construccin de
todas las especificaciones de la arquitectura del diseo. hasta obtener una diseo bien
construido.
Fase de construccin: Durante la fase de construccin, se lleva a cabo la construccin del
producto por medio de una serie de iteraciones las cuales se seleccionan algunos Casos de Uso,
se define su anlisis y despus el diseo y se procede a su implantacin y sus
respectivas pruebas. En esta fase se realiza una serie de cascadas para cada ciclo, se realizan
tantas iteraciones hasta que se termine la nueva implementacin y el producto este listo para
ser enviado al usuario.
Fase de transicin: Durante esta fase de transicin se busca garantizar que el producto este bien
preparado para su entrega al usuario. Es una fase que puede tener muchos cambios a la hora
de la entrega.
7. DISCIPLINA DE DESARROLLO RUP.

Determina las etapas a realizar durante el proyecto de creacin del software.

Ingeniera o modelado del negocio: Analizar y entender las necesidades del negocio para el
cual se est desarrollando el software.
Requisitos: Proveer una base para estimar los costos y tiempo de desarrollo del sistema.
Anlisis y diseo: Trasladar los requisitos analizados anteriormente a un sistema automatizado
y desarrollar una arquitectura para el sistema.
Implementacin: Crear software que se ajuste a la arquitectura diseada y que tenga el
comportamiento deseado.
Pruebas: Asegurarse de que el comportamiento requerido es correcto y que todo lo solicitado
est presente.
Despliegue: Producir distribuciones del producto y distribuirlo a los usuarios.
8. DISCIPLINA DE SOPORTE RUP
Determina la documentacin que es necesaria realizar durante el proyecto.

Configuracin y administracin del cambio: Guardar todas las versiones del proyecto.
Administracin del proyecto: Administrar los horarios y recursos que se deben de emplear.
Ambiente: Administrar el ambiente de desarrollo del software.
Distribucin: Hacer todo lo necesario para la salida del proyecto.

9. ELEMENTOS PRINCIPALES DEL RUP

Actividades: Procesos que se han de realizar en cada etapa/iteracin.

Trabajadores: Personas involucradas en cada actividad del proyecto.

Artefactos: RUP en cada una de sus fases (pertenecientes a la estructura dinmica) realiza una

serie de artefactos que sirven para comprender mejor tanto el anlisis como el diseo del
sistema (entre otros). Estos artefactos (entre otros) son los siguientes:
Inicio:
Documento Visin
Diagramas de caso de uso
Especificacin de Requisitos
Diagrama de Requisitos

Elaboracin:
Documento Arquitectura que trabaja con las siguientes vistas:

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

Vista de Implementacin
Diagrama de Secuencia
Diagrama de estados
Diagrama de Colaboracin

Vista Conceptual
Modelo de dominio

Vista fsica
Mapa de comportamiento a nivel de hardware.
Diseo y desarrollo de casos de uso, o flujos de casos de uso arquitectnicos
Pruebas de los casos de uso desarrollados, que demuestran que la arquitectura

documentada responde adecuadamente a requerimientos funcionales y no funcionales.

Construccin:
Especificacin de requisitos faltantes
Diseo y desarrollo de casos de uso y/o flujos de acuerdo con la planeacin iterativa
Pruebas de los casos de uso desarrollados, y pruebas de regresin segn sea el caso

Transicin:

 Pruebas finales de aceptacin

Puesta en produccin
Estabilizacin

10. VENTAJAS Y DESVENTAJAS

Ventajas:

Est basada totalmente en mejoras prcticas de la metodologa.

Reduce riesgos del proyecto.
Incorpora fielmente el objetivo de calidad.
Integra desarrollo con mantenimiento.

Desventajas:

Pretende prever y tener todo el control de antemano.

Modelo genera trabajo adicional.
Genera muchos costos.
No recomendable para proyectos pequeos.