Sesion05 analisis-definir

Análisis
David Díez Cebollero
Departamento de Informática
Universidad Carlos III de Madrid
DISEÑO DE
SISTEMAS INTERACTIVOS
Grado en
Ingeniería Informática

Diseño de Sistemas Interactivos
Análisis > Contenido sesión 5
 Entender la importancia de la definición del problema
 Entender la importancia de modelar el quién, el qué y el cómo
 Conocer la utilidad del uso de narrativas y diagramas
 Definir el concepto de “persona”
 Definir el concepto de “requisito”
 Conocer la diferencia entre “historia de usuario”, “escenario” y “caso
de uso”
 Conocer el “mapa de tareas” y el “service blueprint” como
representaciones visuales de los escenarios
18/02/2016David Díez Cebollero

Análisis > Definición del problema
“La definición del problema es la
actividad de análisis dirigida a
articular la información generada a
fin de establecer las características
del sistema a elaborar.”
“El objetivo de la actividad es
desarrollar una serie de
entregables que guíen el resto del
proceso de diseño.”

¿Qué acciones cognitivas se realizan?
 Interpretar datos
 Explicitar datos
 Reducir datos
 Analizar datos
 Articular información
 Resumir información
 Extrapolar información
 Abstraer información

¿Qué tipos de artefactos se utilizan?
 Diagramas (D)
Representación gráfica de la operativa de un
sistema o del comportamiento del usuario
del mismo
 Narrativas (N)
Descripción mediante el uso de historias,
relatos o secuencias de hechos de
procesos, contextos o actividades
 Enunciados (E)
Proposiciones o definiciones de tipo textual

¿Qué aspectos deben ser modelados?
 Quién utilizará el sistema
Establecer el perfil y características de los
potenciales usuarios del sistema
 Qué hará ese quién gracias al sistema
Fijar la actividad a resolver en base a los
objetivos y tareas acometidos
 Cómo realizará el quién ese qué
Establecer el conjunto de acciones u
operativas necesarias para ejecutar una
determinada tarea


¿Qué artefactos de modelado utilizaremos?
 Quién
 Persona (N)
 Qué
 Historia de usuario (E)
 Escenario (N)
 Mapa de tareas (D)
 Service blueprint (D)
 Cómo
 Caso de uso (N)
 Diagrama de flujo de tareas (D)
 Requisito de sistema (E)

Análisis > Definición del problema > Modelado
Sobre la importancia del quién…
@About Face 3 - Wiley

Análisis > Definición del problema > Modelado > Quién
Persona
¿Qué es un “persona”?
 Definición
“Un persona es un arquetipo de un usuario real del sistema, definido de
acuerdo a sus objetivos y atributos diferenciadores”
 Características
 No se trata de una descripción de una persona real sino de una
representación de un potencial usuario del sistema
 Un persona debe recoger, al menos, información personal, experiencia,
conocimiento y labor realizada, así como gustos, aficiones y preferencias
 Es necesario crear personas por cada uno de los tipos significativos de
usuarios (primarios) del sistema

Persona
¿Qué NO es un “persona”?
 No es un perfil de usuario
Perfil de usuario (user profile): Conjunto de características de un grupo de
usuarios del sistema
 No es un rol del usuario
Rol del usuario (en UML, actor): Conjunto de tareas/operativas acometidas
por un usuario del sistema
 No es un estereotipo
Estereotipo: Idea comúnmente
aceptada pero no basada en
pruebas ni hechos objetivos

Persona
¿Por qué útil un “persona”?
Permite…
…describir a los potenciales usuarios del sistema desde distintos
puntos de vista.
…mejorar comunicación entre los participantes en el proceso de
diseño.
…alcanzar un mayor nivel de empatía con el potencial usuario del
sistema.

Persona
¿Qué formato tiene un “persona”?

Persona
¿Cómo se elabora un “persona”?
1. Elaborar hipótesis sobre persona
2. Realizar estudio con potenciales usuarios
3. Identificar variables conductuales
(Actividad / Actitud / Aptitud / Motivación / Habilidades)
4. Relacionar los individuos entrevistados (estudiados) con las variables
conductuales definidas
5. Establecer patrones de comportamiento
6. Definir características y objetivos relevantes por patrón de
comportamiento

Persona
¿Cómo se elabora un “persona”?

Persona
¿Cuáles son los pros y contras del “persona”?
 Según el contexto de aplicación puede definirse un
número excesivo de personas
 No incorpora mecanismos de validación, con lo
