Modelado y especificación de caso de...

FATTO Consultoría y Sistemas - www.fattocs.com

FATTO CONSULTORIA Y SISTEMAS

GUILHERME SIQUEIRA SIMÕES

16/04/2019

Modelado y especificación de caso de uso

1


De preferencia al uso de una conexión de banda ancha

Este evento no tendrá video (webcam), solamente la presentación y audio

Si es necesario, ajuste el idioma de la sala en la barra de herramientas superior

Tendrá una duración de ~45 min. de presentación y ~15 min. finales para

preguntas

Puedes enviar tus preguntas por el chat durante la presentación

Para aquellos que poseen certificación PMP, el webinar otorga un crédito de 1

PDU

La grabación y material serán publicados posteriormente en nuestra página web

y redes sociales:

ORIENTACIONES INICIALES

2


FATTO Consultoría y Sistemas

3

Misión: “Ayudar a nuestros clientes en la planeación y evaluación

de desempeño de procesos de TI para aumentar el éxito de su

negocio.”

https://amzn.to/2PPA2xi

https://amzn.to/2PPA2xi


Caso de Uso o Historia de Usuario

El Caso de Uso

El Diagrama de Casos de Uso

La Especificación de Casos de Uso

Los estigmas de caso de uso

Historia de Usuario

Conclusión

Agenda

4


La pregunta que vale un millón

¿Caso de Uso o Historia de Usuario?

5


El Caso de Uso (CU)

Representa el comportamiento del software en la interacción con el usuario para que este alcance un objetivo

Describe lo que el software debe hacer y para quién, no como este será implementado

La técnica de casos de uso está compuesta por:

– Diagrama de casos de uso

– Descripción de los actores

– Especificación de los casos de uso

6


Agregado

Usuario

SubfunciónReglas

Pasos

Objetivos asociados

Requisitos relativos a

tareas y servicios de

usuario transferidas al

software

Niveles de Objetivo de los casos de uso(Granularidad)

7

Asista a “Los niveles de granularidad del requisito funcional”: https://youtu.be/XBVQMR8xQ2M

https://youtu.be/XBVQMR8xQ2M


Diagrama de casos de uso

Compone el producto en análisis

Representa gráficamente

– Casos de uso

– Los roles que los usuarios (actores) desempeñan en estos casos de uso

– La interrelación entre los elementos

Demuestra las funcionalidades queatenderán las necesidades del usuario

– Apoyando en la verificación y validación

Debe ser de fácil lectura e interpretación portodos los interesados

8


Cancelar Consulta

Marcar Consulta

Registrar Historia

Pagar Cuenta

Posponer Pago

Plan de Salud

Buscar Paciente

Prescribir Receta

Enviar Recordatorio

EmitirReceta

Médico

Empleado

Caja

Paciente

<<Include>>

<<Include>>

<<Include>>

<<Extend>>

Clínica

Staff

Actor

Caso de Uso

Relación

Relación con actor

pasivo

Relación con actor activo

Relación de

generalización entre

actores

Relación de inclusión

Relación de extensión

Relación de

generalización entre

casos de uso

Ejemplo de Diagrama de Casos de Uso

9


Elemento Significado Simbología

Actor

Representa una persona (o un grupo de personas) que

desempeñan un papel o interactúan con el software. No

se limita a eso y puede ser cualquier "cosa" que

interactúe con el software con la finalidad de cumplir un

trabajo significativo, como otros productos de software o

mismos equipamientos.

Elementos

10



Actor







Caso de

uso

Representa una funcionalidad que atiende a uno o mas

requisitos del cliente. Como nombre, se sugiere usar un

verbo infinitivo con un complemento.

Los casos de uso pueden opcionalmente estar encerrados

por un rectángulo que representa los limites de sistema.

Elementos

11



Actor







Caso de

uso

Representa una funcionalidad que atiende a uno o mas

requisitos del cliente. Como nombre, se sugiere usar un

verbo infinitivo con un complemento.

Los casos de uso pueden opcionalmente estar encerrados

por un rectángulo que representa los limites de sistema.

Relación (o

asociación)

Un actor interactúa con un caso de uso y es

representado por una relación. Los casos de uso también

pueden relacionarse entre si.

Elementos

12


La asociación entre un Actor y un Caso de Uso es denominado relación decomunicación.

Actor Activo:

Inicia (o dispara) la ejecución del caso de uso

La flecha (si hay) apunta al caso de uso

Generar Informe de Pago

Funcionario

Relaciones

13


Relaciones

La asociación entre un Actor y un Caso de Uso es denominado relación decomunicación.

