Rational Unified Process

(RUP)
 ¿Qué es RUP?
• Es un proceso de ingeniería de software,
que hace una propuesta orientada por
disciplinas para lograr las tareas y
responsabilidades de una organización que
desarrolla software.
• 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
• Estos participantes se involucran con
RUP cumpliendo roles
¿Por qué usar RUP?
• Porque:
– Provee un entorno de proceso de desarrollo
configurable, basado en estándares
– Permite tener claro y accesible el proceso de
desarrollo que se sigue
– Permite ser configurado a las necesidades de
la organización y del proyecto
– Provee a cada participante con la parte del
proceso que le compete directamente,
filtrando el resto
Características
• Dirigido por Casos de Uso
– Los casos de uso son los artefactos primarios para
establecer el comportamiento deseado del sistema
• Centrado en la Arquitectura
– La arquitectura es utilizada para conceptualizar,
construir, administrar y evolucionar el sistema en
desarrollo
• Iterativo e Incremental
– Maneja una serie de entregas ejecutables
– Integra continuamente la arquitectura para producir
nuevas versiones mejoradas
Características (2)
• Conceptualmente amplio y diverso
• Enfoque orientado a objetos
• En evolución continua
• Adaptable
• Repetible
• Permite mediciones
– Estimación de costos y tiempo, nivel de
avance, etc.
Conceptos
Ciclo de vida
Diagrama General de RUP
En la representación gráfica del Modelo…

• Eje horizontal: representa el tiempo y

muestra los aspectos del ciclo de vida del
proceso. Es el aspecto dinámico del
proceso a través de las fases, iteraciones y
productos intermedios.
• Eje vertical: representa las disciplinas que
agrupan actividades por su naturaleza.
Aspecto estático del proceso a través de
componentes, disciplinas, actividades,
flujos de trabajo, artefactos y roles.
 Ciclo de Vida de RUP

• En cuanto a tiempo el ciclo de vida de RUP

se descompone en 4 FASES secuenciales,
cada cual concluye con un producto
intermedio.
• Al terminar cada fase se realiza una
evaluación para determinar si se ha
cumplido o no con los objetivos de la
misma.
• Las fases son: Inicio (Inception),
Elaboración, Construcción y Transición.
 Fases de Ciclo de Vida

Inicio Elaboración Construcción Transición

Esfuerzo 5% 20% 65% 10%

Tiempo 10% 30% 50% 10%

 Inicio (Inception)

• El objetivo general de esta fase es establecer

un acuerdo entre todos los interesados
acerca de los objetivos del proyecto.
• Es significativamente importante para el
desarrollo de nuevo software, ya que se
asegura de identificar los riesgos
relacionados con el negocio y
requerimientos.
• Para proyectos de mejora de software
existente, esta fase es más breve y se centra
en asegurar la viabilidad de desarrollar el
proyecto.
 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.
 Construcción
• El objetivo de la fase de construcción es
clarificar los requerimientos faltantes y
completar el desarrollo del sistema basados en
la arquitectura base.
• Vista de cierta forma esta fase es un proceso de
manufactura, en el cual el énfasis se torna hacia
la administración de recursos y control de la
operaciones para optimizar costos, tiempo y
calidad.
 Transición
• Esta fase se enfoca en asegurar que el software
esté disponible para sus usuarios.
• Se puede subdividir en varias iteraciones, además
incluye pruebas del producto para poder hacer el
entregable del mismo, así como realizar ajuste
menores de acuerdo a ajuste menores propuestos
por el usuario.
• En este punto, la retroalimentación de los
usuarios se centra en depurar el producto,
configuraciones, instalación y aspectos sobre
utilización.
 Disciplinas
• Una disciplina es una colección de
actividades relacionadas con un área
de atención dentro de todo el
proyecto.
• El grupo de actividades que se
encuentran dentro de una disciplina
principalmente son una ayuda para
entender el proyecto desde la
perspectiva clásica de cascada.
Disciplinas
• Son un conjunto de actividades
relacionadas con un área especifica
dentro del proyecto.
• Están inspiradas en las etapas de un
proceso de desarrollo en cascada
• Es una secuencia parcialmente ordenada
de actividades que son realizadas para
lograr un resultado particular,
representado en un conjunto de
artefactos.
• Las disciplinas son:
– Modelado de Negocios,
Requerimientos, Análisis y Diseño,
Implementación, Pruebas,
Transición, Configuración y
Administración del Cambio,
Administración de Proyectos y
Ambiente.
Modelado de Negocios

Los propósitos que tiene el Modelo de Negocios son:

• Entender los problemas que la organización desea
solucionar e identificar mejoras potenciales.
• Medir el impacto del cambio organizacional.
• Asegurar que clientes, usuarios finales, desarrolladores
y los otros participantes tengan un entendimiento
compartido del problema.
• Derivar los requerimientos del sistema de software,
necesarios para dar soporte a los objetivos de la
organización.
• Entender como el sistema a ser desarrollado entra
dentro de la organización.
Requerimientos

Esta disciplina tiene el propósito de:

