sesion05 analisis-definir

AnálisisDavid Díez Cebollero

Departamento de InformáticaUniversidad Carlos III de Madrid

DISEÑO DE SISTEMAS INTERACTIVOS

Grado en Ingeniería Informática

Diseño de Sistemas InteractivosAnálisis > Contenido sesión 5

Entender la importancia de la definición del problemaEntender la importancia de modelar el quién, el qué y el

cómoConocer la utilidad del uso de narrativas y diagramasDefinir 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


Diseño de Sistemas InteractivosAná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 sistemaEstablecer el perfil y características de los potenciales usuarios del sistema

Qué hará ese quién gracias al sistemaFijar 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)


Diseño de Sistemas InteractivosAnálisis > Definición del problema > Modelado

Sobre la importancia del quién…

@About Face 3 - Wiley


Diseño de Sistemas InteractivosAná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 usuarioPerfil de usuario (user profile): Conjunto de características de un grupo de usuarios del sistema

No es un rol del usuarioRol del usuario (en UML, actor): Conjunto de tareas/operativas acometidas por un usuario del sistema

No es un estereotipoEstereotipo: Idea comúnmente aceptada pero no basada enpruebas 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 persona2. Realizar estudio con potenciales usuarios3. Identificar variables conductuales

(Actividad / Actitud / Aptitud / Motivación / Habilidades)

4. Relacionar los individuos entrevistados (estudiados) con las variables conductuales definidas

5. Establecer patrones de comportamiento6. Definir características y objetivos relevantes por patrón de

comportamiento



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

http://learningspacetoolkit.org/wp-content/uploads/IMLS-persona_process.pdf



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)




Sistema Usuario

¿Cómo funciona el sistema? Mapa de tareas

Service blueprint


Diseño de Sistemas InteractivosAná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

FuncionalEl 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



Especificación de requisitosEl documento de especificación de requisitos

Definición“Conjunto de requisitos del sistema estructurados de acuerdo a un formato establecido.”

Características 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



Especificación de requisitosEl documento de especificación de requisitos

Volere Requirements Specification Template



Especificación de requisitosRequisitos de contenido

@Communicating the User Experience - Wiley

http://download.e-bookshelf.de/download/0000/5963/98/L-X-0000596398-0001311611.XHTML/images/9781119971108-fgin04_opt.jpeg



Requisito(70s)




Sistema Usuario

¿Cómo actúa el sistema?

Mapa de tareasService 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.”

Características 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 number2.Enters name and model number in search field at Google.com3.Hits “Enter”4.Searches results appear; scans page for name and model number5.Finds no results that look correct6.Enters chipper name in search field7.Hits “Enter”8.Searches results appear; scans page9.Finds listing for chipper10.Clicks link11.Scans page for model number12.Identifies link for owner’s manual


Diseño de Sistemas InteractivosAnálisis > Definición del problema > Modelado > Qué

Requisito(70s)




Sistema Usuario

¿Qué?(Con algo de cómo)

Mapa de tareasService 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.”

Características 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




“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.”

Complete

Task Scenario


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.”

Características 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?

http://www.servicedesigntools.org/sites/default/files/res_images/TASK_GRID.jpg



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

http://www.uxforthemasses.com/blog/wp-content/uploads/2014/08/Example-task-map-3.jpg


Service BlueprintDefinición

“Representación gráfica (diagrama) que describe la naturaleza y características de un servicio.”

Características 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 BlueprintRepresentación



Service BlueprintProceso de definición




Requisito(70s)




Sistema Usuario

¿Qué? Mapa de tareasService 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.”

Características 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 3Definir 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

Task-based

approach



1 2

3

4Definir 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

Experience-based

approach



1 2

3

4Definir 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

Experience-based

approach


Diseño de Sistemas InteractivosAná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.

Diseño de Sistemas InteractivosAnálisis > Contenido sesión 5

Entender la importancia de la definición del problemaEntender la importancia de modelar el quién, el qué y el

cómoConocer la utilidad del uso de narrativas y diagramasDefinir 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
