Página principal

El diseño Última modificación: 02/05/2002 Objetivos 3 Introducción 4


Descargar 266.68 Kb.
Página2/5
Fecha de conversión18.07.2016
Tamaño266.68 Kb.
1   2   3   4   5

Modelo basado en estados: El sistema se define como un conjunto de estados. Las transiciones son provocadas por eventos claramente definidos. El usuario puede observar los cambios en el estado del sistema. Un ejemplo es el sistema de comunicación por teléfono (diferentes pitidos para estados del sistema: ocupado, llamada, etc.)

  • Modelo basado en objetos y acciones: Se trabaja directamente sobre entidades (físicas o abstractas), sobre las cuales podemos realizar acciones. El usuario debe conocer la existencia de objetos, de sus posibles atributos y acciones aplicables. Por ejemplo, los iconos (acciones asociadas y atributos).

    Con estas posibles estructuraciones de la información que residen en el modelo conceptual, podríamos optar por centrarnos en la descripción del conocimiento que el usuario debe tener del sistema (siendo irrelevante la arquitectura del sistema) o viceversa (dando más importancia al modelo del sistema respecto al conocimiento del usuario). A menudo, estas son dos alternativas (en algunos casos complementarias) para el diseño de sistemas interactivos. Una descripción basada en el conocimiento del usuario nos llevará a un modelo de tareas, mientras que una descripción del sistema nos conducirá a un modelo arquitectónico.

    Los modelos de tareas analizan y describen el conocimiento que el usuario debe poseer acerca del sistema para su correcta utilización. En ese sentido, se ha trabajado en dos vertientes. Por un lado, se debe caracterizar el proceso de adquisición de la información por parte del usuario, y por otro, se busca un mecanismo para expresar el rendimiento humano para la ejecución de unas determinadas actividades. Estos métodos se basan en el análisis de tareas y generalmente usan una descripción funcional jerárquica.

    Los modelos arquitectónicos representan la estructura interna del sistema. Se describe la composición del sistema en base a una descripción modular que facilita la composición de componentes simples para la definición de elementos mas complejos. Estos modelos se basan en el concepto de interador, objeto activo o agente interactivo como un objeto especializado que va a formar parte del sistema interactivo y que posee un estado y reacciona ante eventos (estímulos externos al Objeto). Normalmente se usa una descripción basada en estados o bien en objetos y acciones (aproximación que se adapta bien a las metodologías orientadas a objetos existentes).

    Otra alternativa diferente son los modelos abstractos (basados en un modelo de caja negra), los cuales se utilizan para describir las propiedades más relevantes del sistema (consistencia, visibilidad, etc.) en base a las entradas y salidas que se producen en el sistema, y sin tener en cuenta su estructura interna. El modelo PIE propuesto por A. Dix [DIX91] es el más conocido.

    Estos tres modelos no tienen por qué ser excluyentes entre sí, ya que básicamente se diferencian los aspectos relevantes del estudio y en el nivel de abstracción con el que se analiza el sistema.


    1. Análisis de tareas

    Introducción

    El análisis de tareas es un término que cubre diferentes técnicas orientadas a describir las interacciones entre las personas y los entornos de una manera sistemática. El análisis de tareas se puede definir como el estudio de lo que un usuario tiene que realizar en términos de acciones y/o procesos cognitivos para conseguir un objetivo. Es por tanto una metodología que esta soportada por un conjunto de técnicas para ayudar en el proceso analítico de recogida de información, organizarlo y usarlo para realizar valoraciones o decisiones de diseño.

    Conceptos iniciales:


    • Una de las premisas de cualquier aproximación con la que abordemos el diseño es la de conocer el usuario y las actividades que realiza.

    • Esta información se recoge en la fase de análisis de las tareas con una notación que permita su formalización y estudio.

    • Para ello, consideraremos una tarea como una unidad significativa de trabajo en la actividad de una persona.

    El análisis de tareas nos proporciona información muy relevante acerca del sistema a diseñar que a menudo no se recoge con las técnicas de requisitos tradicionales de la ingeniería del software. Dentro del proceso de análisis de tareas, hay dos fases muy importantes:

    • Obtención de la información necesaria para comprender las actividades que realiza el usuario (fase de análisis)

    • Representación de esta información sobre un modelo adecuado (fase de modelado)

    Mediante estos pasos, se obtiene una descripción formal del conjunto de acciones que debe realizar el usuario para la consecución de un determinado objetivo o finalidad. Estos métodos parten de las teorías cognitivas para realizar una representación del usuario y su interacción con la interfaz. Se modela su comprensión, conocimiento, intenciones y mecanismo de procesamiento. El nivel de representación depende del modelo concreto (desde tareas y objetivos hasta el análisis de la actividades motoras). En concreto, esta información puede ser muy útil para:

    • Comprender el dominio de la aplicación: identificación de las actividades más importantes y sus relaciones.

    • Facilitar discusiones interdisciplinares: el conocimiento de las tareas puede ser útil al diseñador, usuarios, analistas, psicólogos, sociólogos, etc.

    • Diseño de la nueva aplicación de forma consistente con el actual modelo conceptual, preservando las características más relevantes del funcionamiento lógico.

    • Análisis y evaluación de usabilidad. Se puede predecir el rendimiento humano e para identificar problemas de uso.

    Definiciones básicas:

    • Objetivo: Es el estado o logro que el usuario quiere alcanzar dentro de una aplicación

    • Tarea: Es la actividad necesaria para conseguir un objetivo. Pueden ser tanto actividades mentales como físicas.

    • Acción: Es cada uno de los pasos a seguir para cumplimentar una tarea. Podemos considerar una acción como una tarea que no implica una solución de un problema o una estructura de control.

    Proceso de obtención y análisis

    En el análisis de tareas deberemos identificar las tareas más relevantes del sistema. La obtención de esta información se puede realizar mediante las siguientes técnicas:



    • Entrevistas y reuniones

    • Cuestionarios

    • Observación del usuario en su trabajo

    • Identificación de actividades en el contexto del entorno

    • Estudio de la documentación actual, programas de formación, etc.

    Mediante esta técnicas, obtendremos información relevante para identificar las tareas. En concreto, nos deberemos centrar en:

    • Información que necesita el usuario para realizar la tarea (qué hacer)

    • Terminología y símbolos del dominio del problema (elementos).

    • Descripción de cómo esas tareas se realizan actualmente (cómo).

    • Casos de uso (situaciones)

    • Tipos de usuarios

    El resultado de este análisis es una lista de tareas relevantes con algún tipo de información adicional (atributos, restricciones, preferencias, etc.). De esta información deberemos abstraer aquellos conceptos que son relevantes para el diseño de la aplicación como son:

    • El modelo de diálogo: cómo se va a realizar la comunicación persona–ordenador, bajo qué paradigma y estilo.

    • Modelo de tareas: Especificación de las tareas en el sistema nuevo.

    • Dominio de sistema: Descripción de los componentes y arquitectura del sistema.

    • Modelo de usuarios: Identificación del tipo de usuarios, papel que desempeñan en el sistema y sus interrelaciones.

    • Propiedades del sistema. Estudio de las características del sistema y de los requisitos que satisface (seguridad, robustez, etc.).

    Métodos de análisis de tareas

    Para llevar a cabo el análisis de tareas, podemos utilizar diferentes métodos que se diferencian en el grado de formalismo de su notación, poder de expresividad y finalidad. Si bien todos ellos representan las tareas del sistema, la finalidad del estudio puede ser diferente:



    • Métodos de competencia o cognitivos. Estos métodos identifican secuencias de comportamiento correctas, representando el tipo de conocimiento que debe poseer un usuario acerca del uso del sistema. Partiendo de la descripción de tareas generan una especificación del conocimiento del usuario.

    • Métodos predictivos para la evaluación del rendimiento humano. Describen secuencias de comportamiento y el conocimiento que necesita el usuario para su ejecución. Análisis centrado en rutinas de comportamiento.

    • Métodos descriptivos. Permiten obtener una descripción más o menos completa del sistema a partir de la información obtenida de las tareas.

    En la siguiente tabla se detallan algunos de estos métodos con sus características más relevantes.

    Método

    Tipo

    Notación

    Especificación

    Comentarios

    HTA

    Cognitivo

    Gráfico

    Semi–Informal

    Modelo de descomposición del conocimiento

    GOMS

    Cognitivo

    Textual

    Semi–Informal

    Familia de lenguajes para describir el conocimiento

    UAN

    Cognitivo

    Gráfico

    Semi–Informal

    Notación para el estilo de manipulación directa

    KLM

    Predictivo

    Textual

    Tiempo

    Medición del rendimiento humano

    TAG

    Predictivo

    Textual

    Esquemas

    Medida de la consistencia

    CTT

    Descriptivo

    Gráfico

    Lógica temporal

    Herramientas de soporte al análisis y verificación.

    Análisis jerárquico de tareas (HTA)

    El análisis jerárquico de tareas (HTA Hierarchical Task Analysis) desarrollado por Annett y Duncan [ANN67], es la técnica de análisis de tareas más conocido y más antiguo.

    En HTA se realiza una descripción de tareas en términos de operaciones y planes. Las operaciones (descomposición en subtareas) son actividades que realizan las personas para alcanzar un objetivo, y los planes son una descripción de las condiciones que se tienen que dar cuando se realiza cada una de las actividades. Las operaciones se pueden descomponer de forma jerárquica y se asigna un plan a cada una de las subtareas que aparecen. Se define un objetivo como un estado determinado del sistema que puede quiere alcanzar el usuario. Aunque se habla de objetivos y tareas, la representación que se realiza describe únicamente la descomposición jerárquica en subtareas de las tareas que aparecen en el sistema.

    El formato gráfico se parece a un árbol con ramas y subramas en función de las necesidades [SHE89]. A la hora describir la descomposición de una tareas en subtareas podemos representar cuatro tipos de descomposiciones:



    • Secuencia. Descomposición en un conjunto ordenado temporalmente de una secuencia de tareas.

    • Selección. Conjunto de tareas de las que se tendrá que elegir una de ellas.

    • Iteración. Repetición de un subconjunto de tareas.

    • Tarea unitaria. Actividad indivisible (según el nivel de detalle dado)

    El análisis de tarea implica tres etapas enlazadas: recogida de información, diagramación y análisis. Los procedimientos de recogida de información incluyen la revisión de la documentación existente (por ejemplo, manuales de funcionamiento, procedimientos, informes de seguridad, estudios de análisis de tareas previos, diseños, imágenes, prototipos, etc.), que permitan establecer qué hacen las personas en circunstancias especificas (normales y anormales), entrevistas y cuestionarios (descripciones por parte de personas experimentadas como hacen las cosas, que informaciones necesitan y como determinan si la tarea se puede realizar satisfactoriamente).



    Figura 5 Notación de HTA

    Algunas tareas se pueden desglosar con mayor detalle en secuencias. Un plan describe el conjunto de operaciones necesarias para llevar a cabo una actividad, o bien, muestra las circunstancias por las que una operación es realizada antes que otra. Estos planes se añaden a la tabla jerárquica.

    La descripción de la información se realiza en forma de tabla o en forma de diagrama de árbol que describa las relaciones entre tareas y subtareas.



    Figura 6 Descripción en HTA de la preparación del té

    0. Hacer té

    1. Calentar el agua

    1.1 Llenar cazo

    1.2 Encender fuego

    1.3 Poner cazo en fuego

    1.4 Esperar

    1.5 Apagar fuego

    2. Vaciar tetera

    3. Poner hojas de té en tetera

    4. Verter el agua

    5. Esperar

    6. Servir el té

    Plan 0: hacer 1.

    si tetera está llena,

    entonces hacer 2 al mismo tiempo

    hacer 3-4-5

    Cuando el té ha reposado, hacer 6

    Plan 1: hacer 1.1-1.2-1.3-1.4

    Cuando el agua está hirviendo, hacer 1.5

    El análisis de la información es la fase final. Usaremos esta información como base para decisiones de diseño y puede servir como guía para las actividades de diseño. La metodología para utilizar HTA como análisis de tareas sería la siguiente:



    • Etapa inicial. Definición de las tarea principal, que puede ser dividida entre cuatro y ocho subtareas.

    • Etapa intermedia. Decidir el nivel de detalle que se requiere y en que punto acabar la descomposición

    • Parte final. Revisión y evaluación del trabajo realizado para comprobar su consistencia

    GOMS

    GOMS (propuesto por Card/Moran [CAR83]) comprende a una familia de lenguajes (que incluye a NGOMSL, KLM) que se basan en la visión del usuario como un sistema procesador de información (modelo de procesador humano) [EBE94]. El modelo GOMS se basa en el mecanismo de razonamiento humano para la resolución de problemas y realiza la formalización de aquellas actividades (físicas y mentales) que intervienen en esa labor. Para cada tarea se describe el objetivo a satisfacer (Goal), el conjunto de operaciones (Operations) que el sistema pone a disposición del usuario para la interacción, los métodos disponibles para llevar a cabo esas operaciones (Methods) y por último, un conjunto de reglas de selección (Selection) para determinar la alternativa más conveniente en cada caso (descritas mediante estructuras de control if–then). Cada tarea se podría descomponer en otras tareas primitivas formando un árbol jerárquico.

    Los objetivos son las metas que se propone el usuario (lo que desea obtener). Los objetivos pueden servir como un punto de referencia en caso de un error. Un objetivo contiene información de la intención del usuario. Para ello, debe realizar una serie de operaciones básicas. Las operaciones son unidades elementales de percepción, motoras o actos cognitivos cuya ejecución es necesaria para cambiar algún aspecto del modelo mental del usuario, o bien, para modificar el entorno. Este tipo de acciones puede afectar al sistema (pulsar una tecla) o bien, sólo al estado mental del usuario (leer el cuadro de diálogo). Existe un grado de flexibilidad acerca de la granularidad de las operaciones (amplitud de cada operación). Para llevar a cabo estas operaciones, existen varias posibilidades de descomposición de una tarea en subtareas. Por ejemplo, en un gestor de ventanas, se puede cerrar la ventana mediante ratón en un menú o teclado (atajo). Cada una de estas posibilidades será un método.

    GOAL: CERRAR-VENTANA

    [select GOAL: USAR-METODO-RATON

    MOVER-RATON-A-MENU-VENTANA

    ABRIR- MENU

    CLICK-SOBRE-OPCION-CERRAR

    GOAL: USAR-METODO-TECLADO

    PULSAR-TECLAS-ALT-F4]

    Cuando hay más de una alternativa, podemos indicar una serie de condiciones y reglas para tomar la mejor alternativa (método):



    METHODS: IF (USUARIO-EXPERTO)USAR-METODO-TECLADO

    ELSE USAR-METODO-RATON]

    Podemos descomponer los objetivos en subobjetivos.



    GOAL: EDITAR-DOCUMENTO

    GOAL: ABRIR-DOCUMENTO

    La descomposición de tareas nos suministra una comprensión de estrategias para resolver problemas del dominio de la aplicación. El objetivo del análisis jerárquico de tareas es la de producir una descomposición de tareas, de modo que se pueda seguir paso a paso el método de resolución.

    GOMS puede servir también para medir rendimientos. La profundidad de subtareas se puede usar para estimar los requerimientos de la memoria de corto plazo (MCP) (ver capítulo ‘El factor humano’) e incluso para estimar tiempo de respuesta (asumiendo tiempos constantes para cada operación).

    En este ejemplo tenemos una descripción de la tarea de mover una pieza en una partida de ajedrez.

    GOAL: MOVER-PIEZA

    . GOAL: DETERMINAR-TURNO

    . . [select GOAL: CONOCER-ULTIMO-MOVIMIENTO

    . . . MOVER-A-LA-HISTORIA-DE-MOVIMIENTOS

    . . . DETERMINAR-ULTIMO-MOVIMIENTO

    . . . COMPROBAR-SI-NO-ERES-TU

    . . GOAL: CONOCER-MOVIMIENTO-SIGUIENTE

    . . . MOVERSE-AL-TABLERO

    . . . IDENTIFICAR-POSICION-DEL-RELOJ

    . . . COMPROBAR-SI-RELOJ-ESTA-EN-TU-POSICION]

    . GOAL: ELEGIR-MEJOR-ESTRATEGIA

    . GOAL: REALIZAR-MOVIMIENTO

    . . GOAL: SELECCIONAR-PIEZA-ADECUADA

    . . . [select GOAL: IDENTIFICAR-PIEZA

    . . . . SELECCIONAR-TECLADO

    . . . . ESCRIBIR-IDENTIFICACION-PIEZA

    . . . . CONFIRMAR

    . . . GOAL: COGER-PIEZA

    . . . . MOVER-CURSOR-A-PIEZA

    . . . . PULSAR-BOTON-RATON]

    . . GOAL: ELEGIR-DESTINO

    . . . [select GOAL: IDENTIFICAR-DESTINO

    . . . . MOVER-CURSO-ARRASTRANDO-PIEZA

    . . . . ESCRIBIR-IDENTIFICACION-POSICION

    . . . . CONFIRMAR

    . . . GOAL: SOLTAR-PIEZA

    . . . . MOVER-CURSOR-ARRASTRANDO-PIEZA

    . . . . SOLTAR-BOTON-RATON]

    . GOAL: CONFIRMAR-MOVIMIENTO

    . . . [select GOAL: TECLA-CONFIRMACION

    . . . . PULSAR-ENTER

    . . . GOAL: PARAR-RELOJ

    . . . . MOVER-CURSOR-RELOJ

    . . . . PULSAR-BOTON-RATON]

    Selection Rule for GOAL: DETERMINAR-TURNO

    Si es una visualización gráfica, usar el método CONOCER-MOVIMIENTO-SIGUIENTE

    en otro caso usar el CONOCER-ULTIMO-MOVIMIENTO

    Selection Rule for GOAL: SELECCIONAR-PIEZA-APROPIADA

    Si no tienes ratón usar el método IDENTIFICAR-PIEZA,

    en otro caso usar el método COGER-PIEZA

    Selection Rule for GOAL: ELGIR-DESTINO

    Si no tienes ratón usar el método IDENTIFICAR-DESTINO,

    en otro caso usar SOLTAR-PIEZA

    Selection Rule for GOAL: CONFIRMAR-MOVIMIENTO

    Si estas usando el teclado usar el método TECLA-CONFIRMACION,

    en otro caso usar el método PARAR-RELOJ

    El modelo GOMS fue uno de los primeros métodos utilizados para el diseño de interfaces de usuario, teniendo gran repercusión en investigaciones posteriores. Permite describir cómo un experto realiza tareas y las descompone en subtareas. Sin embargo, una de sus puntos débiles es que sólo considera comportamientos sin errores y tareas secuenciales.

    KLM

    Uno de los modelo GOMS más simple es el KLM (KeyStroke Level Mode), que simplifica el conjunto de operaciones disponibles a la pulsación de teclas y movimiento de ratón. Esta simplificación permite obtener predicciones del tiempo que una persona empleará para la realización de una tarea.

    Estas mediciones parten de unos valores experimentales que determinan mediciones concretas para la realización de actividades elementales. A partir de estos resultados experimentales, se puede deducir que por término medio:


    • El tiempo de planificación de una tarea se puede estimar que dura 2-3 seg. si ya está definida, y de 5 a 30 seg. si hay que pensarla.

    • El tiempo de respuesta del usuario para una acción varía notablemente según el tipo de dispositivo y de la destreza del usuario. Podríamos crear una tabla donde aparecen las operaciones más usuales sobre los dispositivos (pulsar tecla, mover ratón, etc.) y su tiempo en función de las habilidades del usuario.

    Operador

    Descripción

    Segundos

    K

    Pulsación de teclado:

    Buen mecanógrafo (135 ppm)

    Habilidoso (90ppm)

    Normal (40ppm)

    Malo

    0.08


    0.12

    0.28


    1.20

    P

    Apuntar con el ratón

    1.10

    H

    Ubicar las manos en teclado

    0.40

    D(ND,ID)

    Dibujar un trazo

    (N: nº segmentos, I: longitud)



    0.9ND+.016ID

    M

    Preparación mental

    1.35

    Por ejemplo, podemos comparar el tiempo de respuesta entre el diseño de dos menús con mucha profundidad o con mucha ramificación. En un menú basado en ordenes numeradas (16 opciones). Partiendo de las siguientes hipótesis:

    • Opciones con igual probabilidad

    • Usuario experto mecanógrafo

    Podríamos concluir con la siguiente medición. Una selección de un menú por su posición (1-16) necesitaría de los siguientes operadores:

    • Operador M para buscar y visualizar el menú

    • Uno o dos operadores K para introducir el número de ítem + 1K (pulsación de tecla ENTER)

    M + K (1er dígito) + 0.44K* (2º dígito) + K (Enter)

    1.35 + 0.20 + 0.44(0.20) + 0.20 = 1.84 seg.

    * Usado para las opciones de la 10-16. Probabilidad 7/16 = 0.44

    Se puede comparar con la utilización del ratón para la elección del menú. Para ello bastarán los siguientes operadores:



    M + P + K (click ratón)

    1,35 + 1.10 + 0.20 = 2.65 seg.

    Como vemos, KLM para este caso podría predecir que la selección por teclado sería más rápida (efectiva) que la selección por menú.

    Se puede utilizar para analizar igualmente el balanceo de los menús (profundidad), selecciones de elementos por identificador o apuntando, etc. Otra utilidad que posee este método es la de hacer explícito el conocimiento implícito que debe poseer el usuario acerca del sistema.

  • 1   2   3   4   5


    La base de datos está protegida por derechos de autor ©espanito.com 2016
    enviar mensaje