El documento proporciona una introducción al Proceso Racional Unificado (RUP), incluyendo su definición, historia, principios, ciclo de vida y etapas. RUP es una metodología para el desarrollo de software que se centra en la calidad, adaptación y colaboración. Se compone de cuatro fases iterativas: inicio, elaboración, construcción y transición. Cada fase tiene objetivos específicos como establecer requisitos, desarrollar la arquitectura y poner el producto final en manos de los usuarios.

1. Proceso Racional Unificado
Rational Unified Process - Rational Software- IMB
Procesos y herramientas de las auditorias de TIC y SI
Marzo 8 de 2017

2. Definición RUP
¿Qué es RUP?
Es la metodología estándar más usada a nivel mundial para el análisis,
implementación y documentación de sistemas. Se apoya en el Lenguaje
Unificado de Modelado (UML) para comprender el funcionamiento del sistema.
Su meta principal es asegurar la producción de software de alta calidad que
cumpla con las necesidades de los usuarios, con una planeación y presupuesto
predecible.
¿Para quién es RUP?
• Diseñado para:
• Profesionales en el desarrollo de software.
• Interesados en productos de software.
• Profesionales en la ingeniería y administración de procesos de software.

3. Historia de RUP

4. Principios de RUP
1. Adaptación del proceso a las necesidades del cliente interactuando con él
2. Equilibrar las necesidades o requerimientos de los participantes con
prioridades justas
3. Etapas iteradas en el proceso
4. Colaboración continua entre equipos de desarrollo del software
5. Uso de elementos reutilizables que permita elevar el nivel de abstracción
6. La calidad del producto debe verificarse en todas las etapas del proceso

5. Ciclo de vida de RUP

6. Etapas o fases de RUP
Flujos de trabajo
Modelado de negocio

7. FLUJOS DE TRABAJO
Modelado de
negocio
mejor
entendimiento
de la
organización
donde se va a
implantar el
producto.
Requisitos
establece
qué tiene que
hacer
exactamente el
sistema que
construyamos.
Análisis y
Diseño
traducir los
requisitos a una
especificación
que describe
cómo
implementar el
sistema.
Implementación
se implementan
las clases y
objetos en
ficheros fuente,
binarios,
ejecutables y
demás.
Verificación
(Pruebas)
evaluar la
calidad del
producto que
estamos
desarrollando.

8. FLUJOS DE TRABAJO
Implantación
(Despliegue)
producir con éxito
distribuciones del
producto y
distribuirlo a los
usuarios.
Gestión del
proyecto
lograr un balance al
gestionar objetivos,
riesgos y
restricciones para
desarrollar un
producto que sea
acorde a los
requisitos de los
clientes y los
usuarios.
Configuración y
control de cambios
mantener la
integridad de todos
los artefactos que se
crean en el proceso.
Entorno
dar soporte al
proyecto con las
adecuadas
herramientas,
procesos y métodos.
Gestión de calidad
Monitorear que el
proyecto cumpla los
objetivos.

9. fase de inicio
El objetivo de esta fase se centra más en buscar o planear todo lo que la
empresa requiera para luego utilizar sus recursos mejorando y dándole una
visión de lo que se espera plantear en el proyecto.

10. fase: ELABORACIÓN
• El objetivo en esta fase es establecer la arquitectura base del sistema para proveer bases
estables para el esfuerzo de diseño e implementación en la siguiente fase.
• La arquitectura debe abarcar todas las consideraciones de mayor importancia de los
requerimientos y una evaluación del riesgo.
• En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline (LINEA DE BASE)
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.

11. Fase Elaboración – Objetivos.
En esta fase se construye un prototipo de la arquitectura, que debe evolucionar
en iteraciones sucesivas hasta convertirse en el sistema final.
Este prototipo debe contener los Casos de Uso críticos identificados en la fase
de inicio. También debe demostrarse que se han evitado los riesgos más
graves. Los objetivos de esta fase son :
• Definir, validar y cimentar la arquitectura.
• Completar la visión.
• Crear un plan fiable para la fase de construcción. Este plan puede evolucionar
en sucesivas iteraciones. Debe incluir los costes si procede.
• Demostrar que la arquitectura propuesta soportará la visión con un coste
razonable y en un tiempo razonable.

