Proceso Unificado de desarrollo

Presentación del tema: "Proceso Unificado de desarrollo"— Transcripción de la presentación:

1 Proceso Unificado de desarrollo

2 Objetivos Ofrecer una visión general del proceso unificado, sus actividades y herramientas. Presentar una visión simplificada del Lenguaje Unificado de Modelado (UML). Aprender la noción de proceso y metodología en la Orientación a Objetos

3 Contenido Introducción al Proceso Unificado
Los flujos de trabajo fundamentales Fases del proceso Organización del proyecto

4 Introducción al Proceso Unificado

5 El proceso Unificado: ¿ Que es ?
Los sistemas son cada día más grandes, existe una tendencia generalizada, esto hace que los procesos iterativos e incrementales sean imprescindibles. Es necesario un proceso común, un método que integre: Guía para ordenar las actividades de un equipo. Dirección de las tareas de cada desarrollador por separado y del equipo como un todo. Especificación de los artefactos que deben ser desarrollados. Criterios para el control y la medición de los productos y actividades del proyecto.

6 El proceso Unificado: Características
Está basado en componentes e interfaces bien definidas Utiliza el Lenguaje Unificado de Modelado (UML) Aspectos característicos: Dirigido por casos de uso Centrado en la arquitectura Iterativo e incremental

7 El proceso Unificado: Estructura

8 El Proceso Unificado Dirigido por casos de uso
Caso de uso: Fragmento de funcionalidad que proporciona al usuario un resultado importante Modelo de casos de uso: Funcionalidad total del sistema ¿Qué debe hacer el sistema … para cada usuario? Guían todo el proceso de desarrollo En cada iteración se identifican e implementan unos cuantos casos de uso Los casos de uso sirven para idear la arquitectura Se seleccionan los casos de uso más representativos Se utiliza como partida para escribir el manual de usuario

9 El Proceso Unificado Dirigido por casos de uso
Modelo de análisis a partir de casos de uso Crece incrementalmente Se especifican a través de diagramas de clases y de colaboración Al principio se examinan unos pocos casos de uso y se crean sus realizaciones Cada clasificador puede participar en varias realizaciones distintas con distintos roles Clases estereotipadas de análisis (entorno, control y entidad)

10 Un proceso dirigido por casos de uso
Realización de un caso de uso (análisis): Modelo de casos de uso Modelo de análisis Sacar dinero Sacar dinero Cuenta Retirada efectivo Interfaz cajero Salida «trace»

11 Un proceso dirigido por casos de uso
Modelo de casos de uso Modelo de análisis Salida Retirada efectivo Sacar dinero Cliente del banco Interfaz cajero Transferencia Cuenta Ingresar dinero Cliente del banco Transferencia Receptor dinero Ingreso

12 Un proceso dirigido por casos de uso
Diagrama de colaboración para describir una realización: :Retirada efectivo :Salida :Cliente del banco :Interfaz cajero :Cuenta 1:Identificación 5: entrega dinero 2: solicitar retirada 4: autorizar entrega 3: validar y retirar

13 Un proceso dirigido por casos de uso
Modelo de diseño a partir del modelo de análisis Se adapta al entorno de implementación Se define con los mismos diagramas El modelo de diseño es más “físico” y el modelo de análisis más “conceptual” Sacar dinero Modelo de casos de uso Modelo de análisis «trace» Modelo de diseño

14 Un proceso dirigido por casos de uso
Modelo de análisis Cuenta Retirada efectivo Interfaz cajero Salida Modelo de diseño «trace» «trace» «trace» «trace» Teclado Cuenta Gestor de Cliente Sensor de salida Retirada de efectivo Clase Persistente Dispositivo de visualización Alimentador de la salida Contador de efectivo Lector de tarjetas Gestor de Transacciones Gestor de Cuentas

15 Un proceso dirigido por casos de uso
Dispositivo de visualización Sensor de salida Teclado Alimentador de la salida Lector de tarjetas Contador de efectivo Retirada de efectivo Gestor de Cliente Gestor de Transacciones Cuenta Gestor de Cuentas Clase Persistente Cliente del banco

16 Un proceso dirigido por casos de uso
:Cliente del banco :Dispositivo de visualización :Teclado :Lector de tarjetas :Contador de efectivo :Gestor de Cliente :Gestor de Transacciones Introducir tarjeta Tarjeta introducida(ID) Solicitar PIN Mostrar petición Especificar código PIN Código PIN Validar código PIN Solicitar cantidad a retirar Mostrar petición Especificar cantidad Cantidad(C) Disponib. Saldo(C) … Solicitar retirada cantidad(C)

