El documento presenta una introducción al Rational Unified Process (RUP). RUP es un marco de trabajo genérico para el desarrollo de software centrado en casos de uso, iterativo e incremental, y dirigido por la arquitectura. El documento describe las características estáticas y dinámicas de RUP, incluyendo roles, actividades, artefactos, disciplinas, fases e iteraciones. También explica los diferentes diagramas de UML utilizados en RUP para modelar requisitos, análisis, diseño e implementación.

1. Rational Unified Process Oswaldo E. Eusebio Rojas Universidad Garcilaso de la Vega

7. Rational Unified Process “ RUP es un marco de trabajo genérico que puede especializarse para una variedad de tipos de sistemas, diferentes áreas de aplicación, tipos de organizaciones y diferentes tamaños de proyectos”. JACOBSON, Ivar; BOOCH, Grady y RUMBAUGH, James 2000 El proceso unificado de desarrollo de software , Addison Wesley

8. Noción de Proceso Rol que puede ser desempeñado por un individuo o conjunto de individuos en la organización de desarrollo Trabajador/Quién? Diseñador Actividad/Cómo? Describe una unidad de trabajo que puede ser asignada a un trabajador. Pieza de información que es producida, modificada, ó utilizada por un proceso Artefacto/Qué? responsable de Diseño de Casos de uso Paquete de Caso de Uso Caso de Uso

10. Evolución de RUP

12. El Ciclo de Vida del Software en RUP

13. El Ciclo de Vida del Software en RUP

14. El Ciclo de Vida del Software en RUP

15. El Ciclo de Vida del Software en RUP

16. Relación entre Diagramas UML y Disciplinas de RUP Disciplina Diagrama Requerimientos Diagramas de Casos de Uso Análisis Refinamiento y documentación de los casos de usos Definición preliminar de clases y Diagramas de Interacción (Secuencia y Colaboraciones) Diseño Empaquetamiento Diagramas de Interacción de diseñ o (Secuencia y Colaboraciones) Diagrama de Clases de diseñ o Modelo de Datos Implementación Diagrama de Componentes Diagrama de Despliegue

22. RUP Visión Dinámica Administración Ambiente Modelación de Negocios Implementación Prueba Análisis y Diseño Iteración(es) Preliminar Iter. #1 Fases Disciplinas de Procesos Iteraciones Disciplinas de Soporte Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Despliegue Admin. Configuración Requerimientos Elaboración Transición Inicio Construcción Estática Dinámica

23. Conformaci ón del Equipo ROLES TAREAS ASIGNADAS Gestor del proyecto Establecer Condiciones de Trabajo Analista del sistema Encontrar Actores y Casos de Uso Estructurar el Modelo de Casos de Uso Arquitecto del sistema Priorizar los Casos de Uso Efectuar el An álisis Arquitectural Efectuar el Diseño Arquitectural Efectuar la Implementación Arquitectural Especificador de casos de uso Detallar un Caso de Uso Dise ñador de interfaz de usuario Prototipar una Interfaz de Usuario Ingeniero de casos de uso Analizar un Caso de Uso Dise ñar un Caso de Uso

24. Conformaci ón del Equipo ROLES TAREAS ASIGNADAS Ingeniero de componentes Analizar una Clase Analizar un Paquete Dise ñar una Clase Diseñar un Subsistema Implementar un Subsistema Implementar una Clase Realizar una Prueba de Unidad Implementar una Prueba Integrador del sistema Integrar el Sistema Ingeniero de pruebas Planear las Pruebas Dise ñar las Pruebas Evaluar las Pruebas Verificador de integraci ón Realizar una Prueba de Integraci ón Verificador del sistema Realizar las Pruebas del Sistema

25. Características de RUP Dirigido por los Casos de Uso Centrado en la Arquitectura Iterativo e Incremental

27. Dependencia entre los Casos de Uso y los demás modelos Modelo de análisis Modelo de diseño Modelo de despliegue Modelo de implementación Modelo de prueba Especificado por Realizado por Distribuido por Implementado por Verificado por X OX X OX X OX

29. Desarrollo “en cascada” tradicional retarda la reducción del Riesgo R I E S G O T I E M P O Test Subs. Test. Sistema Cod. & Test U. Diseño An. Requer.

33. Diagramas de Casos de Uso casos de uso

35. Diagramas de Casos de Uso incluye caso de uso actor extiende Límite

36. Diagramas de Clases

