Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Transcripción

1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1

2 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir software de forma organizada, empleando una colección de técnicas y convenciones de notación predefinidas Mario Piattini et al. Conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software Autor: Ing. Silverio Bonilla 2

3 Concepto de Método El desarrollo de un sistema se puede explicar también como: Una secuencia de modelados que ayuda a construir, a partir de la realidad, uno o varios modelos, derivados unos de otros, con el objetivo de lograr un modelo final o sistema. Y entonces: Sistemas de Información II Un método es una guía que define las reglas de paso de un modelo a otro para evolucionar progresivamente hasta el modelo final. Autor: Ing. Silverio Bonilla 3

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

5 Qué es RUP? UML no es una metodología de diseño y que es bastante independiente del proceso de desarrollo, lo que significa que se puede utilizar con diferentes procesos de ingeniería del software. Para poder aplicar UML con garantía de conseguir un modelo de objetos de calidad, es necesaria una metodología completa, coherente y asequible. Esto es lo que hicieron «los tres amigos de Rational Corp.», James Rumbaugh, Gardy Booch e Ivar Jacobson: Diseñar una metodología que enseña a utilizar correctamente UML en el proceso de modelado de sistemas, denominada Proceso Unificado de Autor: Ing. Silverio Bonilla 5 Rational (Rational Unified process)

6 Características del RUP Las actividades de desarrollo del RUP están dirigidas por los Casos de Uso: El Proceso Unificado pone un gran énfasis en la construcción de sistemas basada en una amplia comprensión de cómo se utilizará el sistema que se entregue Las nociones de los casos de uso y los escenarios se utilizan para guiar el flujo de procesos desde la captura de los requisitos hasta las pruebas, y para proporcionar caminos que se pueden reproducir Autor: Ing. Silverio Bonilla 6 durante el desarrollo del sistema

7 Características del RUP Las actividades de desarrollo del RUP están dirigidas por los Casos de Uso: Es un proceso dirigido por los casos de uso Requisitos Análisis & Diseño Implementación Pruebas Casos de Uso integran el trabajo Capturar, definir y validar los casos de uso Realizar los casos de uso Verificar que se satisfacen los casos de uso Autor: Ing. Silverio Bonilla 7

8 Características del RUP Las actividades de desarrollo del RUP están dirigidas por los Casos de Uso: Es un proceso dirigido por los casos de uso «trace» «trace» Caso de Uso Modelo de Análisis Modelo de Diseño «trace» Pruebas Funcionales X «trace» Pruebas Unitarias Autor: Ing. Silverio Bonilla 8 Caso de Prueba

9 Características del RUP El RUP es un proceso Iterativo-Incremental: Un enfoque iterativo propone una comprensión incremental del problema a través de refinamientos sucesivos y un crecimiento incremental de una solución efectiva a través de varias versiones Como parte del enfoque iterativo se encuentra la flexibilidad para acomodarse a nuevos requisitos o a cambios tácticos en los objetivos del negocio Permite que el proyecto identifique y resuelva los riesgos más bien pronto que tarde. Autor: Ing. Silverio Bonilla 9

10 Características del RUP El RUP es un proceso Iterativo-Incremental: Se basa en la ampliación y el refinamiento del sistema Una serie de desarrollos cortos (mini proyectos de 2 a 6 semanas, cada iteración reproduce el ciclo de vida a menor escala) No sólo se mejora sino que el sistema también crece: Proceso iterativo e incremental El resultado de cada iteración es un sistema ejecutable (aunque sea incompleto y no esté listo para su instalación) Autor: Ing. Silverio Bonilla 10

11 Características del RUP El RUP es un proceso Iterativo-Incremental: Un sistema instalable requiere varias iteraciones Es una evolución de prototipos ejecutables Los objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes Autor: Ing. Silverio Bonilla 11

12 Características del RUP El RUP es un proceso Iterativo-Incremental: Enfoque Secuencial Incremento 1 Enfoque Iterativo e Incremental Incremento 2 Incremento 3 Autor: Ing. Silverio Bonilla 12