que pueden fijarse presunciones erróneas
 Poco estructurado
 Fácil de elaborar
 Fácil de combinar con distintos métodos de diseño
 Proporciona un modelo consistente para todos los
integrantes del equipo de diseño

Requisito
(70s)
Caso de uso
(mid 80s)
Escenario
de uso
(mid 90s)
Historia de
usuario
(2000s)
Sistema Usuario

Sobre la importancia del qué y el cómo…
Mapa de tareas
Service blueprint

Requisito
(70s)
Caso de uso
(mid 80s)
Escenario
de uso
(mid 90s)
Historia de
usuario
(2000s)
Sistema Usuario
¿Cómo funciona el
sistema?
Mapa de tareas
Service blueprint

Análisis > Definición del problema > Modelado > Cómo
Especificación de requisitos
¿Qué es un “requisito”?
“Declaración de un producto que especifica sus características sobre:
(i) qué debe ser –requisitos del producto-; y
(ii) cómo debe ser alcanzado –requisitos del proceso-
Un requisito debe ser claro, concreto y medible”

“El tiempo de descarga de una página debe ser inferior a cinco
segundos.”
“El sistema permitirá el acceso a la página principal desde cualquier
página del sitio.”
“El envío de datos entre el cliente y el servidor debe realizar de
manera cifrada.”
“El sistema controlará el estado de la cuenta corriente antes de
permitir el reembolso de la cantidad solicitada.”

Tipo (de) Usuario (de) Sistema
Funcional
El sistema permitirá
crear un nuevo curso
El sistema permitirá
seleccionar entre los
distintos grupos de
matrícula del curso
No funcional
El tiempo de respuesta
del sistema será tal que
no obligará al usuario a
realizar tareas en
paralelo
El tiempo de respuesta
del sistema desde la
ejecución de la
búsqueda hasta que se
recupere el primer dato
será inferior a 10
segundos

El documento de especificación de requisitos
 Definición
“Conjunto de requisitos del sistema estructurados de acuerdo a un
formato establecido.”
 Existen distintas propuestas de formalización de requisitos:
 Estándar IEEE 830
 Agencia Especial Europea (ESA91)
 Plantilla de Volere
 Por cada requisito debe fijarse, al menos, el identificador del requisito, su
tipo y descripción

El documento de especificación de requisitos
Volere Requirements Specification Template

Requisitos de contenido
@Communicating the User Experience - Wiley

Requisito
(70s)
Caso de uso
(mid 80s)
Escenario
de uso
(mid 90s)
Historia de
usuario
(2000s)
Sistema Usuario
¿Cómo actúa el
sistema?
Mapa de tareas
Service blueprint

Caso de uso
¿Qué es un “caso de uso”?
 Definición
“Un caso de uso es una descripción de una interacción entre el usuario y el
sistema desde el punto de vista del usuario.”
 Los casos de uso describen tareas de usuario pero centrándose en la
interacción con el sistema
 El caso de uso debe recoger, al menos, el objetivo, los persona
implicados, el curso básico y el curso alternativo de acciones asociadas al
caso de uso
 Los casos de uso (su relación entre sí y con los actores del sistema) se
representar de manera gráfica mediante el empleo de “diagramas de
casos de uso”.

Caso de uso
¿Qué formato tiene un “caso de uso”?
Jerry’s commercial chipper breaks down. He:
1. Locates user manual and identifies name and model number
2. Enters name and model number in search field at Google.com
3. Hits “Enter”
4. Searches results appear; scans page for name and model number
5. Finds no results that look correct
6. Enters chipper name in search field
7. Hits “Enter”
8. Searches results appear; scans page
9. Finds listing for chipper
10. Clicks link
11. Scans page for model number
12. Identifies link for owner’s manual

Análisis > Definición del problema > Modelado > Qué
Requisito
(70s)
Caso de uso
(mid 80s)
Escenario
de uso
(mid 90s)
Historia de
usuario
(2000s)
Sistema Usuario
¿Qué?
(Con algo de cómo)
Mapa de tareas
Service blueprint

Escenario
¿Qué es un “escenario”?
 Definición
“Un escenario (o escenario de uso) es una narración informal que describe
actividades humanas o tareas de usuario.”
 Un escenario no describe explícitamente el uso de software o de
tecnologías para ejecutar la tarea sino únicamente la tarea en sí
 El escenario debe recoger el objetivo de la tarea, los actores implicados,
así como las acciones realizadas para completarla
 Se crean tantos escenarios como situaciones de interés que necesitan ser
especificadas

Escenario
¿Qué formato tiene un “escenario”?
@User and Task Analysis for Interface Design – John Wiley & Sons