17 Un proceso dirigido por casos de uso
Las clases se agrupan en subsistemas Dispositivo de visualización Sensor de salida Teclado Alimentador de la salida Lector de tarjetas Contador de efectivo Gestor de Cliente «subsystem» Interfaz del CA Gestor de Transacciones «subsystem» Transacciones Retirada de efectivo Efectivo Cliente del banco Cuenta Gestor de Cuentas Clase Persistente «subsystem» Gestión de Cuentas ITransferen IEntrega IRetirada

18 Un proceso dirigido por casos de uso
Modelo de implementación a partir del modelo de diseño Modelo de diseño Modelo de implementación Cliente.cpp «file» Gestor de Cliente «trace» Cliente.exe «exe» Sensor de salida «compilation» Alimentador de la salida Salida.cpp «file» «trace» Contador de efectivo

19 Un proceso dirigido por casos de uso
Pruebas Modelo de pruebas compuesto por: Casos de prueba Procedimientos de prueba Modelo de casos de uso Modelo de pruebas Sacar dinero X «trace»

20 El Proceso Unificado Centrado en la arquitectura
Describe diferentes vistas del sistema Incluye los aspectos estáticos y dinámicos más significativos Es la forma del software La arquitectura y los casos de uso evolucionan en paralelo Se empieza por la parte que no es específica de los casos de uso Software del sistema Capa intermedia Sistemas heredados Estándares y políticas Requisitos no funcionales Necesidades de distribución Casos de uso Arquitectura Experiencia

21 Un proceso centrado en la arquitectura
La arquitectura se desarrolla principalmente en la fase de elaboración ¿Qué casos de uso tener en cuenta? Los que representen riesgos más importantes Los más importantes para el usuario Funcionalidades significativas Línea base de la arquitectura Esqueleto con pocos músculos

22 El Proceso Unificado Iterativo e incremental
Beneficios de un proceso iterativo controlado: Coste del riesgo a un solo incremento Reduce el riesgo de no sacar el producto en el calendario previsto Acelera el ritmo de desarrollo Se adapta mejor a las necesidades del cliente Se divide el trabajo en mini-proyectos Cada mini-proyecto es una iteración que resulta en un incremento La iteración Trata un conjunto de casos de uso Trata los riesgos más importantes En cada iteración se persiguen unos objetivos concretos

23 Un proceso iterativo e incremental
Iteración genérica: Planificación Requisitos Análisis Diseño Implementación Prueba Evaluación de la iteración

24 Un proceso iterativo e incremental
Fases del proceso: Inicio: Objetivos del ciclo de vida Establecer ámbito del sistema Reducir peores riesgos Preparar el análisis del negocio Elaboración: Arquitectura del ciclo de vida Obtener línea base de la arquitectura Capturar mayoría de requisitos Reducir siguientes riesgos

25 Un proceso iterativo e incremental
Fases del proceso Construcción: Funcionalidad operativa inicial Desarrollo del sistema entero Transición: Versión del producto Producto preparado para su entrega al usuario Se enseña a los usuarios a utilizarlo

26 Personas, Proyecto, Producto y Proceso
Arquitectos, desarrolladores, ingenieros de prueba, personal de gestión, usuarios, clientes El proceso de desarrollo afecta a las personas (viabilidad, gestión del riesgo, estructura de los equipos, planificación, comprensión, cumplimiento) Formación, entrenamiento y experiencia De recurso a trabajador (puestos que asumen las personas) Cada trabajador tiene un conjunto de responsabilidades y lleva a cabo un conjunto de actividades

27 Personas, Proyecto, Producto y Proceso
Elemento organizativo de gestión El proyecto construye el producto Secuencia de cambio. El sistema evoluciona Serie de iteraciones. Cada iteración implementa un conjunto de casos de uso o atenúa algunos riesgos. Mini-proyecto Patrón organizativo. Tipos de trabajadores y artefactos a conseguir

28 Personas, Proyecto, Producto y Proceso
Artefactos que se crean durante la vida del proyecto Artefactos: Modelos, código, ejecutables, documentación, diagramas UML, bocetos de la interfaz de usuario, prototipos, componentes, planes de prueba Artefactos de ingeniería y de gestión Colección de modelos