13 Características del RUP El RUP es un proceso Centrado en la Arquitectura: Arquitectura de un sistema es la organización o estructura de sus partes más relevantes La arquitectura describe los elementos fundamentales del sistema: Subsistemas, Dependencias, Interfaces, Colaboraciones, Nodos... 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 Autor: Ing. Silverio Bonilla 13 evolutivo

14 Características del RUP El RUP es un proceso Centrado en la Arquitectura: El proceso se centra en establecer al principio una arquitectura software que guía el desarrollo del sistema: Se facilita el desarrollo en paralelo Se minimiza la repetición de trabajos Se incrementa la probabilidad de reutilización de componentes y el mantenimiento posterior del sistema Este diseño arquitectónico sirve como una sólida base sobre la cual se puede planificar y manejar el desarrollo de software basado en componentes. Autor: Ing. Silverio Bonilla 14

15 Características del RUP El Proceso Unificado soporta las técnicas orientadas a objetos. Los modelos del Proceso Unificado se basan en los conceptos de objeto y clase y las relaciones entre ellos, y utilizan UML como la notación común. El Proceso Unificado es un proceso configurable. Aunque un único proceso no es adecuado para todas las organizaciones de desarrollo de software, el Proceso Unificado es adaptable y puede configurarse para cubrir las necesidades de proyectos que van desde pequeños equipos de desarrollo de software hasta grandes empresas Autor: Ing. Silverio Bonilla 15 de desarrollo

16 Eje Horizontal: representa el tiempo, Proceso de Dos Dimensiones muestra aspectos dinámicos del proceso, se expresa como ciclos, fases, iteraciones e hitos. Eje Vertical: Sistemas de Información II aspectos estáticos del proceso, actividades, artefactos, trabajadores y flujo de trabajo. Autor: Ing. Silverio Bonilla 16

17 Ciclos y Fases RUP divide el proceso de desarrollo en ciclos, teniendo un producto al final de cada ciclo. Cada ciclo se divide en cuatro Fases: Inicio (inception), Elaboración, Construcción, Transición. Cada fase concluye con un hito bien definido donde deben tomarse ciertas decisiones. Autor: Ing. Silverio Bonilla 17

18 Flujos de Trabajos y Fases del RUP Autor: Ing. Silverio Bonilla 18

19 En esta estructura matricial se puede deducir que: Los resultados de los flujos de trabajo de proceso son los MODELOS La conjunción de tiempo (fases) y esfuerzos (flujos de trabajo) da lugar a las iteraciones La conjunción de resultados (modelos) y esfuerzos (flujos de trabajo) da lugar a los tipos de modelos La conjunción de tiempo (fases) y resultados (modelos) da lugar a las versiones Se puede representar esta estructura conceptual mediante una figura tridimensional donde: Eje X: Fases indica tiempo Eje Y: Flujos de trabajo indica esfuerzos Eje Z: Modelos indica resultados Autor: Ing. Silverio Bonilla 19

20 Autor: Ing. Silverio Bonilla 20

21 Las iteraciones son distintas en el ciclo de vida Autor: Ing. Silverio Bonilla 21

22 Fase Inicio Se establece la oportunidad y alcance el proyecto. Se identifica todas las entidades externas con las que se trata (actores) y se define la interacción a un alto nivel de abstracción: identificar todos los casos de uso, describir algunos en detalle. La oportunidad del negocio incluye: criterios de éxito, identificación de riesgos, estimación de recursos necesarios, plan de las fases incluyendo hitos. Autor: Ing. Silverio Bonilla 22

23 Productos de la Fase Inicio Un documento de visión general requerimientos del proyecto, generales 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. Autor: Ing. Silverio Bonilla 23

24 Hitos Objetivos del Ciclo de Vida Concepción Elaboración Construcción Transición 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. Autor: Ing. Silverio Bonilla 24

