ingenieria de software - ingsw unt29 2. encontrar actores y casos de uso del sistema 2. crear la...
TRANSCRIPT
INGENIERIA DE SOFTWARE
Ing. Francisco Rodríguez Novoa
Ing. Francisco Rodríguez
Tema 6
Requisitos y Casos
de Uso
3
Rational Unified Process (RUP)
4
Requisitos. Objetivos
• Llegar a un acuerdo formal con los clientes y usuarios finales sobre lo que el sistema debe hacer.
• Proporcionar a los miembros del proyecto una idea clara de los Requisitos del sistema.
• Delimitar las fronteras del sistema.
• Proporcionar las bases para la planificación del contenido técnico de las iteraciones.
• Proporcionar las bases para estimar los costos y el tiempo para el desarrollo del sistema.
• Definir la interfase gráfica del sistema.
5
Requisitos. Workflow
6
Requisitos. Artefactos
7
¿Qué es un requerimiento?
Un requerimiento se define como
una condición o capacidad a la que
debe ajustarse el sistema que se
construye
8
¿Cómo son interpretados los
Requisitos?
Necesito algo
para
balancearme
bajo un árbol
en las tardes
de descanso
¿Cómo lo explicó el cliente?
9
¿Cómo son manejados los Requisitos?
¿Cómo lo entendió el lider del proyecto?
¿Cómo fue descrito por el consultor?
¿Cómo fue analizado y diseñado?
10
¿Cómo son manejados los Requisitos?
¿Cómo fue programado?
¿Cómo fue dcumentado?
¿Cómo fue instalado?
11
¿Cómo son manejados los Requisitos?
¿Cómo fue cobrado?
¿Qué soporte se brindó?
¿Qué necesitaba realmente el cliente?
12
¿Dónde identificar Requisitos?
Usuarios
Requisitos
Clientes
Socios
Modelado del Negocio
13
Requisitos. Estereotipos
• Estereotipos más importantes en la etapa de
Requisitos.
Paquete
UM
L
Actor Caso de Uso
14
Requisitos. Actividades
1. Identificar los Requisitos del sistema.
2. Encontrar los actores y casos de uso del sistema.
3. Construir el Modelo de Casos de Uso del Sistema.
4. Estructurar el Modelo de Casos de Uso del Sistema.
5. Priorizar los casos de uso del sistema.
6. Detallar los casos de uso del sistema.
15
1. Identificar los Requisitos del
sistema
Req
uis
ito
s
16
1. Identificar los Requisitos del
sistema
1. Identificar los Requisitos funcionales.
– Especifica lo que debe hacer el sistema en
relación a su entornos (usuarios u otros sistemas)
sin tener en cuenta restricciones físicas.
– Especifican el comportamiento de las entradas y salidas
del sistema.
– Se redactan en lenguaje natural.
– Se capturan en dos artefactos.
• Especificación de Requisitos de Sosftware.
• Modelo de Casos de Uso del Sistemas.
17
1. Identificar los Requisitos del
sistema
1. Identificar los Requisitos funcionales.
– Ejemplo: El sistema debe:
• Actualizar la información de los profesores.
• Consultar los horarios de los cursos.
• Registrar reglas de evaluación.
• Consultar la programación de los exámenes.
• Cerrar un curso.
18
1. Identificar los Requisitos del
sistema
2. Identificar los Requisitos no funcionales.
– Describen los atributos del sistema, entorno
o ambiente donde éste se desarrolla.
– Se capturan en dos artefactos.
• Especificación de Requisitos de Software.
• Modelo de Casos de Uso del Sistemas.
19
2. Identificar los Requisitos no
funcionales
Requisitos NO Funcionales.
• Describen atributos del sistema o del ambiente en
donde éste se desarrolla.
• Se pueden capturar en los casos de uso pero no se
necesitan especificar de manera detallada.
20
2. Identificar los Requisitos no
funcionales
Requisitos NO Funcionales.
• De Facilidad de Uso (Usability)
Están incluidos en las siguientes sub-categorías:
– factores humanos
– estética
– consistencia de la interfaz de usuario
– ayudas en línea
– agentes y wizards
– documentación de usuario y material de entrenamiento
21
2. Identificar los Requisitos no
funcionales
Requisitos NO Funcionales.
• De Fiabilidad (Reliability)
Estan incluidos en las siguientes sub-categorías:
– frecuencia / severidad de los errores
– capacidad de recuperación
– capacidad predictiva
– exactitud
– tiempo promedio entre fallas (MTBF)
22
2. Identificar los Requisitos no
funcionales
Requisitos NO Funcionales.
• De Rendimiento (Performance)
Estos Requisitos afectan a los funcionales en la medida de
parámetros como:
– velocidad
– eficiencia
– disponibilidad
– exactitud
– tiempo de respuesta
– tiempo de uso de recursos
23
2. Identificar los Requisitos no
funcionales
Requisitos NO Funcionales.
• De Soporte (Supportability)
Incluyen la capacidad de:
– prueba
– extensión
– adaptación
– mantenimiento
– compatibilidad
– configuración
– instalación y localización
24
2. Encontrar actores y casos de uso del
sistema
1. Identificar los actores del sistema (actors).
• Un actor del sistema (actor) representa un rol
(humano, software o hardware) externo al
sistema con el que se establece intercambio
directo de información.
• Ejemplo:
– Vendedor.
– Jefe de Almacén.
– Asistente de Producción.
Nombre del
Actor
25
2. Encontrar actores y casos de uso del
sistema
• ¿Dónde encontrar a los actores del sistema?
– Trabajadores del negocio (bussiness workers).
• Por cada trabajador del negocio con actividades a
automatizar identificar a un actor del sistema.
• Dar al actor del sistema el mismo nombre del
trabajador del negocio.
26
2. Encontrar actores y casos de uso del
sistema
• ¿Dónde encontrar a los actores del sistema?
– Trabajadores del negocio (bussiness workers).
27
2. Encontrar actores y casos de uso
del sistema• ¿Dónde encontrar a los actores del sistema?
– Trabajadores del negocio (bussiness workers).
28
2. Encontrar actores y casos de uso del
sistema
• Otros elementos que ayudan a encontrar a los
actores del sistema.
– Personas que usan el sistema.
– Personas que interactuarán con el sistema.
– Personas que proveen información al sistema.
– Usuarios que requieren ayuda de parte del sistema
para poder desarrollar sus actividades o tareas.
– Usuarios que se requieren para ejecutar las
funciones principales o más obvias del sistema.
29
2. Encontrar actores y casos de uso del
sistema
2. Crear la lista de los actores del sistema.
– Nombre del actor.
• Debe dar idea clara del rol que representa o juega.
• Debe ser fácil de entender por los miembros del proyecto.
• Utilizar un sustantivo con letra inicial mayúscula. (UML).
• Siempre corresponde con el nombre de un trabajador o actor del negocio.
– Excepciones pueden ser roles de mantenimiento y administración del sistema.
– Descripción.
• Describir la función que realiza para el sistema.
• Tener en cuenta la responsabilidad que tiene.
30
2. Encontrar actores y casos de uso del
sistema
3. Identificar los casos de uso del sistema
(use cases).
• Un caso de uso del sistema identifica:
– Es un proceso específico del sistema con
identidad propia.
– Define una secuencia de acciones que el
sistema realiza para un actor en particular.
– Define la interacción con el actor
correspondiente.
– Produce un resultado observable y
esperado para el actor correspondiente.
Nombre del
caso de uso
31
2. Encontrar actores y casos de uso
del sistema
• ¿Dónde encontrar casos de uso del sistema?
– ¿Cuáles son las actividades del negocio objetos de automatización?
– ¿Cuáles son las tareas que el actor desea que el sistema desarrolle?
– ¿El actor crea, almacena, cambia, elimina o consulta datos en el sistema?
– ¿El actor necesita informar al sistema cambios generados en el entorno circundante al sistema?
– ¿El actor necesita ser informado sobre la ocurrencia de situaciones externas al sistema?
32
2. Encontrar actores y casos de uso del
sistema
4. Crear la lista de los casos de uso del sistema.
– Nombre del caso de uso del sistema.
• Debe dar idea clara de las acciones a realizar.
• Se concibe desde el punto de vista del actor.
• Debe ser fácil de entender por los miembros del
equipo del proyecto.
• Debe ser un verbo o una frase verbal en infinitivo.
(UML).
– Descripción.
• Se indica el objetivo fundamental del proceso.
• Debe indicar el propósito del caso de uso.
33
3. Construir el Modelo de Casos de
Uso del Sistema
• Está formado por:
– Actores del sistema.
– Diagrama de Actores del sistema.
– Casos de uso del sistema.
– Paquetes.
– Dependencias entre paquetes.
– Asociaciones entre actores y casos de uso del sistema.
– Asociaciones entre casos de uso.
– Diagramas de Casos de Uso.
34
3. Construir el Modelo de Casos de
Uso del Sistema
2. Construir el Diagrama de Casos de Uso del sistema
– El Diagrama de Casos de Uso del sistema es.
• Herramienta proporcionada por UML.
• Muestra gráficamente los Requisitos funcionales del sistema.
• Muestra los procesos que son usados por los roles del sistema.
• Solo se tiene en cuenta “¿QUIÉN realiza QUÉ proceso?”
– ¿QUIÉN? (actor del sistema identificado).
– ¿QUÉ? (caso de uso del sistema identificado).
– Relaciones entre ellos (asociaciones).
• No constituye un Diagrama de Flujo de Datos.
35
4. Estructurar Modelo de Casos de Uso
del Sistema
1. Encontrar comportamiento común en varios casos de uso
del sistema.
– Dentro de la ejecución de un caso de uso del sistema pueden
encontrarse actividades que se repiten en otros.
– Considerarlos duplicados o triplicados hace que.
• Sea más complejo.
• La arquitectura del sistema se multiplique
innecesariamente.
– Estás repeticiones se modelan a través.
• Asociaciones entre casos de uso.
– Asociación de tipo Inclusión (Include).
– Asociación de tipo Extensión (Extend).
– Asociación de tipo Generalización.
36
4. Estructurar Modelo de Casos de Uso
del Sistema
2. Encontrar asociaciones de tipo Inclusión
(Include) entre los casos de uso del sistema.
– Es una relación de dependencia entre dos casos de uso.
– El caso de uso base depende del caso de uso incluido.
– Se establece cuando el caso de uso base necesita incluir obligatoriamente la secuencia de acciones descritas por el caso de uso incluido.
– El caso de uso incluido es de obligatoria ejecución cuando ocurra el evento respectivo dentro del caso de uso base.
37
4. Estructurar Modelo de Casos de Uso
del Sistema
2. Encontrar asociaciones de tipo Inclusión
(Include) entre los casos de uso del sistema.
– ¿Cuándo utilizar la inclusión?
• Cuando exista un comportamiento común a
varios casos de uso (reuso). Las acciones
similares en los casos de uso base se extraen al
caso de uso incluido.
• Cuando existen casos de uso complejos: Se
simplifica el caso de uso base extrayendo parte
de las acciones al caso de uso incluido.
38
4. Estructurar Modelo de Casos de
Uso del Sistema
2. Encontrar asociaciones de tipo Inclusión
(Include) entre los casos de uso del sistema.
– La flecha se orienta de manera que indique que el
caso de uso base es quien necesita incluir al caso de
uso incluido.
– Se utiliza el estereotipo <<include>> y se coloca
encima de la flecha.
Caso de Uso base Caso de Uso incluido
<<include>>
39
Ejemplo de <<include>>
Validar operación
Reintegrar cuenta corriente
Cliente
Reintegrar cuenta crédito
<<include>>
<<include>>
40
4. Estructurar Modelo de Casos de Uso
del Sistema
3. Encontrar asociaciones de tipo Extensión (Extend)
entre los casos de uso del sistema.
– Es una relación de dependencia entre dos casos de uso.
– El caso de uso extendido depende del caso de uso base.
– Se establece cuando el caso de uso extendido ocurre excepcionalmente en el caso de uso base.
– El caso de uso extendido ocurre solo cuando ocurra el evento respectivo dentro del caso de uso base.
41
4. Estructurar Modelo de Casos de
Uso del Sistema
3. Encontrar asociaciones de tipo Extensión
(Extend) entre los casos de uso del sistema.
– Al caso de uso base solo le interesa el resultado de la invocación del caso de uso extendido.
– El caso de uso base es el que conoce la asociación entre ambos.
– El caso de uso extendido no necesita conocer cuáles casos de uso se extienden a él.
42
4. Estructurar Modelo de Casos de
Uso del Sistema
3. Encontrar asociaciones de tipo Extensión
(Extend) entre los casos de uso del sistema.
– ¿Cuándo utilizar la extensión?
• Cuando exista un comportamiento común a varios
casos de uso (reuso). Las acciones similares en los
casos de uso base se extraen al caso de uso
extendido.
• Cuando existen casos de uso complejos: Se
simplifica el caso de uso base extrayendo parte de
las acciones al caso de uso extendido.
43
4. Estructurar Modelo de Casos de Uso
del Sistema
3. Encontrar asociaciones de tipo Extensión
(Extend) entre los casos de uso del sistema.
– La flecha se orienta de manera que indique que el caso
de uso extendido constituye la extensión del caso de
uso base.
– Se utiliza el estereotipo <<extended>> y se coloca
encima de la flecha.
Caso de Uso base Caso de Uso extendido
<<extended>>
44
Casos de Uso – ejemplo1
Identificar Usuario
Realizar Giro por Internet
Cliente
Realizar Giro
<<extends>>
<<includes>>
45
Casos de Uso – ejemplo2
46
4. Estructurar Modelo de Casos de
Uso del Sistema
4. Encontrar asociaciones de tipo Generalización (Generalization) entre los casos de uso del sistema.
– Es una relación de herencia entre casos uso.
– Los casos de uso hijos heredan la estructura, comportamiento y asociaciones del caso de uso padre.
– El caso de uso padre es abstracto y solo se crean instancias de los casos de uso hijos.
47
4. Estructurar Modelo de Casos de
Uso del Sistema
4. Encontrar asociaciones de tipo Generalización
(Generalization) entre los casos de uso del sistema.
– ¿Cuándo utilizar la generalización?
• Cuando existen dos o más casos de uso que poseen un
comportamiento y estructura muy común.
• Las actividades comunes son llevadas hacia un caso
de uso padre o generalizado.
• Las actividades diferentes y particulares se quedan en
los casos de uso hijos.
48
4. Estructurar Modelo de Casos de Uso
del Sistema
4. Encontrar asociaciones de tipo Generalización
(Generalization) entre los casos de uso del sistema.
– Se utiliza una flecha con saeta transparente.
– La flecha se orienta de manera que indique que los casos
de uso hijos necesitan heredar el comportamiento del
caso de uso padre.
Caso de Uso
padre
Caso de Uso
hijo 1
Caso de Uso
hijo 2
49
4. Estructurar Modelo de Casos de Uso
del Sistema
5. Encontrar asociaciones de tipo Generalización
(Generalization) entre los actores del sistema.
– Si existen dos o más actores que:
• Utilizan el sistema de la misma forma.
• Ocupar el rol de otro actor en un momento
determinado.
– Entonces es posible.
• Establecer una relación de Generalización entre ellos.
• Simplificar el modelo de Casos de Uso.
– El actor hijo hereda el rol representado por el actor padre
en la relación.
50
Un ejemplo: Sistema Académico
El sistema permitirá:
• A los profesores:
– Consultar los horarios de sus cursos
– Consultar la programación de los exámenes
– Actualizar y ver su información personal
– Registrar y modificar las notas de los
estudiantes a su cargo
– Cerrar un curso
Requisitos
funcionales
51
Un ejemplo: Sistema Académico
• A los estudiantes:
– Consultar los horarios de sus cursos
– Consultar la programación de los exámenes
– Actualizar y ver su información personal
– Consultar notas de un curso
Requisitos
funcionales
52
El actor Profesor y sus Casos de
uso
Consultar horarios de cursos
(from Use Cases)
Consultar horarios de examenes
(from Use Cases)
Mantener información del profesor
(from Use Cases)
Registrar notas de un curso
(from Use Cases)
Validar acceso
(from Use Cases)
Profesor
(f rom Actors)
53
Relaciones entre actores
Estudiante Profesor
Usuario
54
Casos de uso del Usuario
Consultar horarios de cursos
Consultar horario de exámenes
Validar accesoUsuario
(f rom Actors)
55
Casos de uso del Estudiante
Mantener información del estudiante
Estudiante
(f rom Actors)
Consultar notas de un curso
56
Casos de uso del Profesor
Mantener información del profesor
Registrar notas de un curso
Cerrar un curso
Profesor
(f rom Actors)
57
Modelo de Casos de uso del Sistema
Académico
Consultar notas de un curso
Estudiante
(f rom Actors)
Mantener información del estudiante
Cerrar un curso
Mantener información del profesor
Profesor
(f rom Actors)
Registrar notas de un curso
Consultar horario de exámenes
Validar acceso
Usuario
(f rom Actors)
Consultar horarios de cursos
58
Construcción de Casos de uso
Ejemplo: Sistema de Matricula
La universidad quiere automatizar su sistema de matrícula
de cursos de verano.
Un Empleado inicializa la oferta de cursos ofrecidos para el
verano. Un mismo curso tiene varias ofertas (secciones).
Durante un cierto período de tiempo, después de que se
haya definido la oferta de cursos, los estudiantes pueden
utilizar el sistema para añadir o eliminar cursos a matricular.
Los alumnos seleccionan 4 cursos obligatorios y 2 cursos
electivos.
Los profesores pueden utilizar el sistema para obtener las
listas de alumnos matriculados en su curso.
Los usuarios del sistema de matrícula acceden a él mediante
un login y una password que le es asignada.
59
Construcción de Casos de uso
Ejemplo: Sistema de Matricula
•Actores :
•Empleado
•Estudiante
•Profesor
•Casos de uso
•Ingresar Oferta de cursos
•Añadir o Eliminar Curso
•Obtener Listado de Alumnos
60
Construcción de Casos de uso
Caso Sistema de Matricula
Caso de uso : Ingresar oferta de cursos
Actor : Empleado
Precondición : Empleado ha sido admitido como usuario
Poscondición : Se ha registrado la oferta de cursos
Flujo Básico
Actor1.El C.U. comienza cuando
Empleado Indica “Ingresar oferta”
2.Ingresa Código de Curso
3. Ingresa Sección, Horario y
Aula
4. Repite 2 a 3 por cada curso
5. Indica “Guardar”
Sistema1. El sistema muestra formulario
“Ingresar oferta”
2.Muestra nombre del curso
3.Verifica aula disponible y horario
sin cruce
4. Repite 2 a 3 por cada curso
5. Muestra mensaje de
confirmación y el C.U. termina.
Flujos Alternativos
1.
2.
61
Priorización de Casos de Uso
En base a la experiencia...
• Seleccionar los que influyan profundamente en la
arquitectura básica, dando soporte al dominio y a las
capas de servicio de alto nivel o
• Escoger los que presenten el máximo riesgo,
funciones urgentes o complejas en las primeras
iteraciones.
62
Priorización de Casos de Uso
........
• Los que requieran investigación a fondo o nueva
tecnología.
• Aquellos que representen procesos primarios o la
línea de negocio.
• Los que apoyen directamente el aumento de ingresos
o la reducción de costos.
63
Priorización de Casos de Uso
En base a ponderaciones...
• Se definen valores a los atributos de los Requisitos.
• Se aplican pesos a los diferentes valores de los
atributos.
• Se calcula el peso total de cada requerimiento.
• Se priorizan los Requisitos de mayor peso total.
64
CASOS DE USOS Com
plej
idad
Ries
go
Prec
eden
cia
Prem
ura
Calif
icac
ión
0.3 0.15 0.35 0.2
Crear Proveedor 4 4 5 5 4.55
Generar Orden de Compra 4 4 4 3 3.80
Generar Cotización 4 4 3 4 3.65
Generar Solicitud de Cotización 4 4 4 2 3.60
Generar Documento por Compra en Efectivo 3 3 4 3 3.35
Registrar Importación 3 3 3 3 3.00
Seleccionar Cotizaciones 4 3 2 2 2.75
Crear Moneda 2 2 3 3 2.55
Crear País 2 2 3 3 2.55
Modificar Proveedor 3 3 2 2 2.45
Modificar Solicitud de Cotización 3 3 2 2 2.45
Modificar Cotización 3 3 2 2 2.45
Modificar Orden de Compra 3 3 2 2 2.45
Eliminar Proveedor 2 3 2 2 2.15
Eliminar Solicitud de Cotización 2 3 2 2 2.15
Eliminar Cotización 2 3 2 2 2.15
Eliminar Orden de Compra 2 3 2 2 2.15
Modificar Moneda 1 2 2 2 1.70
Modificar País 1 2 2 2 1.70
Eliminar Moneda 1 2 2 1 1.50
Eliminar País 1 2 2 1 1.50
Emitir Reporte de Requerimientos pendientes 1 0 0 0 0.30
Emitir Reporte de Situación de Requerimientos 1 0 0 0 0.30
Emitir Reporte de Requerimientos por vencer 1 0 0 0 0.30
Emitir Reporte de Cotizaciones 1 0 0 0 0.30
Emitir Reporte de Orden de Compra por Proveedor 1 0 0 0 0.30
Emitir Reporte de Orden de Compra por ítem 1 0 0 0 0.30
Casos de usos primarios
Casos de usos secundarios
Casos de usos opcionales
CRITERIOS DE PRIORIZACION
65
Conclusiones
• La identificación de los Requisitos funcionales
llevará a la proyección de las funciones del
sistema.
• La descripción de los Requisitos no funcionales
facilitarán la construcción de la plataforma del
sistema.
• La construcción del Modelo de
Casos de Uso del Sistema
permitirá la definición de la
arquitectura del sistema.
66
FIN