Facultad de Informática Departamento de Lenguajes y Sistemas Informáticos e Ingeniería de...

1

Facultad de InformáticaDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería de Software

UNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRID

Proceso Unificado de desarrollo

O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –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


Contenido

Introducción al Proceso Unificado

Los flujos de trabajo fundamentales

Fases del proceso

Organización del proyecto


Introducción al Proceso Unificado


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.


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


El proceso Unificado: Estructura


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


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)


Un proceso dirigido por casos de uso

Sacar dinero

Modelo de casos de uso

Modelo de análisis

«trace»Sacar dinero

CuentaRetirada efectivo

Interfaz cajero

Salida

Realización de un caso de uso (análisis):



Cliente del banco

Sacar dinero

Ingresar dinero

Transferencia


Modelo de análisis

Retirada efectivo

Salida

Cliente del banco

Transferencia

IngresoReceptor dinero

Interfaz cajero

Cuenta



: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

Diagrama de colaboración para describir una realización:



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 análisis



Modelo de diseño



CuentaRetirada efectivoInterfaz cajeroSalida

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

«trace» «trace» «trace»«trace»

Modelo de análisis

Modelo de diseño



Cliente del banco


Sensor de salida

Teclado


Lector de tarjetas



Gestor de Cliente


CuentaGestor de Cuentas

Clase Persistente



: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 PINMostrar petición

Especificar código PINCódigo PIN

Validar código PINSolicitar cantidad a retirar

Mostrar petición

Especificar cantidad Cantidad(C)

Solicitar retirada cantidad(C)

Disponib. Saldo(C)



Las clases se agrupan en subsistemas

Cliente del banco


Sensor de salida

Teclado


Lector de tarjetas


Gestor de Cliente

«subsystem»Interfaz del CA

Cuenta

Gestor de Cuentas

Clase Persistente

«subsystem»Gestión de

Cuentas


«subsystem»Transacciones


«subsystem»Efectivo

IRetirada

IEntrega ITransferen



Modelo de implementación a partir del modelo de diseño

Sensor de salida



Gestor de Cliente

Modelo de diseño

Cliente.cpp

«file»

Cliente.exe

«exe»

Salida.cpp

«file»

Modelo de implementación

«compilation»

«trace»

«trace»



Pruebas Modelo de pruebas compuesto por:

Casos de prueba Procedimientos de prueba


Modelo de pruebas

Sacar dinero Sacar dinero

X«trace»


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


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


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


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



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



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


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



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



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



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


Los flujos de trabajo fundamentales


Tópicos

Artefactos

Trabajadores

Flujo de Trabajo


Work Flow de Requisitos


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.


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

n


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.


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


Work Flow de Requisitos

Analista de Sistemas

Arquitecto

Especificador CU

Diseñador de Interfaz de usuario Prototipar

la Interfaz de Usuario

Detallar los Casos de Uso

Priorizar los Casos de Uso

Encontrar Actores y Casos de Uso

Estructurar el Modelode Casos de Uso


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, …)


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


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)


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


¿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?


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.


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


Caso Práctico: Descripción de un Caso de UsoDescripción de Casos de Uso

Número: 001Nombre de Caso de Uso: “Matricular Asignaturas Sueltas”Actor(es): Alumno

DescripciónProceso 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.


Caso Práctico: Descripción de un Caso de UsoDescripción de Casos de Uso

Número: 002Nombre de Caso de Uso: “Logín”Actor(es): Alumno

DescripciónProceso 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.


Caso Práctico: Prototipo de la Interfaz de Usuario Caso de Uso Hacer

Matrícula


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


Work Flow de Análisis


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.


Work Flow de Análisis

Arquitecto

Ingeniero de casos de uso

Ingeniero de Componentes Analizar

una clase

Analizar un Caso de

Uso

Análisis de la

Arquitectura

Analizarun

paquete


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.


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


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)


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.


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.


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»


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


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.


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.


Modelo en tres Capas


Caso Práctico: Colaboraciones. Login ok


Caso Práctico: Colaboraciones. No Login


Work Flow de Diseño


Work Flow de Diseño

Arquitecto


Ingeniero de Componentes Diseñar

una clase

Diseñar un Caso de

Uso

Diseño de la

Arquitectura

Diseñar unsubsistema


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


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…


Work Flow de Implementación

Implementación


Work Flow de Implementación

Arquitecto

Integrador de sistemas

Ingeniero de Componentes

Implementar una clase

Integrar sistemas

Implementación de la

Arquitectura

Realizar prueba de unidad

Implementar un

subsistema


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


Work Flow de Pruebas

Pruebas


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”


Work Flow de Pruebas

Ingeniero de pruebas

Ingeniero de pruebas de integración

Ingeniero de pruebasde sistema

Ingeniero decomponentes Implementar

Prueba

Realizar pruebade sistema

Realizar Pruebade integración

Planificar Pruebas

Diseñar prueba Evaluar prueba


Fases del proceso


Desarrollo iterativo e incremental

76

Analista de sistemas

Encontrar actores y casos de uso

Priorizar los casos de uso

Detallar un caso de uso

Estructurar el modelo de casos de uso

Prototipar la interfaz de usuario

Arquitecto

Especificador de casos de uso

Diseñador de interfaces


Ingeniero de componentes

Analizar un caso de uso

Análisis de la arquitectura

Analizar una clase

Analizar un paquete

Diseño de la arquitectura

Diseñar un caso de uso

Diseñar una clase

Diseñar un subsistema

Integrar sistemas

Implementar un subsistema

Implementar una claseRealizar prueba de

unidad


Ingeniero de pruebas de sis.

Ingeniero de pruebas de int.


Diseñar prueba

Planificar prueba

Implementar pruebas

Realizar prueba de integración

Realizar prueba de sistema

Evaluar prueba

Implementación de la arquitectura


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


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







Arquitecto







Analizar una clase

Analizar un paquete



Diseñar una clase


Integrar sistemas



unidad





Diseñar prueba

Planificar prueba

Implementar pruebas



Evaluar prueba


Definir ámbito del sistema

Esbozar la arquitectura candidata


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


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


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


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% 100% 100% si se mantiene

100%


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


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



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








Arquitecto







Analizar una clase

Analizar un paquete



Diseñar una clase


Integrar sistemas



unidad





Diseñar prueba

Planificar prueba

Implementar pruebas



Evaluar prueba


Refinar mayor parte de requisitos

Desarrollar línea base de la arquitectura



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



Análisis Análisis de la arquitectura Analizar un caso de uso Analizar una clase Analizar un paquete



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



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



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



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


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.



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



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








Arquitecto







Analizar una clase

Analizar un paquete



Diseñar una clase


Integrar sistemas



unidad





Diseñar prueba

Planificar prueba

Implementar pruebas



Evaluar prueba


Se hace crecer el sistema



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



Análisis Puede no mantenerse Análisis de la arquitectura Analizar un caso de uso Analizar una clase Analizar un paquete



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



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



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



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


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


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


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


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


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


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


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


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


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

Facultad de Informática Departamento de Lenguajes y Sistemas Informáticos e Ingeniería de...

Documents

Transcript of Facultad de Informática Departamento de Lenguajes y Sistemas Informáticos e Ingeniería de...