29 Personas, Proyecto, Producto y Proceso
Conjunto de actividades para crear el producto Es una plantilla para crear proyectos (Instancia del proceso) Se define en términos de flujos de trabajo (conjunto de actividades) Se identifican trabajadores y artefactos Adaptación o especialización del proceso Se utilizan diagramas de actividad de UML para describir los flujos de trabajo

30 Los flujos de trabajo fundamentales

31 Tópicos Artefactos Trabajadores Flujo de Trabajo

32 Work Flow de Requisitos

33 Introducción El esfuerzo principal en esta fase (requisitos) es desarrollar un modelo del sistema que se va a construir utilizando casos de uso y los límites bajo los cuales opera. Los casos de uso son un medio intuitivo. Énfasis en el valor añadido que proporciona al usuario. Descripción en tres pasos: Artefactos a desarrollar, Trabajadores que participan y El flujo de trabajo.

34 Artefacto Pieza de información utilizada o producida por un proceso de desarrollo de software Artefactos implicados durante la captura de requisitos Modelo de Casos de Uso Actor Glosario Caso de Uso Prototipo de Interfaz de Usuario Descripción de la Arquitectura

35 Casos de Uso ¿Qué es un caso de uso?
Un caso de uso es una secuencia de interacciones entre uno o varios actores y el sistema que tiene lugar bajo ciertas circunstancias y que: Es iniciada por un actor. Se puede describir como una secuencia de actividades. Produce un resultado de valor observable para algún actor.

36 Casos de uso Se capturan requisitos de usuario a través de casos de uso Son fundamentales para: Identificar y especificar clases, subsistemas e interfaces Identificar y especificar casos de prueba Planificar las iteraciones e integración del sistema Nos guían a través de los flujos de trabajo En cada iteración se identifican e implementan unos cuantos casos de uso Los casos de uso sirven para idear la arquitectura Se seleccionan los casos de uso más representativos Se utiliza como partida para escribir el manual de usuario

37 Work Flow de Requisitos
Encontrar Actores y Casos de Uso Estructurar el Modelo de Casos de Uso Analista de Sistemas Arquitecto Priorizar los Casos de Uso Detallar los Casos de Uso Especificador CU Diseñador de Interfaz de usuario Prototipar la Interfaz de Usuario

38 Actividad: Encontrar actores y casos de uso
Lista de características Se utiliza sólo para planificación Estructura de las características: Nombre y breve descripción Estado (propuesto, aprobado, incluido,…) Coste estimado implementación Prioridad Nivel de riesgo (crítico, significativo, …)

39 Actividad: Detallar un caso de uso
Alternativas: Precondición + Camino básico + Caminos alternativos + Poscondición Diagramas de estado Diagramas de actividades Diagramas de interacción

40 Actividad: Estructurar los casos de uso
Identificar descripciones de funcionalidad compartida (herencia) Casos de uso reales Casos de uso abstractos Identificar descripciones de funcionalidad adicional y opcional (extensión) Otras relaciones (inclusión)

41 Ejemplo “Cuando el cliente inserta su tarjeta en el cajero, la pantalla del cajero le pide que seleccione un idioma. El cliente realiza su selección. El cajero pregunta entonces al cliente cuál es su número de identificación personal ... ... el cliente recoge su dinero de la ranura del dispensador y saca su tarjeta de la ranura de tarjetas”.

42 ¿Por qué utilizar casos de uso?
Un caso de uso ayuda a contestar las siguientes preguntas: ¿Quién hace qué? ¿Cuándo lo hace? ¿Qué actividades se realizan? ¿Qué elementos del sistema se utilizan?

