Interacción Persona - Ordenador

Transcripción

1 Interacción Persona - Ordenador Análisis de Requisitos (II) Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo

2 Análisis de Requisitos Adquisición o recogida de datos Observación y recolección de datos. Toma informal de notas Análisis etnográfico: Observación del entorno y procedimiento de trabajo Estudio de la audiencia: Usuarios y sus necesidades Análisis de la competencia: Métodos anteriores, versiones previas o aplicaciones similares Análisis e interpretación de la información Sistematización en formularios, siguiendo normas o estándares Objetivos de la aplicación: Descripción de tareas (requisitos, casos de uso) Objetivos de usabilidad y accesibilidad Plataforma hardware y software necesaria. Dispositivos de interacción.

3 Análisis de la información Qué tenemos en este momento? Entrevistas, p. ej con 5 clientes, un directivo y tres trabajadores. Cuestionarios, p. ej. 50 encuestas recogidas de un formulario en internet Anotaciones de la observación, p.ej. notas de dos visitas al centro de trabajo: procesos administrativos, organización, posibles incidencias, etc

4 Análisis de la información Siguiente paso: Análisis e interpretación de la información recogida. Los datos obtenidos serán: Cuantitativos: Obtención de valores numéricos: porcentajes, promedios, medias, desviaciones estándar, etc. Cualitativos: Identificar patrones y/o temas recurrentes, categorización y segmentación de datos y usuarios, análisis de los incidentes críticos. Nota: Hay que tener cuidado con el modo de interpretar la información

5 Análisis de la información Se efectúa mediante sistematización en formularios. La información recogida de manera informal se estructura y se presenta en plantillas siguiendo metodologías estandarizadas, en lo posible: Estándares de facto: empresas, fabricantes Estándares de iure: Normas ISO, UNE Metodologías de IS

6 Análisis: Objetivos de la aplicación Además de los requisitos del sistema que veremos no hay que perder de vista los objetivos generales: Objetivos de negocio (de la empresa) Cuáles son las razones de empresa? Cómo determinará la empresa que la aplicación es un éxito? Objetivos de los usuarios Por qué los usuarios van a utilizar esta aplicación y no otra? Si no puedes dar razones para que la usen probablemente fracasará Hay que considerar cómo podemos mejorar nuestro servicio

7 Análisis: Objetivos de la aplicación La información recogida es útil para definir los objetivos de la aplicación. Se definen entonces los requisitos del sistema, es decir, las características que se deben incluir en el sistema. Existen dos tipos de requisitos: Funcionales (RF): Establecen la funcionalidad del sistema qué hace el sistema? Describen las interacciones entre el sistema y el entorno Son independientes de la implementación No funcionales (RNF): Criterios para juzgar cómo opera el sistema Atributos de calidad Restricciones de implementación

8 Análisis: Objetivos de la aplicación Algunos ejemplos de requisitos no funcionales típicos son los siguientes: rendimiento disponibilidad seguridad accesibilidad usabilidad estabilidad portabilidad costo operatividad interoperabilidad escalabilidad concurrencia mantenibilidad interfaz

9 Análisis: Objetivos de la aplicación Es necesario elaborar un catálogo de requisitos que el software deberá satisfacer. Existen diferentes formas de representación de los requisitos: - tablas de requisitos - árboles de decisión - tablas de decisión - casos de uso -...

10 Análisis: Objetivos de la aplicación Representación de Requisitos mediante una tabla: Técnica sencilla de enumeración en una tabla Un requisito se representa con un código y un texto que lo describe La estructura del código es fijada por la organización

11 Análisis: Objetivos de la aplicación Ejemplo: Representación de Requisitos Volere shell (Preece, Rogers & Sharp)

12 Análisis: Objetivos de la aplicación Ejemplo: Representación de requisitos

13 Análisis: Objetivos de la aplicación Representación de Requisitos Funcionales mediante casos de uso:

