un ejemplo: el proceso unificado de …is4-0910... · un ejemplo: el proceso unificado •...

UN EJEMPLO: EL PROCESO UNIFICADO DE DESARROLLO

(1ª parte)

Ingeniería del Software 1

(1ª parte)

The unified software development process, Ivar Jacobson, Grade Booch, James Rumbaug, Ed. Addison Wesley, 1999

El proceso unificado de desarrollo, Ivar Jacobson, Grade Booch, James Rumbaug, Ed. Addison Wesley, 1999

Un ejemplo: el Proceso Unificado

• Características del Proceso Unificado• Flujos de trabajo fundamentales• Iteración genérica• Planificar• Gestionar los riesgos


• Gestionar los riesgos• Recursos• Evaluar


• Características del Proceso Unificado– UML– Basado en casos de uso– Centrado en la arquitectura– Iterativo-Incremental– Modelos del proceso


– Modelos del proceso

• Flujos de trabajo fundamentales• Iteración genérica• Planificar• Gestionar los riesgos• Recursos• Evaluar

El Proceso Unificado (UP)

• Unificación de tres metodologías de desarrollobasadas en el paradigma orientado a objetos.

– OOSE: Object Oriented Software Engineering (Casos de Uso) Jacobson, I.

– Booch (Diseño) Booch, G.


– Booch (Diseño) Booch, G.

– OMT: Object Modeling Technique (Análisis) Rumbaugh, J.

El Proceso Unificado (UP)

• Es más que un proceso de desarrollo software– un marco de trabajo que puede especializarse

• Basado en componentes conectados a través de interfaces

• Utiliza UML - Unified Modeling Language


• Utiliza UML - Unified Modeling Language• Dirigido por casos de uso• Centrado en la arquitectura• Iterativo e incremental

UML

• UML es un lenguaje de modelado• Permite la construcción de distintos modelos

– Diagramas de Clase, Diagramas de Casos de Uso, etc. – Es autodescriptivo porque puede especificarse por medio de

un diagrama de clases de UML.

• Bloques de construcción:


• Bloques de construcción:– Elementos: bloques básicos– Relaciones: ligan los elementos– Diagramas: agrupan colecciones de elementos ligados,

aportando un significado adicional

UML - Elementos y relaciones

• Elementos:– Estructurales: Clases, Casos de Uso, – Comportamiento: Interacción, Estados...– Agrupación: Paquetes– Anotación: Notas

• Relaciones:


• Relaciones:– Dependencia (Relación de Uso)– Asociación (Relación estructural)– Generalización (Representación de la herencia.)– Realización

UML - Diagramas

• Ofrecen distintas perspectivas de una abstracción de la realidad

• Un mismo elemento puede aparecer en distintos diagramas

• En el modelo de un sistema no hay motivo para que aparezcan obligatoriamente todos los elementos.


Estáticos(estructura)D. de ClasesD. de ObjetosD. de ComponentesD. de Despliegue

Dinámicos(comportamiento)Casos de UsoSecuenciaColaboraciónEstadosActividades

aparezcan obligatoriamente todos los elementos.

Interacción

Diagrama de clases

Motor

Avión

1..4

1

Piloto Vendedor de billetes

Reserva

*

1

Vuelo*1

1..2

**1

1

1..4 1..2

*

1

*

1 * 1 *


Avión militar Avión comercial

Avión de carga Avión de pasajeros

Avión ReservaVuelo*1 *1

Línea aérea

1

*

1 * 1 *

*

1

{ disjunta, completa }

{ disjunta, completa }

Control y Análisis

CommentInterfaz de Terminal

Comment

Diagramas de Componentes


Acceso a BD

Comment

Rutinas de Coneccion

Comment

Gestión de Cuentas

Comment

Diagramas de Despliegue

Servidor Central


Comment

Acceso a BD

Comment

Control y Análisis

Comment


Punto de Venta

Terminal de Consulta

Gestión de Cuentas

Comment

Interfaz de Terminal

Comment

Rutinas de ConeccionComment


Comment

Interfaz de Terminal

Comment

Diagrama de casos de uso

Venta Normal


ClienteVenta en Rebajas

Vendedor

Venta en Oferta

Esperando t arjeta

Leyendo tarjeta

tarjeta int roducida

Esperando PIN

Validando PIN

PIN introducido( PIN )

Recogiendo tarjeta

[ incorrec to ]

Diagrama de estados


PINtarjeta

Es perando opción

[ > 3 intentos ]

[ correcto ]

Ingresando

ingreso( importe )

Reintegrando

reintegro( importe )

Transferencia

transferencia( cuenta, importe )

Expulsando dinero

[ OK ]

Expulsar tarjeta

dinero retirado

[ Not OK ]

: Cliente del banco : Interfaz de ca jero : Transacción

1: transferencia

3: cantidad

5: cuenta dest ino

6: t rans ferencia (cuenta, cantidad)

11 : OK

Diagrama de colaboración


: Cliente del banco : Interfaz de ca jero : Transacción

cuentaOrigen : Cuenta cuentaDestino : Cuenta

2: teclee cant idad

4: teclee cuenta destino

12: transferencia realizada

7: reinteg ro (can tidad)

8: OK

9: ingreso (cantidad)

10: OK

Diagramas de Secuencia

: Socio : Encargado : Lib ro : Ficha libro : Ficha socio : Préstamo

Coger libro

Solic itar préstamo


Solic itar préstamo

Verificar situac ión socio

Sit uación socio ok

Verificar situac ión libro

Situación libro ok

Introducir préstamo

Aut orizar p rést amo

Pasajero Vendedor Airline

Verificar existencia vuelo

Dar detalles vuelo

Solicitar pasaje

Diagramas de actividad


Emitir billete

Solicitar pago Reservar plazas

Confirmarplaza reservadaPagar pasaje

Informar alternativas y precios

Seleccionar vuelo

Dirigido por casos de uso

• Usuario: alguien o algo.• Una interacción con el usuario es un caso de uso. • Un caso de uso:

– Es una función del sistema que da al usuario un resultado útil.– Captura los requisitos funcionales.


• ¿Qué debe hacer el sistema para cada usuario?• Modelo de casos de uso.• Conducen el proceso de desarrollo:

– Modelos de diseño e implementación.– Pruebas.

• Se desarrollan y evolucionan junto a la arquitectura del sistema.

Centrado en la arquitectura

• Edificio: estructura, servicios, electricidad, fontanería,...• Agrupa aspectos estructurales y dinámicos

significativos• Influencias: plataforma (BBDD, SO, protocolo de

comunicación,...), aspectos legales, componentes reusables disponibles, requisitos no funcionales,...


reusables disponibles, requisitos no funcionales,...• Es una vista del diseño completo que hace visibles las

características principales.• ¿Cómo se relacionan casos de uso y arquitectura?

Función y forma

Centrado en la arquitectura

• Tareas:– Crear una arquitectura inicial no específica de los casos de

