2. ¿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 deasegurar la producción de
software de alta calidadsoftware de alta calidad que cumpla con las
necesidades de los usuarios, con una planeación y
presupuesto predecible.

3. ¿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

4. ¿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

5. 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

6. 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.

7. Conceptos

8. Ciclo de vida

9. Diagrama General de RUPDiagrama General de RUP

10. 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ámicoaspecto 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áticoAspecto estático
del proceso a través de componentes, disciplinas,
actividades, flujos de trabajo, artefactos y roles.

11. 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.

12. Fases de Ciclo de VidaFases de Ciclo de Vida
Inicio Elaboración Construcción Transición
Esfuerzo 5% 20% 65% 10%
Tiempo 10% 30% 50% 10%

13. Inicio (Inception)Inicio (Inception)
El objetivo general de esta fase es establecer unestablecer un
acuerdo entre todos los interesados acerca de losacuerdo entre todos los interesados acerca de los
objetivos del proyectoobjetivos del proyecto.
Es significativamente importante para el desarrollo de
nuevo software, ya que se asegura de identificar losse asegura de identificar los
riesgos relacionados con el negocio yriesgos relacionados con el negocio y
requerimientosrequerimientos.
Para proyectos de mejora de software existente, esta
fase es más breve y se centra en asegurar la viabilidad
de desarrollar el proyecto.

14. ElaboraciónElaboración
El objetivo en esta fase es establecer laestablecer la
arquitectura base del sistemaarquitectura 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.

15. ConstrucciónConstrucción
El objetivo de la fase de construcción es clarificar losclarificar los
requerimientos faltantes y completar el desarrollo delrequerimientos faltantes y completar el desarrollo del
sistemasistema 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.

16. TransiciónTransición
Esta fase se enfoca en asegurar que el software estéasegurar que el software esté
disponible para sus usuariosdisponible 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.

17. DisciplinasDisciplinas
Una disciplina es una colección dees una colección de
actividades relacionadas con un áreaactividades relacionadas con un área
de atención dentro de todo elde atención dentro de todo el
proyecto.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.

18. 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.

19. DISCIPLINAS
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.

20. Modelado de NegociosModelado 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.

21. RequerimientosRequerimientos
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.

22. Análisis y DiseñoAná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.

23. ImplementaciónImplementació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.

24. PruebasPruebas
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.

25. TransiciónTransició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.

26. Administración y Configuración del CambioAdministració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.

27. Administración de ProyectosAdministració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.

28. AmbienteAmbiente
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.

29. Disciplinas
 Workflow
 Detalles del
workflow
 Actividades
 Artefactos
 Guías de
aplicación

30. 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

31. 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.

32. Artefactos
Unidades de
información
creadas,
producidas,
cambiadas o
utilizadas en el
proceso de
desarrollo.

33. ¿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
Baja complejidad técnica
- 4GL, basado en componentes
- re-ingeniería de aplicaciones
Alta complejidad gerencial
- gran escala
- contractual
- muchos stakeholders
Baja complejidad gerencial
- pequeña escala
- informal
- pocos stakeholders
Mayor necesidad de seguir
un proceso definido

34. ¿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

35. 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