Tema 13: El Proceso Unificado de Desarrollo

Transcripción

1 Tema 13: El Proceso Unificado de Desarrollo Verónica Bollati

2 Introducción El proceso unificado Principios básicos Las 4 p Índice Estructura del proceso unificado Flujos de trabajo principales Fases del desarrollo Otros aspectos Iteración genérica Planificación y evaluación

3 Introducción Realidad actual: sistemas más complejos y más grandes Objetivo: Desarrollo más rápido menor tiempo de salida al mercado Software de calidad Mejor adaptación del software a las necesidades del cliente Solución: un proceso de desarrollo que integre todas las facetas de un desarrollo software Dé una guía para ordenar las actividades del equipo Dirija las tareas de cada desarrollador por separado y del equipo como un todo Especifique los productos (artefactos) que hay que desarrollar Ofrezca criterios para controlar y medir los productos y actividades del proyecto

4 Introducción El proceso unificado Principios básicos Las 4 p Índice Estructura del proceso unificado Flujos de trabajo principales Fases del desarrollo Otros aspectos Iteración genérica Planificación y evaluación

5 El Proceso Unificado Unificación de tres metodologías de desarrollo basadas en el paradigma orientado a objetos OOSE (Object-Oriented Software Engineering) Ivar Jacobson Booch Grady Booch OMT (Object Modeling Technique) James Rumbaugh

6 El Proceso Unificado Unified Process (1999) vs. Rational Unified Process (2003) UP: define el proceso y un marco extensible para el desarrollo de software RUP (propietario: IBM / Rational): 6 disciplinas de ingeniería (flujos de trabajo) principales Elementos principales: roles (quién), productos (qué), tareas (cómo)

7 El Proceso Unificado Es un proceso de desarrollo software Def.: conjunto de actividades para transformar los requisitos de usuario en un sistema software Basado en componentes Principios: Dirigido por casos de uso Centrado en la arquitectura Iterativo e incremental Características Usa UML (Unified Modeling Language) como notación para los modelos del proceso de desarrollo Otros: enfocado a riesgos, impulsa la calidad, es configurable, etc. Las 4 P del proceso unificado: Proyecto Proceso Producto Personas

8 Principios del Proceso Unificado Dirigido por casos de uso Ideas: Cualquier interacción del sistema con el usuario es un caso de uso Actor: alguien o algo Def.: caso de uso Es una función del sistema que da a cada usuario un resultado útil Captura los requisitos funcionales Qué debe hacer el sistema para cada actor? Modelo de casos de uso

9 Principios del Proceso Unificado Dirigido por casos de uso Conducen el proceso de desarrollo: Los desarrolladores crean modelos de diseño e implementación que realizan los casos de uso Los encargados de pruebas aseguran que los componentes implementan los casos de uso Los casos de uso se especifican, se diseñan y sirven de base para construir los casos de prueba Se desarrollan junto a la arquitectura del sistema Ambos evolucionan en paralelo

10 Principios del Proceso Unificado Centrado en la Arquitectura Def.: D. Garlan and D. Perry (guest editorial to the IEEE Transactions on Software Engineering, April 1995): Incluye: Software architecture is "the structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time Es una vista del diseño completo que hace visibles las características principales Más definiciones: Aspectos estáticos Aspectos dinámicos Influencias: Plataforma, aspectos legales, componentes reusables disponibles, consideraciones de implementación El proceso ayuda a centrarse en los objetivos correctos: legibilidad, adaptabilidad, reutilización. Relación entre casos de uso y arquitectura Casos de uso Funcionalidad del sistema Arquitectura Forma

11 Principios del Proceso Unificado Centrado en la Arquitectura El arquitecto debe: Crear una arquitectura inicial, no específica de los casos de uso. Ejemplo: la plataforma Trabajar con un conjunto seleccionado de casos de uso que representan las tareas clave del sistema. Caso de uso subsistemas, clases y componentes Evolución a lo largo del proceso de desarrollo concepto de vista arquitectónica

