facultad de informática departamento de lenguajes y sistemas informáticos e ingeniería de...
TRANSCRIPT
1
Facultad de InformáticaDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería de Software
UNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRID
Proceso Unificado de desarrollo
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –2–
Objetivos
Ofrecer una visión general del proceso unificado, sus actividades y herramientas.
Presentar una visión simplificada del Lenguaje Unificado de Modelado (UML).
Aprender la noción de proceso y metodología en la Orientación a Objetos
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –3–
Contenido
Introducción al Proceso Unificado
Los flujos de trabajo fundamentales
Fases del proceso
Organización del proyecto
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –4–
Introducción al Proceso Unificado
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –5–
El proceso Unificado: ¿ Que es ?
Los sistemas son cada día más grandes, existe una tendencia generalizada, esto hace que los procesos iterativos e incrementales sean imprescindibles.
Es necesario un proceso común, un método que integre: Guía para ordenar las actividades de un equipo. Dirección de las tareas de cada desarrollador por
separado y del equipo como un todo. Especificación de los artefactos que deben ser
desarrollados. Criterios para el control y la medición de los productos
y actividades del proyecto.
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –6–
El proceso Unificado: Características
Está basado en componentes e interfaces bien definidas
Utiliza el Lenguaje Unificado de Modelado (UML)
Aspectos característicos: Dirigido por casos de uso Centrado en la arquitectura Iterativo e incremental
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –7–
El proceso Unificado: Estructura
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –8–
El Proceso Unificado Dirigido por casos de uso Caso de uso: Fragmento de funcionalidad que
proporciona al usuario un resultado importante Modelo de casos de uso: Funcionalidad total del
sistema ¿Qué debe hacer el sistema … para cada usuario? Guían todo el proceso de desarrollo En cada iteración se identifican e implementan unos
cuantos casos de uso Los casos de uso sirven para idear la arquitectura Se seleccionan los casos de uso más representativos Se utiliza como partida para escribir el manual de
usuario
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –9–
El Proceso Unificado Dirigido por casos de uso Modelo de análisis a partir de casos de uso
Crece incrementalmente Se especifican a través de diagramas de clases y de
colaboración Al principio se examinan unos pocos casos de uso y se
crean sus realizaciones Cada clasificador puede participar en varias realizaciones
distintas con distintos roles Clases estereotipadas de análisis (entorno, control y
entidad)
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –10–
Un proceso dirigido por casos de uso
Sacar dinero
Modelo de casos de uso
Modelo de análisis
«trace»Sacar dinero
CuentaRetirada efectivo
Interfaz cajero
Salida
Realización de un caso de uso (análisis):
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –11–
Un proceso dirigido por casos de uso
Cliente del banco
Sacar dinero
Ingresar dinero
Transferencia
Modelo de casos de uso
Modelo de análisis
Retirada efectivo
Salida
Cliente del banco
Transferencia
IngresoReceptor dinero
Interfaz cajero
Cuenta
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –12–
Un proceso dirigido por casos de uso
:Retirada efectivo
:Salida
:Cliente del banco
:Interfaz cajero
:Cuenta
1:Identificación
5: entrega dinero
2: solicitar retirada
4: autorizar entrega
3: validar y retirar
Diagrama de colaboración para describir una realización:
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –13–
Un proceso dirigido por casos de uso
Modelo de diseño a partir del modelo de análisis Se adapta al entorno de implementación Se define con los mismos diagramas El modelo de diseño es más “físico” y el modelo de
análisis más “conceptual”
Sacar dinero
Modelo de casos de uso
Modelo de análisis
«trace»Sacar dinero
«trace»Sacar dinero
Modelo de diseño
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –14–
Un proceso dirigido por casos de uso
CuentaRetirada efectivoInterfaz cajeroSalida
Dispositivo de visualización
Sensor de salida
Teclado
Alimentador de la salida
Lector de tarjetas
Contador de efectivo
Retirada de efectivo
Gestor de Cliente
Gestor de Transacciones
Cuenta
Gestor de Cuentas
Clase Persistente
«trace» «trace» «trace»«trace»
Modelo de análisis
Modelo de diseño
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –15–
Un proceso dirigido por casos de uso
Cliente del banco
Dispositivo de visualización
Sensor de salida
Teclado
Alimentador de la salida
Lector de tarjetas
Contador de efectivo
Retirada de efectivo
Gestor de Cliente
Gestor de Transacciones
CuentaGestor de Cuentas
Clase Persistente
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –16–
Un proceso dirigido por casos de uso
:Cliente del banco
:Dispositivo de visualización
:Teclado:Lector de tarjetas
:Contador de efectivo
:Gestor de Cliente
:Gestor de Transacciones
Introducir tarjeta
Tarjeta introducida(ID)
…
Solicitar PINMostrar petición
Especificar código PINCódigo PIN
Validar código PINSolicitar cantidad a retirar
Mostrar petición
Especificar cantidad Cantidad(C)
Solicitar retirada cantidad(C)
Disponib. Saldo(C)
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –17–
Un proceso dirigido por casos de uso
Las clases se agrupan en subsistemas
Cliente del banco
Dispositivo de visualización
Sensor de salida
Teclado
Alimentador de la salida
Lector de tarjetas
Contador de efectivo
Gestor de Cliente
«subsystem»Interfaz del CA
Cuenta
Gestor de Cuentas
Clase Persistente
«subsystem»Gestión de
Cuentas
Gestor de Transacciones
«subsystem»Transacciones
Retirada de efectivo
«subsystem»Efectivo
IRetirada
IEntrega ITransferen
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –18–
Un proceso dirigido por casos de uso
Modelo de implementación a partir del modelo de diseño
Sensor de salida
Alimentador de la salida
Contador de efectivo
Gestor de Cliente
Modelo de diseño
Cliente.cpp
«file»
Cliente.exe
«exe»
Salida.cpp
«file»
Modelo de implementación
«compilation»
«trace»
«trace»
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –19–
Un proceso dirigido por casos de uso
Pruebas Modelo de pruebas compuesto por:
Casos de prueba Procedimientos de prueba
Modelo de casos de uso
Modelo de pruebas
Sacar dinero Sacar dinero
X«trace»
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –20–
El Proceso Unificado Centrado en la arquitectura Describe diferentes vistas del
sistema
Incluye los aspectos estáticos y dinámicos más significativos
Es la forma del software
La arquitectura y los casos de uso evolucionan en paralelo
Se empieza por la parte que no es específica de los casos de uso
– Software del sistema
– Capa intermedia
– Sistemas heredados
– Estándares y políticas
– Requisitos no funcionales
– Necesidades de distribución
Casos de uso
Arquitectura
Experiencia
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –21–
Un proceso centrado en la arquitectura
La arquitectura se desarrolla principalmente en la fase de elaboración
¿Qué casos de uso tener en cuenta? Los que representen riesgos más importantes Los más importantes para el usuario Funcionalidades significativas
Línea base de la arquitectura Esqueleto con pocos músculos
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –22–
El Proceso Unificado Iterativo e incremental
Beneficios de un proceso iterativo controlado: Coste del riesgo a un solo incremento Reduce el riesgo de no sacar el producto en el calendario
previsto Acelera el ritmo de desarrollo Se adapta mejor a las necesidades del cliente
Se divide el trabajo en mini-proyectos Cada mini-proyecto es una iteración que resulta en un
incremento La iteración
Trata un conjunto de casos de uso Trata los riesgos más importantes
En cada iteración se persiguen unos objetivos concretos
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –23–
Un proceso iterativo e incremental
Iteración genérica: Planificación Requisitos Análisis Diseño Implementación Prueba Evaluación de la iteración
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –24–
Un proceso iterativo e incremental
Fases del proceso: Inicio: Objetivos del ciclo de vida
Establecer ámbito del sistema Reducir peores riesgos Preparar el análisis del negocio
Elaboración: Arquitectura del ciclo de vida Obtener línea base de la arquitectura Capturar mayoría de requisitos Reducir siguientes riesgos
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –25–
Un proceso iterativo e incremental
Fases del proceso Construcción: Funcionalidad operativa inicial
Desarrollo del sistema entero Transición: Versión del producto
Producto preparado para su entrega al usuario Se enseña a los usuarios a utilizarlo
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –26–
Personas, Proyecto, Producto y Proceso
Personas Arquitectos, desarrolladores, ingenieros de prueba, personal de
gestión, usuarios, clientes El proceso de desarrollo afecta a las personas (viabilidad,
gestión del riesgo, estructura de los equipos, planificación, comprensión, cumplimiento)
Formación, entrenamiento y experiencia De recurso a trabajador (puestos que asumen las personas) Cada trabajador tiene un conjunto de responsabilidades y lleva
a cabo un conjunto de actividades
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –27–
Personas, Proyecto, Producto y Proceso
Proyecto Elemento organizativo de gestión El proyecto construye el producto Secuencia de cambio. El sistema evoluciona Serie de iteraciones. Cada iteración implementa un
conjunto de casos de uso o atenúa algunos riesgos. Mini-proyecto
Patrón organizativo. Tipos de trabajadores y artefactos a conseguir
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –28–
Personas, Proyecto, Producto y Proceso
Producto Artefactos que se crean durante la vida del proyecto Artefactos: Modelos, código, ejecutables, documentación,
diagramas UML, bocetos de la interfaz de usuario, prototipos, componentes, planes de prueba
Artefactos de ingeniería y de gestión Colección de modelos
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –29–
Personas, Proyecto, Producto y Proceso
Proceso Conjunto de actividades para crear el producto Es una plantilla para crear proyectos (Instancia del
proceso) Se define en términos de flujos de trabajo (conjunto de
actividades) Se identifican trabajadores y artefactos Adaptación o especialización del proceso Se utilizan diagramas de actividad de UML para describir
los flujos de trabajo
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –30–
Los flujos de trabajo fundamentales
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –31–
Tópicos
Artefactos
Trabajadores
Flujo de Trabajo
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –32–
Work Flow de Requisitos
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –33–
Introducción
El esfuerzo principal en esta fase (requisitos) es desarrollar un modelo del sistema que se va a construir utilizando casos de uso y los límites bajo los cuales opera.
Los casos de uso son un medio intuitivo. Énfasis en el valor añadido que proporciona al
usuario. Descripción en tres pasos:
Artefactos a desarrollar, Trabajadores que participan y El flujo de trabajo.
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –34–
Artefacto
Pieza de información utilizada o producida por un proceso de desarrollo de software
Artefactos implicados durante la captura de requisitos
Modelo de Casos de Uso
Actor
Glosario
Caso de Uso
Prototipo de Interfaz de Usuario
Descripción de la Arquitectura
n
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –35–
Casos de Uso
¿Qué es un caso de uso? Un caso de uso es una secuencia de interacciones
entre uno o varios actores y el sistema que tiene lugar bajo ciertas circunstancias y que:
Es iniciada por un actor.
Se puede describir como una secuencia de actividades.
Produce un resultado de valor observable para algún actor.
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –36–
Casos de uso
Se capturan requisitos de usuario a través de casos de uso
Son fundamentales para: Identificar y especificar clases, subsistemas e interfaces Identificar y especificar casos de prueba Planificar las iteraciones e integración del sistema
Nos guían a través de los flujos de trabajo En cada iteración se identifican e implementan unos
cuantos casos de uso Los casos de uso sirven para idear la arquitectura Se seleccionan los casos de uso más representativos Se utiliza como partida para escribir el manual de
usuario
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –37–
Work Flow de Requisitos
Analista de Sistemas
Arquitecto
Especificador CU
Diseñador de Interfaz de usuario Prototipar
la Interfaz de Usuario
Detallar los Casos de Uso
Priorizar los Casos de Uso
Encontrar Actores y Casos de Uso
Estructurar el Modelode Casos de Uso
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –38–
Actividad: Encontrar actores y casos de uso Lista de características Se utiliza sólo para planificación Estructura de las características:
Nombre y breve descripción Estado (propuesto, aprobado, incluido,…) Coste estimado implementación Prioridad Nivel de riesgo (crítico, significativo, …)
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –39–
Actividad: Detallar un caso de uso
Alternativas: Precondición + Camino básico + Caminos alternativos +
Poscondición
Diagramas de estado
Diagramas de actividades
Diagramas de interacción
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –40–
Actividad: Estructurar los casos de uso
Identificar descripciones de funcionalidad compartida (herencia) Casos de uso reales Casos de uso abstractos
Identificar descripciones de funcionalidad adicional y opcional (extensión)
Otras relaciones (inclusión)
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –41–
Ejemplo
“Cuando el cliente inserta su tarjeta en el cajero, la pantalla del cajero le pide que seleccione un idioma. El cliente realiza su selección. El cajero pregunta entonces al cliente cuál es su número de identificación personal ...... el cliente recoge su dinero de la ranura del dispensador y saca su tarjeta de la ranura de tarjetas”.
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –42–
¿Por qué utilizar casos de uso?
Un caso de uso ayuda a contestar las siguientes preguntas:
¿Quién hace qué?
¿Cuándo lo hace?
¿Qué actividades se realizan?
¿Qué elementos del sistema se utilizan?
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –43–
Caso Práctico: Documento de Requisitos
Requisitos, Antecedentes, Objetivos y Alcance
Los requisitos iniciales se han obtenido directamente del cliente y usuario final. Se desea desarrollar una aplicación para dar soporte a la matriculación de los alumnos de una universidad.La aplicación debe dar soporte a las siguientes funcionalidades: - Un alumno puede matricularse de curso completo o de asignaturas sueltas. - Cada alumno se matricula para una asignatura en concreto en un grupo en concreto, durante un periodo
académico concreto. - Un profesor imparte una asignatura en un grupo - La aplicación debe incorporar la gestión de profesores, es decir, añadir un nuevo profesor, borrarlo o
modificar sus datos. - La aplicación debe permitir al administrador inscribir alumnos en la universidad. - Entendemos por inscripción crear su expediente, es decir, un alumno puede tener expediente pero no estar
matriculado. - Si el alumno se matricula de curso completo elegirá grupo y cursará todas las asignaturas en ese mismo
grupo. - También debe ser posible modificar el expediente de un alumno y en casos especiales borrarlo. - Todas las operaciones de borrado se realizan únicamente a nivel lógico. - La aplicación debe permitir al administrador crear nuevos grupos y también borrarlos. - La aplicación también debe dar soporte a la gestión de asignaturas, es decir, añadir, borrar y modificar. - El administrador también debe poder asignar un profesor a un grupo para una asignatura concreta. - La aplicación funcionará en pc’s con windows 95 y pocos recursos. - La aplicación debe funcionar con un esquema cliente servidor, central. - El sistema desarrollado debe ser lo más estándard posible. - Los alumnos se validarán para usar el sistema introduciendo su login y password en formulario.
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –44–
Caso Práctico: Casos de Uso (Vista Parcial)
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –45–
Caso Práctico: Descripción de un Caso de UsoDescripción de Casos de Uso
Número: 001Nombre de Caso de Uso: “Matricular Asignaturas Sueltas”Actor(es): Alumno
DescripciónProceso que sigue un alumno a la hora de matricular una o varias asignaturas
sueltas.
Flujo de Eventos- Entrada en el sistema- Selección de las asignaturas que desea- Realizar matrícula
Requerimientos Especiales: El actor no puede ser un alumno de nuevo ingreso.
Pre-Condiciones: Haber realizado un login exitoso en la aplicación.
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –46–
Caso Práctico: Descripción de un Caso de UsoDescripción de Casos de Uso
Número: 002Nombre de Caso de Uso: “Logín”Actor(es): Alumno
DescripciónProceso que sigue un alumno para entrar en el sistema.
Flujo de Eventos- Introducir el nombre de usuario- Introducir la password- Realizar Login
Requerimientos Especiales: El actor no puede ser un alumno de nuevo ingreso.
Pre-Condiciones: N/A.
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –47–
Caso Práctico: Prototipo de la Interfaz de Usuario Caso de Uso Hacer
Matrícula
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –48–
Caso Práctico: Prototipo de la Interfaz de Usuario Actividad: Login
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –49–
Work Flow de Análisis
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –50–
Objetivos de Análisis
Ofrecer una especificación más precisa de los requisitos que la que tenemos como resultado de los requisitos.
Estructurar los requisitos de un modo que facilita su compresión, su preparación, su modificación y en general su mantenimiento.
Considerar una primera aproximación al Diseño.
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –51–
Work Flow de Análisis
Arquitecto
Ingeniero de casos de uso
Ingeniero de Componentes Analizar
una clase
Analizar un Caso de
Uso
Análisis de la
Arquitectura
Analizarun
paquete
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –52–
Artefacto: MODELO DE ANÁLISIS
Las clases de análisis representan abstracciones de clases o subsistemas del diseño de sistema y dentro del modelo de análisis, los casos de uso se describen mediante clases de análisis y sus objetos.
Lo que se representa a través de colaboraciones dentro del modelo de análisis que llamamos realizaciones de caso de uso-análisis.
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –53–
Artefacto: CLASE DE ANÁLISIS
• Requisitos funcionales• Más evidente, mayor granularidad• Una clase de análisis, raramente define u ofrece un interface
en términos de operaciones y de sus signaturas. En cambio, su comportamiento se define mediante responsabilidades en un nivel más alto y menos formal.
• Una clase de análisis define atributos de un nivel bastante alto
• Una clase de análisis participa en relaciones, aunque se trata de relaciones más conceptuales
• Las clases de análisis siempre encaja en uno de tres estereotipos básicos: de interfaz, de control o de entidad
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –54–
Artefacto: CLASES DE INTERFAZ
Las clases de interfaz representan a menudo, abstracciones de ventanas, formularios, paneles , interfaces de comunicaciones, interfaces de impresoras, sensores, terminales, y API (posiblemente no orientados a objetos)
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –55–
Artefacto: CLASES DE ENTIDAD
Las clases de entidad se utilizan para modelar información que posee una vida larga y que es, a menudo, persistente. Suelen derivarse directamente de una clase de entidad del negocio.
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –56–
Artefacto: CLASES DE CONTROL
Las clases de control representan coordinación, secuencia, transacciones, y control de otros objetos y se usan frecuentemente para encapsular el control de un caso de uso en concreto.
Los aspectos dinámicos del sistema se modelan con clase de control, manejan y coordinan las acciones y los flujos de control principales, y delegan trabajo en otros objetos, es decir, objetos de interfaz y de entidad.
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –57–
Artefacto: REALIZACIÓN DE CASO DE USO-ANÁLISIS Una realización de caso de uso-análisis es una
colaboración dentro del modelo de análisis que describe cómo se lleva a cabo y se ejecuta un caso de uso determinado en términos de las clases de análisis y de sus objetos de análisis en interacción.
Una realización de caso de uso posee una descripción textual del flujo de sucesos, diagramas de clase que muestran sus clases de análisis participantes, y diagramas de interacción que muestran la realización de un flujo o escenario particular del caso de uso en términos de interacciones de objetos del análisis.
Realización caso de uso -Análisis
Caso de uso
«trace»
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –58–
ARTEFACTO: PAQUETE DE ANÁLISIS
Los paquetes del análisis proporcionan un medio de organizar los artefactos del modelo de análisis en piezas manejables. Un paquete de análisis puede constar de clases de análisis, de realización de casos de uso, y de otros paquetes de análisis (recursivamente).
Deben ser cohesivos y débilmente acoplados Tienen las siguientes características: Pueden representar una separación de intereses de análisis Han de crearse basándose en los requisitos funcionales y
en el dominio del problema Probablemente se convertirán en subsistemas Reglas de
negocio
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –59–
Diagramas de clases
Diagrama más común de modelado estructural.
Contiene: clases, interfaces, colaboraciones y relaciones.
Usos más comunes: Modelar el vocabulario del sistema. Modelar colaboraciones simples. Modelar el esquema lógico de una base de datos.
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –60–
Técnicas comunes de modelado de diagramas de clases Modelado de colaboraciones simples
Identificación de los mecanismos (funciones o comportamientos de la parte del sistema que se está modelando).
Para cada uno, encontrar las clases, interfaces y otras colaboraciones que participan en la colaboración, así como las relaciones entre ellos.
Usar escenarios para recorrer la interacción entre los elementos. Modelado de un esquema lógico de una base de datos
Identificar clases persistentes, representándolas con el valor etiquetado estándar {persistent}.
Expandir los detalles estructurales de dichas clases. Añadir abstracciones intermedias para simplificar la estructura
lógica. Separar el comportamiento de las clases persistentes en dos
bloques: comportamiento intrínseco y tratamiento de los datos.
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –61–
Modelo en tres Capas
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –62–
Caso Práctico: Colaboraciones. Login ok
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –63–
Caso Práctico: Colaboraciones. No Login
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –64–
Work Flow de Diseño
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –65–
Work Flow de Diseño
Arquitecto
Ingeniero de casos de uso
Ingeniero de Componentes Diseñar
una clase
Diseñar un Caso de
Uso
Diseño de la
Arquitectura
Diseñar unsubsistema
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –66–
Realización de caso de uso-diseño
Diagramas de clase
Diagramas de interacción (clases, subsistemas, interfaces)
Flujo de sucesos-diseño
Requisitos de implementación
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –67–
Clases de Diseño
A la hora de construir un modelo de diseño hay que tomar en consideración múltiples aspectos muy cercanos a la implementación como por ejemplo el lenguaje.
Hay que establecer la correspondencia entre las clases de análisis y las de diseño, a un nivel muy básico podríamos considerar simplemente: Clase de Entidad de Análisis Clase que almacena datos. Clase de Control de Análisis Clase que encapsula la
lógica. Clase de Interfaz de Análisis Formularios, Diálogos,
Ventanas…
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –68–
Work Flow de Implementación
Implementación
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –69–
Work Flow de Implementación
Arquitecto
Integrador de sistemas
Ingeniero de Componentes
Implementar una clase
Integrar sistemas
Implementación de la
Arquitectura
Realizar prueba de unidad
Implementar un
subsistema
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –70–
Actividad: Integrar sistemas
Construir el software incrementalmente Control de versiones Integración incremental El plan describe la secuencia de construcciones
necesarias en una iteración Funcionalidad de la construcción Partes del modelo de implementación afectados por la
construcción
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –71–
Work Flow de Pruebas
Pruebas
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –72–
Procedimiento de prueba
Cómo realizar uno o varios casos de prueba
Instrucciones para un individuo
Especificación de interacción manual
Componente de prueba Automatiza uno o varios procedimientos de prueba Puede utilizarse un “modelo de diseño de pruebas”
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –73–
Work Flow de Pruebas
Ingeniero de pruebas
Ingeniero de pruebas de integración
Ingeniero de pruebasde sistema
Ingeniero decomponentes Implementar
Prueba
Realizar pruebade sistema
Realizar Pruebade integración
Planificar Pruebas
Diseñar prueba Evaluar prueba
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –74–
Fases del proceso
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –75–
Desarrollo iterativo e incremental
76
Analista de sistemas
Encontrar actores y casos de uso
Priorizar los casos de uso
Detallar un caso de uso
Estructurar el modelo de casos de uso
Prototipar la interfaz de usuario
Arquitecto
Especificador de casos de uso
Diseñador de interfaces
Ingeniero de casos de uso
Ingeniero de componentes
Analizar un caso de uso
Análisis de la arquitectura
Analizar una clase
Analizar un paquete
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Integrar sistemas
Implementar un subsistema
Implementar una claseRealizar prueba de
unidad
Ingeniero de pruebas
Ingeniero de pruebas de sis.
Ingeniero de pruebas de int.
Integrador de sistemas
Diseñar prueba
Planificar prueba
Implementar pruebas
Realizar prueba de integración
Realizar prueba de sistema
Evaluar prueba
Implementación de la arquitectura
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –77–
Fase de inicio
Objetivo: Establece la viabilidad del proyecto Se fundamenta el análisis de negocio inicial:
Se delimita el ámbito del sistema Se propone o esboza una arquitectura del sistema Se identifican riesgos críticos Se demuestra a los usuarios la utilidad del sistema
propuesto Sistema rentable económicamente
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –78–
Fase de inicio
La mayor parte se realiza en el flujo de requisitos Ajuste del proyecto al entorno
Proceso + herramientas + servicios para proyectos Herramientas para los flujos de trabajo Herramientas para la gestión del proyecto
Identificar y mitigar/planificar riesgos críticos
79
Analista de sistemas
Encontrar actores y casos de uso
Priorizar los casos de uso
Detallar un caso de uso
Estructurar el modelo de casos de uso
Prototipar la interfaz de usuario
Arquitecto
Especificador de casos de uso
Diseñador de interfaces
Ingeniero de casos de uso
Ingeniero de componentes
Analizar un caso de uso
Análisis de la arquitectura
Analizar una clase
Analizar un paquete
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Integrar sistemas
Implementar un subsistema
Implementar una claseRealizar prueba de
unidad
Ingeniero de pruebas
Ingeniero de pruebas de sis.
Ingeniero de pruebas de int.
Integrador de sistemas
Diseñar prueba
Planificar prueba
Implementar pruebas
Realizar prueba de integración
Realizar prueba de sistema
Evaluar prueba
Implementación de la arquitectura
Definir ámbito del sistema
Esbozar la arquitectura candidata
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –80–
Fase de inicio
Requisitos Enumerar requisitos candidatos Comprender contexto del sistema Recopilar requisitos funcionales
Encontrar actores y casos de uso Priorizar casos de uso Detallar un caso de uso
Recoger requisitos no funcionales
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –81–
Fase de inicio
Análisis Se completa alrededor del 5% del modelo Análisis de la arquitectura Analizar un caso de uso
Diseño Diseño de la arquitectura Colaboraciones entre clases y subsistemas Identificar interfaces entre clases y subsistemas Elegir software del sistema y elementos del middleware
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –82–
Fase de inicio
Implementación No suele ser necesaria Implementación de un prototipo desechable
Prueba Los ingenieros de pruebas consideran qué pruebas se
requerirán Planes de prueba No se realizan pruebas
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –83–
Fase de inicio
Modelo negocio
Casos de uso identificados
Casos de uso descritos
Casos de uso analizados
Casos de uso diseñados,
implementados y probados
Fase inicio 50% -70% 50% 10% 5% Lo suficiente para el prototipo
Fase elaboración
Cerca del 100%
>80% 40% - 80% 20% - 40% <10%
Fase construcción
100% 100% 100% 100% si se mantiene
100%
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –84–
Fase de inicio
Productos de la fase: Lista de características Primera versión del modelo del negocio Primera versión del modelo de casos de uso, de análisis y
de diseño Descripción de la arquitectura candidata Prototipo exploratorio Lista inicial de riesgos y clasificación de casos de uso Plan para el proyecto Primer borrador del análisis del negocio
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –85–
Fase de elaboración
Dos grandes objetivos: Elaborar una arquitectura estable Conocer suficientemente el sistema como para planificar
en detalle la fase de construcción
Tareas básicas: Crear una línea base para la arquitectura Identificar riesgos significativos Especificar atributos de calidad Estudiar 80% de los requisitos funcionales
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –86–
Fase de elaboración
Objetivos: Recopilar la mayor parte de los requisitos Establecer la línea base de la arquitectura Controlar riesgos críticos e identificar riesgos
significativos Completar detalles del plan del proyecto
Planificación de la fase Formación del equipo
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –87–
Analista de sistemas
Encontrar actores y casos de uso
Priorizar los casos de uso
Detallar un caso de uso
Estructurar el modelo de casos de uso
Prototipar la interfaz de usuario
Arquitecto
Especificador de casos de uso
Diseñador de interfaces
Ingeniero de casos de uso
Ingeniero de componentes
Analizar un caso de uso
Análisis de la arquitectura
Analizar una clase
Analizar un paquete
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Integrar sistemas
Implementar un subsistema
Implementar una claseRealizar prueba de
unidad
Ingeniero de pruebas
Ingeniero de pruebas de sis.
Ingeniero de pruebas de int.
Integrador de sistemas
Diseñar prueba
Planificar prueba
Implementar pruebas
Realizar prueba de integración
Realizar prueba de sistema
Evaluar prueba
Implementación de la arquitectura
Refinar mayor parte de requisitos
Desarrollar línea base de la arquitectura
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –88–
Fase de elaboración
Recopilar requisitos Encontrar casos de uso y actores adicionales Desarrollar prototipos de interfaces de usuario Determinar prioridad de los casos de uso Detallar un caso de uso Estructurar el modelo de casos de uso
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –89–
Fase de elaboración
Análisis Análisis de la arquitectura Analizar un caso de uso Analizar una clase Analizar un paquete
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –90–
Fase de elaboración
Diseño Diseño de la arquitectura
Identificar la arquitectura en capas Identificar subsistemas y sus interfaces Identificar clases significativas Si es un sistema distribuido, identificar nodos
Diseñar un caso de uso Diseñar una clase Diseñar un subsistema
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –91–
Fase de elaboración
Implementación Implementación de la arquitectura Implementación de una clase y de un subsistema Integrar el sistema
Pruebas Planificar las pruebas Diseñar las pruebas Realizar pruebas de integración y pruebas de sistema
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –92–
Fase de elaboración
Análisis del negocio Evaluación de la fase de elaboración Planificación de la fase de construcción
Se planifica en detalle la 1ª iteración Se esboza el plan de las siguientes
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –93–
Fase de elaboración
Productos Modelo del negocio completo Versión de los modelos Línea base de la arquitectura Lista de riesgos actualizada Plan de proyecto para construcción y transición Manual de usuario (opcional) Análisis del negocio completo
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –94–
Fase de construcción
Objetivo: La capacidad de operación inicial Versión beta Requiere mayor número de iteraciones Tareas básicas:
Extensión a todos los casos de uso Finalización del análisis, diseño, implementación y
prueba Mantenimiento de la integridad de la arquitectura Monitorización de los riesgos críticos y significativos.
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –95–
Fase de construcción
Versión beta Se detallan todos los casos de uso Se modifica la descripción de la arquitectura Se terminan todos los modelos Es la fase del desarrollo Se mitigan todos los riesgos excepto los de
operación
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –96–
Fase de construcción
Esta fase comienza con la firma del contrato Asignación de personal Se divide el trabajo atendiendo a subsistemas e
interfaces Se preparan primeras versiones de manuales de
usuario y cursos de formación
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –97–
Analista de sistemas
Encontrar actores y casos de uso
Priorizar los casos de uso
Detallar un caso de uso
Estructurar el modelo de casos de uso
Prototipar la interfaz de usuario
Arquitecto
Especificador de casos de uso
Diseñador de interfaces
Ingeniero de casos de uso
Ingeniero de componentes
Analizar un caso de uso
Análisis de la arquitectura
Analizar una clase
Analizar un paquete
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Integrar sistemas
Implementar un subsistema
Implementar una claseRealizar prueba de
unidad
Ingeniero de pruebas
Ingeniero de pruebas de sis.
Ingeniero de pruebas de int.
Integrador de sistemas
Diseñar prueba
Planificar prueba
Implementar pruebas
Realizar prueba de integración
Realizar prueba de sistema
Evaluar prueba
Implementación de la arquitectura
Se hace crecer el sistema
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –98–
Fase de construcción
Requisitos Encontrar casos de uso y actores: pequeña fracción Desarrollar prototipos de interfaces de usuario Determinar prioridad de los casos de uso Detallar un caso de uso: todos Estructurar el modelo de casos de uso: sólo para los casos
de uso no desarrollados
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –99–
Fase de construcción
Análisis Puede no mantenerse Análisis de la arquitectura Analizar un caso de uso Analizar una clase Analizar un paquete
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –100–
Fase de construcción
Diseño Diseño de la arquitectura: prácticamente no se modifica Las otras tres tareas se realizan para el resto de los casos
de uso (cerca del 90%) Diseñar un caso de uso Diseñar una clase Diseñar un subsistema
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –101–
Fase de construcción
Implementación Implementación de la arquitectura: se actualiza si es
necesario Implementación de una clase y de un subsistema: se
pueden utilizar stubs Pruebas de unidad: podrá requerir corregir el diseño y la
implementación del componente Integrar el sistema: por capas. Define período de las
construcciones
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –102–
Fase de construcción
Pruebas Planificar las pruebas Diseñar las pruebas Realizar pruebas de integración: después de cada
construcción Realizar pruebas de sistema: hacia el final de las
iteraciones Evaluar las pruebas
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –103–
Fase de construcción
Productos El plan de proyecto para la fase de transición El sistema software ejecutable Todos los artefactos La descripción de la arquitectura actualizada Versión preliminar del manual de usuario Análisis del negocio actualizado
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –104–
Fase de transición
Objetivo: Entrega del producto final Tareas básicas:
Preparar el lugar y actualizar el entorno Preparar manuales Ajustar el software al entorno del usuario Corregir defectos de la versión beta Evaluar y registrar las “lecciones aprendidas” Registrar asuntos útiles para la versión siguiente
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –105–
Fase de transición
Se completa la versión del producto Se gestionan los aspectos relativos al entorno del
cliente Se corrigen los defectos de la versión beta Se terminan los manuales de usuario y cursos de
formación La atención se desplaza a la corrección de
defectos
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –106–
Fase de transición
Preparar la versión beta Instalación Adaptar el producto a las circunstancias del
usuario Completar los artefactos del proyecto Determinar cuándo se acaba el proyecto
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –107–
Fase de transición
Si ya existía un software : Sustitución del sistema antiguo por el nuevo Transferencia de datos del sistema antiguo: migración y
conversión de datos
Evaluación De las iteraciones y de la fase Autopsia del proyecto
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –108–
Fase de transición
Productos El sistema software ejecutable + software instalación Documentos legales, contratos, licencias, garantías Versión completa y corregida del producto, incluyendo los
modelos del sistema La descripción de la arquitectura completa y actualizada Manuales y material de formación del usuario, del
operador y del administrador Referencias para la ayuda del cliente, cómo informar de
defectos
109
Organización del proyecto
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –110–
Planificación de las fases
Asignaciones de tiempo Hitos principales Iteraciones por fases Plan de proyecto En la fase de inicio
Ajustar el PUD al proyecto y seleccionar herramientas Reunir a gente con conocimientos específicos Entender el dominio Familiarizar al equipo con las herramientas
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –111–
Planificación de las iteraciones
La iteración se planifica más en detalle cuando está próxima
Para planificar tenemos en cuenta: Los casos de uso Los riesgos técnicos Cambios en los requisitos Los subsistemas de implementación
El nº de iteraciones depende del proyecto
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –112–
Administración de riesgos
Se crea una lista de riesgos Descripción Prioridad (crítico, significativo, rutinario) Impacto: partes del proyecto afectadas Monitor: responsable del seguimiento del riesgo Responsabilidad: responsable de eliminarlo Contingencia: lo que hacer cuando ocurra
Aparecen nuevos riesgos
O. Sanjuán, Alberto CaramazanaUNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRIDDepartamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software Página –113–
Evaluación de las iteraciones
Se evalúa al final de cada iteración Reconsiderar plan de la siguiente iteración Modificar el proceso, adaptar las herramientas
El jefe del proyecto: Determina si el trabajo está listo para pasar a la siguiente
iteración Planea en detalle la siguiente iteración Actualiza el plan de las siguientes Actualiza la lista de riesgos Compara el coste y la planificación de la iteración