38. Diagramas de Clases Cliente Bebida Barmen Pedido Venta - valor: Doble + ImprimirBoleta() Bodega Jugo Natural Gaseosa 1 1..* 1 realiza 0..* 1 tiene 1..* 1 almacena 0..* asociación multiplicidad atributo operación herencia clase

39. Diagramas de Secuencia

41. Diagramas de Secuencia mensaje objeto línea de vida {x N} Pepe :Barmen Interfaz Barmen (from Use Case View) Motor Venta (from Use Case View) BD de Ventas (from Use Case View) Frambuesa :Jugo Natural (from Logical Model) 12345 :Venta (from Logical Model) Ingresar Datos Venta Confirmar Venta Ejecutar Venta Crear Venta Crear Bebida Ingresar Venta destrucción de objeto creación de objeto ciclos

42. Diagramas de Colaboraci ó n

44. Diagramas de Colaboraci ó n Pepe : Barmen Bucarest :Sistema de Bodega Interfaz Barmen Comunicador Bodega Motor Venta Interfaz Bodega El cálculo dió la cantidad bajo la mínima permitida - hay que pedir bebida de la bodega 1 Vender Jugo Natural 1.1 Vender Jugo Natural 1.2 Calcular Cantidad Bebida 1.3 Pedir Bebida 1.4 Pedir Bebida 1.5 Pedir Bebida enlace objeto mensaje

45. Diagramas de Actividades

47. Diagramas de Actividades actividad decisión sincronización

48. Diagrama de Estados

50. Diagrama de Estados Inicio a Pedidos Cobrados INGRESADO SERVIDO COBRADO PERDIDO CANCELADO a Pedidos Anulados A Pedidos Perdidos Si el estado no se cámbia durante 1 día servir cancelar 1 día cobrar estado transición inicio fin

51. Diagrama de Componentes

53. Diagrama de Componentes dependencia componente interfaz

54. Diagrama de Distribuci ón

56. Diagrama de Distribución nodo enlace

57. Modelos y Flujos de Trabajo

58. Seis Mejores Prácticas

59. Seis “Mejores Prácticas” Controlar Cambios Administrar requerimientos Arquitecturas Basadas en Componentes Desarrollar Iterativamente Verificar Calidad Modelizar Visualmente

63. Administración de requerimientos Req. 10 Aprobado Bajo Alta Req. 13 Propuesto Medio Baja Req. 40 Obligatorio Alto Alto $$$ $$ $ Costo Esfuerzo Riesgo Status Prioridad    

65. Arquitecturas basadas en componentes Database CRM Funciones de cliente/ productos Mecanismos de interfaces Cliente Producto Comprado Existente Nuevo Funciones de licenciamiento Licencia

71. Control de cambios Administración de configuración y cambios Fallas reportadas Órdenes de Trabajo Petición de nuevas características Petición de cambios y arreglo de defectos Administración de configuración Calidad del producto

72. Disciplinas y Flujos de Trabajo

76. Disciplinas y Flujos de Trabajo Disciplinas de Proceso Disciplinas de Soporte

78. Modelamiento de Negocio – Flujo de Trabajo

80. Requerimientos – Flujo de Trabajo

82. Análisis y Diseño – Flujo de Trabajo

84. Implementaci ón – Flujo de Trabajo

86. Test – Flujo de Trabajo

88. Despliegue – Flujo de Trabajo

90. Administración y Configuración de Cambios – Flujo de Trabajo

92. Administración del Proyecto – Flujo de Trabajo

94. Entorno

96. Requerimientos - Workflow Analista Arquitecto Especificador de Casos de uso Diseñ ador de interface

97. Requerimientos Trabajador Responsable de (artefacto) Analista de sistemas Modelo de casos de uso Actores Glosario Especificador de casos de uso Caso de uso Dise ñador de Interfaz de Usuario Prototipo de interfaz de usuario Arquitecto Descripci ón de la arquitectura (vista del modelo de casos de uso)

99. An álisis - Workflow Arquitecto Ing de Casos de Uso Ing de Componentes

100. An álisis Trabajador Responsable de (artefacto) Arquitecto Modelo de An álisis Descripci ón de la arquitectura Ingeniero de Casos de Uso Realizaci ón de casos de usos - Análisis - Ingeniero de Componentes Clases del An álisis Paquete del an álisis