12 Principios del Proceso Unificado Iterativo e incremental División del proyecto en hitos obtenidos como consecuencia de la repetición de iteraciones de trabajo Una iteración produce un incremento Cada fase e iteración se centra en disminuir algún riesgo y concluye con un hito bien definido Todas las iteraciones son planificadas y controladas Incrementa la efectividad Factores para la selección en una iteración: La iteración trata un grupo de casos que extienden la funcionalidad La iteración trata los riesgos más importantes Importante: un incremento no siempre es aditivo Elementos contemplados en cada iteración: Casos de uso relevantes Diseño guiado por arquitectura Actividades de implementación y verificación Beneficios

13 Principios del Proceso Unificado Iterativo e incremental Beneficios de la iteración controlada Reduce el coste riesgo a los costes asociados a un solo incremento Reduce el riesgo de no sacar al mercado el producto en el calendario previsto Identificación de riesgos en fases tempranas Acelera el ritmo del esfuerzo de desarrollo en su totalidad Se trabaja mas eficientemente para obtener resultados en corto plazo Permite refinar los requisitos en iteraciones sucesivas Las necesidades de los usuarios no pueden definirse completamente al principio

14 Principios del Proceso Unificado Ciclo de vida del software: La vida del PU Varios ciclos de desarrollo que concluyen con un producto evolucionado El paso a través de las 4 fases principales constituye un ciclo de desarrollo produce una generación del software Cada fase se subdivide en iteraciones Primera pasada desarrollo inicial Siguientes ciclos de evolución del sistema Entregas: código fuente, ejecutables, manuales y documentos Hitos por fases (milestones) Ciclos Entrega... Fases Iterac. Concepción Elaboración Construcción Transición Iter. Iter. Iter n

15 Principios del Proceso Unificado Otras características Soporta las técnicas orientadas a objetos: Los modelos definidos como artefactos del proceso son orientados a objetos Los modelos se basan en la definición de clases, objetos y las relaciones entre ellos Se utiliza UML como notación común Enfocado a riesgos: La gestión del riesgo está incluida en el proceso Los riesgos se identifican y se acometen al principio del proceso de desarrollo (a tiempo) Impulsa un control de la calidad: La evaluación de la calidad está contenida en el proceso (trazabilidad) Implica a todos los participantes mediante medidas y criterios objetivos No se trata como algo a posteriori o una actividad separada Es un proceso configurable: Puede adaptarse a proyectos de diferente envergadura (medianos-grandes) Se adapta a las necesidades de desarrollo de la organización

16 Principios del Proceso Unificado Las 4 P : Proyecto Elemento organizativo a través del cual se gestiona el desarrollo de SW. El resultado de un proyecto es una versión de un producto Varias iteraciones en cuatro fases Información sobre el sistema propuesto Información del dominio Planificar Plan de proyecto Plan de iteración Experiencia pasada

17 Principios del Proceso Unificado Las 4 P : Proceso Un proceso de IS es una definición del conjunto de actividades necesarias para transformar los requisitos de usuario en un producto Un proceso es una plantilla para crear proyectos FASES Workflow Elaboración Requisitos Análisis Planificación Anál. Riesgos Preparación Construcción Verificación Iteración en Fase de Elaboración Transición Diseño Implementación Prueba Iteración(es) Inicial(es) Iter. #1 Iter. #2 Iter. #3 Iter. #4 Iter. #5 Iter. #6 Iter. #7 (Adaptado de Jacobson, 1999)

18 Principios del Proceso Unificado Las 4 P : Producto Artefactos que se crean durante la vida del proyecto, como los modelos, código fuente, ejecutables, y documentación Especificado por Modelo de análisis Modelo de casos de uso El resultado de llevar a cabo un proceso SW dentro de un proyecto concreto Soportado por Distribuido por Implementado por Verificado por Modelo de pruebas Modelo de diseño Modelo de despliegue Modelo de implementación

