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
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
17.
18.
19.
20.
21.
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
26.
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
28.
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.
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
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
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
59. Seis “Mejores Prácticas” Controlar Cambios Administrar requerimientos Arquitecturas Basadas en Componentes Desarrollar Iterativamente Verificar Calidad Modelizar Visualmente
60.
61.
62.
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
64.
65. Arquitecturas basadas en componentes Database CRM Funciones de cliente/ productos Mecanismos de interfaces Cliente Producto Comprado Existente Nuevo Funciones de licenciamiento Licencia
66.
67.
68.
69.
70.
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
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)
98.
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
101.
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
106.
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
109.
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
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
132.
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.