uso.– Trabajar con un conjunto seleccionado de casos de uso que

representan las tareas clave del sistema.


representan las tareas clave del sistema. Caso de uso - subsistemas, clases y componentes.

– Evolución.

Iterativo - Incremental

• División del proyecto.• Una iteración produce un incremento.• Iteraciones controladas.• Factores para la selección en una iteración:

– La iteración trata un grupo de casos que extienden la


– La iteración trata un grupo de casos que extienden la funcionalidad.

– La iteración trata los riesgos más importantes.

• Incremento no siempre es aditivo.• Cada iteración:

casos relevantes-diseño quiado por arquitectura-implementar-verificar

• Beneficios.

Entrega

Iterativo - Incremental

• Varios ciclos que concluyen con un producto.• Código fuente, manuales y documentos.• Hitos por fases (Milestones)


...Ciclos

Concepción Elaboración TransiciónConstrucción

Iter.1

Iter.2

... ...... ... ... ...Iter.n

Fases

Iterac.

Estructura Modelo de Casos de Uso

Descubre Actoresy Casos de Uso

Analista deSistemas

Detalla un Caso de Uso

EspecificadorCasos de Uso

Prototipo del Diseñador de

Evalua Test

Diseña Test

Ingeniero depruebas

Planifica Test

Integrador deSistemas

Integra Sistema

Ejecuta Test

El procesoTrabajadores y actividades

Ingeniero de


Diseño de Arquitectura

Implementación de Arquitectura

Prototipo del Interfaz de Usuario

Diseñador deInterface de Usuario

Análisis de Arquitectura

Prioriza Casos de Uso

Arquitecto

Diseña un Caso de Uso

Analiza un Caso de Uso

Ingeniero deCasos de Uso

Ingeniero deComponentes

Diseña una claseAnaliza

un Paquete

Analiza una Clase Diseña un

Subsistema

Implementa una clase

Implementa Subsistema

Ejecuta Test Unitario

Implementa Test

Ejecuta Test de Integración

Ejecuta test del sistema

Ingeniero depruebas de integración

Ingeniero depruebas de

sistema

El procesoEl producto (salidas)

Modelo de análisis

Modelo de diseño

Modelo de

Especificado por

Realizado por

Distribuido por

- Refina los casos de uso otorgándoles más detalle- Asigna la funcionalidad a un grupo de objetos

- Define la estructura estática del sistema.- Refleja los casos de uso como colaboraciones


Modelo de despliegue

Modelo de implementación

Modelo de pruebas

Modelo de casos de uso

Distribuido por

Implementado por

Verificado por

- Define la configuración de los nodos de procesamiento y las correspondencias entre ellos.

- Incluye los componentes (código fuente) y las relaciones entre los mismos

- Define los casos de prueba para validar los casos de uso

El procesoFases, iteraciones y actividades

Requisitos

Análisis

PlanificaciónAnál. RiesgosPreparación

Elaboración ConstrucciónVerificación

Transición

FASES

Workflow

Iteración en Fase de Elaboración


Diseño

Implantación

Prueba

Iteración-esInicial-es

Iter. #1

Iter. #2

Iter. #3

Iter. #4

Iter. #5

Iter. #6

Iter. #7

(Adaptado de Jacobson, 1999)


• Una Fase es un intervalo de tiempo entre dos hitos importantes del

proceso donde:

• Se cumple un conjunto definido de objetivos

• Se completan artefactos

• Se toman decisiones de continuar o no

• Iniciación, Elaboración, Construcción, Transición


• Iniciación, Elaboración, Construcción, Transición

• Dentro de cada fase hay varias iteraciones

• Una iteración representa un ciclo de desarrollo completo.

• El énfasis en cada flujo de trabajo es diferente dependiendo de la

fase


• Características del Proceso Unificado• Flujos de trabajo fundamentales

– Requisitos– Análisis– Diseño– Implementación


– Implementación– Pruebas

• Iteración genérica• Planificar• Gestionar los riesgos• Recursos• Evaluar

Captura de requisitos

• La captura de requisitos es complicada– Creamos código para otros– Los usuarios no los conocen y les cuesta especificarlos de

forma precisa– Suelen ser varios usuarios sin una visión global– Los requisitos cambian


– Los requisitos cambian– Las condiciones en las que se especifico un requisito varian


• Objetivo: guiar el desarrollo hacia el sistema correcto• El cliente debe ser capaz de leer y comprender el

resultado de la captura• El resultado ayuda al jefe de proyecto a planificar las

iteraciones y los recursos


• Usuarios muy diferentes• Puntos de partida Diferentes• Se deben reducir los riesgos


• Pasos a seguir– Enumerar los requisitos candidatos– Comprender el contexto del sistema– Capturar requisitos funcionales– Capturar requisitos no funcionales


• Se realizan de forma conjunta


TAREAEnumerar requisitos candidatosEntender el contexto

PRODUCTOS (artifact)

Lista de características

Modelo de negocio o de


Entender el contexto del sistemaCapturar requisitos funcionalesCapturar requisitos no funcionales

Modelo de negocio o de dominioModelo de casos de uso

Requisitos suplementarios o casos individuales

Artefactos de requisitos

• Modelo de casos de uso– Actores– Casos de uso– Varios diagramas para diferentes perspectivas

• Descripción de la arquitectura• Glosario


• Glosario• Prototipo de la interfaz de usuario

Sistema de casos de uso

Caso de uso

Modelo de casos de uso

1

* *

Actor

Artefactos de requisitos

Analista de

sistemas

Especificador

de casos de uso

ArquitectoDiseñador de

interfaz de usuario


GlosarioActorModelo casos

de uso

Caso de uso Descripción de

la arquitectura

Prototipo

de interfaz

de usuario

Flujo de trabajo de la captura de requisitos funcionales (Actividades)

Analista

Arquitecto

Encontrar actores y

casos de uso

Priorizar los casos de

Estructurar el modelo

de casos de uso


Arquitecto

Especificador

Diseñador

Priorizar los casos de

uso

Detallar un caso de

uso

Prototipar la interfaz

de usuario

Flujo de trabajo de la captura de requisitos funcionales (Actividades)• Encontrar actores y casos de uso

Analista de Modelo del Modelo de


Analista de

sistemas

Encontrar actores y

casos de uso

Glosario

Modelo del

negocioModelo de

casos de uso

(esbozado)

Requisitos

adicionales

Lista de

característ.


• Priorizar casos de uso

ArquitectoModelo de


Arquitecto

Priorizar casos de

usoDescripción de la

arquitectura (vista del

modelo de casos de uso)

Modelo de

casos de uso

Requisitos

adicionales

Glosario


• Detallar un caso de uso

Especificador de Modelo de


Especificador de

casos de uso

Detallar un caso de

uso

Modelo de

casos de uso

Requisitos

adicionales

Glosario

Caso de uso

(detallado)


• Prototipar la interfaz de usuario

Diseñador de

Modelo de