25 Objetivos: Sistemas de Información II Fase de Elaboración analizar el dominio del problema, establecer una arquitectura base sólida, desarrollar un plan de proyecto, eliminar los elementos de mayor riesgo para el desarrollo exitoso del proyecto. Visión de una milla de amplitud y una pulgada de profundidad porque las decisiones de arquitectura requieren una visión global del sistema. Autor: Ing. Silverio Bonilla 25

26 Productos de la Fase de Elaboración Es la parte más crítica del proceso: al final toda la ingeniería dura está hecha, se puede decidir si vale la pena seguir adelante. A partir de aquí la arquitectura, los requerimientos y los planes de desarrollo son estables. Ya hay menos riesgos y se puede planificar el resto del proyecto con menos incertidumbre. Se construye una arquitectura ejecutable que contemple los casos de uso críticos, los riesgos identificados. Autor: Ing. Silverio Bonilla 26

27 Productos Concretos de la 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. Autor: Ing. Silverio Bonilla 27

28 Hitos Arquitectura de Ciclo de Vida Concepción Elaboración Construcción Transición Condiciones de éxito de la elaboración: es estable la visión del producto? es estable la arquitectura? las pruebas de ejecución convencen de que los riesgos han sido abordados y resueltos? es el plan del proyecto algo realista? están de acuerdo con Autor: el plan Ing. Silverio todas Bonillas personas involucradas? 28

29 Fase de Construcción 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. Autor: Ing. Silverio Bonilla 29

30 Productos de la Fase de Construcción El producto de software integrado y corriendo en la plataforma adecuada. Manuales de usuario. Una descripción del release actual. Autor: Ing. Silverio Bonilla 30

31 Hitos Capacidad Operacional Concepción Elaboración Construcción Transición 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? Autor: Ing. Silverio Bonilla 31

32 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: Sistemas de Información II 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 Autor: Ing. Silverio Bonilla 32

33 Hitos Producto Concepción Elaboración Construcción Transición Obtener autosuficiencia de parte de los usuarios. Concordancia en los logros del producto de parte de las personas involucradas. Lograr el consenso cuanto antes para liberar el producto al mercado. Autor: Ing. Silverio Bonilla 33

34 Trabajador Un trabajador define el comportamiento y las responsabilidades de un individuo. Es como un sombrero que la persona usa durante el proyecto: una persona puede tener varios sombreros, es el rol que desempeña en un momento dado. Las responsabilidades: Flujo de Trabajo (Workflows) hacer una serie de actividades, ser el responsable de una serie de artefactos. Autor: Ing. Silverio Bonilla 34

35 Flujo de Trabajo (Workflows) Una actividad es una unidad de trabajo que se asigna a un trabajador: crear o modificar un artefacto. Una actividad lleva entre un par de horas y un par de días, involucra un solo trabajador y un número pequeño de artefactos. Actividades Las actividades se consideran en la planificación y evaluación del progreso del proyecto. Ejemplos: Planificar una iteración - Administrador de proyecto. Encontrar actores y casos de uso - Analista. Revisar el diseño - Revisor de diseño. Ejecutar pruebas de performance - Ing. de pruebas de performance. Autor: Ing. Silverio Bonilla 35

36 Flujo de Trabajo (Workflows) Asignación de Actividades Recurso Trabajador Actividad Pablo Diseñador Diseño de Objetos María Autor de Casos de Uso Detallar un Caso de Uso José Diseñador de Casos de Uso Diseñar un Caso de Uso Silvia Revisor de Diseño Rever el Diseño Eduardo Arquitecto Análisis de Arquitectura Diseño de Arquitectura Autor: Ing. Silverio Bonilla 36

37 Flujo de Trabajo (Workflows) Elemento de información producido, modificado o usado por el proceso. Son los productos tangibles del proyecto. Son usados por los trabajadores para realizar nuevas actividades y son el resultado de esas actividades. Artefactos Ejemplos: Un modelo como el modelo de casos de uso o el modelo de diseño. Un elemento del modelo, como una clase o un caso de uso. Un documento tal como el Caso del Negocio o la Arquitectura del Software. Código fuente. Autor: Ing. Silverio Bonilla 37 Código ejecutable.

