Flujos de Trabajo Fundamentales Proceso Unificado de Desarrollo de Software.

Presentación del tema: "Flujos de Trabajo Fundamentales Proceso Unificado de Desarrollo de Software."— Transcripción de la presentación:

1 Flujos de Trabajo Fundamentales Proceso Unificado de Desarrollo de Software

2 Documentos de Usuario Diseño Mapa del Territorio Necesi- dades Características Requerimientos Guías de Pruebas Espacio del Problema Espacio de la Solución Producto a ser construido Problema Trazabilidad

3 Captura de los Requisitos Trabajo a Realizar Artefactos Resultantes Enumerar requisitos candidatos Lista de Características Comprender el contexto del sistema Modelo de dominio de negocio Capturar los requisitos funcionales Modelo de Casos de Uso Capturar los requisitos no funcionales Requisitos adicionales o casos de uso concretos

4 Modelo de Dominio Captura los tipos más importantes de objetos en el contexto del sistema. Aparecen en tres formas típicas: –Objetos del negocio que representan cosas que se manipulan como contratos, cuentas. –Objetos del mundo real y conceptos de los que el sistema debe hacer el seguimiento como misil y trayectoria. –Sucesos que ocurrirán o no han ocurrido como llegada de un avión, salida y hora de comida

5 Modelo de Dominio Contribuye a una comprensión del problema que se supone que el sistema resuelve en relación a su contexto.

6 Modelo de Negocio Es un modelo de las funciones de negocio vistas desde la perspectiva de los actores externos (Agentes de registro, solicitantes finales, otros sistemas etc.). permite situar al sistema en el contexto organizacional haciendo énfasis en los objetivos en este ámbito. Este modelo se representa con un Diagrama de Casos de Uso usando estereotipos específicos para este modelo.

7 Requerimientos Adicionales Requisitos no funcionales que no pueden asociarse a ningún caso de uso en concreto, en cambio cada uno de estos requisitos tiene impacto en varios casos de uso o en ninguno. Usabilidad, confiabilidad, rendimiento, soportabilidad y restricciones de diseño

8 Glosario Es un documento que define los principales términos usados en el proyecto. Permite establecer una terminología consensuada.

9 Modelo de Casos de Uso El modelo de Casos de Uso presenta las funciones del sistema y los actores que hacen uso de ellas. Se representa mediante Diagramas de Casos de Uso.

10 Visión Este documento define la visión del producto desde la perspectiva del cliente, especificando las necesidades y características del producto. Constituye una base de acuerdo en cuanto a los requisitos del sistema.

11 Especificaciones de Casos de Uso Para los casos de uso que lo requieran (cuya funcionalidad no sea evidente o que no baste con una simple descripción narrativa) se realiza una descripción detallada utilizando una plantilla de documento, donde se incluyen: precondiciones, post-condiciones, flujo de eventos, requisitos no-funcionales asociados. También, para casos de uso cuyo flujo de eventos sea complejo podrá adjuntarse una representación gráfica mediante un Diagrama de Actividad.

12 Prototipos de Interfaces de Usuario Se trata de prototipos que permiten al usuario hacerse una idea más o menos precisa de las interfaces que proveerá el sistema y así, conseguir retroalimentación de su parte respecto a los requisitos del sistema. Estos prototipos se realizarán como: dibujos a mano en papel, dibujos con alguna herramienta gráfica o prototipos ejecutables interactivos, siguiendo ese orden de acuerdo al avance del proyecto. Sólo los de este último tipo serán entregados al final de la fase de Elaboración, los otros serán desechados. Asimismo, este artefacto, será desechado en la fase de Construcción en la medida que el resultado de las iteraciones vayan desarrollando el producto final.

13 Análisis y Diseño Los propósitos del Análisis & Diseño son: Transformar los requerimientos en un diseño de lo que será el sistema. Evolucionar a una arquitectura robusta para el sistema. Adaptar el diseño al ambiente de la implementación. El principal artefacto es el modelo de Diseño

