Este documento describe el Proceso Racional Unificado (RUP), incluyendo sus fases, roles y proceso iterativo e incremental. RUP es un proceso disciplinado de desarrollo de software centrado en casos de uso, arquitectura y iteraciones. Se compone de fases de inicio, elaboración, construcción y transición. Cada fase termina con un hito y contiene múltiples iteraciones para desarrollar incrementos del sistema de manera evolutiva.

1. INGENIERÍA DE
SOFTWARE I
PROCESO RACIONAL UNIFICADO (RUP)

2. ¿QUÉ ES EL RUP?
• RUP es un proceso de desarrollo de software:
• Forma disciplinada de asignar tareas y
responsabilidades en una empresa de desarrollo
(quién hace qué, cuándo y cómo).
• Objetivos:
• Asegurar la producción de software de calidad
dentro de plazos y presupuestos predecibles.
Dirigido por casos de uso, centrado en la
arquitectura, iterativo (mini-proyectos) e incremental
(versiones).

3. BENEFICIOS DEL RUP
• Aumenta la productividad de los desarrolladores
mediante acceso a:
• Base de conocimiento, plantillas y herramientas.
• Se centra en la producción y mantenimiento de
modelos del sistema más que en producir
documentos.
• RUP es una guía de cómo usar UML de la forma más
efectiva.

4. FASES Y FLUJOS DE TRABAJO

5. FASE DE INICIO
• Su objetivo
• Lo que deberá hacer el producto
• Reducción de los peores riesgos
• Preparación para el análisis del negocio inicial

6. FASE DE INICIO
• Un documento de visión general:
• Requerimientos generales del proyecto
• Características principales
• Restricciones
• Caso de negocio:
• Contexto
• Criterios de éxito
• Pronóstico financiero
• Identificación inicial de riesgos.
• Plan de proyecto.
• Uno o más prototipos.

7. FASE DE INICIO
• Modelo inicial de casos de uso (10% a 20 % listos).
• Glosario.

8. FASE DE ELABORACIÓN
• Objetivos:
• Obtener la línea base de la arquitectura
• Capturar la mayoría de los requisitos
• Reducir los peores riesgos
• Estimar costos y fechas
• Planificar la fase de construcción con algún detalle

9. FASE DE ELABORACIÓN
• Modelo de casos de uso (80% completo) con descripciones
detalladas.
• Otros requerimientos no funcionales o no asociados a casos
de uso.
• Descripción de la Arquitectura del Software.
• Un prototipo ejecutable de la arquitectura.
• Lista revisada de riesgos y del caso de negocio.
• Plan de desarrollo para el resto del proyecto.
• Un manual de usuario preliminar.

10. FASE DE CONSTRUCCIÓN
• Objetivos:
• El desarrollo del sistema
• Garantía de que el producto puede comenzar su transición a
los clientes

11. FASE DE CONSTRUCCIÓN
• El producto de software integrado y corriendo en la
plataforma adecuada.
• Manuales de usuario.
• Una descripción del “release” actual.

12. FASE DE TRANSICIÓN
• Objetivos:
• Garantizar que se tiene el producto preparado para su entrega
(versión del producto)
• Entrenar a los usuarios a utilizar el sistema.

13. FASE DE TRANSICIÓN
• Pruebas Beta para validar el producto con las
expectativas del cliente
• Ejecución paralela con sistemas antiguos
• Conversión de datos
• Entrenamiento de usuarios
• Distribuir el producto

14. FASES E HITOS (MILESTONES)
tiempo
Objetivos
(Visión)
Arquitectura Capacidad
Operacional
Inicial
Release
del Producto
Inicio Elaboración Construción Transición
Hito: Punto de terminación de la
iteración cuando se toma alguna
decisión o evaluación importante

15. PROCESO DE INGENIERÍA DE
SOFTWARE WORKFLOWS
(DISCIPLINAS)

16. PROCESO DE INGENIERÍA DE
SOFTWARE WORKFLOWS
(DISCIPLINAS)
Workflows Primarios
• Business Modeling (Modado del Negocio)
• Requirements (Requisitos)
• Analysis & Design (Análisis y Diseño)
• Implementation (Implementación)
• Test (Pruebas)
• Deployment (Despliegue)
Workflows de Apoyo
• Environment (Entorno)
• Project Management (Gestión del Proyecto)
• Configuration & Change Management (Gestión de
Configuración y Cambios)

17. ARTEFACTOS
 Resultado parcial o final que es producido y usado