102. Dise ñ o Modelo de An álisis Modelo de Dise ño Modelo conceptual. Modelo f ísico (implementación) Gen érico respecto al diseño (aplicable a varios diseños) Espec ífico para una implementación Tres estereotipos: entidad, control, interface. Cualquier nro. de estereotipos f ísicos. Menos formal. Mas formal. Menos caro de desarrollar M ás caro.

103. Dise ñ o Modelo de An álisis Modelo de Dise ño Menos capas. M ás capas. Din ámico (no muy centrado en la secuencia) Din ámico (muy centrado en la secuencia) Creado principalmente como trabajo manual Creado fundamentalmente como "programaci ón visual" en ing.de ida y vuelta. Puede no mantenerse todo el ciclo de vida. Debe ser mantenido todo el ciclo de vida.

104. Dise ñ o - Workflow Arquitecto Ing de Casos de Uso Ing de Componentes

105. Dise ñ o Trabajador Responsable de (artefacto) Arquitecto Modelo de dise ño Modelo de despliegue Descripci ón de la arquitectura Ingeniero de Casos de Uso Realizaci ón de casos de usos - Diseño - Ingeniero de Componentes Clases del dise ño Subsistema de Dise ño Interfaz

107. Implementación Trabajador Responsable de (artefacto) Arquitecto Modelo de implementaci ón Modelo de despliegue Descripci ón de la arquitectura Integrador de sistema Integraci ón de sistema Ingeniero de Componentes Componente Implementaci ón de subsistema Interfaz

108. Implementación - Workflow Arquitecto Integrador del Sistema Ingeniero de Componentes

110. Prueba Trabajador Responsable de (artefacto) Dise ñador de Pruebas Modelo de pruebas Casos de Prueba Procedimientos de prueba Evaluaci ón de pruebas Plan de pruebas Ingeniero de Componentes Componente de pruebas Ingeniero de Pruebas de Integraci ón Defecto Ingeniero de Pruebas de Sistema Defecto

111. Fases

127. RUP y CMMI

130. CMMI – Niveles de Madurez NIVEL Descripción 1-Inicial Punto base. La organización tiene procesos ad-hoc o caóticos. El éxito se debe a personas heroícas. 2-Repetible La organización empieza a guardar información. Ya hay definiciones, pueden repetirse éxitos anteriores. 3-Definido Se conocen procesos estándares para desarrollar o mantener software. Hay prácticas de Ingeniería de Software y de Administración de procesos. 4-Administrado Se usan datos recolectados. Las decisiones están basadas en datos cuantitativos. Los procesos son medidos, hay retroalimentación. 5-Optimizado La organización se dedica a mejorar contínuamente. Se localizan debilidades y fortalezas.

131. CMMI Areas Clave de Proceso (KPAs) NIVEL Áreas Clave de Proceso 1-Inicial 2-Repetible Gestión de Requisitos (REQM) , Planificación de proyecto, Monitorización y control de Proyectos, Gestión y acuerdo de suministros, Medición y Análisis, Gestión de la calidad de procesos y productos, Gestión de la configuración 3-Definido Desarrollo de requisitos (RD) , Solución técnica, Verificación, Validación, Integración de producto, Procesos orientados a la organización, Formación, Gestión Integrada de proyecto, Gestión de riesgos, Análisis y resolución de decisiones 4-Administrado Gestión cuantificada de proyectos, Rendimiento de los procesos de la organización 5-Optimizado Innovación y desarrollo

133. Análisis RUP – CMMI Áreas Clave de Proceso Revisi ón Gestión de Requisitos RUP define claramente el proceso de administración de requerimientos y aporta herramientas como los casos de uso, es una de las bases de RUP Planificación de proyecto RUP habla de la planeación del proyecto de manera iterativa y del control de riesgos. Monitorización y control de Proyectos RUP define cómo debe ser el control del proyecto. Gestión de la configuración RUP es muy claro cuando se habla de administración de la configuración incluso es una de las mejores prácticas recomendada.

134. Análisis RUP – CMMI Áreas Clave de Proceso Revisi ón Gestión y acuerdo de suministros RUP no menciona nada sobre administración de acuerdos, es algo no considerado. Medición y Análisis La medición y análisis no están contemplados detalladamente en RUP. Gestión de la calidad de procesos y productos En la etapa de transición se lleva a cabo la verificación de la calidad aunque no tan detallada como lo exige CMMI. La verificación de calidad del producto está bien definida pero la evaluación de calidad del proceso no está considerada.

135. Conclusiones