un ejemplo: el proceso unificado de …is4-0910... · un ejemplo: el proceso unificado •...
TRANSCRIPT
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
Ingeniería del Software 2
• Gestionar los riesgos• Recursos• Evaluar
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
Ingeniería del Software 3
– 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.
Ingeniería del Software 4
– 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
Ingeniería del Software 5
• 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:
Ingeniería del Software 6
• 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:
Ingeniería del Software 7
• 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.
Ingeniería del Software 8
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 *
Ingeniería del Software 9
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
Ingeniería del Software 10
Acceso a BD
Comment
Rutinas de Coneccion
Comment
Gestión de Cuentas
Comment
Diagramas de Despliegue
Servidor Central
Rutinas de Coneccion
Comment
Acceso a BD
Comment
Control y Análisis
Comment
Ingeniería del Software 11
Punto de Venta
Terminal de Consulta
Gestión de Cuentas
Comment
Interfaz de Terminal
Comment
Rutinas de ConeccionComment
Rutinas de Coneccion
Comment
Interfaz de Terminal
Comment
Diagrama de casos de uso
Venta Normal
Ingeniería del Software 12
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
Ingeniería del Software 13
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
Ingeniería del Software 14
: 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
Ingeniería del Software 15
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
Ingeniería del Software 16
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.
Ingeniería del Software 17
• ¿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,...
Ingeniería del Software 18
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.
Ingeniería del Software 19
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
Ingeniería del Software 20
– 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)
Ingeniería del Software 21
...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
Ingeniería del Software 22
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
Ingeniería del Software 23
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
Ingeniería del Software 24
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)
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
Ingeniería del Software 25
• 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
El procesoFases, iteraciones y actividades
Ingeniería del Software 26
Un ejemplo: el Proceso Unificado
• Características del Proceso Unificado• Flujos de trabajo fundamentales
– Requisitos– Análisis– Diseño– Implementación
Ingeniería del Software 27
– 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
Ingeniería del Software 28
– Los requisitos cambian– Las condiciones en las que se especifico un requisito varian
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
Ingeniería del Software 29
• Usuarios muy diferentes• Puntos de partida Diferentes• Se deben reducir los riesgos
Captura de requisitos
• Pasos a seguir– Enumerar los requisitos candidatos– Comprender el contexto del sistema– Capturar requisitos funcionales– Capturar requisitos no funcionales
Ingeniería del Software 30
• Se realizan de forma conjunta
Captura de requisitos
TAREAEnumerar requisitos candidatosEntender el contexto
PRODUCTOS (artifact)
Lista de características
Modelo de negocio o de
Ingeniería del Software 31
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
Ingeniería del Software 32
• 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
Ingeniería del Software 33
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
Ingeniería del Software 34
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
Ingeniería del Software 35
Analista de
sistemas
Encontrar actores y
casos de uso
Glosario
Modelo del
negocioModelo de
casos de uso
(esbozado)
Requisitos
adicionales
Lista de
característ.
Flujo de trabajo de la captura de requisitos funcionales (Actividades)
• Priorizar casos de uso
ArquitectoModelo de
Ingeniería del Software 36
Arquitecto
Priorizar casos de
usoDescripción de la
arquitectura (vista del
modelo de casos de uso)
Modelo de
casos de uso
Requisitos
adicionales
Glosario
Flujo de trabajo de la captura de requisitos funcionales (Actividades)
• Detallar un caso de uso
Especificador de Modelo de
Ingeniería del Software 37
Especificador de
casos de uso
Detallar un caso de
uso
Modelo de
casos de uso
Requisitos
adicionales
Glosario
Caso de uso
(detallado)
Flujo de trabajo de la captura de requisitos funcionales (Actividades)
• Prototipar la interfaz de usuario
Diseñador de
Modelo de
casos de uso
Ingeniería del Software 38
Diseñador de
interfaz de usuario
Prototipar la interfaz
de usuario
Requisitos
adicionales
Glosario
Prototipo
de interfaz
de usuarioCaso de uso
(descrito)
Flujo de trabajo de la captura de requisitos funcionales (Actividades)
• Estructurar el modelo de casos de uso
Analista de
Modelo de
casos de uso
Ingeniería del Software 39
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
Ingeniería del Software 40
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
Ingeniería del Software 41
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.
Ingeniería del Software 42
• 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,...
Ingeniería del Software 43
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
Ingeniería del Software 44
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.
Ingeniería del Software 45
• 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
Ingeniería del Software 46
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
Ingeniería del Software 47
*
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
Ingeniería del Software 48
• 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
Ingeniería del Software 49
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
Ingeniería del Software 50
– 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
Ingeniería del Software 51
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
Ingeniería del Software 52
: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
Ingeniería del Software 53
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
Ingeniería del Software 54
• 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
Ingeniería del Software 55
– 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
Ingeniería del Software 56
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
Ingeniería del Software 57
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)
Ingeniería del Software 58
Análisis de la
arquitectura
Requisitos
adicionales
Descripción de la
arquitectura (vista del
modelo de casos de uso)
Clase del
análisis (esbozo)
Descripción de la
arquitectura (vista del
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
Ingeniería del Software 59
Analizar un
caso de uso
Requisitos
adicionales
Descripción de la
arquitectura (vista del
modelo de análisis)
Clase del
análisis (esbozo)
de uso - análisis
Actividades: Analizar una clase
Ingeniero de
componentesRealización caso
de uso - análisis
Ingeniería del Software 60
Analizar una
clase
Clase del
análisis (esbozo)
Clase del análisis
(terminada)
Actividades: Analizar un paquete
Ingeniero de
componentesDescripción de la
arquitectura (vista del
modelo de análisis)
Ingeniería del Software 61
Analizar un
paquete
modelo de análisis)
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
Ingeniería del Software 62
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)
Ingeniería del Software 63
: 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)
Ingeniería del Software 64
: 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”
Ingeniería del Software 65
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
Ingeniería del Software 66
: Cliente del banco : Interfaz de cajero : Transacción
cuentaOrigen : Cuenta cuentaDestino : Cuenta
2: teclee cantidad
4: teclee cuenta destino
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
6: transferencia (cuenta, cantidad)
9: no hay fondos
Ingeniería del Software 67
: Cliente del banco : Interfaz de cajero : Transacción
cuentaOrigen : Cuenta
2: teclee cantidad
4: teclee cuenta destino
10: no hay fondos
9: no hay fondos
7: reintegro (cantidad)
8: no hay saldo
Análisis del caso de uso: “Transferencia”No se puede acceder a la cuenta destino
: Cliente del banco : Interfaz de cajero : Transacción
11: rollback
1: transferencia
3: cantidad
5: cuenta destino
6: transferencia (cuenta, cantidad)
12: error
Ingeniería del Software 68
: Cliente del banco : Interfaz de cajero : Transacción
cuentaOrigen : Cuenta cuentaDestino : Cuenta
2: teclee cantidad
4: teclee cuenta destino
13: error
7: reintegro (cantidad)
8: OK9: ingreso (cantidad)
10: error
Modelo de clases de análisis
Cliente del banco Interfaz de cajero CuentaTransacción
Ingeniería del Software 69
UsuariosDelBancoAutenticar
Análisis de las clases
CLASE CUENTA.
Interviene en tres casos de uso: - sacar dinero
reintegro (importe)
- ingresar dinero
Ingeniería del Software 70
- 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
Ingeniería del Software 71
- 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.
Ingeniería del Software 72
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
Ingeniería del Software 73
• 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
Ingeniería del Software 74
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.
Ingeniería del Software 75
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
Ingeniería del Software 76
• 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)
Ingeniería del Software 77
– 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
*
Ingeniería del Software 78
► 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
Ingeniería del Software 79
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
Ingeniería del Software 80
• 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
Ingeniería del Software 81
• 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
Ingeniería del Software 82
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
Diseño: Actividades
Ingeniería del Software 83
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
Ingeniería del Software 84
Diseño de la
arquitectura
Requisitos
adicionales
Descripción de la
arquitectura (vista del
modelo de análisis)
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
Ingeniería del Software 85
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
Ingeniería del Software 86
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)
Descripción arquitectura
(vista modelo de diseño)
Ingeniería del Software 87
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
Ingeniería del Software 88
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
Ingeniería del Software 89
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
Ingeniería del Software 90
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
Ingeniería del Software 91
(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
Ingeniería del Software 92
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
Ingeniería del Software 93
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
Ingeniería del Software 94
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
Ingeniería del Software 95
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
Ingeniería del Software 96
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
Ingeniería del Software 97
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
Ingeniería del Software 98
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
Ingeniería del Software 99
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
Ingeniería del Software 100
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.
Ingeniería del Software 101
**
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:
Ingeniería del Software 102
• 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
Ingeniería del Software 103
• <<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
* *
Ingeniería del Software 104
– 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.
Ingeniería del Software 105
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
Ingeniería del Software 106
• 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)
Ingeniería del Software 107
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)
Diseño: Actividades
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)
Ingeniería del Software 108
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
Ingeniería del Software 109
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)
Ingeniería del Software 110
Implementación de la
arquitectura
Modelo de
despliegue
Descripción arquitectura
(vista de modelo de
diseño y despliegue)
Descripción arquitectura
(vista de modelo de
implement. y despliegue)
Actividades: Integrar el Sistema
Integrador de
sistemasModelo de
Requisitos
adicionales
Plan de integración
Ingeniería del Software 111
Integrar sistemas
Modelo de
casos de uso
Modelo de
implementac.Modelo de
implementac.
Modelo de
diseño
Plan de integración
de construcciones
Actividades: Implementar un Subsistema
Ingeniero de
componentes
Descripción arquitectura
(vista de modelo de
implementación)
Plan de integración
Subsistema de
implementac.
Ingeniería del Software 112
Implementar un
subsistema
Plan de integración
de construcciones
Subsistema de
diseñoInterfaz
implementac.
Interfaz
Actividades: Implementar una Clase
Ingeniero de
componentes
Clase de diseño
Ingeniería del Software 113
Implementar una
clase Componente
(implementado)
Interfaz
Clase de diseño
(diseñada)
Actividades: Realizar una Prueba de Unidad
Ingeniero de
componentes
Ingeniería del Software 114
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
Ingeniería del Software 115
prueba– Realizar las diferentes pruebas.
Artefactos de pruebas
• Modelo de pruebas• Casos de prueba• Procedimientos de prueba• Componentes de prueba• Plan de prueba• Defectos
Ingeniería del Software 116
• 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
Ingeniería del Software 117
– 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...
Ingeniería del Software 118
Resumiendo...
Realizaciónen diseño
Realizaciónen implementación
<<trace>>
Ingeniería del Software 119
<<trace>> (1:1)<<implem. subsystem>>
<<file>>
<<file>>
<<desing subsystem>>
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
Ingeniería del Software 120
• Planificar• Gestionar los riesgos• Recursos• Evaluar
Iteración genérica
• Incluye:– Planificación– Flujos de trabajo fundamentales
• Requisitos• Análisis• Diseño
Ingeniería del Software 121
• 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)
Ingeniería del Software 122
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)
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 siguientes con precisión
– Actividades:1. Línea base de la arquitectura. Consiste en: modelos, descripción
Ingeniería del Software 123
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.
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.
Ingeniería del Software 124
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.
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.
Ingeniería del Software 125
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
Un ejemplo: el Proceso Unificado
• Características del Proceso Unificado• Flujos de trabajo fundamentales• Iteración genérica• Planificar
– Las fases
Ingeniería del Software 126
– Las fases– Las iteraciones– Los criterios de evaluación
• Gestionar los riesgos• Recursos• Evaluar
Planificar
Varias iteracionesen cuatro fases
Planificar
Plan de proyecto
Información sobreel sistema propuesto
Ingeniería del Software 127
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.
Ingeniería del Software 128
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
Ingeniería del Software 129
• 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
Ingeniería del Software 130
– 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)
Ingeniería del Software 131
• Requisitos verificables (pruebas)• Requisitos generales (prototipo)• Productos intermedios para determinar el progreso del
trabajo
Un ejemplo: el Proceso Unificado
• Características del Proceso Unificado• Flujos de trabajo fundamentales• Iteración genérica• Planificar• Gestionar los riesgos
Ingeniería del Software 132
• 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
Ingeniería del Software 133
– 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
Ingeniería del Software 134
• 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)
Ingeniería del Software 135
• 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:
Ingeniería del Software 136
– 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
Ingeniería del Software 137
• 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
Ingeniería del Software 138
• 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
Un ejemplo: el Proceso Unificado
• Características del Proceso Unificado• Flujos de trabajo fundamentales• Iteración genérica• Planificar• Gestionar los riesgos
Ingeniería del Software 139
• Gestionar los riesgos• Recursos• Evaluar
Recursos
• ¿Cuánto cuestan las fases de inicio y elaboración? ¿Quién las costea? ¿Cuánto duran?
• Depende del proyecto• Considerar:
– ¿Hay experiencia?
Ingeniería del Software 140
– ¿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
Ingeniería del Software 141
• Más incógnitas, más tiempo y recursos en inicio y elaboración.
Un ejemplo: el Proceso Unificado
• Características del Proceso Unificado• Flujos de trabajo fundamentales• Iteración genérica• Planificar• Gestionar los riesgos
Ingeniería del Software 142
• Gestionar los riesgos• Recursos• Evaluar
– 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
Ingeniería del Software 143
– 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
Ingeniería del Software 144
– Actualizar riesgos y plan del proyecto
• Evolución del conjunto de modelos