Rational Unified

Process (RUP)
P O R MA R IO R O S S A I NZ LÓ P E Z
I NG E NIER IA DE S O F T WA R E I I
OTO ÑO 2022
NR C: 1 0 8 3 8
 •1967: Metodología Ericsson:
HISTORIA DEL RUP Aproximación de Desarrollo Basada
en Componentes.
•Ésta metodología introduce el
concepto de Caso de Uso
•1987-1995: Jacobson funda la
compañía Objectory AB.
•Se lanza el proceso de desarrollo
Objectory Factory.
•1995: Rational Software
Corporation Adquiere Objectory AB
•1995-1997: se desarrolla Rational
Objectory Process (ROP)
adoptando UML
•1998: se lanza RUP por Booch,
Jacobson y Rumbaugh.
Características del RUP • RUP esta dirigido por Casos
[Dirigido por Casos de Uso] de Uso.
• En RUP los casos de uso
especifican requisitos y guían
el diseño, la implementación y
las pruebas
• Los casos de uso inician el
proceso de desarrollo de
software y establecen una
trazabilidad entre los
artefactos generados en las
distintas actividades del
proceso de desarrollo
 • Trazabilidad del RUP
Características del RUP mediante los casos de
[Dirigido por Casos de Uso] uso:
• 1. Se crean los modelos
de Análisis y Diseño
• 2. Se efectúa la
implementación que los
lleva a cabo
• 3. Se verifica que el
producto satisfaga cada
caso de uso
• Todos estos elementos se
sincronizan con el modelo
de casos de uso
Características del RUP
[Centrado en la Arquitectura]

Incepción (Concepción): La meta de la fase de concepción es establecer un

caso empresarial para el sistema. Deben identificarse todas las entidades
externas (personas y sistemas) que interactuarán con el sistema y definirán
dichas interacciones. Luego se usa esta información para valorar la
aportación del sistema hacia la empresa. Si esta aportación es menor,
entonces el proyecto puede cancelarse después de esta fase
Características del RUP
[Centrado en la Arquitectura]

Elaboración: Las metas de la fase de elaboración consisten en desarrollar la comprensión

del problema de dominio, establecer un marco conceptual arquitectónico para el sistema,
diseñar el plan del proyecto e identificar los riesgos clave del proyecto. Al completar esta
fase, debe tenerse un modelo de requerimientos para el sistema, que podría ser una serie
de casos de uso del UML, una descripción arquitectónica y un plan de desarrollo para el
software.
Características del RUP
[Centrado en la Arquitectura]

Construcción. La fase de construcción incluye diseño, programación y pruebas del sistema.

Partes del sistema se desarrollan en paralelo y se integran durante esta fase. Al completar
ésta, debe tenerse un sistema de software funcionando y la documentación relacionada y
lista para entregarse al usuario.
Características del RUP
[Centrado en la Arquitectura]