19 Principios del Proceso Unificado Las 4 P : Personas Los principales autores de un Py de SW son los arquitectos, desarrolladores, ingenieros de prueba y el personal de gestión que les da soporte, además de los usuarios, clientes, y otros interesados Las personas son realmente seres humanos, a diferencia del termino abstracto trabajadores Analista de Sistemas Descubre Actores y Casos de Uso Estructura Modelo de Casos de Uso Planific a Test Diseñ a Test Evalu a Test Ingeniero de pruebas Especifica Casos de Uso Detalla un Caso de Uso Integra Sistem a Integrador de Sistemas Diseñador de Interface de Usuario Prototipo del Interfaz de Usuario Ejecuta Test de Integración Ingeniero de pruebas de integración Arquitecto Prioriza Casos de Uso Ingeniero de Casos de Uso Análisis de Arquitectu ra Analiza un Caso de Uso Diseño de Arquitectu ra Diseña un Caso de Uso Implementaci ón de Arquitectura Ejecuta test del sistema Ingeniero de pruebas de sistema Ingeniero de Componentes Analiza una Clase Analiza un Paquet e Diseña una clase Implemen Diseña un ta una Subsistem Implement clase a a Subsistem a Ejecuta Test Unitario Implement a Test

20 Índice Introducción El proceso unificado Principios básicos Las 4 p Estructura del proceso unificado Flujos de trabajo principales Fases del desarrollo Otros aspectos Iteración genérica Planificación y evaluación

21 Estructura del Proceso Unificado Fases e iteraciones Fase: intervalo de tiempo entre dos hitos importantes del proceso durante el cual se cumple un conjunto bien definido de objetivos, se completan artefactos y se toman decisiones sobre si pasar a la siguiente fase Cada ciclo está compuesto por 4 fases: Iniciación (inception): Establecer la visión, el alcance y el plan inicial del proyecto Elaboración (elaboration): Diseñar, implementar y probar una arquitectura correcta, y completar el plan del proyecto Construcción (construction): Desarrollar el sistema (construir la primera versión operativa) Transición (transition): Proporcionar el sistema a sus usuarios finales

22 Estructura del Proceso Unificado Fases e iteraciones Iteración: representa un ciclo de desarrollo completo, desde la captura de requisitos en el análisis hasta la implementación y pruebas, que produce una versión (interna o externa) de un producto ejecutable, que constituye un subconjunto del producto final en desarrollo Iteración genérica (similar al modelo en cascada): Planificación Flujos de trabajo fundamentales: requisitos, análisis, diseño, implementación y pruebas Evaluación Dependiendo de la iteración y de la fase en la que se encuentre el proyecto, el énfasis se pone más en unos u otros flujos de trabajo El contenido varía para adaptarse al objetivo de cada fase

23 Índice Introducción El proceso unificado Principios básicos Las 4 p Estructura del proceso unificado Flujos de trabajo principales Fases del desarrollo Otros aspectos Iteración genérica Planificación y evaluación

24 Flujos de trabajo principales (Workflows) Workflow Requisitos Planificación Anál. Riesgos Preparación Elaboración FASES Construcción Verificación Transición Análisis Diseño Implementación Prueba Iteración(es) Inicial(es) Iter. #1 Iter. #2 Iter. #3 Iter. #4 Iter. #5 Iter. #6 Iter. #7 (Adaptado de Jacobson, 1999)

25 Flujos de Trabajo Principales Requisitos Captura de los requisitos del sistema Difícil: Los requisitos cambian Comprensión: lenguaje utilizado cliente El cliente debe ser capaz de leer y comprender el resultado de la captura Objetivo: guiar el desarrollo hacia el sistema correcto El resultado ayuda al jefe de proyecto a planificar las iteraciones y los recursos Pasos a seguir: Enumerar los requisitos candidatos lista de características Comprender el contexto del sistema modelo de negocio/dominio Capturar requisitos funcionales modelo de casos de uso Capturar requisitos no funcionales requisitos suplementarios o casos individuales