casos de uso


Diseñador de

interfaz de usuario

Prototipar la interfaz

de usuario

Requisitos

adicionales

Glosario

Prototipo

de interfaz

de usuarioCaso de uso

(descrito)


• Estructurar el modelo de casos de uso

Analista de

Modelo de

casos de uso


Analista de

sistemas

Estructurar el

modelo de casos

de uso

Requisitos

adicionales

Glosario

Caso de uso

(descrito)

Modelo de

casos de uso

(estructurado)

Caso de uso “Validar usuario”Flujo de eventos

RESPUESTA DEL SISTEMA

2. Pide la clave de identificación

4. Comprueba la clave

5. Si es válida presenta las opciones

ACCIÓN DEL ACTOR

1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en el cajero

3. Introduce la clave


5. Si es válida presenta las opciones disponibles y se termina el caso de uso

CAMINOS ALTERNATIVOS

Línea 3. El cliente cancela la transacciónLínea 4. La clave no es válida y se reinicia el caso de uso. Si ocurre tres veces se cancela la transacción y no se devuelve la tarjeta

¡¡HAY QUE DEFINIR ESTOS DOS FLUJOS DE EVENTOS!!

Caso de uso “Sacar dinero”Flujo de eventos

RESPUESTA DEL SISTEMA

1. Este caso de uso empieza cuando un Cliente ha sido identificadoPresenta las opciones de operaciones disponible

3. Pide la cantidad a retirar.

ACCIÓN DEL ACTOR

2. Selecciona la operación de


3. Pide la cantidad a retirar.

5. Procesa la petición y da el dinero solicitado.

Devuelve la tarjeta y genera un recibo

2. Selecciona la operación de Reintegro

4. Introduce la cantidad requerida

6. Recoge la tarjeta.

7. Recoge el recibo

8. Recoge el dinero y termina el CU

Caso de uso “Sacar dinero”Flujo de eventos

CAMINOS ALTERNATIVOS

• Línea 5: La cantidad solicitada supera el saldo. Se indica el error y se cancela la operación.

• Línea 5: La cantidad solicitada supera el límite diario. Se indica el error y se vuelve a pedir otra cantidad.

• Línea 5: En el cajero no hay dinero.


• Línea 5: En el cajero no hay dinero.

¡¡HAY QUE DEFINIR ESTOS TRES FLUJOS DE EVENTOS!!

Podríamos definir diagramas de estados

Requisito no funcional asociado al caso de uso Sacar dinero:El tiempo de respuesta para un cliente debe ser <30 sg en el 90% de los casos

Ejemplo. Cajero automático

Sacar dinero

Validarusuario

Sacar con visa

Usuario <<extend>>

R2, R3,...


Ingresardinero

Transf.

Consultarsaldo

Reponerdinero

Recogerdinero

Cliente del banco

Empleadosucursal

R1

R4,...

Análisis

• Se trabaja con conceptos• Especificación más precisa de los requisitos• Se utiliza el lenguaje de desarrolladores• Facilita comprensión, preparación,

modificación y mantenimiento de requisitos


modificación y mantenimiento de requisitos• Primera aproximación al modelo de diseño

Análisis

Modelo Casos Uso• Lenguaje del cliente.

• Vista externa del sistema.

• Estructurado por casos de uso. Estructura a la vista externa.

• Utilizado principalmente para el

Modelo Análisis• Lenguaje del desarrollador.

• Vista interna del sistema.

• Estructurado por clases. Estructura a la vista interna.


• Utilizado principalmente para el contrato entre desarrolladores y cliente.

• Puede contener redundancias, inconsistencias entre requisitos.

• Captura la funcionalidad del sistema.

• Los casos de uso se analizarán con más profundidad en análisis.

• Utilizado principalmente por los desarrolladores para entender cómo debe ser diseñado el SI.

• No debe contener redundancias e inconsistencias entre requisitos.

• Primera aproximación al diseño. Esboza cómo llevar a cabo la funcionalidad.

• Es el análisis de cada C.U.

Artefactos de análisis

Arquitecto Ingeniero de

componentesIngeniero de

casos de uso


Descripción de la

arquitectura

Realización caso

de uso -Análisis

Clase del

análisis

Modelo de

análisisPaquete del

análisis

Artefacto: Modelo de Análisis

Sistema de

análisis

*

Paquete del

análisis

*

Modelo de Análisis

1


*

Realización caso

de uso -Análisis

Clase del

análisis

* * *

Artefacto: Clases de Análisis

• Una clase de análisis representa una abstracción de una o mas clases del diseño del sistema

• Se centra en el tratamiento de los requisitos funcionales

• Son evidentes en el dominio del problema.• Sus atributos, operaciones y relaciones están a un


• Sus atributos, operaciones y relaciones están a un nivel mayor de abstracción.

• Pueden clasificarse fácilmente en clases de entidad, interfaz y de control.

Artefacto: Clases de Análisis

Clase del

análisis


Clase de

control

Clase de

entidad

Clase de

interfaz

Artefacto: Realización de caso de uso-análisis

• Define como se lleva a cabo y se ejecuta un caso de uso en términos de clases del análisis y de sus objetos de análisis en colaboración.

• Una realización de caso de uso queda definida por:– Diagramas de clases del análisis– Diagramas de interacción de objetos del análisis


– Diagramas de interacción de objetos del análisis– Una descripción textual del flujo de sucesos

Artefacto: Realización de caso de uso-análisis (Diag. De Clases)

Gestor de

Pedidos

Confirmación

de Pedido

Factura


Comprador

Planificador

de Pagos

IU Solicitud

de Pago

Factura

Solicitud

de Pago

Artefacto: Realización de caso de uso-análisis (Diag. De Colaboración)

:Gestor de

Pedidos

:Confirmación

de Pedido

:Factura

3: Comprobar Factura2: Mostrar

5: Obtener

4: Obtener


:Planificador

de Pagos

:IU Solicitud

de Pago

:Factura

:Solicitud

de Pago

:Comprador

1: Mostrar Facturas

6: Planificar pago de Factura

7:Planificar Pago

8: Obtener

9: establecerEstado(Planificado)

Artefacto: Realización de caso de uso-análisis: (Desc. Textual)

“ El comprador consulta a través del IU Solicitud de Pago las facturas gestionadas por el sistema para encontrar las recibidas (1,2). El IU Solicitud de Pago utiliza el Gestor de Pedidos para comprobar las facturas con sus correspondientes


comprobar las facturas con sus correspondientes confirmaciones de pedido…”

Artefacto: Paquete del análisis

• Proporcionan un medio para organizar los artefactos del modelo de análisis en piezas manejables.

• Son cohesivos y débilmente acoplados• Basados en los requisitos funcionales y en el dominio

del problema.• Generan subsistemas del diseño


• Generan subsistemas del diseño

Realización

caso de uso -

Análisis

Clase del

análisis

Paquete del

análisis

**

*

Artefacto: Descripción de la Arquitectura