• Establecer y mantener un acuerdo con los clientes y
los otros interesados acerca de que debe hacer el
sistema.
• Proveer a los desarrolladores del sistema de un mejor
entendimiento de los requerimientos del sistema.
• Definir los límites (o delimitar) del sistema.
• Proveer un base para la planeación de los contenidos
técnicos de las iteraciones.
• Proveer una base para la estimación de costo y
tiempo necesarios para desarrollar el sistema.
• Definir una interfaz de usuario para el sistema,
enfocada en las necesidades y objetivos del usuario.
Análisis y Diseño

El propósito del Análisis y Diseño es:

• Transformar los requerimientos a diseños
del sistema.
• Desarrollar una arquitectura robusta para
el sistema.
• Adaptar el diseño para hacerlo
corresponder con el ambiente de
implementación y ajustarla para un
desempeño esperado.
Implementación

El propósito de la implementación es:

• Definir la organización del código, en términos de la
implementación de los subsistemas organizados en
capas.
• Implementar el diseño de elementos en términos de los
elementos (archivos fuente, binarios, ejecutables y
otros)
• Probar los componentes desarrollados como unidades.
• Integrar los resultados individuales en un sistema
ejecutable.

La disciplina de implementación limita su alcance a como

las clases individuales serán probadas. Las pruebas del
sistema son descritas en futuras disciplinas.
Pruebas

Actúa como un proveedor de servicios a las otras

disciplinas en muchos aspectos. Se enfoca
principalmente en la evaluación y aseguramiento de la
calidad del producto, desarrollado a través de las
siguientes prácticas:
• Encontrar fallas de calidad en el software y
documentarlas.
• Recomendar sobre la calidad percibida en el software.
• Validar y probar las suposiciones hechas durante el
diseño y la especificación de requerimientos de forma
concreta.
• Validar que el software trabaja como fue diseñado.
• Validar que los requerimientos son implementados
apropiadamente.
Transición

• Esta disciplina describe las actividades

asociadas con el aseguramiento de la
entrega y disponibilidad del producto de
software hacia el usuario final.
• Existe un énfasis en probar el software en
el sitio de desarrollo, realización de
pruebas beta del sistema antes de su
entrega final al cliente.
Administración y Configuración del
Cambio
• Consiste en controlar los cambios y mantener la
integridad de los productos que incluye el proyecto.
• Incluye:
– Identificar los elementos configurables.
– Restringir los cambios en los elementos configurables.
– Auditar los cambios hechos a estos elementos.
– Definir y mantener las configuraciones de estos elementos.
• Los métodos, procesos y herramientas usadas para
proveer la administración y configuración del cambio
pueden ser consideradas como el sistema de
administración de la configuración.
Administración de Proyectos

El propósito de la Administración de
Proyectos es:
• Proveer un marco de trabajo para
administrar los proyectos intensivos de
software.
• Proveer guías prácticas para la planeación,
soporte, ejecución y monitoreo de
proyectos.
• Proveer un marco de trabajo para la
administración del riesgo.
Ambiente

• Se enfoca en las actividades necesarias

para configurar el proceso al proyecto.
• Describe las actividades requeridas para
desarrollar las líneas guías de apoyo al
proyecto.
• El propósito de las actividades de
ambiente es proveer a las organizaciones
de desarrollo de software del ambiente
necesario (herramientas y procesos) que
den soporte al equipo de desarrollo.
Disciplinas
• Workflow
– Detalles del
workflow
• Actividades
• Artefactos
• Guías de
aplicación
Roles
• Definen el comportamiento y
responsabilidades de individuos o grupos
de individuos
– Un individuo puede jugar más de un rol
• Son descripciones abstractas de
– Conjuntos de actividades realizadas
– Responsabilidad sobre artefactos
• Ejemplos de roles
– Software Architect
– Architecture Reviewer
Actividades
• Una actividad es algo que un rol hace y
que provee un resultado de interés en el
contexto del proyecto.
• Es una unidad de trabajo que individuos
jugando cierto rol pueden ser llamados a
realizar.
• Son utilizadas para detallar los workflows.
• Toman artefactos como entrada y
producen artefactos (o nuevas versiones)
como salida.
Artefactos
Unidades de
información
creadas,
producidas,
cambiadas o
utilizadas en el
proceso de
desarrollo.
 ¿Cuándo usar RUP?
Alta complejidad técnica
- embebidos, tiempo real, distribuidos, tolerancia a fallas
- alta performance
- personalizado, sin precedentes, re-ingeniería arquitectónica

Mayor necesidad de seguir

un proceso definido

Baja complejidad gerencial Alta complejidad gerencial

- pequeña escala - gran escala
- informal - contractual
- pocos stakeholders - muchos stakeholders

Baja complejidad técnica

- 4GL, basado en componentes
- re-ingeniería de aplicaciones
¿Cuándo usar RUP? (2)
• RUP puede utilizarse
– En proyectos de nuevos productos de
software
– En ciclos de desarrollo subsecuentes
• Consideraciones que alteran cuándo y
cómo usar partes de RUP
– El ciclo de vida del proyecto
– Los objetivos del negocio, la visión, el
alcance y los riesgos
– El tamaño del esfuerzo de desarrollo
Conclusiones
• Es un modelo de proceso de desarrollo
de software
– Es una base para procesos particulares
• El objetivo es asegurar el desarrollo
– De productos de software de alta
calidad
– Que satisfagan los requerimientos
– En tiempo y presupuesto predecible
• Permite un vocabulario común entre
equipos de desarrollo