43 Caso Práctico: Documento de Requisitos
Requisitos, Antecedentes, Objetivos y Alcance Los requisitos iniciales se han obtenido directamente del cliente y usuario final. Se desea desarrollar una aplicación para dar soporte a la matriculación de los alumnos de una universidad. La aplicación debe dar soporte a las siguientes funcionalidades: - Un alumno puede matricularse de curso completo o de asignaturas sueltas. - Cada alumno se matricula para una asignatura en concreto en un grupo en concreto, durante un periodo académico concreto. - Un profesor imparte una asignatura en un grupo - La aplicación debe incorporar la gestión de profesores, es decir, añadir un nuevo profesor, borrarlo o modificar sus datos. - La aplicación debe permitir al administrador inscribir alumnos en la universidad. - Entendemos por inscripción crear su expediente, es decir, un alumno puede tener expediente pero no estar matriculado. - Si el alumno se matricula de curso completo elegirá grupo y cursará todas las asignaturas en ese mismo grupo. - También debe ser posible modificar el expediente de un alumno y en casos especiales borrarlo. - Todas las operaciones de borrado se realizan únicamente a nivel lógico. - La aplicación debe permitir al administrador crear nuevos grupos y también borrarlos. - La aplicación también debe dar soporte a la gestión de asignaturas, es decir, añadir, borrar y modificar. - El administrador también debe poder asignar un profesor a un grupo para una asignatura concreta. - La aplicación funcionará en pc’s con windows 95 y pocos recursos. - La aplicación debe funcionar con un esquema cliente servidor, central. - El sistema desarrollado debe ser lo más estándard posible. - Los alumnos se validarán para usar el sistema introduciendo su login y password en formulario.

44 Caso Práctico: Casos de Uso (Vista Parcial)

45 Caso Práctico: Descripción de un Caso de Uso
Descripción de Casos de Uso Número: 001 Nombre de Caso de Uso: “Matricular Asignaturas Sueltas” Actor(es): Alumno Descripción Proceso que sigue un alumno a la hora de matricular una o varias asignaturas sueltas. Flujo de Eventos - Entrada en el sistema - Selección de las asignaturas que desea - Realizar matrícula Requerimientos Especiales: El actor no puede ser un alumno de nuevo ingreso. Pre-Condiciones: Haber realizado un login exitoso en la aplicación.

46 Caso Práctico: Descripción de un Caso de Uso
Descripción de Casos de Uso Número: 002 Nombre de Caso de Uso: “Logín” Actor(es): Alumno Descripción Proceso que sigue un alumno para entrar en el sistema. Flujo de Eventos - Introducir el nombre de usuario - Introducir la password - Realizar Login Requerimientos Especiales: El actor no puede ser un alumno de nuevo ingreso. Pre-Condiciones: N/A.

47 Caso Práctico: Prototipo de la Interfaz de Usuario
Caso de Uso Hacer Matrícula

48 Caso Práctico: Prototipo de la Interfaz de Usuario
Actividad: Login

49 Work Flow de Análisis

50 Objetivos de Análisis Ofrecer una especificación más precisa de los requisitos que la que tenemos como resultado de los requisitos. Estructurar los requisitos de un modo que facilita su compresión, su preparación, su modificación y en general su mantenimiento. Considerar una primera aproximación al Diseño.

51 Ingeniero de casos de uso Ingeniero de Componentes
Work Flow de Análisis Análisis de la Arquitectura Arquitecto Analizar un Caso de Uso Ingeniero de casos de uso Ingeniero de Componentes Analizar una clase Analizar un paquete

52 Artefacto: MODELO DE ANÁLISIS
Las clases de análisis representan abstracciones de clases o subsistemas del diseño de sistema y dentro del modelo de análisis, los casos de uso se describen mediante clases de análisis y sus objetos. Lo que se representa a través de colaboraciones dentro del modelo de análisis que llamamos realizaciones de caso de uso-análisis.

53 Artefacto: CLASE DE ANÁLISIS
Requisitos funcionales Más evidente, mayor granularidad Una clase de análisis, raramente define u ofrece un interface en términos de operaciones y de sus signaturas. En cambio, su comportamiento se define mediante responsabilidades en un nivel más alto y menos formal. Una clase de análisis define atributos de un nivel bastante alto Una clase de análisis participa en relaciones, aunque se trata de relaciones más conceptuales Las clases de análisis siempre encaja en uno de tres estereotipos básicos: de interfaz, de control o de entidad

54 Artefacto: CLASES DE INTERFAZ
Las clases de interfaz representan a menudo, abstracciones de ventanas, formularios, paneles , interfaces de comunicaciones, interfaces de impresoras, sensores, terminales, y API (posiblemente no orientados a objetos)

55 Artefacto: CLASES DE ENTIDAD
Las clases de entidad se utilizan para modelar información que posee una vida larga y que es, a menudo, persistente. Suelen derivarse directamente de una clase de entidad del negocio.