• Contiene una Vista de la arquitectura del modelo de análisis

• Descomposición del modelo en paquetes• Clases fundamentales:

– De entidad, importante en dominio– De interfaz, comunicación importante


– De interfaz, comunicación importante– De control, con amplia cobertura– Generales, centrales y con muchas relaciones

• Realizaciones de casos de uso

Flujo de trabajo del análisis

1. Análisis de la arquitecturaIdentificar paquetes de análisis Identificar clases de entidadRequisitos comunes

2. Analizar (refinar) un caso de usoIdentificar clases de análisis


Identificar clases de análisis Describir interacciones entre los objetos del análisis Capturar req. especiales sobre la realización del CU

3. Analizar una claseIdentificar responsabilidades y atributosIdentificar relaciones: asoc., agreg. y gener.Capturar req. especiales sobre la realización del CU

4. Analizar un paquete

Actividades

Arquitecto

Análisis de la

arquitectura


Analizar un caso de

uso

Ingeniero de

componentes

Ingeniero de

casos de uso

Analizar una clase Analizar un paquete

Actividades: Análisis de la Arquitectura

Arquitecto

Modelo de

casos de uso

Requisitos

Paquete del

análisis (esbozo)


Análisis de la

arquitectura

Requisitos

adicionales

Descripción de la


modelo de casos de uso)

Clase del

análisis (esbozo)

Descripción de la


modelo de análisis)

Actividades: Analizar un caso de uso

Ingeniero de casos

de uso

Modelo de

casos de uso

Requisitos

Realización caso

de uso - análisis


Analizar un

caso de uso

Requisitos

adicionales

Descripción de la



Clase del

análisis (esbozo)

de uso - análisis

Actividades: Analizar una clase

Ingeniero de

componentesRealización caso

de uso - análisis


Analizar una

clase

Clase del

análisis (esbozo)

Clase del análisis

(terminada)

Actividades: Analizar un paquete

Ingeniero de

componentesDescripción de la




Analizar un

paquete


Paquete del

análisis(esbozo)

Paquete del

análisis

(terminado)

Análisis del caso de uso: “Validar usuario”

Validar usuario

Realización en análisis

Modelo de Casos de Uso Modelo de Análisis


Validar usuario

UsuariosDelBanco

(from Logical View)

Autenticar

(from Logical View)

Interfaz de cajero

Análisis del caso de uso: “Validar usuario” Secuencia correcta

: Interfaz de cajero: Cliente del banco

1: introducir tarjeta

2: teclear código

3: código

: Autenticar

4: autentica (datos, código)

7: visualiza (opciones)


: UsuariosDelBanco

5: valida (datos, codigo)

6: OK

8: seleccioneOpcion (opciones)

Análisis del caso de uso: “Validar usuario”. Código incorrecto

: Interfaz de cajero: Cliente del banco

1: introducir tarjeta

2: teclear código

3: código

: Autenticar

4: autentica (datos, código)

7: visualiza (error)


: UsuariosDelBanco

5: valida (datos, codigo)

6: Error

8: teclear código

- Suponemos que el usuario ya ha sido identificado (se ha ejecutadoel caso de uso anterior).

- Ahora selecciona la opción “transferencia”. Consideramos que lacuenta origen es la de la tarjeta y hay que teclear la destino.

- El importe y el número de cuenta destino deben darse juntos. Evitarcondiciones de carrera: mirar primero si hay saldo y luego sacar.

Análisis del caso de uso: “Transferencia”


Realización en análisis

Interfaz de cajero CuentaTransacción

Transferencia

Análisis del caso de uso: “Transferencia”Secuencia correcta

: Cliente del banco : Interfaz de cajero : Transacción

1: transferencia

3: cantidad

5: cuenta destino

6: transferencia (cuenta, cantidad)

11: OK




2: teclee cantidad


12: transferencia realizada

7: reintegro (cantidad)

8: OK9: ingreso (cantidad)

10: OK

Análisis del caso de uso: “Transferencia”No hay saldo en la cuenta origen

: Interfaz de cajero : Transacción

1: transferencia

3: cantidad

5: cuenta destino


9: no hay fondos



cuentaOrigen : Cuenta

2: teclee cantidad


10: no hay fondos

9: no hay fondos


8: no hay saldo

Análisis del caso de uso: “Transferencia”No se puede acceder a la cuenta destino


11: rollback

1: transferencia

3: cantidad

5: cuenta destino


12: error




2: teclee cantidad


13: error


8: OK9: ingreso (cantidad)

10: error

Modelo de clases de análisis

Cliente del banco Interfaz de cajero CuentaTransacción


UsuariosDelBancoAutenticar

Análisis de las clases

CLASE CUENTA.

Interviene en tres casos de uso: - sacar dinero

reintegro (importe)

- ingresar dinero


- ingresar dineroingreso (importe)

- transferencialas dos operaciones anteriores

atributos - - > saldo

Análisis de las clases

CLASE TRANSACCIÓN

Interviene en cuatro casos de uso: - validar usuario

autentica (datos, código)atributos - - > código cuenta


- sacar dineroretirarDinero (importe)

- ingresar dineroingresarDinero (importe)

- transferenciatransferencia (cuenta, cantidad)rollback

Diseño

• Se modela el sistema para que de soporte a los requisitos funcionales y no funcionales.

• Su entrada esencial es el modelo de análisis (una comprensión detallada de los requisitos)

• Propósitos:• Profundizar en la requisitos no funcionales y restricciones

dependientes de la plataforma.


dependientes de la plataforma.• Crear una entrada apropiada para la implementación• Descomponer los trabajos de implementación en partes mas

manejables y que permitan concurrencia.• Capturar las interfaces entre los subsistemas.• Notación común para reflexionar sobre el diseño.• Crear una abstracción de la implementación.

• Es el centro de atención final de la fase de elaboración e iteraciones iniciales de la fase de construcción

Diseño

Modelo Análisis• Abstracción del sistema.

• Genérico respecto al diseño (aplicable a varios diseños).

• 3 estereotipos conceptuales sobre las clases: interfaz, control y entidad.

• Menos formal y menos caro de

Modelo Diseño• Modelo físico. Plano de

implementación.

• No genérico. Específico para una implementación.

• Cualquier número de estereotipos físicos sobre las clases de diseño


• Menos formal y menos caro de desarrollar

• Bosquejo del diseño del sistema.

• No necesariamente tiene que estar mantenido durante todo el ciclo de vida del software.

• Entrada esencial para modelar el sistema.

físicos sobre las clases de diseño (depende del leng. programación)

• Más formal y más caro de desarrollar.

• Manifiesto del diseño del sistema.

• Debe ser mantenido durante todo el ciclo de vida del software.

• Da forma al sistema mientras intenta preservar la estructura definida por el modelo de análisis lo más posible.

Artefactos de diseño

Arquitect

o

Ingeniero de

componentesIngeniero de

casos de uso


Descripción de

la arquitectura