14 Análisis: Objetivos de la aplicación Casos de uso Un caso de uso especifica el comportamiento de un sistema o de una parte del mismo. Pero no especifica cómo se implementa dicho comportamiento. Describe el funcionamiento del sistema desde el punto de vista del usuario. Se usa fundamentalmente en la fase de análisis de requisitos. Un caso de uso describe la secuencia de interacciones que se producen entre un actor y el sistema. Los casos de uso describen los requisitos funcionales del sistema. Descripción: diagrama de casos de uso

15 Análisis: Objetivos de la aplicación Diagrama de caso de uso: Muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. Los elementos que pueden aparecer en un diagrama de Caso de Uso son: Actores, Casos de uso y Relaciones.

16 Elementos de un diagrama de casos de uso Casos de uso Un caso de uso tiene un nombre y se representa mediante una elipse. El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema.

17 Elementos de un diagrama de casos de uso Actores Un actor es una entidad externa al sistema que realiza algún tipo de interacción con el mismo. Esta representación sirve tanto para actores que son personas como para otro tipo de actores (otros sistemas, sensores, etc.). Los actores no forman parte del sistema, aunque aparecen en los modelos.

18 Elementos de un diagrama de casos de uso Relaciones UML define cuatro tipos de relación en los Casos de Uso: De Comunicación:

19 Elementos de un diagrama de casos de uso Relaciones De Generalización: El caso de uso hijo hereda la especificación del caso de uso padre. El hijo puede añadir o redefinir el comportamiento del padre. El hijo puede ser colocado en cualquier lugar donde aparezca el padre.

20 Elementos de un diagrama de casos de uso Relaciones De Inclusión: un caso de uso base incorpora explícitamente el comportamiento de otro caso de uso (proveedor) en el lugar especificado en el caso base. Representa un comportamiento común del caso de uso. Representa un comportamiento que es reusado (un caso de uso utiliza a otro). Relación de dependencia con estereotipo <<include>>

21 Elementos de un diagrama de casos de uso Relaciones De Extensión: un caso de uso base incorpora implícitamente el comportamiento de otro caso de uso (proveedor) en el lugar especificado indirectamente por el caso proveedor. Se utiliza para modelar la parte de un caso de uso que el usuario puede ver como comportamiento opcional del sistema. Separa el comportamiento opcional del obligatorio. También se usa para modelar un subflujo que se ejecuta bajo ciertas condiciones.

22 Elementos de un diagrama de casos de uso Ejemplos: Biblioteca, cajero automático

23 Construcción del diagrama de casos de uso Para construir el modelo de Casos de Uso en la fase de Análisis se siguen los siguientes pasos: 1. Se describe uno o varios escenarios 2. Se identifican los posibles usuarios del sistema y los casos de uso 3. Se dibuja el diagrama de casos de uso 4. Se ordenan y describen los casos de uso

24 Construcción del diagrama de casos de uso 1. Descripción de escenarios Una técnica muy útil para descubrir el funcionamiento de un sistema desde el punto de vista de los usuarios es la de los escenarios. Un escenario es una descripción textual del funcionamiento típico de un sistema o tarea desde la perspectiva de un usuario concreto. Describe el comportamiento de usuarios representativos. Al menos un escenario por tipo de usuario o actor

25 Construcción del diagrama de casos de uso Ejemplo: Caso de uso: Comprar entradas Ange Schmidt es una clienta de DeustcheSparKasse con un saldo medio de más de Utiliza el cajero para la mayor parte de sus transacciones. A última hora de la tarde de los viernes entra a un cajero de la entidad, se registra, selecciona la operación Comprar entradas, revisa las ofertas para ese fin de semana y selecciona un espectáculo. Si quedan entradas, selecciona dos localidades y las paga. Recoge las entradas y su tarjeta y sale del cajero.

26 Construcción del diagrama de casos de uso 2. Identificación de los posibles usuarios del sistema y de los casos de uso Se identifican los actores del sistema. En una tabla se especifican todos los casos de uso en el formato de alto nivel. 3. Dibujado del Diagrama general de Caso de Uso. Se relacionan los casos de uso y se ilustran las relaciones en el Diagrama de Casos de Uso (<<extend>> y <<include>>). 4. Ordenación y descripción Se ordenan según prioridad los casos de uso para implementar primero los que sean críticos. Se describe cada caso de uso.