38 Flujos de Trabajo (Workflows) Una lista de actividades, trabajadores y artefactos no constituye un proceso. Un flujo de trabajo es una secuencia de actividades que produce un resultado valioso. No siempre es posible representar flujos de trabajo. Arquitecto Diseñador de Casos de Uso Diseñador Análisis de Arquitectura Análisis de Casos de Uso Diseño de Arquitectura Análisis de Objetos Describir Concurrencia Diseño de Casos de Uso Diseño de Objetos Describir Distribución Revisor de Diseño Revisar el Análisis Revisar el Diseño Revisar la Arquitectura Autor: Ing. Silverio Bonilla 38

39 Flujos de Trabajo Esenciales Flujos de Trabajo de Ingeniería Flujos de Trabajo de Apoyo Autor: Ing. Silverio Bonilla 39

40 Flujos de Trabajo (Workflows) Modelamiento del egocio Existen habitualmente problemas de comunicación entre ingenieros de software e ingenieros de negocios. RUP proporciona un lenguaje y proceso común para ambos ámbitos. Para el modelamiento del negocio se usan business use cases y su objetivo es conocer el sistema actual o el negocio. Autor: Ing. Silverio Bonilla 40

41 Flujo de Trabajo (Workflows) 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 Cliente Reciclar Imprimir Informe Administrar Depósito Los casos de uso describen la funcionalidad. Los requerimientos no funcionales se incluyen en una especificación complementaria. Autor: Ing. Silverio Bonilla 41 Operador

42 Descripción de cómo se implementará el sistema: un plano. Debe: Sistemas de Información II Flujo de Trabajo (Workflows) 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. Análisis y Diseño 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. Autor: Ing. Silverio Bonilla 42

43 Propósito: Sistemas de Información II Flujos de Trabajo (Workflows) Implementación 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. Autor: Ing. Silverio Bonilla 43

44 Propósitos: Sistemas de Información II Flujo de Trabajo (Workflows) 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. Pruebas RUP propone probar las componentes desde el principio: confiabilidad, funcionalidad y performance. Las pruebas de regresión son importantes en desarrollos iterativos. Rational tiene herramientas para automatizar algunas pruebas. Autor: Ing. Silverio Bonilla 44

45 Flujo de Trabajo (Workflows) Distribución Producir un producto y A veces también incluye: hacerlo llegar a sus realizar pruebas beta, usuarios finales. migración de datos, Incluye varias actividades: aceptación formal. producir un release, empaquetar el software, distribuir el software, instalarlo, asistir a los usuarios La mayor parte de la distribución ocurre durante la transición. Este es uno de los flujos de trabajo menos documentados en RUP. Autor: Ing. Silverio Bonilla 45

46 Flujo de Trabajo (Workflows) Elementos del RUP Workflow, Workflow Detail, Workers, Actividades y Artefactos Ejemplo Workflow: Requirements Workflow Detail:Analyse the Problem Workers Autor: Ing. Silverio Bonilla 46 Actividades Artefactos

47 Artefactos Modelos Modelo del negocio: establece una abstracción de la organización Modelo del dominio: establece el contexto del sistema Modelo de casos de uso: funcionales del sistema establece los requisitos Modelo de análisis: establece un diseño de las ideas Modelo de diseño: establece el vocabulario del problema y su solución Modelo del proceso (opcional): establece los mecanismos de concurrencia y sincronización del sistema Autor: Ing. Silverio Bonilla 47

48 Artefactos Modelos Modelo de despliegue: establece la topología hardware sobre la cual se ejecutará el sistema Modelo de implementación: establece las partes que se utilizarán para ensamblar y hacer disponible el sistema físico Modelo de pruebas: establece las formas de validar y verificar el sistema. Autor: Ing. Silverio Bonilla 48

49 Artefactos Modelos Autor: Ing. Silverio Bonilla 49

50 Modelos y flujos de trabajo del Proceso Unificado Autor: Ing. Silverio Bonilla 50

51 Modelos y Diagramas en RUP Autor: Ing. Silverio Bonilla 51