Realización

caso de uso -

diseño

InterfazModelo de

diseño

Subsistema de

diseño

Modelo de

despliegue

Clases

del

diseño

Artefactos de diseño: modelo de diseño

• Modelo de objetos UML que contiene el diseño de la aplicación.

• Describe la realización física de los casos de uso: como afectan los requisitos funcionales, no funcionales y otras restricciones.


Sistema de

diseño

*

Realización caso

de uso - diseño

* **

*

Clases

del

diseño

Interfaz

*

Subsistema de

diseño

**

Artefactos de diseño: Clase de diseño

• Sintaxis del lenguaje de programación• Visibilidad de atributos y operaciones (public, private,

protected)• Traducción de las relaciones• Métodos por pseudocódigo


• Estereotipos que se correspondan con construcciones del lenguaje de programación.

• Pueden realizar interfaces

Clases del

diseño

Interfaz

► realiza

Artefactos de diseño: Realización de un caso de uso-diseño

• Es una colaboración en el modelo de diseño que describe como se realiza un caso de uso en termino de clases y objetos de diseño

• Contenido:– Diagramas de clases de realización– Diagramas de interacción (clases, subsistemas, interfaces)


– Diagramas de interacción (clases, subsistemas, interfaces)– Flujo de sucesos-diseño– Requisitos de implementación

Realización caso

de uso - diseño

Realización caso

de uso - análisis

«trace»

Artefactos de diseño: Subsistema de Diseño

• Para organizar los artefactos del diseño en piezas mas manejables.

• Debe ser cohesivo y débilmente acoplado

*


► realiza

*

Realización caso

de uso - diseño

* *

Clases del

diseño

Interfaz

*

Subsistema de

diseño

*

Artefactos de diseño: Interfaz

• Se utilizan para especificar las operaciones que proporcionan las clases y subsistemas de diseño

• Separan la especificación de funcionalidad en término de operaciones de sus implementaciones en términos de métodos


Clases del

diseño

Interfaz

► realiza

Subsistema de

diseño

► realiza

*

*

Artefactos de diseño: Descripción de la Arquitectura

• Descomposición en subsistemas• Traza con clases de análisis• Clases fundamentales (abstractas)• Clases generales y centrales• Realizaciones de caso de uso


• Realizaciones de caso de uso

Modelo de

diseño

Descripción de

la arquitectura

Artefactos de diseño: Modelo de Despliegue

• Representa una correspondencia entre la arquitectura del Hardware y la arquitectura del Software

• Describe la distribución física del sistema en nodos de computo.

• Cada nodo representa un recurso de

Modelo de

despliegue


• Cada nodo representa un recurso de computo

• Las relaciones entre nodos representan medios de comunicación entre ellos.

• La funcionalidad de un nodo se determina por los componentes que se le asignan

Nodo

*

Diseño: Actividades

Creación modelos diseño y despliegue

(arquitecto)

Esbozo nodos del modelo de despliegue, subsistemas principales e interfaces, clases importantes

Realizar cada caso de uso en términos de clases y/o

Las realizaciones establecen los


en términos de clases y/o subsistemas de diseño(Ingeniero de casos de

uso)

establecen los requisitos de comportamiento para cada clase.

Definen para cada clase de diseño: atributos y

operaciones.(Ingeniero de componentes)

1. Diseño de la arquitecturaIdentificar nodos y configuración, subsistemas, clases

2. Diseñar un caso de usoIdentificar clases de diseño y subsistemas Distribuir comportamiento del CU



Distribuir comportamiento del CU Capturar requisitos de implementación

3. Diseñar una clase4. Diseñar un subsistema

Actividades: Diseño de la Arquitectura

ArquitectoModelo de

casos de uso

Requisitos

SubsistemaInterfaz

Clase de

diseño


Diseño de la

arquitectura

Requisitos

adicionales

Descripción de la



Modelo de

análisis

Modelo de

despliegue

diseño

Descripción arquitectura

(vista de modelo de

diseño y despliegue)

Actividades: Diseño de un caso de uso

Ingeniero de

casos de uso

Modelo de

casos de uso

Requisitos

adicionales Clase de

Realización caso

de uso - diseño


Diseñar un caso de

uso

adicionales

Modelo de

despliegue

Subsistema

Interfaz

Clase de

diseño

Modelo de

análisis

Modelo de

diseño

Actividades: Diseño de una clase

Ingeniero de

componentes

Realización caso

de uso - diseño


Diseñar una clase

Interfaz

Clase de

diseño

Clase de diseño

(completa)

Clase del análisis

(completa)

Actividades: Diseño de un Subsistema

Ingeniero de

componentes

Subsistema

(terminado)


(vista modelo de diseño)


Diseñar un

subsistema

Interfaz

(terminada)Interfaz

(esbozada)

Subsistema

(esbozado)

Diseño del caso de uso: “Validar usuario”

Validar usuario

(from Use Case View)

Realización en diseño


LectorDeTarjetas

Pantalla

Teclado

GestorDeCliente UsuariosDelBanco

Transacción

Diseño del caso de uso: “Validar usuario” Secuencia correcta

: Cliente del banco:

LectorDeTarjetas: Pantalla : Teclado

: GestorDeCliente : Transacción : UsuariosDelBanco

1: introducirTarjeta (tarjeta)

2: datosTarjeta (tarjeta)

3: visualizar (Introducir PIN)

4: OK


5: leerPIN6: introducirPIN (PIN)

7: datosPIN (PIN)

8: autentica (datos, PIN)

9: valida (datos, PIN)

10: OK

12: visualiza (opciones)

11: almacenaDatos (datos)

13: visualizar (opciones)

: Cliente del banco :

Lect orDeTarjetas : Pantal la : Teclado

: GestorDeCliente : Transacción : UsuariosDelBanco

2: introduci rTarjeta (tarjet a)3: datosTarjeta (tarjeta)

4: vis ualizar ( In troduci r PIN)

1: leerTarjeta

5: OK

Diseño del caso de uso: “Validar usuario” Código incorrecto


7: introduci rPIN (PIN)

6: leerPIN

8: datosPIN (PIN)

9: au tent ic a (datos , PIN)

10: valida (datos, PIN)

11: E rror

12: visualiza (error PIN)13: visuali zar (error PIN)

Hay más escenarios: anular transacción y tres intentos

- Suponemos que el usuario ya ha sido identificado (se ha ejecutadoel caso de uso anterior). Ahora selecciona la opción “transferencia”.

Diseño del caso de uso: “Transferencia”

Transferencia Realización en diseño, transferencia


(from Use Case View) transferencia

Teclado

Pantalla

GestorDeCliente Transacción CuentaCuentas

2

: Cliente del banco : Teclado : Pantalla

: GestorDeCliente : Transacción : Cuentas : Cuen ta

1: opcion (transferencia)

4: IntroducirImporte

2: transferencia

3: visu alizar (Teclee im port e)

5: importe

