2. Agenda
► Objetivos
► Conceptos Claves
► Metodología de Levantamiento
► Modelamiento de Procesos
► Casos de Uso
► Entregables y Criterios de Aceptación
► Bibliografía
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
3. Objetivos
► Conocer las reglas de juego que se tendrán para llevar a
cabo el levantamiento de requerimientos
► Conocer el proceso metodológico que será utilizado
para llevar a cabo el levantamiento de requerimientos en
TC
► Conocer en detalle el proceso de especificación de
requerimientos funcionales utilizando casos de uso
► Identificar las características principales de los casos de
uso
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
4. Conceptos claves
► Proceso: Es un conjunto de pasos parcialmente
ordenados que buscan alcanzar una meta u objetivo
► Disciplina: Es una colección de actividades
interrelacionadas asociadas a un área específica de
trabajo
► Flujo de Trabajo: Un flujo de trabajo es una secuencia
de actividades que produce un resultado significativo y
es observable
► Actividad: Una actividad es algo que un rol hace para
proveer un resultado significativo dentro del contexto de
un proyecto
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
5. Conceptos claves
► RUP: Rational Unified Process (Proceso Unificado de
Desarrollo). Metodología que integra mejores prácticas
para la ejecución de las diferentes etapas de un proceso
de desarrollo
► Diagrama de proceso: Modelo de procesos; también
diagrama de actividades del proceso
► Caso de uso: Un caso de uso es un artefacto cuyo
objetivo principal es capturar el comportamiento del
sistema, a través de una secuencia de acciones (flujo de
trabajo), que desde la perspectiva del usuario final
permiten alcanzar los objetivos deseados
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
8. Metodología
Reunión de Lanzamiento
El cliente tiene sus
Procesos modelados ?
Presentaciones generales
del negocio
NO
SI
Revisar documentación
entregada por el cliente
Documentación
suficiente ?
Recolectar documentación
adicional
SI
Convenciones Roles
NO
Solicitar documentación
adicional
Cliente
Analista Líder
Analista
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
9. Metodología
Elaboración y ajustes del
documento de Visión
Revisión Documento
de Visión
Revisión OK ?
Aprobación Documento
de Visión
NO
SI
Documento
aprobado ?
SI
Preparación agenda
de entrevistas
Convenciones Roles
Cliente
Notificar compromiso
a entrevistados
HEINSOHN Software House |
Preparación y ejecución
de entrevistas
Analista Líder
Analista
HEINSOHN Software House | Fábrica software
10. Metodología
Preparación y Ejecución de Entrevistas
Elaboración del modelo
de proceso propuesto
Solicitar entrevistas
adicionales
Identificación de
Reglas de Negocio
Identificación y
elaboración del
Glosario
Convenciones Roles
Cliente
Analista Líder
Analista
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
11. Metodología
Aprobación Modelo
de Procesos
Modelo de
Procesos OK ?
Revisión Artefactos
de Proceso
Revisión OK ?
NO
Ajuste Artefactos
de Proceso
NO
SI
SI
Aprobación Definición
Preliminar del Alcance
Definición Preliminar
del Alcance
Ajustes Definición
Preliminar del Alcance
Definición
Preliminar OK ?
Convenciones Roles
NO
Cliente
SI
Planeación detallada
de especificaciones
HEINSOHN Software House |
Aprobación
planeación detallada
Analista Líder
Analista
HEINSOHN Software House | Fábrica software
12. Metodología
Aprobación planeación detallada
Aprobar ajustes a la
definición del alcance
Refinar definición
del alcance
Aprobación casos de
uso terminados
Especificar casos
de uso
Crear relaciones
de trazabilidad
Especificar Reglas
de Negocio
Casos de uso
aprobados ?
NO
Refinar Glosario
SI
Solicitar y ejecutar
Sesiones de aclaraciones
HEINSOHN Software House |
Elaborar arquitectura
de casos de uso
HEINSOHN Software House | Fábrica software
13. Metodología
Aprobación planeación detallada
Especificar requerimientos
No funcionales
Aprobación Artefactos
de Requerimientos
Elaborar y documentar
Prototipo / StoryBoards
Revisión Artefactos
de Requerimientos
Artefactos OK ?
NO
Ajustes Artefactos
de Requerimientos
SI
NO
Artefactos OK ?
NO
SI
Cerrar fase de
requerimientos
HEINSOHN Software House |
Cambios en los
requerimientos ?
Convenciones Roles
SI
Cliente
Procedimiento de
Control de Cambios
Analista Líder
Analista
HEINSOHN Software House | Fábrica software
15. Elementos
Inicio
Final
cd Due Diligence pre para ...
«ROL Analista de DD»
Pr0074 Seleccionar
archiv os planos
► Estados Inicial y Final: Todo
proceso debe tener un inicio y un fin.
Los elementos Inicio no reciben
ninguna entrada y los elementos
Final no generan ninguna salida
► Actividad: Representa un paso
atómico de un proceso
Actividad
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
16. Elementos
Enlace
► Enlace: Los enlaces se utilizan para
representar la transición de un
estado a otro y el paso de una
actividad a otra
► Decisión: Se utiliza para representar caminos
alternativos en el flujo del proceso. Tiene una
única entrada y puede tener dos o más salidas.
Por cada salida se tiene una expresión booleana
que será evaluada al llegar a la bifurcación. Las
condiciones deben ser excluyentes y se deben
contemplar todos los posibles casos que se
puedan generar
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
17. Elementos
► Fork / Join: Para representar las
tareas concurrentes que pueden
formar parte de un proceso se utiliza
el elemento Fork. En el diagrama de
ejemplo las actividades 2 y 3 se
pueden ejecutar concurrentemente.
El elemento Join se utiliza para
representar la unión al flujo de
control secuencial del proceso
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
18. Elementos
► Signal Sending: Representa el
envío de un mensaje
► Signal Receipt: Representa la
recepción de un evento o mensaje
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
20. ¿Qué es un caso de uso?
► Artefacto cuyo objetivo principal es capturar el
comportamiento del sistema, a través de una secuencia
de acciones (flujo de trabajo), que desde la perspectiva
del usuario final permiten alcanzar los objetivos
deseados
► Un caso de uso describe lo QUE debe hacer el sistema
para satisfacer un requisito, NO COMO debe hacerlo
► El caso esta compuesto por uno o más flujos (secuencia
de acciones) y es invocado por un actor (usuario o
sistema)
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
21. ¿Qué es un caso de uso?
► Los casos de uso describen la interacción del usuario
con el sistema
Acción 1
Acción 2
Actor
Acción 3
Sistema
► La especificación de la interacción debe contemplar
posibles flujos alternos ante distintas condiciones que se
pueden dar en medio
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
22. Elementos de Caso de Uso
► Actor: Es un rol que un usuario juega en el
sistema. No necesariamente es una
persona. Puede estar representado por un
grupo de usuarios, otro sistemas o hardware
► Flujo Básico de Eventos: Corresponde al
flujo de eventos cuando todas las
circunstancias son ideales (todas las
validaciones son cruzadas exitósamente).
● Se deben numerar cada uno de los pasos
● En cada paso hay que describir la acción
efectuada por el actor o por el sistema
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
23. Elementos de Caso de Uso
► Flujos Alternos: Toda situación que impida que se
pueda llevar a cabo el flujo normal como está
presupuestado. Habitualmente validaciones.
● Tipos de validaciones:
• Sintácticas : Inherentes a la naturaleza del dato : Obligatoriedad,
tipo de dato, rango y formato
• Semánticas : A partir del significado del dato o conjunto de datos
(Reglas del Negocio)
● Se debe indicar el paso en el que se da la situación, la
situación, la acción del sistema y a qué paso se retorna
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
24. Elementos de Caso de Uso
► Pre-condiciones: Preconcepciones acerca del sistema
que deben darse para que se pueda llevar a cabo el
caso de uso como esta concebido
► Post-condiciones: Especifica cual es el resultado de
valor que genera el caso de uso (cómo modifica su
entorno)
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
25. Ejemplo
CASO DE ESTUDIO DEL RESTAURANTE “O SOLE MIO”
El restaurante “O Sole Mío” desea construir una solución que le permita
administrar la elaboración de los diversos platos que ofrece a sus clientes. Para
esto, el administrador quiere que se maneje una relación de cada plato junto con
los ingredientes necesarios para elaborarlo. Cada relación de ingrediente debe
tener la cantidad y costo del mismo. De esta manera, también será posible
establecer el costo del plato. El precio cobrado a los clientes siempre será un
porcentaje fijo por encima de la suma de los costos de los ingredientes que se
requieren para su elaboración. Con esta información registrada, Don Vittorio
Corleogni (su gerente y dueño) desea obtener solo dos servicios:
•Que el cocinero, cuando lea una orden escrita por un mesero, consulte en el
sistema el plato y conozca cómo elaborar el mismo, junto con sus ingredientes y
cantidades.
•Que el cajero, al momento de elaborar la cuenta, consulte cada plato y el
sistema le diga cuánto cobrar por él. Con ésta información, el cajero puede
calcular (con calculadora) el costo total de la cuenta.
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
26. Ejemplo
Casos de uso
Asociaciones
uc Primary Use Cases
System Boundary
Consultar elaboración
de plato
Roles
Cocinero
Consultar plato
Caj ero
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
27. Ejemplo
► Consultar elaboración de un plato
● Breve Descripción: Permite la consulta de la
elaboración e ingredientes de un plato
● Entradas: Código del plato. Es un campo
alfanumérico. Es obligatorio
● Flujo Básico de Eventos
1. El sistema solicita le sea ingresado el código del plato
2. El actor digita el código del plato y acepta
3. El sistema despliega la información del plato: nombre, elaboración
y la lista de ingredientes con código, nombre y cantidad
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
28. Ejemplo
► Flujos alternativos
● Código del plato no ingresado
1. Si en el paso 1, no se ingresa ningún codigo, el sistema informa
del error y retorna al paso 1 (Obligatoriedad)
● Código del plato no existente
2. Si en el paso 1 se ingresa un código de plato que no existe
registrado en el sistema, el sistema informa del error y retorna al
paso 1 (validación semántica)
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
29. Ejemplo
► Pre-condiciones
● El sistema cuenta con todo el registro de los platos y sus
elaboraciones
► Post-condiciones
● El sistema despliega los datos de la elaboración del plato
junto con sus ingredientes
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
30. Relaciones de los casos de uso
► Herencia
● Relación entre
actores en la cual
los roles hijos
heredan todos los
casos de uso en
los cuales
interviene el
padre
uc Primary Use Cases
System Boundary
Consultar estado de
cartera
Funcionario de Pedidos
(from Actors)
Registrar pedidos
personas naturales
Funcionario de pedidos
de personas naturales
(from Actors)
Registrar pedidos
personas j urídicas
Funcionario de pedido de
personas j urídicas
(from Actors)
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
31. Relaciones de los casos de uso
► Inclusión
● Se factoriza una interacción en un conjunto de casos (al
menos 2)
uc Primary Use Cases
Consultar estado
cartera
«include»
«include»
Administrador
Cancelar pedido
(from Actors)
Los dos casos de uso incluyen
en su narración la validación del
usuario y password
HEINSOHN Software House |
Validar usuario y
passw ord
1.
2.
3.
El sistema solicita le sea ingresado el usuario y la
palabra clave
El actor digita los datos y acepta
El sistema verifica el usuario y el password y
genera un mensaje de éxito
HEINSOHN Software House | Fábrica software
32. Relaciones de los casos de uso
► Extensión
● Permite que se pueda extender un flujo de eventos de un
caso hacia otro caso de uso bajo una situación
excepcional
uc Primary Use Cases
Consultar pedido
«extend»
Cancelar pedido
Administrador
(from Actors)
Luego de consultar un pedido, el actor puede ir al caso de uso
de Cancelar pedido
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
33. Malas prácticas
► El sistema solicita le sea ingresado el dato del plato
● El diseñador y el programador NO saben cuál es el dato. Debe
enunciarse específicamente qué datos son ingresados en cada
paso de un caso de uso.
► El sistema despliega la información del plato
● El diseñador y el programador no saben cuáles son los datos
que se deben desplegar o contemplar en este caso de uso
► El sistema despliega la información del plato: nombre, elaboración y
lista de ingredientes
● El diseñador y el programador NO saben qué datos desplegar
para los ingredientes = información incompleta
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software
34. Algunos entregables
► Documento de visión
► Cronograma y resumen del proyecto
► Definición preliminar de alcance
● Casos de uso suficientes que soportan el proceso
► Modelo de procesos
► Matriz de trazabilidad de Procesos vs. Casos de uso
► Especificaciones de casos de uso
► Glosario
► Reglas de negocio
● Solo las utilizadas por algún caso de uso
HEINSOHN Software House |
HEINSOHN Software House | Fábrica software