56 Artefacto: CLASES DE CONTROL
Las clases de control representan coordinación, secuencia, transacciones, y control de otros objetos y se usan frecuentemente para encapsular el control de un caso de uso en concreto. Los aspectos dinámicos del sistema se modelan con clase de control, manejan y coordinan las acciones y los flujos de control principales, y delegan trabajo en otros objetos, es decir, objetos de interfaz y de entidad.

57 Artefacto: REALIZACIÓN DE CASO DE USO-ANÁLISIS
Una realización de caso de uso-análisis es una colaboración dentro del modelo de análisis que describe cómo se lleva a cabo y se ejecuta un caso de uso determinado en términos de las clases de análisis y de sus objetos de análisis en interacción. Una realización de caso de uso posee una descripción textual del flujo de sucesos, diagramas de clase que muestran sus clases de análisis participantes, y diagramas de interacción que muestran la realización de un flujo o escenario particular del caso de uso en términos de interacciones de objetos del análisis. Realización caso de uso -Análisis Caso de uso «trace»

58 ARTEFACTO: PAQUETE DE ANÁLISIS
Los paquetes del análisis proporcionan un medio de organizar los artefactos del modelo de análisis en piezas manejables. Un paquete de análisis puede constar de clases de análisis, de realización de casos de uso, y de otros paquetes de análisis (recursivamente). Deben ser cohesivos y débilmente acoplados Tienen las siguientes características: · Pueden representar una separación de intereses de análisis · Han de crearse basándose en los requisitos funcionales y en el dominio del problema · Probablemente se convertirán en subsistemas Reglas de negocio

59 Diagramas de clases Diagrama más común de modelado estructural.
Contiene: clases, interfaces, colaboraciones y relaciones. Usos más comunes: Modelar el vocabulario del sistema. Modelar colaboraciones simples. Modelar el esquema lógico de una base de datos.

60 Técnicas comunes de modelado de diagramas de clases
Modelado de colaboraciones simples Identificación de los mecanismos (funciones o comportamientos de la parte del sistema que se está modelando). Para cada uno, encontrar las clases, interfaces y otras colaboraciones que participan en la colaboración, así como las relaciones entre ellos. Usar escenarios para recorrer la interacción entre los elementos. Modelado de un esquema lógico de una base de datos Identificar clases persistentes, representándolas con el valor etiquetado estándar {persistent}. Expandir los detalles estructurales de dichas clases. Añadir abstracciones intermedias para simplificar la estructura lógica. Separar el comportamiento de las clases persistentes en dos bloques: comportamiento intrínseco y tratamiento de los datos.

61 Modelo en tres Capas

62 Caso Práctico: Colaboraciones. Login ok

63 Caso Práctico: Colaboraciones. No Login

64 Work Flow de Diseño

65 Ingeniero de casos de uso Ingeniero de Componentes
Work Flow de Diseño Diseño de la Arquitectura Arquitecto Diseñar un Caso de Uso Ingeniero de casos de uso Ingeniero de Componentes Diseñar una clase Diseñar un subsistema

66 Realización de caso de uso-diseño
Diagramas de clase Diagramas de interacción (clases, subsistemas, interfaces) Flujo de sucesos-diseño Requisitos de implementación

67 Clases de Diseño A la hora de construir un modelo de diseño hay que tomar en consideración múltiples aspectos muy cercanos a la implementación como por ejemplo el lenguaje. Hay que establecer la correspondencia entre las clases de análisis y las de diseño, a un nivel muy básico podríamos considerar simplemente: Clase de Entidad de Análisis  Clase que almacena datos. Clase de Control de Análisis  Clase que encapsula la lógica. Clase de Interfaz de Análisis  Formularios, Diálogos, Ventanas…

68 Work Flow de Implementación

69 Work Flow de Implementación
Implementación de la Arquitectura Arquitecto Integrar sistemas Integrador de sistemas Ingeniero de Componentes Implementar un subsistema Implementar una clase Realizar prueba de unidad

70 Actividad: Integrar sistemas
Construir el software incrementalmente Control de versiones Integración incremental El plan describe la secuencia de construcciones necesarias en una iteración Funcionalidad de la construcción Partes del modelo de implementación afectados por la construcción

71 Work Flow de Pruebas Pruebas

72 Procedimiento de prueba
Cómo realizar uno o varios casos de prueba Instrucciones para un individuo Especificación de interacción manual Componente de prueba Automatiza uno o varios procedimientos de prueba Puede utilizarse un “modelo de diseño de pruebas”