durante el proyecto. Son las entradas y salidas de
las actividades
 Un artefacto puede ser un documento, un modelo
o un elemento de modelo
 Conjuntos de Artefactos
 Deployment Set
 Project Management Set
 Configuration & Change Management Set
 Environment Set
 Business Modeling Set
 Requirements Set
 Analysis & Design Set
 Implementation Set
 Test Set

18. PROCESO ITERATIVO E
INCREMENTAL
 El ciclo de vida iterativo se basa en la evolución de
prototipos ejecutables que se muestran a los usuarios
y clientes (mini-proyectos)
 En el ciclo de vida iterativo a cada iteración se
reproduce el ciclo de vida en cascada a menor escala
 Los objetivos de una iteración se establecen en
función de la evaluación de las iteraciones
precedentes

19. PROCESO ITERATIVO E
INCREMENTAL
 Las actividades se encadenan en una mini-cascada
con un alcance limitado por los objetivos de la
iteración
Análisis
Diseño
Imple.
Pruebas e
Integración
n veces
Req.

20. PROCESO ITERATIVO E INCREMENTAL
 Cada iteración comprende:
• Planificar la iteración (estudio de riesgos)
• Análisis de los Casos de Uso y escenarios
• Diseño de opciones arquitectónicas
• Codificación y pruebas. La integración del nuevo
código con el existente de iteraciones anteriores se
hace gradualmente durante la construcción
• Evaluación de la entrega ejecutable (evaluación del
prototipo en función de las pruebas y de los
criterios definidos)
• Preparación de la entrega (documentación e
instalación del prototipo)

21. LAS ITERACIONES SOBRE EL CICLO
DE VIDA
• Cada una de las cuatro fases termina con hito
principal.

22. PLAN DE ITERACIONES
• El número de iteraciones planeado para cada fase
depende, básicamente de la complejidad del sistema
propuesto. Un proyecto simple puede realizarse con
una sola iteración por fase. Un proyecto mas complejo
podría comprender el siguiente numero de
iteraciones.

23. PLAN DE ITERACIONES
• Fase de Inicio: una iteración, principalmente dedicada
a definir el ámbito del sistema
• Fase de elaboración: dos iteraciones, la primera para
esbozar la arquitectura y la segunda para completar la
línea base de la arquitectura

24. PLAN DE ITERACIONES
• Fase de construcción: dos iteraciones, para asegurar
que los incrementos resultantes funcionan
satisfactoriamente
• Fase de transición: una iteración

25. PROCESO ITERATIVO E INCREMENTAL
Enfoque
Secuencial
Enfoque
Iterativo e
Incremental

26. ITERACIONES
• Cada fase consiste en las iteraciones del
desarrollo en las cuales un subconjunto del
sistema se desarrolla. En general, estas
iteraciones:
• Reducen los riesgos técnicos;
• Proporcionan versiones tempranas;
• Permiten mayor flexibilidad para el lanzamiento de
cada característica; y
• Permiten controlar los cambios con respecto al
alcance de manera efectiva con las iteraciones
durante los ciclos.

27. PROCESO CENTRADO EN LA
ARQUITECTURA
• Arquitectura de un sistema es la organización o
estructura de sus partes más relevantes
• Un arquitectura ejecutable es una implementación
parcial del sistema, construida para demostrar algunas
funciones y propiedades
• RUP establece refinamientos sucesivos de una
arquitectura ejecutable, construida como un prototipo
evolutivo
Architecture
Inception Elaboration Construction Transition

28. FASES, BASE LINE, VERSIÓN, RELEASE
ciclo de desarrollo ciclo de evolución
release
(producto al final de
una iteración, lanzado
para su puesta en producción)
versión
(subconjunto de
artefactos
estable
y ejecutable)
base line
(release asociada
a un hito)

29. BASE LINE
• Conjunto de artefactos revisados y aprobados que
constituyen una base convenida para la evolución y
desarrollo adicional y que se puede cambiar
solamente a través de la administración de cambios.
• Asegurarse qué subsistemas, cuándo alcanzan un nivel
especifico de la madurez, son la línea base para que
esté disponible para el release (“liberación), o la
reutilización en iteraciones subsecuentes del proyecto
y/o otros proyectos.

30. BASE LINE
• Se considera como candidato para una Línea Base el
conjunto de archivos y directorios bajo control de
versión que son desarrollados, integrados y puestos
juntos en un release.
• Una línea base se crea al final de cada iteración