26 Flujos de Trabajo Principales Artefactos de requisitos Requisitos Modelo de casos de uso Diagramas de casos de uso: Flujos de eventos principales Caminos alternativos Descripciones textuales de los casos de uso Diagramas de estado para explicar los casos de uso complejos Descripción de la arquitectura Glosario Prototipo de la interfaz de usuario Actividades Encontrar actores y casos de uso Priorizar los casos de uso Detallar un caso de uso Prototipar la interfaz de usuario Estructurar el modelo de casos de uso Analista de sistemas Arquitecto Especificador de C.U. Diseñador de la interfaz Arquitecto

27 Flujos de Trabajo Principales Análisis Se trabaja con conceptos Especificación más precisa de los requisitos Se utiliza el lenguaje de desarrolladores Facilita comprensión, preparación, modificación y mantenimiento de requisitos Primera aproximación al modelo de diseño

28 Flujos de Trabajo Principales Análisis Modelo de Casos de Uso Lenguaje del cliente Vista externa del sistema Estructurado por casos de uso Contrato entre cliente-desarrolladores Redundancias, inconsistencias, etc. entre requisitos Captura la funcionalidad del sistema Define casos de uso Modelo de Análisis Lenguaje del desarrollador Vista interna del sistema Estructurado por clases y paquetes Usado por desarrolladores para entender el sistema No debería contener redundancias ni inconsistencias de requisitos Captura cómo realizar la funcionalidad del sistema Define realizaciones de casos de uso

29 Artefactos de análisis Modelo de análisis Flujos de Trabajo Principales Análisis Diagramas de colaboración: Flujos de eventos principales Caminos alternativos Descripciones textuales de las clases Descripción de la arquitectura Vista de la arquitectura del modelo de análisis Descomposición del modelo en paquetes Realización de los casos de uso en análisis Diagramas de clases del análisis Diagramas de interacción de objetos del análisis Una descripción textual del flujo de sucesos Clases y paquetes de análisis

30 Flujos de Trabajo Principales Análisis Actividades Análisis de la arquitectura Identificar paquetes de análisis Identificar clases de entidad Requisitos comunes Analizar (refinar) un caso de uso Arquitecto Ingeniero de CU Identificar clases de análisis Describir interacciones entre los objetos del análisis Capturar requisitos especiales sobre la realización del CU Analizar una clase Ingeniero de Componentes Identificar responsabilidades y atributos Identificar relaciones: asociación, agregación y generalización Capturar requisitos especiales sobre la realización del CU Analizar un paquete Ingeniero de Componentes

31 Flujos de Trabajo Principales Diseño Se modela el sistema para que dé soporte a los requisitos funcionales y no funcionales Objetivos: Profundizar los requisitos no funcionales y restricciones dependientes de la plataforma. Crear una entrada apropiada para la implementación Descomponer los trabajos de implementación en partes mas manejables y que permitan concurrencia. Capturar las interfaces entre los subsistemas. Es el centro de atención final de la fase de elaboración e iteraciones iniciales de la fase de construcción

32 Flujos de Trabajo Principales Diseño Artefactos de diseño Modelo de diseño Diagramas de secuencia Flujos de eventos principales Caminos alternativos Descripciones textuales de las clases Diagramas de transición de estados para el comportamiento interno de cada clase Modelo de despliegue Diagramas de despliegue: distribución física del sistema en nodos de computo Descripciones de los nodos y sus interrelaciones Descripción de la arquitectura Vista de la arquitectura del modelo de diseño Descomposición del modelo en subsistemas Realización de los casos de uso en diseño Diagramas de clases de realización en diseño Diagramas de interacción (clases, subsistemas, interfaces) Flujo de sucesos-diseño Requisitos de implementación

33 Actividades Flujos de Trabajo Principales Diseño Diseño de la arquitectura Arquitecto Identificar nodos y configuración Identificar subsistemas y clases Diseñar un caso de uso Ingeniero de CU Identificar clases de diseño y subsistemas Distribuir comportamiento del caso de uso Capturar requisitos de implementación Diseñar una clase Ingeniero de Componentes Identificar responsabilidades y atributos Capturar requisitos especiales sobre la realización del CU Diseñar un subsistema Ingeniero de Componentes