73 Work Flow de Pruebas Ingeniero de pruebas Ingeniero de pruebas
Planificar Pruebas Diseñar prueba Evaluar prueba Ingeniero de pruebas Ingeniero de pruebas de integración Realizar Prueba de integración Ingeniero de pruebas de sistema Realizar prueba de sistema Ingeniero de componentes Implementar Prueba

74 Fases del proceso

75 Desarrollo iterativo e incremental

76 Encontrar actores y casos de uso Estructurar el modelo de casos de uso
Analista de sistemas Ingeniero de pruebas Planificar prueba Encontrar actores y casos de uso Estructurar el modelo de casos de uso Diseñar prueba Evaluar prueba Integrador de sistemas Especificador de casos de uso Detallar un caso de uso Integrar sistemas Ingeniero de pruebas de int. Diseñador de interfaces Realizar prueba de integración Prototipar la interfaz de usuario Ingeniero de pruebas de sis. Realizar prueba de sistema Arquitecto Priorizar los casos de uso Análisis de la arquitectura Diseño de la arquitectura Implementación de la arquitectura Ingeniero de casos de uso Analizar un caso de uso Diseñar un caso de uso Implementar pruebas Diseñar una clase Analizar una clase Implementar un subsistema Ingeniero de componentes Realizar prueba de unidad Analizar un paquete Diseñar un subsistema Implementar una clase

77 Fase de inicio Objetivo: Establece la viabilidad del proyecto
Se fundamenta el análisis de negocio inicial: Se delimita el ámbito del sistema Se propone o esboza una arquitectura del sistema Se identifican riesgos críticos Se demuestra a los usuarios la utilidad del sistema propuesto Sistema rentable económicamente

78 Fase de inicio La mayor parte se realiza en el flujo de requisitos
Ajuste del proyecto al entorno Proceso + herramientas + servicios para proyectos Herramientas para los flujos de trabajo Herramientas para la gestión del proyecto Identificar y mitigar/planificar riesgos críticos

79 Definir ámbito del sistema
Planificar prueba Analista de sistemas Encontrar actores y casos de uso Estructurar el modelo de casos de uso Ingeniero de pruebas Diseñar prueba Evaluar prueba Integrador de sistemas Especificador de casos de uso Detallar un caso de uso Integrar sistemas Definir ámbito del sistema Realizar prueba de integración Ingeniero de pruebas de int. Prototipar la interfaz de usuario Diseñador de interfaces Esbozar la arquitectura candidata Realizar prueba de sistema Ingeniero de pruebas de sis. Análisis de la arquitectura Diseño de la arquitectura Priorizar los casos de uso Implementación de la arquitectura Arquitecto Ingeniero de casos de uso Analizar un caso de uso Diseñar un caso de uso Implementar pruebas Diseñar una clase Analizar una clase Implementar un subsistema Ingeniero de componentes Realizar prueba de unidad Analizar un paquete Diseñar un subsistema Implementar una clase

80 Fase de inicio Requisitos Enumerar requisitos candidatos
Comprender contexto del sistema Recopilar requisitos funcionales Encontrar actores y casos de uso Priorizar casos de uso Detallar un caso de uso Recoger requisitos no funcionales

81 Fase de inicio Análisis Diseño Se completa alrededor del 5% del modelo
Análisis de la arquitectura Analizar un caso de uso Diseño Diseño de la arquitectura Colaboraciones entre clases y subsistemas Identificar interfaces entre clases y subsistemas Elegir software del sistema y elementos del middleware

82 Fase de inicio Implementación Prueba No suele ser necesaria
Implementación de un prototipo desechable Prueba Los ingenieros de pruebas consideran qué pruebas se requerirán Planes de prueba No se realizan pruebas

83 Fase de inicio Modelo negocio Casos de uso identificados
Casos de uso descritos Casos de uso analizados Casos de uso diseñados, implementados y probados Fase inicio 50% -70% 50% 10% 5% Lo suficiente para el prototipo Fase elaboración Cerca del 100% >80% 40% - 80% 20% - 40% <10% Fase construcción 100% 100% si se mantiene

84 Fase de inicio Productos de la fase: Lista de características
Primera versión del modelo del negocio Primera versión del modelo de casos de uso, de análisis y de diseño Descripción de la arquitectura candidata Prototipo exploratorio Lista inicial de riesgos y clasificación de casos de uso Plan para el proyecto Primer borrador del análisis del negocio

