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

2. Temario Introducción Concepto Vista Dinámica y Estática Características de RUP Las seis mejores prácticas Disciplinas y Flujos de Trabajo Fases RUP y CMMI Conclusiones

3. ¿Qué es un Proceso de Desarrollo de SW? Requisitos nuevos o modificados Sistema nuevo o modificado Proceso de Desarrollo de Software Define Quién debe hacer Qué , Cuándo y Cómo debe hacerlo No existe un proceso de software universal. Las características de cada proyecto (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable

4. El Problema Si un proceso es utilizado, equipos funcionales diferentes normalmente utilizan procesos y lenguajes de modelación inconsistentes. Requerimientos Pruebas Análisis Diseño La mayoría de los proyectos de software utilizan procesos que no están bien definidos. En su lugar los miembros del equipo (re)inventan sus propios procesos. ? ? ? ? ? ? ? Los procesos no están apropiadamente relacionados con herramientas, ó no están propiamente automatizados. ? Proceso Herramienta

5. Conceptos fundamentales Proceso : Es un marco de trabajo común compuesto por actividades de trabajo (conjuntos de tareas, hitos, productos y puntos de garantía de calidad) y actividades de protección (garantía de calidad, gestión de configuración y medición) (Pressman 2001). Producto: Es el resultado previsto y consistente del proceso.

6. Conceptos fundamentales Ciclo de vida del software : Es el conjunto de fases por las que pasa el software, que abarcan desde su creación u origen, hasta su eliminación o liquidación formal. Modelo de desarrollo: También denominado Modelo de Proceso . Estrategia de desarrollo basada en el ciclo de vida, naturaleza del proyecto y metodología, que determina las características específicas del proceso (Pressman 2001).

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

9. Rational Unified Process Creado por los 3 amigos: Grandy Booch (creador de “The Booch Method”), Ivar Jacobson e James Rumbag (creador de “Object Modeling Technique” = OMT) Aparece por primera vez en Junio de 1998 con el nombre de Rational Unified Process 5.0 (RUP) Fue puesto a disposición pública entre finales de 1998 e inicios de 1999. Centrado en tres Puntos: Personas Procesos Herramientas y métodos

10. Evolución de RUP

11. Estructura de RUP El proceso puede describirse en dos dimensiones, o a lo largo de dos ejes: El eje horizontal representa tiempo y muestra el aspecto dinámico del proceso, expresado en términos de ciclos , fases , iteraciones , y metas . El eje vertical representa el aspecto estático del proceso; como está descrito en términos de disciplinas: actividades , artefactos , trabajadores y flujos de trabajo .

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

17. RUP Visión Estática En su visión estática, el modelo RUP está compuesto por: Roles : analista de sistemas, diseñador, diseñador de pruebas, roles de gestión y roles de administración. Actividades : RUP determina el trabajo de cada rol a través de actividades. Cada actividad del proyecto debe tener un propósito claro, y se asigna a un rol específico. Las actividades pueden tener duración de horas o de algunos días; y son elementos base de planificación y progreso.

18. RUP Visión Estática En su visión estática, el modelo RUP está compuesto por: Artefactos : Son los elementos de entrada y salida de las actividades. Son productos tangibles del proyecto. Las cosas que el proyecto produce o usa para componer el producto final (modelos, documentos, código, ejecutables…) Flujos de trabajo : son el “pegamento”de los roles, actividades, artefactos y disciplinas, y constituyen la secuencia de actividades que producen resultados visibles.

19. RUP Visión Estática En su visión estática, el modelo RUP está compuesto por: Disciplinas : son “contenedores” empleados para organizar las actividades del proceso. RUP comprende 6 disciplinas de proceso y 3 de soporte. Proceso : modelado del negocio, requisitos, análisis y diseño, implementación, pruebas y desarrollo. Soporte : gestión de proyecto, gestión de configuración y cambio, y entorno.

20. RUP Visión Dinámica En su visión dinámica, la visión de la estructura del ciclo de vida RUP se basa en un desarrollo iterativo, jalonado por hitos para revisar el avance y planear la continuidad o los posibles cambios de rumbo. Cuatro son las fases que dividen el ciclo de vida de un proyecto RUP: 1.- Inicio . Es la fase de la idea, de la visión inicial de producto, su alcance. El esbozo de una arquitectura posible y las primeras estimaciones. Concluye con el “hito de objetivo”. 2.- Elaboración . Comprende la planificación de las actividades y del equipo necesario. La especificación de las necesidades y el diseño de la arquitectura. Termina con el “hito de Arquitectura”.

21. RUP Visión Dinámica 3.- Construcción . Desarrollo del producto hasta que se encuentra disponible para su entrega a los usuarios. Termina con el “hito del inicio de la capacidad operativa”. 4.- Transición . Traspaso del producto a los usuarios. Incluye: manufactura, envío, formación, asistencia y el mantenimiento hasta lograr la satisfacción de los usuarios. Termina con el “hito de entrega del producto”.

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. Dirigido por Casos de Uso Un caso de uso es un fragmento de funcionalidad del sistema que proporciona un resultado de valor a un usuario. Los casos de uso modelan los requerimientos funcionales del sistema. Los casos de uso también guían el proceso de desarrollo (diseño, implementación y pruebas). De este modo los casos de uso no solo inician el proceso de desarrollo sino que le proporcionan un hilo conductor, que avanza a través de una serie de flujos de trabajo.

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. Iterativo e incremental Es práctico dividir el esfuerzo de desarrollo de un proyecto de software en partes mas pequeñas o mini proyectos. Cada mini proyecto es una iteración que resulta en un incremento. Las iteraciones deben seleccionarse y ejecutarse de forma planificada. Esta selección se basa en dos cosas: El conjunto de casos de uso que amplían funcionalidad En los riesgos mas importantes que deben mitigarse En cada iteración se identifica y especifica los casos de uso relevantes, se crea un diseño utilizando la arquitectura seleccionada como guía, para implementar dicho caso de uso.

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.

30. Aplicando cascada iterativamente Las primeras iteraciones reducen los principales riesgos Cada iteración produce una versión ejecutable, un incremento adicional al sistema Cada iteración incluye integración y test T C D R T I E M P O Iteración 1 Iteración 2 Iteración 3 T C D R T C D R

31. Centrado en la Arquitectura La arquitectura se describe mediante diferentes vistas del sistema en construcción. Incluye aspectos estáticos y dinámicos. La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando de los detalles de lado. La arquitectura debe permitir el desarrollo de todos los casos de uso requeridos actualmente y a futuro, y los casos de uso deben encajar en la arquitectura.

32. 5 Vistas 9 Diagramas Organización de Modelos Vistas de UML: Arquitectura 4 + 1

33. Diagramas de Casos de Uso casos de uso

34. Proporciona c r edibilidad en una etapa inicial del desarrollo del sistema Asegura una comprensión mutua de los requisitos Que se hayan capturado todos los requ erimientos Que los desarrolladores hayan entendido los requ erimientos Usados Para Verificar Usados Para Comunicarse con el Usuario Final y el Experto de Dominio Diagramas de Casos de Uso

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

36. Diagramas de Clases

37. Usados para mostrar la Estructura Estática de un sistema computacional o una parte relevante del mundo real Son los diagramas más frecuentemente usados. Y se les puede considerar con Tres Perspectivas posibles : Conceptual – muestra las entidades del mundo real con sus relaciones Especificación – muestra la estructura del sistema o sus partes, destacando las interfaces Implementación – el dise ño del código fuente 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

40. Usados para representar el comportamiento del sistema Muestran colaboración a través de mensajes entre los objetos del sistema Destacan: Mensajes enviados entre los objetos Orden secuencial entre los mensajes Un escenario concreto, sin condiciones Útiles tanto en análisis (identificación de clases), como en diseño (especificación de componentes) 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

43. Usados para representar el comportamiento del sistema Muestran colaboración entre los objetos del sistema Destacan: Mensajes enviados entre los objetos Enlaces entre los objetos Un escenario concreto, sin condiciones Útiles tanto en análisis (identificación de clases), como en diseño (especificación de componentes) 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

46. Usados para representar el comportamiento del sistema o negocio Muestran actividades y procesos Destacan: Condiciones y flujos alternativos Tareas y procesos concurentes Responsabilidades sobre ciertas actividades Útiles en análisis de negocio para capturar procesos de alto nivel Diagramas de Actividades

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

48. Diagrama de Estados

49. Usados para representar el comportamiento INTERNO de un objeto o de un módulo del sistema Muestran estados en los cuales un objeto se puede encontrar Destacan: Estados Transiciones y condiciones de las transiciones Actividades realizadas Típicamente usados para describir ciclo de vida de un objeto 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

52. Usados para mostrar los Módulos Físicos de software : Los ejecutables y librerías dinámicas Las páginas WEB y los scripts Los módulos o funciones, etc. Sin embargo se usan más bien para capturar la Organización de los Componentes de Software (EXE, DLL, EJB, etc) Destacan Dependencias entre los Componentes Diagrama de Componentes

53. Diagrama de Componentes dependencia componente interfaz

54. Diagrama de Distribuci ón

55. Usados Para Modelar las Relaciones entre el Software y el Hardware Mapeo de los Componentes de Software a los Nodos de Hardware Típicamente contienen elementos tales como Servidores Procesadores Impresoras Redes computacion a l e s Etc. 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

60. El software moderno es complejo y novedoso. No es realista usar un modelo lineal de desarrollo como el de cascada. Un proceso iterativo permite una comprensión creciente de los requerimientos a la vez que se va haciendo crecer el sistema. RUP sigue un modelo iterativo que aborda las tareas más riesgosas primero. Con esto se logra reducir los riesgos del proyecto y tener un subsistema ejecutable tempranamente. Desarrollo Iterativo

61. Desarrollo Iterativo Cada iteración resulta en un release ejecutable Planeamiento Inicial Planeamiento Requerimientos Análisis y Diseño Implementación Prueba Distribución Evaluación Ambiente de Administración

62. RUP describe cómo: Obtener los requerimientos Organizarlos Documentar requerimientos de funcionalidad y restricciones Rastrear y documentar decisiones Captar y comunicar requerimientos del negocio Los casos de uso y los escenarios indicados por el proceso han probado ser una buena forma de captar requerimientos y guiar el diseño, la implementación y las pruebas. Administración de requerimientos

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. Arquitecturas basadas en componentes El proceso se basa en diseñar tempranamente una arquitectura base ejecutable. La arquitectura debe ser: Flexible Fácil de modificar Intuitivamente comprensible Promueve la reutilización de componentes RUP apoya el desarrollo basado en componentes, tanto nuevos como preexistentes.

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

66. Modelamiento Visual Modelamiento visual de la estructura y el comportamiento de la arquitectura y los componentes. Bloques de construcción: Permiten la comunicación en el equipo de desarrollo Permiten analizar la consistencia: entre las componentes entre diseño e implementación UML es la base del modelamiento visual de RUP.

67. Diagramas de Casos de Uso Diagramas de Clases Diagramas de Estados Diagramas de Componentes Diagramas de Implementación Modelización Visual eleva el nivel de abstracción Modelamiento Visual Código Clases Subsistemas

68. Verificación de la Calidad La actividad fundamental de esta práctica es el testing Evaluar continuamente la calidad de un sistema con respecto a funcionalidad, confiabilidad, performance El aseguramiento de la calidad es parte del proceso de desarrollo y no la responsabilidad de un grupo independiente.

69. Plan de actividades de aseguramiento de la calidad Conjunto de actividades que serán ejecutadas para generar confianza en que el producto cumplirá con los requerimientos y el proceso es efectivo Verificación de la Calidad Cliente Necesidades Requisitos Revisiones Verificaciones Validaciones Producto

70. Los cambios son inevitables, pero es necesario evaluar si éstos son necesarios y rastrear su impacto. RUP indica como controlar, rastrear y monitorear los cambios dentro del proceso iterativo de desarrollo. Las solicitudes de cambios formales facilitan la claridad de comunicación La propagación del cambio es evaluable y controlable Controlar, registrar y monitorear los cambios para posibilitar el desarrollo iterativo Control de cambios

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

73. Disciplinas Una disciplina es una colección de actividades relacionadas vinculadas con un área específica del proyecto. Este agrupamiento de actividades en disciplinas es principalmente para facilitar la comprensión del proyecto desde la perspectiva tradicional del modelo en cascada. Flujo de Trabajo Un flujo de trabajo describe la secuencia en que se realizan las actividades en una disciplina, quienes la realizan (trabajadores) y que artefactos producen. .

74. Modelado del negocio : describe la estructura y la dinámica de la organización. Requisitos : describe el método basado en casos de uso para extraer los requisitos. Análisis y diseño : describe las diferentes vistas arquitectónicas. Implementación : tiene en cuenta el desarrollo de software, la prueba de unidades y la integración. Pruebas : describe los casos de pruebas, los procedimientos y las métricas para evaluación de defectos. Despliegue : cubre la configuración del sistema entregable. Disciplinas de Proceso

75. Gestión de configuraciones : controla los cambios y mantiene la integridad de los artefactos de un proyecto. Gestión del Proyecto : describe varias estrategias de trabajo en un proceso iterativo. Entorno : cubre la infraestructura necesaria para desarrollar un sistema. Disciplinas de Soporte

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

77. Modelamiento de Negocio Los objetivos son: Entender la estructura y la din ámica del negocio . Asegurar que los clientes, usuarios y desarrolladores tengan un entendimiento común de la organización. Un Modelo de Casos de Uso del Negocio describe los proceso de negocio de una empresa en términos de casos de uso del negocio y actores del negocio que se corresponden con los procesos del negocio y los clientes respectivamente .

78. Modelamiento de Negocio – Flujo de Trabajo

79. Requerimientos Los desarrolladores y clientes deben acordar qué es lo que el sistema debe hacer: Relevar requerimientos Documentar funcionalidad y restricciones Documentar decisiones Identificar actores Identificar casos de uso Los requerimientos no funcionales se incluyen en una especificación complementaria.

80. Requerimientos – Flujo de Trabajo

81. Análisis y Diseño Objetivos: Ejecutar las tareas y funciones descritas en los casos de uso Satisfacer todos los requerimientos Flexible a cambios El diseño se centra en la noción de arquitectura Diseñar y validar la arquitectura es una tarea esencial. El modelo de diseño consta de Clases estructuradas en paquetes Diseños de subsistemas con interfaces definidas (componentes) Forma de colaboración entre las clases.

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

83. Implementación Objetivo: Definir la organización del código Implementar clases y objetos en forma de componentes (fuente, ejecutables, etc.) Probar las componentes desarrolladas Integrar las componentes en un sistema ejecutable

84. Implementaci ón – Flujo de Trabajo

85. Test Objetivo: Verificar la interacción entre los objetos Verificar la integración apropiada de componentes Verificar que se satisfacen los requerimientos Identificar los defectos y corregirlos antes de la instalación RUP describe como planear y ejecutar estas pruebas. RUP propone probar los componentes desde el principio: Confiabilidad, funcionalidad y performance.

86. Test – Flujo de Trabajo

87. Despliegue Producir un producto y hacerlo llegar a sus usuarios finales. Incluye varias actividades: Producir un “release” Empaquetar el software Distribuir el software Realizar pruebas beta Instalar el software Apoyar a los usuarios Migración de datos

88. Despliegue – Flujo de Trabajo

89. Administración y Configuración de Cambios Forma de controlar los artefactos producidos por las personas que trabajan en el proyecto. Algunos problemas habituales: Actualizaciones simultáneas Múltiples versiones RUP da guías para: Desarrollos en paralelo Automatizar la construcción Administrar defectos

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

91. Administración del Proyecto Es el arte de balancear objetivos contrarios, manejar riesgos y producir software que satisface a clientes y usuarios. Existen pocos proyectos realmente exitosos. RUP incluye: Un framework para manejo de proyectos de software Guías para planificación, provisión de personal, ejecución y monitoreo de planes Un framework para manejar riesgos

92. Administración del Proyecto – Flujo de Trabajo

93. Entorno Ambiente y herramientas de desarrollo que harán posible llevar a cabo el proyecto. RUP guía en la configuración de un ambiente de proceso apropiado a cada proyecto. Se debe seleccionar un conjunto de artefactos para el proyecto, esta elección se puede recoger en un documento breve llamado Marco de Desarrollo

94. Entorno

95. Requerimientos El propósito fundamental del flujo de trabajo de los requisitos es guiar el desarrollo hacia el sistema correcto. Hay diferentes puntos de partida para la captura de requisitos. En algunos casos comenzamos haciendo un modelo del negocio o partimos de uno ya desarrollado. En otros casos el cliente puede ya haber desarrollado una especificación completa de requisitos no basada en objetos, de la cual podemos partir.

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. Análisis Durante el análisis, revisamos los requisitos que se describieron en la captura de requisitos, refinándolos y estructurándolos. El objetivo de hacerlo es conseguir una comprensión más precisa de los requisitos y una descripción de los mismos que sea fácil de mantener y que nos ayude a estructurar el sistema entero, incluyendo su arquitectura.

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. Dise ñ o Durante el diseño modelamos el sistema y su arquitectura para que soporte los requisitos funcionales y no funcionales. Una entrada esencial al diseño es el modelo de análisis. El diseño es el centro de atención al final de la fase de elaboración y comienzo de las iteraciones de construcción .

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. Implementación Se inicia con el resultado del diseño y se implementa el sistema en término de componentes, es decir, ficheros de código fuente, scripts, ficheros de código binario, ejecutables, y similares. Es el centro durante las iteraciones de construcción. Aunque también se realiza durante : La fase de elaboración, para crear la línea base ejecutable de la arquitectura La fase de transición para tratar defectos tardíos.

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. Prueba Los objetivos de la prueba son: Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de integración y las pruebas de sistema. Diseñar e implementar pruebas creando: Casos de prueba (especifican qué probar), Procedimientos de prueba (especifican cómo realizar las pruebas), Componentes de prueba para automatizar las pruebas. Realizar las pruebas.

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

112. Fase de Inicio Durante la fase de inicio se desarrolla la descripción del producto final, y se presenta el análisis del negocio. Esta fase responde las siguientes preguntas: • ¿Cuáles son las principales funciones del sistema para los usuarios mas importantes? • ¿Cómo podría ser la mejor arquitectura del sistema? • ¿Cuál es el plan del proyecto y cuanto costará desarrollar el producto? En esta fase se identifican y priorizan los riesgos mas importantes.

113. Fase de Inicio Los objetivos son: Poner en marcha el proyecto Desarrollar el análisis del negocio hasta justificar la puesta en marcha plan de proyecto Para ello Esbozar una arquitectura Mitigar los riesgos Análisis inicial del negocio (coste, agenda, recuperación de la inversión)

114. Un documento de visión general: Requerimientos generales del proyecto Características principales Restricciones Modelo inicial de casos de uso (10% a 20 % listos). Glosario. Caso de negocio: Contexto Criterios de éxito Pronóstico financiero Identificación inicial de riesgos. Plan de proyecto. Uno o más prototipos. Artefactos Fase de Inicio

115. Inicio Elaboración Construcción Transición Objetivos del Ciclo de Vida Las partes interesadas deben acordar el alcance y la estimación de tiempo y costo. Comprensión de los requerimientos plasmados en casos de uso. Hito: Fase de Inicio

116. Fase de Elaboración Durante la fase de elaboración se especifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura. Las iteraciones en la fase de elaboración: Establecen una firme comprensión del problema a solucionar. Establece un plan detallado para las siguientes iteraciones. Elimina los mayores riesgos. El resultado de esta fase es la línea base de la arquitectura.

117. Fase de Elaboración Los objetivos son: Recopilar la mayor parte de los requisitos definiéndolos como casos de uso Establecer una arquitectura sólida para guiar las fases posteriores Continuar la observación y control de los riesgos críticos Completar el plan de proyecto Para ello Se toman decisiones considerando la comprensión global del sistema: ámbito, requisitos funcionales y no funcionales

118. Modelo de casos de uso (80% completo) con descripciones detalladas. Otros requerimientos no funcio-nales 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. Fase de Elaboración Artefactos:

119. Condiciones de éxito de la elaboración: ¿Es estable la visión del producto? ¿Es estable la arquitectura? ¿Las pruebas de ejecución demuestran que los riesgos han sido abordados y resueltos? ¿Están de acuerdo con el plan todas las personas involucradas? Concepción Elaboración Construcción Transición Arquitectura de Ciclo de Vida Hito: Fase de Elaboración

120. En esta fase todas las componentes restantes se desarrollan e incorporan al producto. Todo es probado en profundidad. El énfasis está en la producción eficiente y no ya en la creación intelectual. Puede hacerse construcción en paralelo, pero esto exige una planificación detallada y una arquitectura muy estable. Fase de Construcción

121. Fase de Construcción Los objetivos son: Línea base de la arquitectura crece hasta convertirse en el sistema completo Riesgos reducidos o rutinarios Implementación de los casos de uso Prototipo Para ello A través de sucesivas iteraciones e incrementos se desarrolla un producto software, listo para operar, éste es frecuentemente llamado versión beta

122. El producto de software integrado y corriendo en la plataforma adecuada. Manuales de usuario. Una descripción del “release” actual. Artefactos: Fase de Construcción

123. Se obtiene un producto Beta que debe decidirse si puede ponerse en ejecución sin mayores riesgos. Condiciones de éxito: ¿El producto está maduro y estable para instalarlo en el ambiente del cliente? ¿Están los interesados listos para recibirlo? Concepción Elaboración Construcción Transición Capacidad Operacional Hito: Fase de Construcción

124. Fase de Transición Los objetivos son: Cumplir requisitos Gestionar todos los aspectos de implantación Pruebas de aceptación Para ello Las iteraciones en esta fase continúan agregando características al sw. El equipo se encuentra ocupado en corregir y extender la funcionalidad del sistema desarrollado en la fase anterior.

125. El objetivo es traspasar el software desarrollado a la comunidad de usuarios. Una vez instalado surgirán nuevos elementos que implicarán nuevos desarrollos (ciclos). Incluye: 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 Fase de Transición

126. Condiciones de éxito: ¿ Se han alcanzado los objetivos fijados en la fase de Inicio ? ¿ El usuario está satisfecho ? Concepción Elaboración Construcción Transición Hito: Fase de Transición Producto

127. RUP y CMMI

128. Capability Maturity Model Integration. Modelo para la mejora o evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software. Desarrollado por el Instituto de Ingeniería del Software de la Universidad Carnegie Mellon (SEI), y publicado en su primera versión en enero de 2002. Para los usuarios es difícil especificarlos en forma cuantitativa Modelo CMMI

129. CMMI se desarrolló para facilitar y simplificar la adopción de varios modelos de forma simultánea, y su contenido integra y da relevo a la evolución de sus predecesores: CMM-SW (CMM for Sofwtare) SE-CMM(Systems Engineering Capability Maturity Model) IPD-CMM(Integrated Product Development) Modelo 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

132. Análisis RUP – CMMI RUP es un proceso que define quién debe hacer las cosas, qué debe hacerse, cómo y cuándo. Dado su enfoque mantiene modelos en lugar de gran cantidad de documentación, utiliza un lenguaje concreto y bien definido (UML). CMMI es un modelo estático que define áreas claves (PA) en las que se deben llevar a cabo prácticas específicas o genéricas, por lo tanto el hecho de implementar RUP en el desarrollo de un proyecto implica que ciertas KPA de CMMI sean alcanzadas y otras no.

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

136. La aplicación formal del Proceso Unificado supone: Desventajas: Grandes esfuerzos en la construcción de modelos. Necesidad del soporte de herramientas informáticas. Ventajas: Disminuye el riesgo del error de análisis / diseño acumulado. Aligera el esfuerzo en implementación. Proporciona la documentación del ciclo de vida en el mismo proceso. Conclusiones

137. El Proceso Unificado es flexible y se puede adaptar al grado de complejidad del modelo de proceso de desarrollo (descarte de algunos modelos o flujos). El Proceso Unificado es abierto y permite la incorporación de enfoques y artefactos complementarios: Patrones de diseño. Patrones de implementación. Combinación de varios modelos de proceso. Arquitecturas Dirigidas por Modelos ( Model Driven Architectures ). Conclusiones

138. Booch G., Rumbaugh J., Jacobson I. El Lenguaje Unificado de Modelado, Addison-Wesley, Madrid, 1999. Bruegge B., Dutoit A.H. Ingeniería de Software Orientado a Objetos, Prentice Hall– Pearson educación, México, 2002. Jacobson I., Booch G., Rumbaugh J. El Proceso Unificado de Desarrollo de Software, Addison-Wesley, Madrid, 2000. Pressman R.S. Ingeniería del Software. Un enfoque práctico (5ª ed.) Mc Graw-Hill; New York , 2001. Rumbaugh J., Jacobson I., Booch G. El Lenguaje Unificado de Modelado. Manual de Referencia, Addison-Wesley, Madrid, 2000. Sommerville I. Ingeniería de software, 6ª edición, Prentice Hall – Pearson educación, México, 2002. Stevens P., Pooley R. Utilización de UML en Ingeniería del Software con Objetos y Componentes, Addison-Wesley, Madrid, 2002. Bibliografía