6: visual izar (Teclee cuent a destino)

7: cuentaDes tino (cuent a)

8: cuentaDestino (cuenta)

Diseño del caso de uso: ”Transferencia”Secuencia correcta


19 : vis ualizar (Transfe rencia real izada)

20: visu ali zar (Reti re su tar jet a)

9: t ransferencia (cuentaO rigen, cuen taDestino,import e)

10: reintegro (cuentaOrigen, importe)

11: reintegro (importe)

12: OK

13: OK

18: OK

14: ingreso (cuentaDestino, importe)

15: ingreso (im porte)

16: OK17: OK

: Cliente del banco : Tec lado : Pantalla

: GestorDeCliente : Transacc ión : Cuentas : Cuen ta

1: opcion (transferencia)

4: Introduc irImporte

2: transferencia

3: visualizar (Teclee im port e)

5: importe

6: visual izar (Tec lee cuent a destino)

Diseño del caso de uso: ”Transferencia”No hay saldo en la cuenta origen


7: cuentaDes tino (cuent a)

15: visualiz ar ((No hay fondos))

16: visuali zar (Reti re su tar jet a)

6: visual izar (Tec lee cuent a destino)

8: cuentaDestino (cuenta)

9: t ransferencia (cuentaO rigen, cuen taDestino,import e)

14: no hay fondos

10: reintegro (cuentaOrigen, importe)

13: no hay saldo

11: reintegro (importe)

12 : no hay saldo

Modelo de clases de diseño

CajonDinero

Impresora

LectorDeTarjetasCliente del banco

GestorDeCliente

UsuariosDelBanco

Transacción


Pantalla

Teclado

DarDinero

Cuenta

Cuentas

LectorDeTarjetas

crearLec tor() : Lect orDeTarjetasleerTar jeta() : datosTarjeta

Pantalla

vis uali zar(m ensaje : St ring)c rearPantalla() : Pantal la

Teclado

crearTeclado() : TecladoleerPIN() : unPIN

Gesto rDeCliente

Diseño de las clases


CajonDinero

crearCajon() : CajonDineroabrirCajon()cerra rCajon()contarCantidad() : Dinero

leerOpcion() : unaOpcionleerCantidad() : DineroleerNumCuenta() : unIDCuenta

DarDinero

crear() : DarDineroexpulsa r(im porte : Dinero)

Gesto rDeCliente

crear() : GestorDeClientecreaCajeroVi rtual()inic iarSesion()

Impresora

crearImpresora() : Im pres oraimprimir(mensaje : String)

Diseño de las clases

GestorDeClientemiTransaccion : Transacción

crear() : GestorDeClientecreaCajeroVirtual()iniciarSesion()visualizar(resultados : String)

TransacciónmiCliente : GestorDeClientedatosTarjeta : DatosTarjetanumIntentosFallidos : 1..3 = 0cuentas : Cuentasusuarios : UsuariosDelBanco

almacenarDatos(datos : DatosTarjeta)validar(importe : Dinero, cantidad : Dinero)autenticar(datos : DatosTarjeta, PIN : UnPIN) : BooleanretirarDinero(importe : Dinero) : BooleaningresarDinero(importe : Dinero) : Boolean


ingresarDinero(importe : Dinero) : Booleantrasnsferencia(cuentaOrigen : Cuenta, cuentaDestino : Cuenta, importe : Dinero) : Boolean

UsuariosDelBancousuarios : Dictionary

validar(datos : DatosTarjeta, PIN : UnPIN) : Boolean

Cuentascuentas : Dictionary

reintegro(cuenta : Cuenta, importe : Dinero) : Booleaningreso(cuenta : Cuenta, importe : Dinero) : Boolean

Cuentadatos : DatosCuentalimiteDiario : Dinero = 50000

reintegro(importe : Dinero) : Booleaningreso(importe : Dinero) : Boolean

Esperando t arjeta

Leyendo tarjeta

tarjeta int roducida

Esperando PIN

Validando PIN

PIN introducido( PIN )

Recogiendo tarjeta

[ incorrec to ]

Clase GestorDeCliente


PINtarjeta

Es perando opción

[ > 3 intentos ]

[ correcto ]

Ingresando

ingreso( importe )

Reintegrando

reintegro( importe )

Transferencia

transferencia( cuenta, importe )

Expulsando dinero

[ OK ]

Expulsar tarjeta

dinero retirado

[ Not OK ]

Implementación

• Se implementa el sistema en términos de componentes: ficheros de código fuente, scripts, ficheros de código binarios, ejecutables y similares.

• Objetivos:– planificar las integraciones de sistema necesarias en cada

iteración


iteración– distribuir el sistema asignando componentes ejecutables a

nodos en el diagrama de despliegue– implementar las clases y subsistemas encontrados durante el

diseño– probar los componentes individualmente, integrarlos

(compilándolos y enlazándolos en uno o más ejecutables)

Artefactos de implementación

Arquitecto Ingeniero de

componentesIntegrador de

sistemas


Descripción de la

arquitectura

InterfazModelo de

implementac.

Implementac.

subsistema

Modelo de

despliegue

Componente

Integración de

sistema

Artefactos de implementación: Modelo de Implementación

• Cómo los elementos del modelo de diseño (clases) se implementan en términos de componentes (ficheros de código fuente, ejecutables...)

• Cómo se organizan los componentes (de acuerdo con los mecanismos de estructuración y modularización del entorno de implementación y los lenguajes de


entorno de implementación y los lenguajes de programación utilizados)

• Cómo dependen los componentes unos de otros

Artefactos de implementación: Modelo de Implementación

Sistema de

implementac.

* *

Subsistema de

implementac.


**

Interfaz

**

Componente

Artefactos de implementación: Componente

• Empaquetamiento físico de los elementos de un modelo cada uno puede implementar varios elementos dependiendo del lenguaje que se utilice.

• Proporcionan las mismas interfaces que los elementos que implementan.

• Tienen:


• Tienen:– relaciones de traza con los elementos del diseño que

implementan.– dependencias de compilación entre ellos (unos deben haberse

compilado antes para poder compilar otros).

Artefactos de implementación: Componente

• <<executable>> programa que puede ser ejecutado en un nodo

• <<file>> fichero que contiene código fuente o datos• <<library>> librería estática o dinámica• <<table>> una tabla de base de datos


• <<document>> un documento

Componente

«trace»

Clase de

diseño

InterfazInterfaz

Artefactos de implementación: Subsistema de Implementación

• Forma de organizar los artefactos del modelo de implementación en trozos más manejables.

• Un subsistema puede estar formado por:– componentes– interfaces

* *


– interfaces– otros subsistemas (recursivamente)

• Se manifiestan a través de un mecanismo de empaquetamiento concreto de un entorno de implementación determinado.– Paquete en Java– Proyecto en VB– Etc.

► realiza

*

Interfaz

Subsistema de

implementac.

* *

Componente

Artefactos de implementación: Interfaz

