un ejemplo: el proceso unificado de desarrollo · un ejemplo: el proceso unificado de desarrollo...
TRANSCRIPT
Ingeniería del Software 1
UN EJEMPLO: EL PROCESO UNIFICADO DE DESARROLLO
(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
Ingeniería del Software 2
Un ejemplo: el Proceso Unificado
• Características del Proceso Unificado• Flujos de trabajo fundamentales• Iteración genérica• Planificar• Gestionar los riesgos• Recursos• Evaluar
Ingeniería del Software 3
Un ejemplo: el Proceso Unificado
• Características del Proceso Unificado– UML– Basado en casos de uso– Centrado en la arquitectura– Iterativo-Incremental– Modelos del proceso
• Flujos de trabajo fundamentales• Iteración genérica• Planificar• Gestionar los riesgos• Recursos• Evaluar
Ingeniería del Software 4
El Proceso Unificado (UP)
• Unificación de tres metodologías de desarrollo basadas en el paradigma orientado a objetos.
– OOSE: Object Oriented Software Engineering (Casos de Uso) Jacobson, I.
– Booch (Diseño) Booch, G.
– OMT: Object Modeling Technique (Análisis) Rumbaugh, J.
Ingeniería del Software 5
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• Dirigido por casos de uso• Centrado en la arquitectura• Iterativo e incremental
Ingeniería del Software 6
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:– Elementos: bloques básicos– Relaciones: ligan los elementos– Diagramas: agrupan colecciones de elementos ligados,
aportando un significado adicional
Ingeniería del Software 7
UML - Elementos y relaciones
• Elementos:– Estructurales: Clases, Casos de Uso, – Comportamiento: Interacción, Estados...– Agrupación: Paquetes– Anotación: Notas
• Relaciones:– Dependencia (Relación de Uso)– Asociación (Relación estructural)– Generalización (Representación de la herencia.)– Realización
Ingeniería del Software 8
Estáticos(estructura)D. de ClasesD. de ObjetosD. de ComponentesD. de Despliegue
Dinámicos(comportamiento)Casos de UsoSecuenciaColaboraciónEstadosActividades
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.
Interacción
Ingeniería del Software 9
Diagrama de clases
Avión militar Avión comercial
Avión de carga Avión de pasajeros
Motor
Avión
1..4
1
Piloto Vendedor de billetes
Reserva
*
1
Vuelo*1
1..2
**1
Línea aérea
1
*
1
1..4 1..2
*
1
*1 * 1 *
*
1
{ disjunta, completa }
{ disjunta, completa }
Ingeniería del Software 10
Control y Análisis
Comm
Acceso a BD
CommRutinas de Coneccion
Comm
Interfaz de Terminal
Comm
Gestión de Cuentas
Comm
Diagramas de Componentes
Ingeniería del Software 11
Diagramas de Despliegue
Punto de Venta
Servidor Central
Terminal de Consulta
Gestión de Cuentas
C
Interfaz de Terminal
CRutinas de Coneccion
C
Rutinas de Coneccion
C
Interfaz de Terminal
C
Rutinas de Coneccion
C
Acceso a BD
C
Control y Análisis
C
Ingeniería del Software 12
Cliente
Venta Normal
Venta en RebajasVendedor
Venta en Oferta
Diagrama de casos de uso
Ingeniería del Software 13
Esperando t arjeta
Leyendo tarjeta
tar jeta int roducida
Esperando PIN
Validando PIN
PIN introducido( PIN )
Recogiendo tarjeta
Es perando opción
[ incorrec to ]
[ > 3 intentos ]
[ correcto ]
Ingresando
ingreso( importe )
Reintegrando
reintegro( importe )
Transferencia
transferencia( cuenta, importe )
Expulsando dinero
[ OK ]
Expulsar tarjeta
dinero retirado
[ Not OK ]
Diagrama de estados
Ingeniería del Software 14
: Cliente del banco : Interfaz de ca jero : Transacción
cuentaOrigen : Cuenta cuentaDestino : Cuenta
1: transferencia
2: tec lee cant idad
3: cantidad
4: teclee cuenta destino
5: cuenta dest ino
12: transferencia realizada
6: t rans ferencia (cuenta, cantidad)
11 : OK
7: reinteg ro (can tidad)
8: OK9: ingreso (cantidad)
10: OK
Diagrama de colaboración
Ingeniería del Software 15
Diagramas de Secuencia
: Socio : Encargado : Lib ro : Ficha libro : Ficha socio : Préstamo
Coger libro
Solic itar préstamo
Verificar s ituación socio
Sit uación socio ok
Verificar s ituación libro
Situación libro ok
Introducir préstamo
Aut orizar p rést amo
Ingeniería del Software 16
Emitir billete
Pasajero Vendedor Airline
Solicitar pago Reservar plazas
Confirmarplaza reservadaPagar pasaje
Informar alternativas y precios
Verificar existencia vuelo
Dar detalles vuelo
Solicitar pasaje
Seleccionar vuelo
Diagramas de actividad
Ingeniería del Software 17
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.
Ingeniería del Software 18
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,...
• 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
Ingeniería del Software 19
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. Caso de uso - subsistemas, clases y componentes.
– Evolución.
Ingeniería del Software 20
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 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.
Ingeniería del Software 21
...
Entrega
Ciclos
Concepción Elaboración TransiciónConstrucciónIter.
1Iter.
2 ... ...... ... ... ... Iter.n
FasesIterac.
Iterativo - Incremental
• Varios ciclos que concluyen con un producto.• Código fuente, manuales y documentos.• Hitos por fases (Milestones)
Ingeniería del Software 22
Diseño de Arquitectura
Implementación de Arquitectura
Estructura Modelo de Casos de Uso
Descubre Actoresy Casos de Uso
Analista deSistemas
Detalla un Caso de Uso
EspecificaCasos de Uso
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 TestUnitario
Implementa Test
EvaluaTest
Diseña Test
Ingeniero depruebas
Planifica Test
Integrador deSistemas
Integra Sistema
Ejecuta Testde Integración
Ejecuta test del sistema
El procesoPapeles y actividades
Ingeniero depruebas de integración
Ingeniero depruebas de
sistema
Ingeniería del Software 23
El procesoEl producto (salidas)
Modelo de análisis
Modelo de diseño
Modelo de despliegue
Modelo de implementación
Modelo de pruebas
Modelo de casos de uso
Especificado por
Realizado por
Distribuido por
Implementado por
Verificado 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
- 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
Ingeniería del Software 24
El procesoFases, iteraciones y actividades
Requisitos
Diseño
Implantación
Prueba
Análisis
PlanificaciónAnál. RiesgosPreparación
Elaboración ConstrucciónVerificación
Transición
FASESWorkflow
Iteración-esInicial-es
Iter. #1
Iter. #2
Iter. #3
Iter. #4
Iter. #5
Iter. #6
Iter. #7
(Adaptado de Jacobson, 1999)
Iteración en Fase de Elaboración
Ingeniería del Software 25
El procesoFases, iteraciones y actividades
• 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
• 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
Ingeniería del Software 26
El procesoFases, iteraciones y actividades
Ingeniería del Software 27
Un ejemplo: el Proceso Unificado
• Características del Proceso Unificado• Flujos de trabajo fundamentales
– Requisitos– Análisis– Diseño– Implementación– Pruebas
• Iteración genérica• Planificar• Gestionar los riesgos• Recursos• Evaluar
Ingeniería del Software 28
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– Las condiciones en las que se especifico un requisito varian
Ingeniería del Software 29
Captura de requisitos
• 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
Ingeniería del Software 30
Captura de requisitos
• Pasos a seguir– Enumerar los requisitos candidatos– Comprender el contexto del sistema– Capturar requisitos funcionales– Capturar requisitos no funcionales
• Se realizan de forma conjunta
Ingeniería del Software 31
Captura de requisitos
TAREAEnumerar requisitos candidatosEntender el contexto del sistemaCapturar requisitos funcionalesCapturar requisitos no funcionales
PRODUCTOS (artifact)
Lista de características
Modelo de negocio o de dominioModelo de casos de uso
Requisitos suplementarios o casos individuales
Ingeniería del Software 32
Artefactos de requisitos
• Modelo de casos de uso– Actores– Casos de uso– Varios diagramas para diferentes perspectivas
• Descripción de la arquitectura• Glosario• Prototipo de la interfaz de usuario
Sistema de casos de uso
Caso de uso
Modelo de casos de uso
1
* *
Actor
Ingeniería del Software 33
Artefactos de requisitos
GlosarioActor
Analista de sistemas
Modelo casos de uso
Especificadorde casos de uso
Caso de uso Descripción de la arquitectura
ArquitectoDiseñador de interfaz de usuario
Prototipo de interfaz de usuario
Ingeniería del Software 34
Flujo de trabajo de la captura de requisitos funcionales (Actividades)
Analista
Arquitecto
Especificador
Diseñador
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
Ingeniería del Software 35
Flujo de trabajo de la captura de requisitos funcionales (Actividades)• Encontrar actores y casos de uso
Analista
Encontrar actores y casos de uso
Glosario
Modelo del negocio
Modelo de casos de uso(esbozado)
Requisitos adicionales
Lista de característ.
Ingeniería del Software 36
Flujo de trabajo de la captura de requisitos funcionales (Actividades)
• Priorizar casos de uso
Arquitecto
Priorizar casos de uso Descripción de la
arquitectura (vista del modelo de casos de uso)
Modelo de casos de uso
Requisitos adicionales
Glosario
Ingeniería del Software 37
Flujo de trabajo de la captura de requisitos funcionales (Actividades)
• Detallar un caso de uso
Especificador de casos de uso
Detallar un caso de uso
Modelo de casos de uso
Requisitos adicionales
Glosario
Caso de uso(detallado)
Ingeniería del Software 38
Flujo de trabajo de la captura de requisitos funcionales (Actividades)
• Prototipar la interfaz de usuario
Diseñador de interfaz de usuario
Prototipar la interfaz de usuario
Modelo de casos de uso
Requisitos adicionales
Glosario
Prototipo de interfaz de usuario
Caso de uso(descrito)
Ingeniería del Software 39
Flujo de trabajo de la captura de requisitos funcionales (Actividades)
• Estructurar el modelo de casos de uso
Analista de sistemas
Estructurar el modelo de casos
de uso
Modelo de casos de uso
Requisitos adicionales
Glosario
Caso de uso(descrito)
Modelo de casos de uso
(estructurado)
Ingeniería del Software 40
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 disponibles y se termina el caso de uso
ACCIÓN DEL ACTOR
1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en el cajero
3. Introduce la clave
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!!
Ingeniería del Software 41
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.
5. Procesa la petición y da el dinero solicitado.
Devuelve la tarjeta y genera un recibo
ACCIÓN DEL ACTOR
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
Ingeniería del Software 42
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.
¡¡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
Ingeniería del Software 43
Ejemplo. Cajero automático
Sacar dinero
Ingresardinero
Transf.
Consultarsaldo
Validarusuario
Reponerdinero
Recogerdinero
Cliente del banco
Empleadosucursal
Sacar con visa
Usuario <<extends>>
R1
R4,...
R2, R3,...
Ingeniería del Software 44
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• Primera aproximación al modelo de diseño
Ingeniería del Software 45
Artefactos de análisis
Descripción de la arquitectura
Realización caso de uso -Análisis
Clase del análisis
Arquitecto
Modelo de análisis
Paquete del análisis
Ingeniero de componentes
Ingeniero de casos de uso
Ingeniería del Software 46
Artefacto: Modelo de Análisis
Sistema deanálisis
*
*
Realización caso de uso -Análisis
Clase del análisis
Paquete delanálisis
* * *
*
Ingeniería del Software 47
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
nivel mayor de abstracción.• Pueden clasificarse fácilmente en clases de entidad,
interfaz y de control.
Ingeniería del Software 48
Artefacto: Clases de Análisis
Clase del análisis
Clase de control
Clase de entidad
Clase de interfaz
Ingeniería del Software 49
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– Una descripción textual del flujo de sucesos
Ingeniería del Software 50
Artefacto: Realización de caso de uso-análisis (Diag. De Clases)
Comprador
Planificadorde Pagos
Gestor dePedidos
IU Solicitudde Pago
Confirmaciónde Pedido
Factura
Solicitudde Pago
Ingeniería del Software 51
Artefacto: Realización de caso de uso-análisis (Diag. De Colaboración)
:Planificadorde Pagos
:Gestor dePedidos
:IU Solicitudde Pago
:Confirmaciónde Pedido
:Factura
:Solicitudde Pago
:Comprador
1: Mostrar Facturas6: Planificar pago de Factura
3: Comprobar Factura 2: Mostrar
5: Obtener
4: Obtener
7:Planificar Pago
8: Obtener
9: establecerEstado(Planificado)
Ingeniería del Software 52
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 confirmaciones de pedido…”
Ingeniería del Software 53
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
Realización caso de uso -
Análisis
Clase del análisis
Paquete delanálisis
**
*
Ingeniería del Software 54
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 control, con amplia cobertura– Generales, centrales y con muchas relaciones
• Realizaciones de casos de uso
Ingeniería del Software 55
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 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
Ingeniería del Software 56
Actividades
Analizar un caso de uso
Arquitecto
Ingeniero de componentes
Ingeniero de casos de uso
Análisis de la arquitectura
Analizar una clase Analizar un paquete
Ingeniería del Software 57
Actividades: Análisis de la Arquitectura
Arquitecto
Análisis de la arquitectura
Modelo de casos de uso
Requisitos adicionales
Descripción de la arquitectura (vista del
modelo de casos de uso)
Paquete del análisis (esbozo)
Clase del análisis (esbozo)
Descripción de la arquitectura (vista del modelo de análisis)
Ingeniería del Software 58
Actividades: Analizar un caso de uso
Ingeniero de casos de uso
Analizar un caso de uso
Modelo de casos de uso
Requisitos adicionales
Descripción de la arquitectura (vista del modelo de análisis)
Clase del análisis (esbozo)
Realización caso de uso - análisis
Ingeniería del Software 59
Actividades: Analizar una clase
Ingeniero de componentes
Analizar una clase
Clase del análisis (esbozo)
Realización caso de uso - análisis
Clase del análisis (terminada)
Ingeniería del Software 60
Actividades: Analizar un paquete
Ingeniero de componentes
Analizar un paquete
Descripción de la arquitectura (vista del modelo de análisis)
Paquete del análisis(esbozo)
Paquete del análisis
(terminado)
Ingeniería del Software 61
Validar usuario Reali zación en aná li s is
UsuariosDelBanco
(from Logica l V iew)
A utenti car
(from L ogi ca l V ie w)
Interfaz de cajero
Análisis del caso de uso: “Validar usuario”
Ingeniería del Software 62
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)
: UsuariosDelBanco
5: valida (datos, codigo)
6: OK
7: visualiza (opciones)
8: seleccioneOpcion (opciones)
Ingeniería del Software 63
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)
: UsuariosDelBanco
5: valida (datos, codigo)
6: Error
7: visualiza (error)
8: teclear código
Ingeniería del Software 64
- 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
Ingeniería del Software 65
Análisis del caso de uso: “Transferencia”Secuencia correcta
: Cliente del banco : Interfaz de cajero : Transacción
cuentaOrigen : Cuenta cuentaDestino : Cuenta
1: transferencia
2: teclee cantidad
3: cantidad
4: teclee cuenta destino
5: cuenta destino
12: transferencia realizada
6: transferencia (cuenta, cantidad)
11: OK
7: reintegro (cantidad)
8: OK9: ingreso (cantidad)
10: OK
Ingeniería del Software 66
Análisis del caso de uso: “Transferencia”No hay saldo en la cuenta origen
: Cliente del banco : Interfaz de cajero : Transacción
cuentaOrigen : Cuenta
1: transferencia
2: teclee cantidad
3: cantidad
4: teclee cuenta destino
5: cuenta destino
10: no hay fondos
6: transferencia (cuenta, cantidad)
9: no hay fondos
7: reintegro (cantidad)
8: no hay saldo
Ingeniería del Software 67
Análisis del caso de uso: “Transferencia”No se puede acceder a la cuenta destino
: Cliente del banco : Interfaz de cajero : Transacción
cuentaOrigen : Cuenta cuentaDestino : Cuenta
11: rollback
1: transferencia
2: teclee cantidad
3: cantidad
4: teclee cuenta destino
5: cuenta destino
13: error
6: transferencia (cuenta, cantidad)
12: error
7: reintegro (cantidad)
8: OK9: ingreso (cantidad)
10: error
Ingeniería del Software 68
Modelo de clases de análisis
Cliente del banco Interfaz de cajero CuentaTransacción
UsuariosDelBancoAutenticar
Ingeniería del Software 69
Análisis de las clases
CLASE CUENTA.
Interviene en tres casos de uso: - sacar dinero
reintegro (importe)
- ingresar dineroingreso (importe)
- transferencialas dos operaciones anteriores
atributos - - > saldo
Ingeniería del Software 70
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
Ingeniería del Software 71
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.• 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.
• Es el centro de atención final de la fase de elaboración e iteraciones iniciales de la fase de construcción
Ingeniería del Software 72
Artefactos de diseño
Descripción de la arquitectura
Realización caso de uso -
diseño
Interfaz
Arquitecto
Modelo de diseño
Subsistema de diseño
Ingeniero de componentes
Ingeniero de casos de uso
Modelo de despliegue
Clases del
diseño
Ingeniería del Software 73
Artefactos de diseño: modelo de diseño
Sistema dediseño
*
Realización caso de uso - diseño
* * *
*
Clases del
diseño
Interfaz
*
Subsistema dediseñ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.
Ingeniería del Software 74
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
Ingeniería del Software 75
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)– Flujo de sucesos-diseño– Requisitos de implementación
Realización caso de uso - diseño
Realización caso de uso - análisis
«trace»
Ingeniería del Software 76
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 dediseño
*
Ingeniería del Software 77
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 dediseño
► realiza
*
*
Ingeniería del Software 78
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
Modelo de diseño
Descripción de la arquitectura
Ingeniería del Software 79
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 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
Modelo de despliegue
Nodo
*
Ingeniería del Software 80
Diseño: Actividades
Diseñar un caso de uso
Arquitecto
Ingeniero de componentes
Ingeniero de casos de uso
Diseño de la arquitectura
Diseñar una clase Diseñar un subsistema
Ingeniería del Software 81
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 Capturar requisitos de implementación
3. Diseñar una clase4. Diseñar un subsistema
Diseño: Actividades
Ingeniería del Software 82
Actividades: Diseño de la Arquitectura
Arquitecto
Diseño de la arquitectura
Modelo de casos de uso
Requisitos adicionales
Descripción de la arquitectura (vista del modelo de análisis)
Modelo de análisis
SubsistemaInterfaz
Modelo de despliegue
Clase de diseño
Descripción arquitectura (vista de modelo de diseño y despliegue)
Ingeniería del Software 83
Actividades: Diseño de un caso de uso
Diseñar un caso de uso
Ingeniero de casos de uso
Modelo de casos de uso
Requisitos adicionales
Modelo de despliegue
Subsistema
Interfaz
Clase de diseño
Modelo de análisis
Modelo de diseño
Realización casode uso - diseño
Ingeniería del Software 84
Actividades: Diseño de una clase
Ingeniero de componentes
Diseñar una clase
Interfaz
Clase de diseño
Realización casode uso - diseño
Clase de diseño(completa)
Clase del análisis(completa)
Ingeniería del Software 85
Actividades: Diseño de un Subsistema
Ingeniero de componentes
Diseñar un subsistema
Interfaz (terminada)
Subsistema (terminado)
Descripción arquitectura (vista modelo de diseño)
Interfaz (esbozada)
Subsistema (esbozado)
Ingeniería del Software 86
Val idar usuario
(from Use Case View)
Realización en diseño
LectorDeTarjetas
Pantalla
Teclado
GestorDeCliente Us uariosDelBanco
Transacción
Diseño del caso de uso: “Validar usuario”
Ingeniería del Software 87
: 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
6: leerPIN7: introduci rPIN (PIN)
8: datosPIN (PIN)
9: au tent ic a (datos , PIN)
10: valida (datos, PIN)
11: OK
13: visual iza (opciones)
12: almacenaDatos (datos)
14: visualizar (opciones)
Diseño del caso de uso: “Validar usuario”Secuencia correcta
Ingeniería del Software 88
: Cliente del banco :
Lect orDeTarjetas : Pantal la : Teclado
: GestorDeCliente : Transacción : UsuariosDelBanco
2: introduci rTarjeta (tarjet a)
7: introduci rPIN (PIN)
3: datosTarjeta (tarjeta)
4: vis ualizar ( In troduci r PIN)
1: leerTarjeta
5: OK
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
Diseño del caso de uso: “Validar usuario”Código incorrecto
Ingeniería del Software 89
- Suponemos que el usuario ya ha sido identificado (se ha ejecutadoel caso de uso anterior). Ahora selecciona la opción “transferencia”.
Transferencia
(from Use Case View)
Realización en diseño, transferenc ia
Teclado
Pantalla
GestorDeCliente Transacción CuentaCuentas
2
Diseño del caso de uso: “Transferencia”
Ingeniería del Software 90
: Cliente del banco : Teclado : Pantalla
: GestorDeCliente : Transacción : Cuentas : Cuen ta
1: opcion (transferencia)
4: IntroducirImporte
2: transferencia
3: visualizar (Teclee im port e)
5: importe
19 : vis ualizar (Transfe rencia real izada)
20: visuali zar (Reti re su tar jet a)
6: visual izar (Teclee cuent a destino)
9: t ransferencia (cuentaO rigen, cuen taDestino,import e)
10: reintegro (cuentaOrigen, importe)
11: reintegro (importe)
12: OK
13: OK
18: OK
7: cuentaDes tino (cuent a)
8: cuentaDestino (cuenta)
14: ingreso (cuentaDestino, importe)
15: ingreso (im porte)
16: OK17: OK
Diseño del caso de uso: ”Transferencia”Secuencia correcta
Ingeniería del Software 91
: Cliente del banco : Teclado : Pantalla
: GestorDeCliente : Transacción : Cuentas : Cuen ta
1: opcion (transferencia)
4: IntroducirImporte
7: cuentaDes tino (cuent a)
2: transferencia
3: visualizar (Teclee im port e)
5: importe
15: visualiz ar ((No hay fondos))
16: visuali zar (Reti re su tar jet a)
6: visual izar (Teclee 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
Diseño del caso de uso: ”Transferencia”No hay saldo en la cuenta origen
Ingeniería del Software 92
Modelo de clases de diseño
CajonDinero
Impresora
LectorDeTarjetas
Pantalla
Teclado
DarDinero
Cliente del banco
GestorDeCliente
Cuenta
UsuariosDelBanco
Transacción
Cuentas
Ingeniería del Software 93
CajonDinero
crearCajon() : CajonDineroabrirCajon()cerra rCajon()contarCantidad() : Dinero
LectorDeTarjetas
crearLec tor() : Lect orDeTarjetasleerTarjeta() : datosTarjeta
Pantalla
vis uali zar(m ensaje : St ring)c rearPantalla() : Pantal la
Teclado
crearTeclado() : TecladoleerPIN() : unPINleerOpcion() : 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
Ingeniería del Software 94
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) : 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
Ingeniería del Software 95
Esperando t arjeta
Leyendo tarjeta
tar jeta int roducida
Esperando PIN
Validando PIN
PIN introducido( PIN )
Recogiendo tarjeta
Es perando opción
[ incorrec to ]
[ > 3 intentos ]
[ correcto ]
Ingresando
ingreso( importe )
Reintegrando
reintegro( importe )
Transferencia
transferencia( cuenta, importe )
Expulsando dinero
[ OK ]
Expulsar tarjeta
dinero retirado
[ Not OK ]
Clase GestorDeCliente
Ingeniería del Software 96
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– 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)
Ingeniería del Software 97
Artefactos de implementación
Descripción de la arquitectura
Interfaz
Arquitecto
Modelo de implementac.
Implementac. subsistema
Ingeniero de componentes
Integrador de sistemas
Modelo de despliegue
Componente
Integración de sistema
Ingeniería del Software 98
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 programación utilizados)
• Cómo dependen los componentes unos de otros
Ingeniería del Software 99
Artefactos de implementación: Modelo de Implementación
Sistema deimplementac.
**
*
Interfaz
*
Subsistema deimplementac.
**
Componente
Ingeniería del Software 100
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:– 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).
Ingeniería del Software 101
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
Ingeniería del Software 102
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– 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.
► r
*
*
Interfaz
*
Subsistema deimplementac.
* *
Componente
Ingeniería del Software 103
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.
Interfaz
► realiza
Subsistema deimplementac.
► realiza
*
*
Componente
Ingeniería del Software 104
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 diseño significativas arquitectónicamente, y los ejecutables)
Ingeniería del Software 105
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)
– partes del modelo de implementación afectadas por la construcción (lista de los subsistemas y componentes necesarios para implementar esa funcionalidad)
Ingeniería del Software 106
Implementación: Actividades
Integrar sistemas
Arquitecto
Ingeniero de componentes
Integrador de sistemas
Implementación de la arquitectura
Implementar una clase
Implementar un subsistema
Realizar prueba de unidad
Ingeniería del Software 107
Actividades: Implementación de la Arquitectura
Arquitecto
Implementación de la arquitectura
Modelo de casos de uso
Modelo de análisis
Descripción arquitectura (vista de modelo de diseño y despliegue)
Componente (esbozado y asignado
a un nodo)
Descripción arquitectura (vista de modelo de
implement. y despliegue)
Ingeniería del Software 108
Actividades: Integrar el Sistema
Integrar sistemas
Integrador de sistemas
Modelo de casos de uso
Requisitos adicionales
Modelo de implementac.
Modelo de implementac.
Modelo de diseño
Plan de integración de construcciones
Ingeniería del Software 109
Actividades: Implementar un Subsistema
Ingeniero de componentes
Implementar un subsistema
Descripción arquitectura (vista de modelo de
implementación)
Plan de integración de construcciones
Subsistema de diseño
Interfaz
Subsistema de implementac.
Interfaz
Ingeniería del Software 110
Actividades: Implementar una Clase
Ingeniero de componentes
Implementar una clase Componente
(implementado)Interfaz
Clase de diseño(diseñada)
Ingeniería del Software 111
Actividades: Realizar una Prueba de Unidad
Ingeniero de componentes
Realizar prueba de unidad Componente
(unidades probadas)Interfaz
Clase de diseño(implementada)
Ingeniería del Software 112
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
– Realizar las diferentes pruebas.
Ingeniería del Software 113
Artefactos de pruebas• Modelo de pruebas• Casos de prueba• Procedimientos de prueba• Componentes de prueba• Plan de prueba• Defectos• Evaluación de la prueba
Sistema de pruebas
Componentede prueba
*
Caso de pruebaX X
Procedimientode prueba
Ingeniería del Software 114
1. Planificar prueba2. Diseñar prueba
– Describir casos de prueba de cada construcción– Identificar y estructurar los procedimientos de prueba
3. Implementar prueba4. Realizar pruebas de integración5. Realizar prueba de sistema6. Evaluar prueba
Flujo de trabajo de pruebas
Ingeniería del Software 115
Caso de uso Realizaciónen análisis
<<trace>>
Realizaciónen diseño
<<trace>>
Resumiendo...
Ingeniería del Software 116
Resumiendo...
<<trace>> (1:1)
Realizaciónen diseño
Realizaciónen implementación
<<trace>>
<<implem. subsystem>>
<<file>>
<<file>>
<<desing subsystem>>
Ingeniería del Software 117
Un ejemplo: el Proceso Unificado
• Características del Proceso Unificado• Flujos de trabajo fundamentales• Iteración genérica
– División del trabajo en fases
• Planificar• Gestionar los riesgos• Recursos• Evaluar
Ingeniería del Software 118
Iteración genérica
• Incluye:– Planificación– Flujos de trabajo fundamentales
• Requisitos• Análisis• Diseño• Implementación• Pruebas
– Evaluación
• El contenido varía para adaptarse al objetivo de cada fase.
Ingeniería del Software 119
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)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 (exploratorio)
Ingeniería del Software 120
División del trabajo en fases
• Fase de elaboración: factibilidad– Objetivo
• Arquitectura estable para guiar el sistema• Estimación de de costes para fases sisguientes con precisión
– Actividades: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.
Ingeniería del Software 121
División del trabajo en fases
• 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.
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.
Ingeniería del Software 122
División del trabajo en fases
• 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.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
Ingeniería del Software 123
Un ejemplo: el Proceso Unificado
• Características del Proceso Unificado• Flujos de trabajo fundamentales• Iteración genérica• Planificar
– Las fases– Las iteraciones– Los criterios de evaluación
• Gestionar los riesgos• Recursos• Evaluar
Ingeniería del Software 124
Planificar
Varias iteracionesen cuatro fases
Planificar
Experienciapasada
Plan de proyecto
Plan de iteración
Información sobreel sistema propuesto
Informacióndel dominio
Ingeniería del Software 125
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.– Plan de proyecto: fechas y criterios de objetivos principales y
división de fases en iteraciones
• Pensar a largo plazo
Ingeniería del Software 126
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• 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.
Ingeniería del Software 127
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– Lista de riesgos
Ingeniería del Software 128
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 generales (prototipo)• Productos intermedios para determinar el progreso del
trabajo
Ingeniería del Software 129
Un ejemplo: el Proceso Unificado
• Características del Proceso Unificado• Flujos de trabajo fundamentales• Iteración genérica• Planificar• Gestionar los riesgos
– Priorizar los casos de uso– Categorías de riesgos
• Recursos• Evaluar
Ingeniería del Software 130
Riesgos
• Lista de riesgos:– Identificador– Descripción– Prioridad (crítico, significativo, rutinario)– Impacto: qué parte del proyecto se ve afectada– Monitor: responsable del seguimiento– Responsabilidad: reponsable de eliminarlo– Contingencia: qué hacer si se materializa
• BD• Jefe de proyecto celebra reuniones periódicas para
revisar el estado de los riesgos
Ingeniería del Software 131
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– En cada fase o iteración se eliminan o se prepara plan de
contingencia– No planificarlos: modificaciones, retrasos– A veces no se descubren
Ingeniería del Software 132
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.
Ingeniería del Software 133
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:– Específicos– Arquitectónicos– De requisitos
Ingeniería del Software 134
Categorías de riesgos
• Específicos de un producto– Técnicos– Implementar un caso de uso mitiga el riesgo– Deben tratarse uno a uno (no está en el PU)
• 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
Ingeniería del Software 135
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
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
Ingeniería del Software 136
Un ejemplo: el Proceso Unificado
• Características del Proceso Unificado• Flujos de trabajo fundamentales• Iteración genérica• Planificar• Gestionar los riesgos• Recursos• Evaluar
Ingeniería del Software 137
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?– ...
Ingeniería del Software 138
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 elaboración.
Ingeniería del Software 139
Un ejemplo: el Proceso Unificado
• Características del Proceso Unificado• Flujos de trabajo fundamentales• Iteración genérica• Planificar• Gestionar los riesgos• Recursos• Evaluar
– Las fases– Las iteraciones
Ingeniería del Software 140
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
• 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
Ingeniería del Software 141
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
• Evolución del conjunto de modelos