Escenario
“Jerry has been helping his father manage an all-purpose machine shop in Western
Massachusetts since he graduated from high school a decade ago. In the last year,
Jerry’s father has retired, leaving Jerry in charge. Their only commercial wood
chipper, which Jerry’s father purchased before Jerry began working with him, has
broken down. He suspects that the hydraulic pump lever is broken. Jerry manages
to locate the operator’s manual for the chipper, and searches the web for the
manufacturer’s name and the model number. He finds several listings for his
chipper online, and chooses the first one to view. On the chipper’s listing page, he
finds a link to a PDF of the owner’s manual. He reads through it and finds a
diagram showing the hydraulic pump and the part number for the lever. But there is
nowhere on the page he is viewing that indicates he can order this part. He clicks a
link to contact the manufacturer, who he hopes can point him in the right direction.
One of Jerry’s long-time clients, the local country club, is expecting to pick up the
chipper in two weeks.”

Escenario

 Definición
“Representación gráfica de un escenario de uso del sistema priorizando las
tareas necesarias para su ejecución, así como la funcionalidad requerida por
el sistema.”
 Planteado como una alternativa visual al documento de especificación de
requisitos
 Adecuado para representar tanto tareas como flujos de información con el
sistema
 Algunos autores lo nomina como “design map” o “task analysis grid”,
considerándolo como un instrumento para guiar el diseño del sistema
Mapas de tareas
¿Qué es un mapa de tareas?

Mapa de tareas
¿Qué formato tiene un mapa de tareas?

Service Blueprint
 Definición
“Representación gráfica
(diagrama) que describe la
naturaleza y características de
un servicio.”
 Modelo conceptual del servicio
 Frontera entre el análisis del
problema (identificar el servicio) y
la síntesis de la solución (definir la
estructura del servicio)
 Básico en el diseño de servicios y
cada vez más utilizado en Agile UX

Service Blueprint
Representación

Service Blueprint
Proceso de definición

Requisito
(70s)
Caso de uso
(mid 80s)
Escenario
de uso
(mid 90s)
Historia de
usuario
(2000s)
Sistema Usuario
¿Qué? Mapa de tareas
Service blueprint

Historia de usuario
¿Qué es una “historia de usuario”?
 Definición
“Una historia de usuario (en inglés, user story) es una breve descripción que
identifica a un usuario y su necesidad.”
 Originario de las metodologías de desarrollo ágiles dónde se emplean
para la especificación de requisitos
 Una historia de usuario es un enunciado, no una narración, tiene una
extensión de una o dos frases
 Las historias de usuario siguen la estructura:
<persona> <acción> <objetivo>
Alguien realiza una acción para alcanzar un objetivo

Historia de usuario
¿Qué formato tiene una “historia de usuario”?
“As an Industrial Facilities Manager, Cathy is responsible for
maintaining production systems and sustainability, which includes
keeping equipment functional. She needs quick access to maintenance
information and parts supply for her facility’s entire inventory.”
“Jack owns a small landscaping business. He needs to be able to order
replacement parts and have access to resources that will help him
safely and properly service his equipment on his own.”

1 2 3
Definir los “persona” Elaborar “mapa mental” Modelar qué y cómo
1. En base al “modelo mental”,
definir “escenarios” o
“mapas de tareas”
2. Definir los “casos de uso” de
cada “escenario”
3. Si es obligado, definir los
requisitos del sistema

1 2
3
4
Definir los “persona” Elaborar “user journey”
Elaborar “experience map”
Modelar qué y cómo
1. En base al “experience
map”, establecer
“touchpoints”
2. Por cada “touchpoint”, definir
“historias de usuario”
(tomando como referencia el
“experience map”)
3. Si lo solicita el cliente, definir
los requisitos del sistema

1 2
3
4
Definir los “persona” Elaborar “user journey”
Elaborar “experience map”
Modelar qué y cómo
1. Elaborar el “service
blueprint”
2. En base a los artefactos
previos, establecer
“touchpoints”
3. Por cada “touchpoint”, definir
“historias de usuario”
(tomando como referencia el
“experience map”)
4. Si lo solicita el cliente, definir
los requisitos del sistema

Análisis > Definición del problema > Consejo
Recordad: El objetivo no es elaborar
artefactos por elaborarlos, sino definir
adecuadamente las características del
sistema a fin de guiar sucesivas etapas
del proceso.

Sesion05 analisis-definir

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (9)

Similar a Sesion05 analisis-definir

Similar a Sesion05 analisis-definir (20)

Último

Último (20)

Sesion05 analisis-definir

Notas del editor