• Un componente que implementa una interfaz debe implementar correctamente todas las operaciones del interfaz.

• Un subsistema que implementa una interfaz debe contener componentes que proporcionen la interfaz u otros subsistemas que la proporcionen.


otros subsistemas que la proporcionen.

Interfaz

► realiza

Subsistema de

implementac.

► realiza

*

*

Componente

Artefactos de implementación: Descripción de la arquitectura

• La descomposición del modelo de implementación en subsistemas, sus interfaces y las dependencias entre ellos (cómo vienen dados por los equivalentes del modelo de diseño suele ser innecesario representarlos)

• Componentes clave (los que tienen traza a clases de


• Componentes clave (los que tienen traza a clases de diseño significativas arquitectónicamente, y los ejecutables)

Artefactos de implementación: Plan de Integración de las Construcciones

• Describe la secuencia de construcciones necesarias en una iteración.

• Para cada construcción debe describir:– funcionalidad que se espera que sea implementada en esa

construcción (lista de casos de uso o escenarios o parte de ellos, también puede incluir requisitos adicionales)


ellos, también puede incluir requisitos adicionales)– partes del modelo de implementación afectadas por la

construcción (lista de los subsistemas y componentes necesarios para implementar esa funcionalidad)


Creación modelo de implementación

(arquitecto)

Planear las construcciones en la presente iteración(Integrador del sistema)

Construcción de los componentes para cada

construcción(Ingeniero de componentes)


Los componentes se prueban con pruebas de

unidad(Ingeniero de pruebas)

Integrar todos los componentes en una misma construcción.

(Integrador del sistema)

Pruebas de integración para cada construcción(Ingeniero de pruebas)

Implementación: Actividades

Arquitecto

Implementación de la

arquitectura


Integrar sistemas

Ingeniero de

componentes

Integrador de

sistemas

Implementar una

clase

Implementar un

subsistemaRealizar prueba de

unidad

Actividades: Implementación de la Arquitectura

ArquitectoModelo de

diseño Componente

(esbozado y asignado

a un nodo)


Implementación de la

arquitectura

Modelo de

despliegue


(vista de modelo de

diseño y despliegue)


(vista de modelo de

implement. y despliegue)

Actividades: Integrar el Sistema

Integrador de

sistemasModelo de

Requisitos

adicionales

Plan de integración


Integrar sistemas

Modelo de

casos de uso

Modelo de

implementac.Modelo de

implementac.

Modelo de

diseño


de construcciones

Actividades: Implementar un Subsistema

Ingeniero de

componentes


(vista de modelo de

implementación)


Subsistema de

implementac.


Implementar un

subsistema


de construcciones

Subsistema de

diseñoInterfaz

implementac.

Interfaz

Actividades: Implementar una Clase

Ingeniero de

componentes

Clase de diseño


Implementar una

clase Componente

(implementado)

Interfaz

Clase de diseño

(diseñada)

Actividades: Realizar una Prueba de Unidad

Ingeniero de

componentes


Realizar prueba de

unidad Componente

(unidades probadas)

Interfaz

Clase de diseño

(implementada)

Prueba

• Verificamos el resultado de la implementación probando cada construcción

• Objetivos de la prueba– Planificar las pruebas necesarias para cada iteración (pruebas

de sistema y pruebas de integración)– Diseñar e implementar las pruebas diseñando los casos de

prueba


prueba– Realizar las diferentes pruebas.

Artefactos de pruebas

• Modelo de pruebas• Casos de prueba• Procedimientos de prueba• Componentes de prueba• Plan de prueba• Defectos


• Defectos• Evaluación de la prueba

Sistema de pruebas

Componentede prueba

*

Caso de pruebaX

XProcedimiento

de prueba

1. Planificar prueba (estimar el esfuerzo en cada iteración) – Ingeniero de pruebas.

2. Diseñar prueba – Ingeniero de pruebas.– Describir casos de prueba.– Identificar y estructurar los procedimientos de prueba.

Flujo de trabajo de pruebas


– Identificar y estructurar los procedimientos de prueba.

3. Implementar prueba – Ingeniero de componentes.4. Realizar pruebas de integración para cada

construcción – Ingeniero pruebas integración. 5. Realizar prueba de sistema – Ingeniero de pruebas

de sistema6. Evaluar prueba

Caso de uso Realizaciónen análisis

<<trace>>

Realizaciónen diseño

<<trace>>

Resumiendo...


Resumiendo...

Realizaciónen diseño

Realizaciónen implementación

<<trace>>


<<trace>> (1:1)<<implem. subsystem>>

<<file>>

<<file>>

<<desing subsystem>>


• Características del Proceso Unificado• Flujos de trabajo fundamentales• Iteración genérica

– División del trabajo en fases

• Planificar


• Planificar• Gestionar los riesgos• Recursos• Evaluar

Iteración genérica

• Incluye:– Planificación– Flujos de trabajo fundamentales

• Requisitos• Análisis• Diseño


• Diseño• Implementación• Pruebas

– Evaluación

• El contenido varía para adaptarse al objetivo de cada fase.

División del trabajo en fases

• Fase de inicio: establecer viabilidad– Objetivo:

• Análisis del negocio: casos de uso fundamentales para el negocio

– Actividades:1. Delimitar el ámbito (interfaces con otros sistemas)


1. Delimitar el ámbito (interfaces con otros sistemas)2. Proponer una arquitectura especialmente en lo nuevo, arriesgado

o difícil (expresada en función de algunos modelos)3. Identificar riesgos críticos (los que afecten a la viabilidad)4. Demostrar a usuarios y clientes un prototipo (interfaz usuario)


• Fase de elaboración: factibilidad– Objetivo

• Arquitectura estable para guiar el sistema• Estimación de de costes para fases siguientes con precisión

– Actividades:1. Línea base de la arquitectura. Consiste en: modelos, descripción


1. Línea base de la arquitectura. Consiste en: modelos, descripción de la arquitectura e implementación ejecutable de la arquitectura.

2. Identificación de riesgos que pueden perturbar los planes y costes posteriores.

3. Especificar niveles para los atributos de calidad: fiabilidad y tiempo de respuesta.

4. Recopilar casos de uso para el 80% de los requisitos funcionales para planificar la fase de construcción.

5. Planificación: personal, coste.


• Fase de construcción– Objetivo

• Versión beta

– Actividades:1. Terminar la identificación, descripción y realización de todos los

casos de uso.


casos de uso.2. Finalizar el análisis, el diseño la implementación y pruebas.3. Mantener la integridad de la arquitectura.4. Monitorizar los riesgos críticos.


• Fase de transición: en el entorno del usuario– Objetivo

• Producto final

– Actividades:1. Preparar las actividades, por ejemplo, el lugar.2. Aconsejar sobre el entorno de funcionamiento.


2. Aconsejar sobre el entorno de funcionamiento.3. Manuales y documentos para la entrega.4. Ajustar el software al entorno del usuario.5. Corregir los defectos detectados en la versión beta.