34 Flujos de Trabajo Principales Implementación Se implementa el sistema en términos de componentes: Ficheros de código fuente, scripts, ficheros de código binarios, ejecutables y similares Objetivos: Planificar las integraciones de sistema necesarias en cada iteración Distribuir el sistema asignando componentes ejecutables a nodos en el diagrama de despliegue Implementar las clases y subsistemas encontrados durante el diseño Probar los componentes individualmente, integrarlos (compilándolos y enlazándolos en uno o más ejecutables)

35 Flujos de Trabajo Principales Implementación Artefactos de implementación Modelo de implementación Diagramas de componentes Subsistemas de implementación y sus dependencias Componentes (fichero y ejecutables) y sus dependencias Interfaces Modelo de despliegue Diagrama de despliegue Nodos Descripción de la arquitectura Vista de la arquitectura del modelo de implementación Asignación de componentes ejecutables a nodos Plan de integración de construcciones

36 Flujos de Trabajo Principales Actividades Implementación Implementación de la arquitectura Integrar sistemas Implementar una clase Componentes Arquitecto Integrador de sistemas Ingeniero de Implementar un subsistema Ingeniero de Componentes Realizar prueba de unidad Componentes Ingeniero de

37 Flujos de Trabajo Principales Prueba Verificamos el resultado de la implementación probando cada construcción Objetivos: Planificar las pruebas necesarias para cada iteración Pruebas de sistema Pruebas de integración Diseñar e implementar las pruebas diseñando los casos de prueba Realizar las diferentes pruebas

38 Flujos de Trabajo Principales Artefactos de prueba Modelo de pruebas Prueba Casos de prueba Procedimientos de prueba Componentes de prueba Plan de prueba Defectos Evaluación de la prueba

39 Actividades Planificar prueba Diseñar prueba Flujos de Trabajo Principales Prueba Diseñador de pruebas Diseñador de pruebas Describir casos de prueba de cada construcción Identificar y estructurar los procedimientos de prueba Implementar prueba Ingeniero de componentes Realizar pruebas de integración Ingeniero de pruebas de integración Realizar prueba de sistema Diseñador de pruebas Evaluar prueba Diseñador de pruebas

40 Índice Introducción El proceso unificado Principios básicos Las 4 p Estructura del proceso unificado Flujos de trabajo principales Fases del desarrollo Otros aspectos Iteración genérica Planificación y evaluación

41 Fases del Proceso Unificado Workflow Requisitos Planificación Anál. Riesgos Preparación Elaboración FASES Construcción Verificación Transición Análisis Diseño Implementación Prueba Iteración(es) Inicial(es) Iter. #1 Iter. #2 Iter. #3 Iter. #4 Iter. #5 Iter. #6 Iter. #7 (Adaptado de Jacobson, 1999)

42 Fases del Proceso Unificado Inicial Propósito: establecer viabilidad Objetivo: Análisis del negocio: casos de uso fundamentales para el negocio Actividades: 1. Delimitar el ámbito (interfaces con otros sistemas) 2. Proponer una arquitectura especialmente en lo nuevo, arriesgado o difícil (expresada en función de algunos modelos) 3. Identificar riesgos críticos (los que afecten a la viabilidad) 4. Demostrar a usuarios y clientes un prototipo (exploratorio)

43 Propósito: factibilidad Objetivo: Fases del Proceso Unificado Elaboración Arquitectura estable para guiar el sistema Estimación de costes para fases siguientes con precisión Actividades: 1. Línea base de la arquitectura. Consiste en: modelos, descripción de la arquitectura e implementación ejecutable de la arquitectura. 2. Identificación de riesgos que pueden perturbar los planes y costes posteriores. 3. Especificar niveles para los atributos de calidad: fiabilidad y tiempo de respuesta. 4. Recopilar casos de uso para el 80% de los requisitos funcionales para planificar la fase de construcción. 5. Planificación: personal, coste.