Actor Pasivo:

No es iniciado por el actor, el caso de uso reacciona ante una provocación de software que inicia la comunicación

La flecha apunta para el actorEmitir aviso de pago

(Actor pasivo)

Funcionario

14


Elemento Significado SimbologíaDirección de la

Flecha

Generalización

o

Especialización

El caso de uso generalizado (padre)

contempla un comportamiento

común, abstraídos de otros casos de

uso, que permite que los casos de

uso hijo hereden este

comportamiento común y también

describan un comportamiento

particular y específico

El caso de

uso general

recibe la

punta de la

flecha

Relaciones

15



Flecha

Generalización

o

Especialización

El caso de uso generalizado (padre)

contempla un comportamiento

común, abstraídos de otros casos de

uso, que permite que los casos de

uso hijo hereden este

comportamiento común y también

describan un comportamiento

particular y específico

El caso de

uso general

recibe la

punta de la

flecha

ExtensiónEs llamado, en algunos casos

(opcional) de un caso de uso por otro

La fecha

apunta al

que lo llama

Relaciones

16



Flecha

Generalización

o Especialización

El caso de uso generalizado (padre) contempla

un comportamiento común, abstraídos de otros

casos de uso, que permite que los casos de uso

hijo hereden este comportamiento común y

también describan un comportamiento particular y

específico

El caso de uso

general recibe

la punta de la

flecha

ExtensiónEs llamado, en algunos casos (opcional) de un

caso de uso por otro

La fecha apunta

al que lo llama

InclusiónEs la continuación obligatoria de un caso de uso

en otro caso de uso

La flecha

apunta a la

continuación

Relaciones

17


Escenarios

Son los diferentes pasos que:

– Despliegan a partir de un evento

– Las condiciones que afectan en su comportamiento

Un escenario explora:

– Como y cuando un caso de uso comienza

– Cuando el CU interactúa con los actores y que datos se intercambian entre si

– Cuando el CU referencia o almacena datos

– Como y cuando el caso de uso termina

Un escenario no aborda aspectos como:

– Interfaz gráfica

– Plataforma de hardware o software

– Requisitos no funcionales

18


Especificación de casos de uso

Su comportamiento debe estar descrito en

– Un documento

– O en una herramienta de gestión de requisitos

La UML no establece un estándar

– Cada organización establece un modelo que atienda a sus necesidades

• independientemente del modelo en particular, debe atender las necesidadesde información básica

19


Especificación de casos de uso

Su comportamiento debe estar descrito en

– Un documento

– O en una herramienta de gestión de requisitos

La UML no establece un estándar

– Cada organización establece un modelo que atienda a sus necesidades

• independientemente del modelo en particular, debe atender las necesidadesde información básica

Información básica que la Especificación de Caso

de Uso debe tener:

Nombre

Breve descripción de comportamiento

Actores que interactúan con el software

Pre-condiciones necesarias al inicio del caso de

uso

Post-condiciones que se esperan a su término

Secuencia de pasos que describe el flujo

principal

Escenarios alternativos y de excepción

Reglas de negocio

20


Ejemplo de especificación de Casos de Uso

Especificación de Caso de Uso: <Agendar Consulta>

1. Descripción

Permite que un paciente o empleado agende una consulta médica.

2. Actores

Paciente o Empleado

3. Pre-condiciones

Para el Paciente, este necesita estar logueado en el sistema con el perfil “Paciente”.

Para Empleado, este necesita estar logueado en el sistema con el perfil “Empleado”.

4. Post-condiciones

Consulta médica agendada.

21


El término flujo también es usado para designar un escenario

Diferencia

Los escenarios son subdivididos en dos tipos

Los flujos son subdivididos en tres tipos

Flujos o Escenarios

Fin del Caso de Uso

Inicio del Caso de Uso

Flujo Alternativo Flujo de Excepción

Principal,

Básico o

Normal

Alternativo

Excepción

22



5. Flujo de Eventos

5.1. Flujo Principal

P1. El flujo de eventos principal se inicia cuando un usuario Paciente o Empleado entra en el

sistema y hace login. (A1)

P2. El sistema presenta al actor los datos del Paciente que tendrá la consulta. Los datos

presentados son:

Nombre del paciente, Identificación, Dirección, Teléfono, Plan de Salud

P3. El actor informa el nombre del médico y un período de fechas que desea marcar a cita medica.

(A2)

P4. El sistema exhibe todos los horarios disponibles y ocupados para realizar el agendamiento de

la consulta para el médico informado.

P5. El actor selecciona el horario deseado y confirma la cita.