12. Fase Elaboración – Resultados
• Un modelo de Casos de Uso completa al menos hasta el 80%: todos los
casos y actores identificados, la mayoría de los casos desarrollados.
• Requisitos adicionales que capturan los requisitos no funcionales y
cualquier requisito no asociado con un Caso de Uso específico.
• Descripción de la arquitectura software.
• Un prototipo ejecutable de la arquitectura.
• Lista de riesgos y caso de negocio revisados.
• Plan de desarrollo para el proyecto.
• Un caso de desarrollo actualizado que especifica el proceso a seguir.
• Un manual de usuario preliminar (opcional).

13. Fase de Elaboración
• Análisis y diseño del proyecto.
• Administración de la configuración y cambio.
• Diseñar componentes.
• Diseñar el modelo de datos.
• Artefactos.

14. Modelos para Realizar la fase de Elaboración.
- Modelado de clases y objetos: modelar conceptos de dominio de la aplicación, así como
los conceptos internos inventados como parte de la implementación de la aplicación.
- Modelos de interacción: muestran el comportamiento del sistema y el flujo de control
dispuestos en una secuencia temporal y con los enlaces significativos dentro de una
interacción.
- Diagrama de estados: representan las posibles historias de vida de un objeto de una clase.
- Diagrama de actividad: muestran las actividades de computo implicadas para realizar una
operación.
- Diagrama de paquetes del sistema: proporciona una visión de los diferentes módulos del
sistema.
- Modelo de datos: se representa a través de un modelo de BD.

15. El objetivo de la fase de construcción es clarificar los requerimientos faltantes y
completar el desarrollo del sistema basados en la arquitectura base.
Comprende implementación, pruebas y muestra del sistema al usuario.
Fase de Construcción

16. Documento Arquitectura que trabaja con cuatro vistas:
1. Vista lógica: flujo de trabajo
entre el análisis y el diseño
• Diagrama de clases
• Modelo E-R (Si el sistema así lo
requiere)
Fase de Construcción

17. 2. Vista Implementación: Todos los
elementos que se utilizaron para desarrollar
y poner a producción una herramienta;
permite tener control de cambios de
versión configuraciones a través de archivos.
Para presentar estos compontes utiliza los
diagramas en UML
• Diagrama de Secuencia: muestra una
interacción, que representa la secuencia
de mensajes entre instancias de clases,
componentes, subsistemas o actores.
• Diagrama de estados: Determina cada
una de las rutas o caminos que puede
tomar un movimiento de información
luego de ejecutarse cada proceso: Estado,
eventos, envío de mensajes, transición
simple, transición interna y acciones
• Diagrama de Colaboración: Muestra las
relaciones entre roles.
Fase de Construcción

18. 3 Vista Conceptual: Presentación real
del sistema.
• Modelo de dominio: Presenta su
realidad física
Fase de Construcción

19. 4. Vista Física: Revisa el
comportamiento del aplicativo a nivel
de hardware
• Mapa de comportamiento a nivel de
hardware.
Fase de Construcción

20. Fase de transición
La finalidad de la fase de transición es poner el
producto en manos de los usuarios finales, para
lo que se requiere desarrollar nuevas versiones
actualizadas del producto, completar la
documentación, entrenar al usuario en el
manejo del producto, y en general tareas
relacionadas con el ajuste, configuración,
instalación y facilidad de uso del producto.

21. Fase de transición
Objetivos:
El usuario pueda
hacer el proceso,
además de esto que
el producto cumpla
los requisitos
esperados
Actividades:
Versión beta
Funcionamiento en
paralelo
Conversión de las
bases de datos
operacionales
Resultados:
Prototipo
Documentación
legal
Caso de negocio
completo

22. METODOLOGIA RUP
Ventajas
• reduce riesgos del proyecto
• El objetivo de calidad del proyecto de alto
• Integra desarrollo con mantenimiento
• Es una forma disciplinada de asignar tareas
y responsabilidades
• un proceso de software confiable para
satisfacer las necesidades del proyecto
Desventajas
• En proyectos pequeños, es posible que no
se puedan cubrir los costos de dedicación
del equipo de profesionales necesarios.
• Por el grado de complejidad puede ser no
muy adecuado

23. Referencias
https://es.wikipedia.org/wiki/Proceso_Unificado_Racional
https://softwarerecopilation.wordpress.com/modelo-rup/
http://ima.udg.edu/~sellares/EINF-ES2/Present1011/MetodoPesadesRUP.pdf