85 Fase de elaboración Dos grandes objetivos: Tareas básicas:
Elaborar una arquitectura estable Conocer suficientemente el sistema como para planificar en detalle la fase de construcción Tareas básicas: Crear una línea base para la arquitectura Identificar riesgos significativos Especificar atributos de calidad Estudiar 80% de los requisitos funcionales

86 Fase de elaboración Objetivos: Planificación de la fase
Recopilar la mayor parte de los requisitos Establecer la línea base de la arquitectura Controlar riesgos críticos e identificar riesgos significativos Completar detalles del plan del proyecto Planificación de la fase Formación del equipo

87 Desarrollar línea base de la arquitectura
Planificar prueba Analista de sistemas Encontrar actores y casos de uso Estructurar el modelo de casos de uso Ingeniero de pruebas Diseñar prueba Evaluar prueba Desarrollar línea base de la arquitectura Integrador de sistemas Especificador de casos de uso Detallar un caso de uso Integrar sistemas Refinar mayor parte de requisitos Realizar prueba de integración Ingeniero de pruebas de int. Prototipar la interfaz de usuario Diseñador de interfaces Realizar prueba de sistema Ingeniero de pruebas de sis. Análisis de la arquitectura Diseño de la arquitectura Priorizar los casos de uso Implementación de la arquitectura Arquitecto Ingeniero de casos de uso Analizar un caso de uso Diseñar un caso de uso Implementar pruebas Diseñar una clase Analizar una clase Implementar un subsistema Ingeniero de componentes Realizar prueba de unidad Analizar un paquete Diseñar un subsistema Implementar una clase

88 Fase de elaboración Recopilar requisitos
Encontrar casos de uso y actores adicionales Desarrollar prototipos de interfaces de usuario Determinar prioridad de los casos de uso Detallar un caso de uso Estructurar el modelo de casos de uso

89 Fase de elaboración Análisis Análisis de la arquitectura
Analizar un caso de uso Analizar una clase Analizar un paquete

90 Fase de elaboración Diseño Diseño de la arquitectura
Identificar la arquitectura en capas Identificar subsistemas y sus interfaces Identificar clases significativas Si es un sistema distribuido, identificar nodos Diseñar un caso de uso Diseñar una clase Diseñar un subsistema

91 Fase de elaboración Implementación Pruebas
Implementación de la arquitectura Implementación de una clase y de un subsistema Integrar el sistema Pruebas Planificar las pruebas Diseñar las pruebas Realizar pruebas de integración y pruebas de sistema

92 Fase de elaboración Análisis del negocio
Evaluación de la fase de elaboración Planificación de la fase de construcción Se planifica en detalle la 1ª iteración Se esboza el plan de las siguientes

93 Fase de elaboración Productos Modelo del negocio completo
Versión de los modelos Línea base de la arquitectura Lista de riesgos actualizada Plan de proyecto para construcción y transición Manual de usuario (opcional) Análisis del negocio completo

94 Fase de construcción Objetivo: La capacidad de operación inicial
Versión beta Requiere mayor número de iteraciones Tareas básicas: Extensión a todos los casos de uso Finalización del análisis, diseño, implementación y prueba Mantenimiento de la integridad de la arquitectura Monitorización de los riesgos críticos y significativos.

95 Fase de construcción Versión beta Se detallan todos los casos de uso
Se modifica la descripción de la arquitectura Se terminan todos los modelos Es la fase del desarrollo Se mitigan todos los riesgos excepto los de operación

96 Fase de construcción Esta fase comienza con la firma del contrato
Asignación de personal Se divide el trabajo atendiendo a subsistemas e interfaces Se preparan primeras versiones de manuales de usuario y cursos de formación

97 Se hace crecer el sistema
Planificar prueba Analista de sistemas Encontrar actores y casos de uso Estructurar el modelo de casos de uso Ingeniero de pruebas Diseñar prueba Evaluar prueba Integrador de sistemas Especificador de casos de uso Detallar un caso de uso Integrar sistemas Realizar prueba de integración Ingeniero de pruebas de int. Se hace crecer el sistema Prototipar la interfaz de usuario Diseñador de interfaces Realizar prueba de sistema Ingeniero de pruebas de sis. Análisis de la arquitectura Diseño de la arquitectura Priorizar los casos de uso Implementación de la arquitectura Arquitecto Ingeniero de casos de uso Analizar un caso de uso Diseñar un caso de uso Implementar pruebas Diseñar una clase Analizar una clase Implementar un subsistema Ingeniero de componentes Realizar prueba de unidad Analizar un paquete Diseñar un subsistema Implementar una clase

