Proceso Unificado de desarrollo

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
trace
11
Un proceso dirigido por casos de uso
Modelo de casos de uso
Modelo de análisis
Sacar dinero
Ingresar dinero
Transferencia
12
Un proceso dirigido por casos de uso
Diagrama de colaboración para describir una
realización
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

14
Un proceso dirigido por casos de uso
Modelo de análisis
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
Gestor de Transacciones
Gestor de Cuentas
Lector de tarjetas
Contador de efectivo
15
Un proceso dirigido por casos de uso
16
Un proceso dirigido por casos de uso

17
Un proceso dirigido por casos de uso

• Las clases se agrupan en subsistemas

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
Gestor de Cliente
trace
Sensor de salida
compilation
Alimentador de la salida
trace
Contador de efectivo
19
Un proceso dirigido por casos de uso

• Pruebas
• Modelo de pruebas compuesto por
• Casos de prueba
• Procedimientos de prueba

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

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

• Personas
• 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

• Proyecto
• 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

• Producto
• 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

• 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
Priorizar los Casos de Uso
Arquitecto
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 pcs con windows
  95 y pocos recursos.

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

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

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
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
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
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
(No Transcript)
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
Planificar prueba
Encontrar actores y casos de uso
Estructurar el modelo de casos de uso
Ingeniero de pruebas
Analista de sistemas
Diseñar prueba
Evaluar prueba
Integrador de sistemas
Especificador de casos de uso
Detallar un caso de uso
Integrar sistemas
Definir ámbito del sistema
Ingeniero de pruebas de int.
Realizar prueba de integración
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
Implementación de la arquitectura
Priorizar los casos de uso
Arquitecto
Analizar un caso de uso
Diseñar un caso de uso
Ingeniero de casos de uso
Implementar pruebas
Diseñar una clase
Implementar un subsistema
Analizar una clase
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
• 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
• 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 gt80 40 - 80 20 - 40 lt10
Fase construcción 100 100 100 100 si se mantiene 100
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
• 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
• 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
Planificar prueba
Encontrar actores y casos de uso
Estructurar el modelo de casos de uso
Ingeniero de pruebas
Analista de sistemas
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
Ingeniero de pruebas de int.
Realizar prueba de integración
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
Implementación de la arquitectura
Priorizar los casos de uso
Arquitecto
Analizar un caso de uso
Diseñar un caso de uso
Ingeniero de casos de uso
Implementar pruebas
Diseñar una clase
Implementar un subsistema
Analizar una clase
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
• 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
Planificar prueba
Encontrar actores y casos de uso
Estructurar el modelo de casos de uso
Ingeniero de pruebas
Analista de sistemas
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.
Realizar prueba de integración
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
Implementación de la arquitectura
Priorizar los casos de uso
Arquitecto
Analizar un caso de uso
Diseñar un caso de uso
Ingeniero de casos de uso
Implementar pruebas
Diseñar una clase
Implementar un subsistema
Analizar una clase
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
• 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