27 Documentación del diagrama de casos de uso Descripción del caso de uso (textual): Nombre del caso de uso Actores implicados Flujo de eventos: Flujo de eventos principal: Cómo y cuándo empieza y acaba el caso de uso y secuencia de interacciones con los actores. Flujos alternativos

28 Documentación del diagrama de casos de uso Caso de Uso: Reintegrar efectivo Actores: Cliente Flujo de eventos principal: El caso de uso comienza cuando un cliente llega al cajero automático e introduce la tarjeta. Include introducir pin. El sistema le muestra las operaciones disponibles. El cliente selecciona la operación de reintegro por una cantidad específica. El cajero le da el dinero solicitado. Generar comprobante: punto de extensión. El cliente coge el dinero, la tarjeta (y el comprobante, si lo ha solicitado) y se acaba el caso de uso. Flujo de eventos alternativo: Si el pin introducido es incorrecto se reinicia el caso de uso. Flujo de eventos alternativo: Si el saldo es insuficiente se cancela la operación y se reinicia el caso de uso.

29 Análisis: Objetivos de usabilidad Desde el punto de vista de la empresa: Establecer medidas (cuantitativas) de éxito: Órdenes de compra Acceso a un documento Visitas Descargas Necesitamos un marco formal: Normativa ISO/EN/UNE

30 Análisis: Objetivos de usabilidad Desde el punto de vista del usuario: Cómo aseguramos la eficiencia, eficacia y satisfacción del usuario? Es necesario identificar objetivos cuantificables que permitan medir y valorar si la aplicación es usable Cuánto tiempo pueden invertir los usuarios aprendiendo? Cuántos errores podrían cometer?

31 Definición: Análisis: Objetivos de usabilidad La medida en la que un producto se puede usar por determinados usuarios para conseguir objetivos específicos con efectividad, eficiencia y satisfacción en un contexto de uso especificado (ISO ). Un sistema es usable si es fácil de aprender y fácil de utilizar. Para poder hacer sistemas usables hace falta: Comprender los factores psicológicos, ergonómicos, organizativos y sociales. Desarrollar herramientas y técnicas. Conseguir una interacción eficiente, efectiva y satisfactoria.

32 Análisis: Objetivos de usabilidad Normativa: UNE-EN ISO Componentes de la usabilidad

33 Análisis: Objetivos de usabilidad Definiciones (ISO ): Efectividad: Precisión y grado de consecución con que los usuarios logran objetivos establecidos. Eficiencia: Relación entre los recursos empleados y la precisión y el grado de consecución con que los usuarios logran objetivos establecidos. Satisfacción: Ausencia de incomodidad y existencia de actitudes positivas hacia la utilización del producto.

34 Efectividad Usabilidad: Objetivos Cómo de bueno es el sistema a la hora de hacer lo que se supone debe hacer? Eficiencia Una vez aprendido el manejo se tarda poco en llevar a cabo las tareas? Satisfacción Está el usuario conforme con el sistema? Tiene quejas?

35 Análisis: Objetivos de usabilidad Normativa: UNE-EN ISO Esta normativa se utiliza para comprobar la usabilidad de un sistema.

36 Análisis: Otros objetivos de usabilidad Seguridad El sistema protege al usuario de situaciones no deseadas? Permite al usuario recuperarse fácilmente en caso de error? Utilidad El sistema permite hacer todas las tareas que el usuario debe hacer? Facilidad de aprendizaje Puede el usuario aprender por exploración? Cuánto le costaría aprender todas las funcionalidades de esa forma? Facilidad de recuerdo de uso Qué tipo de soporte se le da al usuario para que recuerde cómo llevar a cabo tareas infrecuentes?

37 Análisis: Objetivos de usabilidad UNE-EN ISO