Transición. La fase final del RUP se interesa por el cambio del sistema desde la comunidad
de desarrollo hacia la comunidad de usuarios, y por ponerlo a funcionar en un ambiente
real. Esto es algo ignorado en la mayoría de los modelos de proceso de software aunque, en
efecto, es una actividad costosa y en ocasiones problemática. En el complemento de esta
fase se debe tener un sistema de software documentado que funcione correctamente en su
entorno operacional.
Características del RUP
[Proceso Iterativo e Incremental]
• La iteración con el RUP se apoya en dos formas. Cada fase puede
presentarse en una forma iterativa, con los resultados desarrollados
incrementalmente. Además, todo el conjunto de fases puede
expresarse de manera incremental, como se muestra en la flecha en
curva desde transición hasta concepción en la figura.
Características del RUP
[Proceso Iterativo e Incremental]
• En el proceso de desarrollo de software con RUP se identifican seis
flujos de trabajo de proceso centrales y tres flujos de trabajo de apoyo
centrales.
• El RUP se diseñó en conjunto con el UML, de manera que la
descripción del flujo de trabajo se orienta sobre modelos UML
asociados, como modelos de secuencia, modelos de objeto, etcétera.
Características del RUP [Proceso Iterativo e Incremental]
Características del RUP
[Proceso Iterativo e Incremental]
• El proceso iterativo e
incremental consta entonces de
una secuencia de iteraciones.
Cada iteración aborda una
parte de la funcionalidad total,
pasando por todos los flujos de
trabajo relevantes y refinando
la arquitectura. Cada iteración
se analiza cuando termina. Se
puede determinar si han
aparecido nuevos requisitos o
han cambiado los existentes,
afectando a las iteraciones
siguientes.
Buenas (mejores) Prácticas de la IS en RUP
• Gestión de requisitos. RUP brinda una guía para encontrar, organizar, documentar,
y seguir los cambios de los requisitos funcionales y restricciones. Utiliza una
notación de Caso de Uso y escenarios para representar los requisitos.
• Desarrollo de software iterativo. Desarrollo del producto mediante iteraciones con
hitos bien definidos, en las cuales se repiten las actividades pero con distinto
énfasis, según la fase del proyecto.
• Desarrollo basado en componentes. La creación de sistemas intensivos en
software requiere dividir el sistema en componentes con interfaces bien definidas,
que posteriormente serán ensamblados para generar el sistema. Esta característica
en un proceso de desarrollo permite que el sistema se vaya creando a medida que
se obtienen o se desarrollan sus componentes.
Buenas (mejores) Prácticas de la IS en RUP
• Modelado visual (usando UML). UML es un lenguaje para visualizar, especificar, construir y
documentar el software. Utilizar herramientas de modelado visual facilita la gestión de
dichos modelos, permitiendo ocultar o exponer detalles cuando sea necesario. El modelado
visual también ayuda a mantener la consistencia.
• Verificación continua de la calidad. Es importante que la calidad se evalúe en varios
puntos durante el proceso de desarrollo, especialmente al final de cada iteración. En esta
verificación las pruebas juegan un papel fundamental y se integran a lo largo de todo el
proceso.
• Gestión de los cambios. El cambio es un factor de riesgo crítico en los proyectos de
software. El software cambia no sólo debido a acciones de mantenimiento posteriores a la
entrega del producto, sino que durante el proceso de desarrollo, especialmente
importantes por su posible impacto son los cambios en los requisitos.
Estructura del Proceso en RUP
• EJE ORIZONTAL: Representa
los aspectos dinámicos del
proceso en RUP (concepción o
inicio, elaboración,
construcción y transición)
expresado en fases, iteraciones
e hitos.
• EJE VERTICAL: Representa los
aspectos estáticos del proceso
en RUP en términos de
componentes, flujos de trabajo,
actividades, artefactos y roles
Estructura Dinámica del Proceso RUP
• RUP se repite a lo largo de una serie de ciclos que constituyen la vida de un producto.
• Cada ciclo concluye con una generación del producto para los clientes. Cada ciclo
consta de cuatro fases: Inicio, Elaboración, Construcción y Transición.
• Cada fase se subdivide a la vez en iteraciones, el número de iteraciones en cada fase
es variable
Estructura Dinámica del Proceso RUP
• Fases e Hitos iniciales
Estructura Dinámica del Proceso RUP

• Duración y Esfuerzo

• Distribución típica de
Recursos Humanos
Estructura Dinámica del Proceso RUP

• CONCEPCIÓN O INICIO:
• Propósito: Definir el modelo del negocio y el alcance del proyecto. Se
identifican todos los actores y Casos de Uso, y se diseñan los Casos de
Uso más esenciales (aproximadamente el 20% del modelo completo).
Se desarrolla, un plan de negocio para determinar que recursos deben
ser asignados al proyecto.
Estructura Dinámica del Proceso RUP