44 Fases del Proceso Unificado Construcción Propósito: desarrollar el sistema Objetivo: Versión beta Actividades: 1. Terminar la identificación, descripción y realización de todos los casos de uso. 2. Finalizar el análisis, el diseño la implementación y pruebas. 3. Mantener la integridad de la arquitectura. 4. Monitorizar los riesgos críticos

45 Fases del Proceso Unificado Transición Propósito: puesta en funcionamiento del sistema en el entorno del cliente/usuario Objetivo: Producto final Actividades: 1. Preparar las actividades, por ejemplo, el lugar 2. Aconsejar sobre el entorno de funcionamiento 3. Manuales y documentos para la entrega 4. Ajustar el software al entorno del usuario 5. Corregir los defectos detectados en la versión beta Lecciones aprendidas Asuntos útiles para la versión siguiente

46 Índice Introducción El proceso unificado Principios básicos Las 4 p Estructura del proceso unificado Flujos de trabajo principales Fases del desarrollo Otros aspectos Iteración genérica Planificación y evaluación

47 Otros aspectos del Proceso Unificado Iteración genérica Incluye Planificación Flujos de trabajo fundamentales Requisitos Análisis Diseño Implementación Pruebas Evaluación El contenido varía para adaptarse al objetivo de cada fase

48 Establecer: Otros aspectos del Proceso Unificado Planificación (fases) Asignaciones de tiempo y fecha de entrega por cada fase (inestable hasta fin de elaboración) Hitos principales y criterios de aceptación Iteraciones por fase y qué se realiza en ellas Depende de la complejidad del sistema Plan de proyecto: Fechas y criterios de objetivos principales División de fases en iteraciones Pensar a largo plazo

49 Otros aspectos del Proceso Unificado Planificación (iteraciones) Se define: Planificación de la Iteración: cuánto tiempo, fecha de terminación, etc. Contenido de la Iteración: ya está esbozado en el plan del proyecto pero al comenzar cada iteración se debe detallar: Casos de uso Riesgos técnicos que se deben identificar en forma de casos de uso Cambios que han sufrido los requisitos o defectos encontrados Subsistemas que se deben implementar Personal El plan de la iteración siguiente se va detallando. El número de iteraciones de cada fase esta determinado por la complejidad del sistema.

50 Otros aspectos del Proceso Unificado Planificación / Evaluación Antes de cada iteración se han de planificar los criterios de evaluación para establecer la satisfacción de los objetivos de cada iteración (medidos u observados): Requisitos funcionales en casos de uso Requisitos no funcionales de esos requisitos funcionales Requisitos no funcionales sueltos Requisitos verificables (pruebas) Requisitos generales (prototipo) Productos intermedios para determinar el progreso del trabajo Al final de cada iteración se realiza la evaluación de la misma de acuerdo a los criterios inicialmente establecidos

51 Otros aspectos del Proceso Unificado Evaluación Jefe de proyecto: ha de crear un documento como resultado de la evaluación Objetivos: Evaluar iteraciones según criterios: presupuesto, tiempo, requisitos de calidad, resultados de las pruebas Reconsiderar el plan de la siguiente iteración Modificar el proceso Evaluar y modificar criterios Es frecuente no alcanzar los criterios prolongar el trabajo a la iteración siguiente: Modificar o extender el modelo de casos de uso Modificar o extender la arquitectura Modificar o extender los subsistemas desarrollados Buscar otros riesgos Incorporar ciertas habilidades al equipo Puede que solo falte tiempo

52 Otros aspectos del Proceso Unificado Evaluación A partir de la evaluación anterior, el jefe de proyecto: Determina si se puede pasar a la siguiente iteración Si hay que rehacer, decide cuándo, quién y cómo Planifica en detalle siguiente iteración Actualiza el plan de las iteraciones posteriores a la siguiente Actualiza la lista de riesgos y el plan del proyecto Evolución del conjunto de modelos

53 Bibliografía The unified software development process. Ivar Jacobson, Grady Booch, James Rumbaugh, Ed. Addison Wesley, 1999 El proceso unificado de desarrollo. Ivar Jacobson, Grady Booch, James Rumbaugh, Ed. Addison Wesley, 1999