38 Análisis: Objetivos de usabilidad UNE-EN ISO

39 Análisis: Objetivos de usabilidad Se pueden utilizar los parámetros de medida de ISO también para establecer objetivos de usabilidad: Impresión subjetiva Calificar el sitio como mínimo de 2,5 sobre 7 (elegante ) Tareas realizadas Un 75% de usuarios que intente comprar un artículo llegue al final

40 Análisis: Objetivos de usabilidad Tiempo aprendizaje/tiempo tarea Usar el sitio por primera vez sin entrenamiento < 10 minutos Encontrar un tema por primera vez en menos de 2 minutos Usuarios expertos (5 visitas) menos de 30 segundos Número de errores No visitar más de tres páginas erróneas para visitar una página No cometer errores fatales irrecuperables

41 Análisis: Objetivos de usabilidad Al analizar los objetivos de la aplicación hay que tener en cuenta el estudio de la audiencia y el análisis de la diversidad y optar por el diseño adecuado: Diseño generalista: Una interfaz de propósito general para todo el mundo Diseño optimizado: Diseño simple para audiencia reducida y concreta Diseño alternativo: Diferentes interfaces individuales para cada grupo, entorno (móvil u oficina), etc. Diseño multipropósito: Diseño único con partes diferentes para cada sector

42 Análisis: Objetivos de accesibilidad Accesibilidad: Grado en el que un producto, dispositivo, servicio o entorno está disponible para tantas personas como sea posible. Pensar en dotar de funcionalidad total para todos los tipos de discapacidades supone un reto difícilmente alcanzable (amplio abanico de discapacidades, dificultad de personalización, ) Hay que tener en cuenta la necesidad de incorporar dispositivos específicos.

43 Análisis: Objetivos de accesibilidad Para plantear los objetivos de accesibilidad hay que considerar las limitaciones que se van a abordar. Discapacidad Una diferencia individual que supera un límite más o menos arbitrario Muchas de estas discapacidades están presentes en grado diferente entre muchos sujetos considerados normales

44 Análisis: Objetivos de accesibilidad Para plantear los objetivos de accesibilidad hay que considerar las limitaciones que se van a abordar. Tipos de discapacidades: Deficiencias visuales Auditivas Movimiento Cognitivas

45 Análisis: Plataforma HW & SW Entorno informático de trabajo de los usuarios Ordenadores y sistemas operativos Monitores y otros periféricos Considerar diferencias en el dispositivo (móviles, oficina) Considerar diferencias en navegador, en la red

46 Análisis: Plataforma HW & SW Definir la plataforma HW y el entorno SW más adecuado teniendo en cuenta: Análisis etnográfico: considerar el modelo mental del usuario, cómo realiza las tareas, etc. Análisis de la audiencia: considerar el grupo o grupos que utilizarán la aplicación, teniendo en cuenta todos los puntos de vista (edad objetivo, nivel adquisitivo, perfil, etc) Objetivos de la aplicación Objetivos de usabilidad Objetivos de accesibilidad

47 Esbozos: Prototipado de los requisitos El documento de análisis de requisitos suele incluir unos primeros bocetos (prototipo inicial).

48 Evaluación en Análisis de Requisitos Para verificar que los requisitos planteados son adecuados hay que realizar una evaluación Existen numerosas técnicas de evaluación, entre las que destacan: Entrevistas, cuestionarios, grupos de discusión (utilizadas también en la definición de los requisitos) Evaluaciones de tipo recorrido cognitivo Evaluaciones a partir de descripciones formales de escenarios de casos de uso Tests de usabilidad

49 Conclusiones Hacer un buen análisis de los requisitos del sistema a desarrollar es crucial. Debemos conocer quiénes serán nuestros usuarios. Hace falta definir para cada categoría sus necesidades y metas. Debe hacerse un prototipado completo: actores, tareas, relaciones... Se deben definir de forma clara los objetivos de la aplicación, de usabilidad y de accesibilidad para tenerlos en cuenta a la hora de realizar el diseño.