14 Modelo de Diseño Es un modelo de objetos que describe la realización de los casos de uso. Muestra como los elementos del modelo colaboran para darle comportamiento del sistema. Sirve como una abstracción del modelo de implementación y su código fuente. Es usado como entrada principal en las actividades de implementación y pruebas.

15 Análisis y Diseño Análisis y Diseño Modelo de Casos de Uso Especificaciones Suplementarias Documento de Arquitectura Modelo de Datos Modelo de Diseño Modelo de Análisis (Opcional)

16 Realización de Casos de Uso en el Análisis y Diseño Caso de Uso (Modelo de Casos de Uso) Caso de Uso Diagrama de SecuenciaDiagrama de Clases Diagrama de Colaboración Realización de Casos de Uso (Modelo de Diseño)

17 Casos de Uso en el Análisis y Diseño El comportamiento completo de un caso de uso descrito en clases colaborativas

18 Propósito: –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 El principal artefacto es el modelo de Implementación Implementación

19 ¿Qué es un Modelo de Implementación? Un modelo de implementación consiste de: – –Componentes – –Subsistemas de implementación Los componentes incluyen: – –Componentes entregables tales como ejecutables – –Componentes de los cuales se producen los entregables tales como los archivos de código fuente CONTABILIDAD A VENTAS B

20 Modelo de Implementación Consiste de una colección de componentes y los subsistemas de implementación que los contienen. –Un componente es una pieza de código de software (Fuente, binario o ejecutable), o un archivo que contiene información (archivos Readme o Startup) o puede ser una agregación de otros componentes –Un subsistema de implementación es una colección de componentes y es usado para estructurar el modelo de implementación reduciendo el número de partes necesarias a considerar.

21 Propósito : –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 las componentes desde el principio: –Confiabilidad, funcionalidad y performance Rational tiene herramientas para automatizar algunas pruebas. Pruebas

22 Pruebas Permite: –Mitigar los riesgos más grandes de manera temprana. –Enfocar los recursos cuando y dónde pueda haber el mayor impacto. –Maximizar la efectividad adaptando el proceso conforme se avanza en el proyecto.

23 Tipos de Pruebas Pruebas de Funcionalidad –Funciones –Seguridad –Volumen Pruebas de Usabilidad Pruebas de Confiabilidad –Integridad –Estructura –Stress Pruebas de Rendimiento –Benchmark –Contención –Carga –Rendimiento Pruebas de Soportabilidad –Configuración –Instalación

24 Producir un producto y hacerlo llegar a sus usuarios finales. Incluye varias actividades: –Producir un “release” –Empaquetar el software –Distribuir el software –Instalar el software –Apoyar a los usuarios A veces también incluye: –Realizar pruebas beta –Migración de datos –Aceptación formal La mayor parte de la distribución ocurre durante la transición. Crear: Material para el usuario final Material para entrenamiento Despliegue

25 Despliegue Modelo de Despliegue

26 Casos de Uso y Documentación para el Usuario Final Despliegue Modelo de Casos de Uso Especificaciones Suplementarias Material de soporte al usuario final Guía del usuario Ayuda en línea Demos Tutoriales Material de entrenamiento

27 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 Administración de proyectos

28 Planeación para el Desarrollo Iterativo Plan del Proyecto Fases y principales hitos Plan de Fases Iteraciones para cada Fase: Número de iteraciones Objetivos Duración Plan de la siguiente Iteración Plan de la Iteración actual

29 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 Administración de Configuración y Cambios

30 Administración de Configuración y Cambios

31 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. Ambiente

32 Propósito: Enfocarse a las actividades necesarias para configurar el proceso para un proyecto. Define qué mejoras son adecuadas para las circunstancias del proyecto: Procesos actuales Herramientas Habilidades y capacidades del staff Problemas y posibles objetivos de mejora Ambiente