31. VERSIONES
• Identifican el estado de un elemento de configuración
o una configuración en un punto definido en el
tiempo
• Conjunto de artefactos relativamente completo y
consistente –que incluye posiblemente una
construcción- entregado a un usuario interno o
externo;

32. VERSIONES
• La mayoría de los programas grandes se
desarrollan en release evolutivos. Un release
podría estar en uso del cliente, mientras que otro
está en prueba, y el tercero todavía está en el
desarrollo. Si se encuentran problemas en
cualquiera de las versiones, los arreglos necesitan
ser propagados entre ellas. La confusión puede
acrecentarse conduciendo a arreglos costosos y
retrabajo a menos de que los cambios sean
cuidadosamente controlados y supervisados.

33. RELEASE
• Es una versión que se ha puesto disponible a los
usuarios.
La frecuencia y la formalidad de los releases son
descritos en el plan del CM (Configuration
Management ). El grado de la formalidad es
claramente mucho más alto para un producto que es
liberado a un cliente, que el que es generado para la
estructura o la revisión siguiente de la iteración.

34. RELEASE
• Regularmente está asociado a un baseline de una
configuración

35. ESFUERZO Y DEDICACIÓN POR FASES EN
RUP
Inicio Elaboración Construcción Transición
Esfuerzo 5 % 20 % 65 % 10%
Tiempo
Dedicado
10 % 30 % 50 % 10%

36. DISTRIBUCIÓN DE RECURSOS POR FASES EN
RUP

37. ROLES: ANALISTA DE SISTEMAS
El papel del analista de sistemas conduce y coordina la captura de requisitos y el
modelado de casos de uso que definiendo la funcionalidad del sistema y delimitando
el sistema.

38. ROLES: DISEÑADOR
• El diseñador define las responsabilidades, operaciones,
atributos y relaciones entre las clases y determina
cómo éstas deben ajustarse a el ambiente de
implantación. Además el diseñador puede tener la
responsabilidad de uno o más paquetes de diseño o
diseño de susbsistemas.

39. ROLES: DISEÑADOR DE PRUEBAS
• El Diseñador de pruebas es el responsable de definir los métodos
de prueba y asegurarse del éxito de su implementación. Debe
identificar las técnicas apropiadas, herramientas y guías para
implementar las pruebas requeridas, y brindar dirección en los
requisitos correspondientes al esfuerzo de las pruebas.

40. ROLES: PROGRAMADOR
(IMPLEMENTADOR)
• El programador es responsable de desarrollar y probar
los componentes, de acuerdo a los estándares
adoptados para el proyecto, y la integración de los
subsistemas.

41. ROLES: INTEGRADOR
• Los desarrolladores entregan sus componentes probados en un espacio
de trabajo de la integración, mientras que los integradores los
combinan para producir una estructura. Un integrador es también
responsable de planear la integración, que ocurre en los niveles del
subsistema y de sistema, con cada uno teniendo un espacio de trabajo
separado de la integración. Los componentes probados se entregan del
espacio de trabajo privado del desarrollo de un ejecutor en un espacio
de trabajo de la integración del subsistema,

42. ROLES: ADMINISTRADOR DE
PROYECTO
• El Administrador de Proyecto asigna recursos, asigna
prioridades, coordina interacciones con los clientes y
usuarios, y generalmente mantiene al equipo de
proyecto centrado en la meta. Además establece un
conjunto de prácticas que aseguran la integridad y
calidad de los artefactos del proyecto.

43. ROLES: ADMINISTRADOR DE
PROYECTO

44. ROLES: ADMINISTRADOR DE LA
CONFIGURACIÓN
• El Administrador de la Configuración proporciona toda la
infraestructura y el ambiente la administración de la
configuración (CM) al equipo del desarrollo de producto.
La función del CM apoya la actividad del desarrollo de
producto de modo que los desarrolladores y los
integradores tengan espacios de trabajo apropiados para
construir y para probar su trabajo, y de modo que todos
los artefactos estén disponibles para la inclusión en la
unidad del despliegue según lo requerido. El encargado
de la configuración también tiene que asegurarse de que
el ambiente del CM facilite la revisión del producto, y las
actividades que siguen del cambio y del defecto. El
encargado de la configuración es también responsable
de escribir el plan del CM y de dar a conocer la
estadística del progreso basada en peticiones del cambio.

45. ROLES: ADMINISTRADOR DE LA
CONFIGURACIÓN

46. REFERENCIAS
• El Proceso Unificado de Desarrollo de
Software, Ivar Jacobson, Grady Booch, James
Rumbaugh
• RUP 2001
• UML y Patrones, Craig Larman