98 Fase de construcción Requisitos
Encontrar casos de uso y actores: pequeña fracción Desarrollar prototipos de interfaces de usuario Determinar prioridad de los casos de uso Detallar un caso de uso: todos Estructurar el modelo de casos de uso: sólo para los casos de uso no desarrollados

99 Fase de construcción Análisis Puede no mantenerse
Análisis de la arquitectura Analizar un caso de uso Analizar una clase Analizar un paquete

100 Fase de construcción Diseño
Diseño de la arquitectura: prácticamente no se modifica Las otras tres tareas se realizan para el resto de los casos de uso (cerca del 90%) Diseñar un caso de uso Diseñar una clase Diseñar un subsistema

101 Fase de construcción Implementación
Implementación de la arquitectura: se actualiza si es necesario Implementación de una clase y de un subsistema: se pueden utilizar stubs Pruebas de unidad: podrá requerir corregir el diseño y la implementación del componente Integrar el sistema: por capas. Define período de las construcciones

102 Fase de construcción Pruebas Planificar las pruebas
Diseñar las pruebas Realizar pruebas de integración: después de cada construcción Realizar pruebas de sistema: hacia el final de las iteraciones Evaluar las pruebas

103 Fase de construcción Productos
El plan de proyecto para la fase de transición El sistema software ejecutable Todos los artefactos La descripción de la arquitectura actualizada Versión preliminar del manual de usuario Análisis del negocio actualizado

104 Fase de transición Objetivo: Entrega del producto final
Tareas básicas: Preparar el lugar y actualizar el entorno Preparar manuales Ajustar el software al entorno del usuario Corregir defectos de la versión beta Evaluar y registrar las “lecciones aprendidas” Registrar asuntos útiles para la versión siguiente

105 Fase de transición Se completa la versión del producto
Se gestionan los aspectos relativos al entorno del cliente Se corrigen los defectos de la versión beta Se terminan los manuales de usuario y cursos de formación La atención se desplaza a la corrección de defectos

106 Fase de transición Preparar la versión beta Instalación
Adaptar el producto a las circunstancias del usuario Completar los artefactos del proyecto Determinar cuándo se acaba el proyecto

107 Fase de transición Si ya existía un software : Evaluación
Sustitución del sistema antiguo por el nuevo Transferencia de datos del sistema antiguo: migración y conversión de datos Evaluación De las iteraciones y de la fase Autopsia del proyecto

108 Fase de transición Productos
El sistema software ejecutable + software instalación Documentos legales, contratos, licencias, garantías Versión completa y corregida del producto, incluyendo los modelos del sistema La descripción de la arquitectura completa y actualizada Manuales y material de formación del usuario, del operador y del administrador Referencias para la ayuda del cliente, cómo informar de defectos

109 Organización del proyecto

110 Planificación de las fases
Asignaciones de tiempo Hitos principales Iteraciones por fases Plan de proyecto En la fase de inicio Ajustar el PUD al proyecto y seleccionar herramientas Reunir a gente con conocimientos específicos Entender el dominio Familiarizar al equipo con las herramientas

111 Planificación de las iteraciones
La iteración se planifica más en detalle cuando está próxima Para planificar tenemos en cuenta: Los casos de uso Los riesgos técnicos Cambios en los requisitos Los subsistemas de implementación El nº de iteraciones depende del proyecto

112 Administración de riesgos
Se crea una lista de riesgos Descripción Prioridad (crítico, significativo, rutinario) Impacto: partes del proyecto afectadas Monitor: responsable del seguimiento del riesgo Responsabilidad: responsable de eliminarlo Contingencia: lo que hacer cuando ocurra Aparecen nuevos riesgos

113 Evaluación de las iteraciones
Se evalúa al final de cada iteración Reconsiderar plan de la siguiente iteración Modificar el proceso, adaptar las herramientas El jefe del proyecto: Determina si el trabajo está listo para pasar a la siguiente iteración Planea en detalle la siguiente iteración Actualiza el plan de las siguientes Actualiza la lista de riesgos Compara el coste y la planificación de la iteración