• CONCEPCIÓN O INICIO:
• Objetivos:
• Establecer el ámbito del proyecto y sus límites.
• Encontrar los Casos de Uso críticos del sistema, los escenarios básicos que
definen la funcionalidad.
• Mostrar al menos una arquitectura candidata para los escenarios
principales.
• Estimar el coste en recursos y tiempo de todo el proyecto.
• Estimar los riesgos, las fuentes de incertidumbre.
Estructura Dinámica del Proceso RUP
• CONCEPCIÓN O INICIO:
• Resultados:
• Un documento de visión: Una visión general de los requerimientos del proyecto,
características clave y restricciones principales.
• Modelo inicial de Casos de Uso (10-20% completado).
• Un glosario inicial: Terminología clave del dominio.
• El caso de negocio.
• Lista de riesgos y plan de contingencia.
• Plan del proyecto, mostrando fases e iteraciones.
• Modelo de negocio, si es necesario
• Prototipos exploratorios para probar conceptos o la arquitectura candidata
Estructura Dinámica del Proceso RUP
• CONCEPCIÓN O INICIO:
• Comprobación de Criterios:
• Todos los interesados en el proyecto coinciden en la definición del ámbito
del sistema y las estimaciones de agenda.
• Entendimiento de los requisitos, como evidencia de la fidelidad de los
Casos de Uso principales.
• Las estimaciones de tiempo, coste y riesgo son creíbles.
• Comprensión total de cualquier prototipo de la arquitectura desarrollado.
• Los gastos hasta el momento se asemejan a los planeados.
Estructura Dinámica del Proceso RUP
• ELABORACIÓN:
• Propósito: Analizar el dominio del problema, establecer los
cimientos de la arquitectura, desarrollar el plan del proyecto y
eliminar los mayores riesgos. 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.
Estructura Dinámica del Proceso RUP
• ELABORACIÓN:
• Objetivos:
• 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.
Estructura Dinámica del Proceso RUP
• 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).
Estructura Dinámica del Proceso RUP
• ELABORACIÓN:
• Comprobación de Criterios:
• La visión del producto es estable.
• La arquitectura es estable.
• Se ha demostrado mediante la ejecución del prototipo que los principales
elementos de riesgo han sido abordados y resueltos.
• El plan para la fase de construcción es detallado y preciso. Las estimaciones son
creíbles.
• Todos los interesados coinciden en que la visión actual será alcanzada si se siguen
los planes actuales en el contexto de la arquitectura actual.
• Los gastos hasta ahora son aceptables, comparados con los previstos
Estructura Dinámica del Proceso RUP
• CONSTRUCCIÓN:
• Propósito: Alcanzar la capacidad operacional del producto de forma
incremental a través de las sucesivas iteraciones. Durante esta fase
todos los componentes, características y requisitos deben ser
implementados, integrados y probados en su totalidad, obteniendo
una versión aceptable del producto.
Estructura Dinámica del Proceso RUP
• CONSTRUCCIÓN:
• Objetivos:
• Minimizar los costes de desarrollo mediante la optimización de recursos y
evitando el tener que rehacer un trabajo o incluso desecharlo.
• Conseguir una calidad adecuada tan rápido como sea práctico.
• Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba)
tan rápido como sea práctico.
Estructura Dinámica del Proceso RUP
• CONSTRUCCIÓN:
• Resultados:
• Modelos Completos (Casos de Uso, Análisis, Diseño, Despliegue e
Implementación)
• Arquitectura íntegra (mantenida y mínimamente actualizada)
• Riesgos Presentados Mitigados
• Plan del Proyecto para la fase de Transición.
• Manual Inicial de Usuario (con suficiente detalle)
• Prototipo Operacional – beta
• Caso del Negocio Actualizado
Estructura Dinámica del Proceso RUP
• CONSTRUCCIÓN:
• Comprobación de Criterios:
• El producto es estable y maduro como para ser entregado a la comunidad
de usuario para ser probado.
• Todos los usuarios expertos están listos para la transición en la comunidad
de usuarios.
• Son aceptables los gastos actuales versus los gastos planeados
Estructura Dinámica del Proceso RUP
• TRANSICIÓN:
• Propósito: 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.
Estructura Dinámica del Proceso RUP
• TRANSICIÓN:
• Objetivos:
• Prueba de la versión Beta para validar el nuevo sistema frente a las expectativas de los
usuarios
• Funcionamiento paralelo con los sistemas legados que están siendo sustituidos por
nuestro proyecto.
• Conversión de las bases de datos operacionales.
• Entrenamiento de los usuarios y técnicos de mantenimiento.
• Traspaso del producto a los equipos de marketing, distribución y venta.
• Conseguir que el usuario se valga por si mismo.
• Un producto final que cumpla los requisitos esperados, que funcione y satisfaga
suficientemente al usuario
Estructura Dinámica del Proceso RUP
• TRANSICIÓN:
• Resultados:
• Prototipo Operacional
• Documentos Legales
• Caso del Negocio Completo
• Línea de Base del Producto completa y corregida que incluye todos los modelos
del sistema
• Descripción de la Arquitectura completa y corregida
• Las iteraciones de esta fase irán dirigidas normalmente a conseguir una nueva
versión
Estructura Dinámica del Proceso RUP
• TRANSICIÓN:
• Comprobación de Criterios:
• El usuario se encuentra satisfecho.
• Son aceptables los gastos actuales versus los gastos planificados.
 Estructura Estática del Proceso RUP
• Un proceso de desarrollo de software define
quién hace qué, cómo y cuándo. RUP define
cuatro elementos:
• Roles →¿Quién?,
• Actividades → ¿Cómo?
• Productos →¿Qué?
• Flujos de trabajo →¿Cuándo?