P6. El sistema asigna la consulta.23

Flujo Principal

Es la descripción de los pasos que refleja un

único escenario para satisfacer el objetivo del

caso de uso. Es el “camino feliz”



5.2. Flujos Alternativos

A1. Empleado marcando una consulta para un Paciente

• El sistema presenta al actor el formulario para encuestar a los pacientes registrados.

• El actor informa la identificación del Paciente que hará la consulta médica (E1)

• El sistema regresa para el Paso 2 (P2) del flujo principal.

24

Flujo Alternativo

Cumple el papel de complementar el escenario principal con fragmentos de flujos

Son condiciones de desvíos al camino feliz



5.3. Flujos de Excepción

E1. Empleado no informa al Paciente que será atendido

• El sistema presenta un mensaje “Por favor introduzca un paciente ya registrado para hacer la

cita.”

• El sistema regresa al Paso 2 de flujo (A1)

E2. Actor no selecciona médico

• El sistema presenta un mensaje “Seleccione un médico”.

• El sistema regresa para el Paso 2 (P2) de flujo principal.

25

Excepción

Específicamente para describir el comportamiento asociado a las

condiciones de excepción


Como identificar y describir

La identificación de un caso de uso debe inicialmente ser hecha en

el nivel tareas en el ámbito del negocio

Comienza cuando el usuario ha cumplido todas las condiciones para iniciar el caso de uso

Todo lo que debió haberse hecho para concluir la tarea, fue hecho sin necesidad de un paso

subsiguiente

Describir los escenarios relativos a la evaluación de condiciones,

sin describir las reglas de negocio asociadas (sólo referéncialas)

Si una herramienta de gestión de requisitos es utilizada, entonces, esa separación se torna

irrelevante ya que la especificación de caso de uso pasa a ser un simple informe y no un

repositorio centralizado de información


Con la información organizada de un modelo funcional basado en

casos de uso, se proporciona información para trabajar en

tres áreas muy importantes en proyectos:

Definición de requisitos Comunicación con los clientes

Elaboración de casos de prueba

Importancia

27

FATTO Consultoría y Sistemas - www.fattocs.com 28

Breve descripción de las funcionalidades de la solución que los usuarios necesitan parasatisfacer los objetivos de negocio

Aunque el estilo sea libre, la historia de usuario debe responder a tres preguntas:

¿Quién se beneficia? : Interesados que se benefician de la historia de usuario (Actor)

¿Qué se quiere hacer? : Visión de alto nivel de la funcionalidad para el usuario(Descripción)

¿Cuál es el beneficio? : El valor de negocio que la historia proporciona (Porqué)

Historias de Usuario

Como un cliente,

quiero consultar el catálogo

para poder

encontrar el producto que

deseo comprar.


¿Caso de Uso o Historia de Usuario?

No hay dilema entre diagrama de caso y historia de usuario

Especificación de caso de uso x historia de usuario

– Asista a “¿Cuál es el nivel de detalle apropiado para una especificación de requisitos?“

– https://youtu.be/cHwvkzMMfeY

29

https://youtu.be/cHwvkzMMfeY


Conclusión

Vimos que un caso de uso

Es un conjunto de pasos que describe un escenario principal y alternativo para

que el actor alcance su objetivo

Describe el comportamiento del software y no como este será implementado

Presentamos los elementos que componen un diagrama de casos

de uso

Describimos la estrucutura de una especificación de Caso de Uso

30


¡ENCUESTA!

31


PRÓXIMOS EVENTOS

WEBINARS:

• SCRUM: Lo que comienza bien, termina mejor - como un product owner

elabora un backlog de calidad y resuelve conflictos

Fecha: 29 de abril de 2019 https://bit.ly/2TcJgoY

• La Ingeniería de Requisitos en el entorno Ágil

Fecha: 28 de mayo de 2019 https://bit.ly/2InhCVa

CURSOS SUGERIDOS:

• Ingeniería de Requerimientos: Software Orientado al Negocio

http://www.fattocs.com/es/ireq-ead

32

https://bit.ly/2TcJgoY

https://bit.ly/2InhCVa

http://www.fattocs.com/es/ireq-ead


¿PREGUNTAS?

¡Muchas gracias por la atención!

GUILHERME SIQUEIRA SIMÕES

E-mail: [email protected]

Linkedin: https://br.linkedin.com/in/guilhermesimoes/es

Skype: guilherme.s.simoes

Whatsapp: +5527981117505

33

Modelado y especificación de caso de...

Documents

Transcript of Modelado y especificación de caso de...