• Lecciones aprendidas• Asuntos útiles para la versión siguiente


• Características del Proceso Unificado• Flujos de trabajo fundamentales• Iteración genérica• Planificar

– Las fases


– Las fases– Las iteraciones– Los criterios de evaluación


Planificar

Varias iteracionesen cuatro fases

Planificar

Plan de proyecto

Información sobreel sistema propuesto


Planificar

Experienciapasada

Plan de iteración

el sistema propuesto

Informacióndel dominio

Planificar las fases

• Establecer:– Asignaciones de tiempo y fecha de entrega por cada fase

(inestable hasta fin de elaboración)– Hitos principales y criterios de aceptación– Iteraciones por fase y qué se realiza en ellas. Depende de la

complejidad del sistema.


complejidad del sistema.– Plan de proyecto: fechas y criterios de objetivos principales y

división de fases en iteraciones

• Pensar a largo plazo

Planificar las iteraciones

• Definimos:– Planificación de la Iteración: cuanto tiempo, fecha de terminación.– Contenido de la Iteración: Contenido. Ya está esbozado en el plan del

proyecto pero al comenzar cada iteración se debe detallar:• Casos de uso• Riesgos técnicos que se deben identificar en forma de casos de uso• Cambios que han sufrido los requisitos o defectos encontrados


• Cambios que han sufrido los requisitos o defectos encontrados• Subsistemas que se deben implementar• Personal

• El plan de la iteración siguiente se va detallando.• El número de iteraciones de cada fase esta determinado por la

complejidad del sistema.

Planificar las iteraciones

• La 1ª iteración suele ser más difícil– Ajustar el PU al proyecto y seleccionar herramientas– Seleccionar personal y crear equipo. – Familiarizarlo con el proyecto y las herramientas– Entender el dominio


– Entender el dominio– Lista de riesgos

Planificar los criterios de evaluación

• Criterios para establecer la satisfacción de los objetivos de cada iteración (medidos u observados):– Requisitos funcionales en casos de uso– Requisitos no funcionales de esos requisitos funcionales– Requisitos no funcionales sueltos

• Requisitos verificables (pruebas)


• Requisitos verificables (pruebas)• Requisitos generales (prototipo)• Productos intermedios para determinar el progreso del

trabajo




• Gestionar los riesgos– Priorizar los casos de uso– Categorías de riesgos

• Recursos• Evaluar

Riesgos

• Lista de riesgos:– Identificador– Descripción– Prioridad (crítico, significativo, rutinario)– Impacto: qué parte del proyecto se ve afectada– Monitor: responsable del seguimiento


– Monitor: responsable del seguimiento– Responsabilidad: responsable de eliminarlo– Contingencia: qué hacer si se materializa

• Cuando tenemos cientos de riesgos - Base de Datos• Jefe de proyecto celebra reuniones periódicas para

revisar el estado de los riesgos

Riesgos

• Influencia en el plan de iteraciones – Desarrollar prototipo para conocer riesgo– Incrementar el esfuerzo– Prolongar la planificación– Calidad o rendimiento

• Planificar acciones sobre los riesgos cuando se


• Planificar acciones sobre los riesgos cuando se materializan– En cada fase o iteración se eliminan o se prepara plan de

contingencia– No planificarlos: modificaciones, retrasos– A veces no se descubren

Priorizar los casos de uso

• Los casos de uso (escenarios) guían las iteraciones• Se ordenan según el riesgo que conllevan• Evitar:

– cambiar la arquitectura– no satisfacer los requisitos (producto no correcto)


• Los riesgos se transforman en casos de uso que se priorizan

• Ej:– Riesgo: Dar dinero sin haber saldo– Caso de uso: habrá un escenario en que se solicite una

cantidad mayor que el saldo.

Priorizar los casos de uso

• Primeras iteraciones– Riesgos relacionados con el ámbito del sistema y arquitectura

• Últimas iteraciones– Añadir más funciones

• Categorías de riesgos:


– Técnicos– Arquitectónicos– De requisitos

Categorías de riesgos

• Técnicos– Relacionados con las nuevas tecnologías– Causados por no disponer de las técnicas necesarias para

llevar a cabo el caso de uso (reconocimiento lenguaje natural)– Deben tratarse uno a uno

• De requisitos


• De requisitos– Puede crecer– ¿Estamos desarrollando el producto correcto? – ¿Qué casos de uso aseguran que el sistema puede

evolucionar?– Solución: requisitos, modelo de negocio

» uso real en prototipos

Categorías de riesgos

• Arquitectónicos– No establecer una arquitectura flexible– Fases de inicio y elaboración– ¿Cómo determinar casos de uso importantes para la

arquitectura correcta?• Casos de uso críticos (los más importantes para los usuarios del


• Casos de uso críticos (los más importantes para los usuarios del sistema y los que tienen requisitos no funcionales como rendimiento, tiempo de respuesta,...)

– Otras categorías de casos de uso: secundarios, auxiliares, opcionales

– 80% de casos de uso descritos en elaboración para hacer la planificación detallada y estar seguros de haber considerado lo importante para la arquitectura

Recursos

• ¿Cuánto cuestan las fases de inicio y elaboración? ¿Quién las costea? ¿Cuánto duran?

• Depende del proyecto• Considerar:

– ¿Hay experiencia?


– ¿Cómo es la base de componentes?– ¿Es una nueva entrega?– ¿Es distribuido?– ...

Recursos

• Tiempo:– Inicio 5%, elaboración 20%, construcción 65%, transición 10%

• Recursos– Inicio 10%, elaboración 30%, construcción 50%, transición

10%

• Más incógnitas, más tiempo y recursos en inicio y


• Más incógnitas, más tiempo y recursos en inicio y elaboración.





– Las fases– Las iteraciones

Evaluar iteraciones y fases

• Jefe de proyecto (documento)• Objetivos:

– evaluar iteraciones según criterios: presupuesto, tiempo, requisitos de calidad, resultados de las pruebas

– reconsiderar el plan de la siguiente iteración– modificar el proceso– evaluar y modificar criterios


– evaluar y modificar criterios

• Es frecuente no alcanzar los criterios. Prolongar el trabajo a la iteración siguiente:– Modificar o extender el modelo de casos de uso– Modificar o extender la arquitectura– Modificar o extender los subsistemas desarrollados– Buscar otros riesgos– Incorporar ciertas habilidades al equipo– Puede que solo falte tiempo

La siguiente iteración

• A partir de la evaluación anterior, el jefe de proyecto:– Determina si se puede pasar a la siguiente iteración– Si hay que rehacer, cuándo– Planificar en detalle siguiente iteración– Actualizar el plan de las iteraciones posteriores a la siguiente– Actualizar riesgos y plan del proyecto


– Actualizar riesgos y plan del proyecto

• Evolución del conjunto de modelos

un ejemplo: el proceso unificado de …is4-0910... · un ejemplo: el proceso unificado •...

Documents