El diseño

Objetivos

Objetivos a conseguir

• Conocer el proceso de diseño de sistemas interactivos

• Estudiar notaciones y métodos para el análisis de la interfaz de usuario

• Conocer y aplicar análisis de tareas

• Introducir conceptos de diseño orientado a objetos

• Analizar estrategias de diseño

Introducción

Los sistemas interactivos se caracteriza por la importancia del diálogo con el usuario. La interfaz de usuario es por tanto, una parte fundamental en el proceso de desarrollo de cualquier aplicación y por tanto se tiene que tener en cuenta su diseño desde el principio. La interfaz es la parte (hardware y software) del sistema informático que facilita al usuario el acceso a los recursos del ordenador. En este sentido, Thimbleby [THI90] sugiere que la interfaz determinará en gran medida la percepción e impresión que el usuario poseerá de la aplicación. El usuario no está interesado en la estructura interna de la aplicación, sino en cómo usarla. No se puede realizar la especificación, diseñar las funciones y estructuras de datos y escribir el código y una vez casi terminado el proceso de desarrollo de la aplicación plantearse el diseño de la interfaz de usuario. Siguiendo esta forma de trabajo lo mas seguro es que se obtengan diseños de interfaces muy dependientes de los diseños que se han realizado de las datos y de las funciones, sin tener en cuenta que esos datos han de ser obtenidos y representados por y para el usuario.

Una vez tenemos hecha la especificación, propuesto un diseño y el código está implantado, es muy difícil cambiar las características de la interacción y presentación de la información, excepto pequeñas cosas. Por tanto, deberemos empezar con un idea clara de cómo queremos la interfaz y como serán las interacciones con el usuario para después, desarrollar las especificaciones funcionales que sirvan de guía al diseño posterior.

En el desarrollo de aplicaciones interactivas se podrán aplicar las técnicas de la ingeniería de software, pero teniendo en cuenta que hemos de modificar algunos aspectos de los métodos de diseño clásico para adaptarlos a las peculiaridades de estos sistemas. Hay que tener en cuenta que un aspecto fundamental es el análisis y diseño de la parte interactiva, y que para realizarlo, necesitaremos aplicar de técnicas de análisis y diseño específicas.

El desarrollo de un sistema interactivo deberá tener en cuenta a los participantes que van a intervenir en el mismo: el usuario, que posee la capacidad de elección y actuación, la computadora, que ofrece un programa y mecanismos para su acceso, y el diseñador, el encargado de anticipar las posibles acciones del usuario y codificarlas en el programa. Todo ello se articula a través de la interfaz de Usuario de la aplicación.

Figura 1 Participantes de un sistema interactivo

La tendencia hacia interfaces de usuarios fáciles de usar provoca que su diseño sea cada vez más complejo. La interfaz de usuario, como medio de comunicación entre el humano y la computadora se caracteriza por su apariencia (presentación) y su capacidad de gestión del diálogo. Podemos encontrar multitud de productos que permiten la descripción y generación automática de la apariencia externa de una aplicación mediante la utilización de paletas de recursos (botones, menús, etc.) herramientas visuales, toolkits, etc. Sin embargo, estas herramientas no suministran suficiente ayuda en el análisis del comportamiento dinámico de la interfaz, en su descripción y sobre todo, no aseguran su corrección. A continuación introduciremos una aproximación de ingeniería para el diseño de sistemas interactivos.

Análisis centrado en el usuario

El diseño de un sistema interactivo debe satisfacer las demandas de los usuarios que lo van a utilizar. El ordenador es una herramienta para realizar un determinado trabajo o actividad, y para que sea una buena herramienta, deberá ser adecuada, cómoda y eficiente para realizar estos cometidos. Para lograr un buen diseño, deberemos partir de un análisis profundo del contexto donde se desarrolla el trabajo [HAC98]. Para ello deberemos analizar las características del usuario, las actividades que realiza y el escenario donde se desempeña su actividad. Todos estos factores permitirán conocer los requisitos que se deben satisfacer en el diseño del sistema.

Los usuarios

En primer lugar, a la hora de diseñar el sistema, deberemos tener en cuenta las peculiaridades de los usuarios potenciales del mismo. Esta necesidad de incorporar el factor humano en el diseño viene dada por el reconocimiento del mal diseño que se ha hecho en gran cantidad de aplicaciones y el deseo de crear productos que ayuden de forma efectiva al usuario. Además, la características de los usuarios pueden afectar al modo de trabajo y condicionar el proceso de comunicación con el sistema. Por ejemplo, los factores humanos pueden condicionar el tiempo de aprendizaje, el rendimiento (tiempo para realizar una tarea), la frecuencia de errores cometidos, grado de retención (memoria de uso) o de satisfacción del usuario. A la hora de diseñar la aplicación, se puede realizar por encargo directo (por lo que existe un cliente), o bien, dirigirlo a un colectivo más o menos amplio de potenciales usuarios (niños, profesionales, estudiantes, etc.).

El análisis del usuario implica conocer aspectos tales como:

• Habilidades físicas y sensoriales. Estas habilidades determinarán en gran medida la adaptación del entorno de trabajo a las características del usuario (tamaño de los botones, tipo de dispositivos, etc.). Podemos encontrar casos en los que el diseño debe ser preferentemente ergonómico por las limitaciones en movilidad de los usuarios, como por ejemplo, la discapacidad por parálisis cerebral, o tener en cuenta pequeñas alteraciones como por ejemplo el daltonismo (ver capítulo "Accesibilidad").

• Habilidades cognitivas. Estas diferencias en la capacidad de razonamiento y conocimiento están motivadas por el grado de experiencia que posee el usuario tanto de su propio trabajo como del uso del ordenador como herramienta. Podemos tener una gran variedad de usuarios desde los expertos a los noveles, usuarios cotidianos u ocasionales, motivados o no, etc.

• Diferencias de personalidad. Las diferencias en la personalidad puede provocar alteraciones en la propia comunicación. Así, personas tímidas tendrán un comportamiento más cauto y prudente ante el ordenador que una persona extrovertida y nerviosa.

• Diferenciación cultural. También podemos encontrar diferencias motivadas por el entorno socio–cultural donde se encuentra el usuario, que puede afectar al lenguaje utilizado, expresiones y terminología, modo de trabajar, etc. (ver capítulo "Internacionalización")

Este conjunto de características relevantes de los usuarios serán de gran ayuda en las etapas posteriores de diseño. Para ello, podemos partir de una tabla en la cual se recoja los distintos tipos de usuarios (secretaria, director, técnico..) y sus características relevantes (grado de utilización del sistema, nivel de experiencia, etc.).

Las tareas

Otro factor importante a tener en cuenta en el diseño son las tareas que realizan los usuarios. Nuestra forma de actuar está dirigida por objetivos (goals) como se recoge en el modelo de Norman (ver capítulo "El factor humano"). Para lograr ese objetivo (por ejemplo comer), debemos llevar a cabo una serie de actividades (encender, coger, poner…) sobre unos objetos (microondas, pizza, temporizador…) encaminadas a lograr ese objetivo. A la hora de realizar estas tareas mediante un sistema interactivo deberemos tener en cuenta que sigan siendo familiares al usuario, es decir, la forma de llevarlas a cabo, su representación así como la secuencia de acciones debe ser similar a la que realiza en el entorno real. Si esto no se satisface, el usuario requerirá un esfuerzo adicional para comprender las tareas que realiza cotidianamente.

El escenario

Las personas no realizan su trabajo de forma aislada, sino que se ven condicionadas por el escenario donde se desempeña esta labor. Los aspectos más relevante a tener en cuenta son:

• Entorno físico. El entorno es fundamental para poder trabajar. Deberemos prestar atención a las características ergonómicas del mismo (tipo de ubicación, iluminación, espacio, etc.) así como las peculiaridades del entorno (ruido, polución, calor, etc.). Puede haber casos de especial importancia como sitios de alto riesgo (central nuclear) o condiciones extremas (submarino, aeronave..)

• Entorno social. El entorno social implica el trabajo dentro de un grupo donde existen unas normas de comportamiento. Podemos encontrar situaciones en las cuales pueda haber cooperación para el trabajo (ayuda), compartir datos o recursos, dependencias jerárquicas, etc.

Algunas de estas características pueden condicionar el diseño, ya que un trabajo en equipo fuertemente acoplado (con alto nivel de cooperación y compartición de datos) requerirá de una aplicación groupware para trabajo en grupo (ver capítulo "Trabajo cooperativo con ordenador").

Ciclo de vida de la interfaz de usuario

La construcción de un sistema interactivo implica un proceso cíclico de diseño, desarrollo y evaluación. La realimentación que proporciona la evaluación sobre el diseño es fundamental para refinar y pulir aspectos que son muy dependientes de los usuarios finales (el factor humano) una vez que el sistema se ha puesto en marcha. En la siguiente figura se muestran algunas de las peculiaridades de ciclo de vida como son la importancia del usuario (tanto en la fase de análisis como de evaluación) y la naturaleza cíclica del diseño (con continua realimentación a partir de la evaluación).

Figura 2 Ciclo de vida del sistema interactivo

Las primeras interfaces las realizaban los propios programadores para los programas que ellos mismos utilizaban. Sin embargo, los diseños deben ir dirigidos a usuarios con diferentes habilidades, y no necesariamente tienen que ser expertos en informática. Los ordenadores son herramientas con las cuales las personas pueden realizar sus tareas, por lo que deberemos tener esto en cuenta a la hora del diseño, ya que si el usuario percibe que algo es difícil de usar, cometerá errores, o bien no realizará la tarea adecuadamente. Para que esto no suceda, es muy importante basar el diseño del sistema sobre aquellos conceptos que maneja el usuario y fundamentarse sobre criterios consistentes y fundamentos teóricos y no en meros juicios intuitivos.

Un buen diseño depende del conocimiento (fundamentos) y experiencia de los diseñadores. Esta información se puede organizar y estructurar para que pueda servir a otros diseñadores. Podemos disponer de varias fuentes de información con diferente grado de rigor y normativa, entre las que podemos destacar:

• Principios. Son objetivos generales que pueden ser útiles para organizar el diseño. Aconsejan al diseñador cómo debe proceder. Sin embargo, no se especifican métodos para obtener esos objetivos, y está limitado al uso práctico (por ejemplo: conocer al usuario, minimizar el esfuerzo para realizar una tarea, mantener la consistencia, etc.).

• Guías (guidelines). Conjunto de recomendaciones que deben ser aplicados a la interfaz y que son cuantificables. Deben ser generales para que puedan ser aplicadas en diferentes contextos. Pueden deducirse de teorías cognitivas, ergonomía, sociología, de la experiencia etc. (por ejemplo, no disponer mas de siete ítems en un menú).

• Estándares. Son principios y guías que se deben seguir por imposición industrial. Existen estándares de facto (Macintosh Toolbook, MS Windows, IBM SAA/CUA). Estos estándares se diseñan para proteger la uniformidad y la línea de productos desarrollados. Con ello, mejoran la eficiencia del usuario (beneficio de una interfaz común para muchos programas). Existen otros estándares en otros ámbitos: ANSI, ISO, DIN, MIL–STD, NASA–STD.

Este conocimiento puede ayudar en el diseño, aunque sin embargo no es suficiente, por lo que deberemos partir de los requisitos del sistema, conocimiento del usuario y aplicar una metodología para un desarrollo efectivo del sistema. Deberemos aplicar técnicas de análisis y especificación para la descripción de aquellos aspectos que sean relevantes dentro del sistema.

Un diseño centrado en el usuario requiere de una continua evaluación del producto a desarrollar. Por este motivo, cobran gran importancia los siguientes aspectos:

• Métodos formales. Permiten una especificación precisa y sin ambigüedad del diseño a generar. Permite una verificación formal de propiedades y en algunos casos se puede generar la implementación automáticamente.

• Herramientas de desarrollo de interfaces modelados (MB–UID). Estas herramientas obtienen el interfaz a partir del análisis de los requisitos de usuario. Su labor fundamental es la generación de aplicaciones a partir del diseño aunque también se pueden considerar como herramientas de prototipado. Actualmente los lenguajes de programación visuales también disponen de librerías (ej. AWT en Java) que permiten implementar las técnicas de interacción y presentación de la información. (ver capítulo "Herramientas").

• Prototipado. Los prototipos son documentos, diseños o sistemas que simulan o tienen implementadas partes del sistema final. El prototipo es una herramienta muy útil para hacer participar al usuario en el desarrollo y poder evaluar el producto ya en las primeras fases del diseño (modelo del ciclo de vida basado en prototipos).

No obstante, el desarrollo de sistemas interactivos sigue siendo una labor difícil y con un alto coste en tiempo y esfuerzo. Un motivo de esta complejidad es por la necesidad de adaptar el diseño a una gran variedad de usuarios, a diferentes cometidos y sobre diferentes contextos.

Aproximaciones al diseño

El desarrollo de Sistemas Interactivos es una tarea compleja para la cual necesitaremos de herramientas y metodologías que nos permitan realizar un diseño satisfactorio centrado en el usuario. Existen dos aproximaciones para realizar el diseño:

• Aproximación empírica. El diseño se basa en la propia experiencia del diseñador o bien en la de otros diseñadores que se recoge mediante compendios de recomendaciones (guías, reglas de oro, estándares, etc.) más o menos relevantes para la construcción de un interfaz con éxito. Estos resultados generalmente están avalados por unos estudios de evaluación por el usuario (tests de usabilidad).

• Aproximación metodológica. Se basa en unos fundamentos teóricos y en la aplicación de una serie de pasos para la realización del diseño.

La aproximación metodológica posee bastantes aportaciones de otras disciplinas, sobre todo de las teorías cognitivas ya que aportan mecanismos para la descripción del conocimiento que el usuario posee del sistema. De hecho, la aproximación empírica se basa en las aportaciones más relevantes (enunciadas como reglas de diseño) de las aportaciones teóricas (ver capítulo "Estándares y guías"). En este capítulo nos centraremos en una aproximación metodológica para el desarrollo de sistemas interactivos, analizando las peculiaridades de este tipo de sistemas y los mecanismos existentes para su análisis y diseño.

En el ámbito del los sistemas interactivos se ha utilizado el término diseño con muchas connotaciones. De hecho, el concepto de diseño abarca desde aspectos de análisis (de usuarios, tareas, del entorno, propiedades), aspectos de modelado (arquitectura) hasta cuestiones relativas propiamente de diseño (apariencia, codificación, etc.).

Modelo mental y modelo conceptual

Un aspecto muy importante en el diseño de sistemas interactivos es el factor humano (ver capítulo "El factor humano"), por lo que deberemos partir de modelos cognitivos que nos permita estudiar y representar cómo es asimilada y procesada la información por una persona. La obtención del conocimiento acerca de una aplicación basada en ordenadores se realiza mediante un aprendizaje. Para ello, se introducen dos términos para identificar el grado de asimilación y comprensión del usuario del entorno:

• Modelo conceptual: Es una abstracción externa que describe, mediante diagramas y notaciones más o menos formales, el conocimiento que debe poseer una persona acerca de un sistema. Este modelo es realizado por el analista y debe ser completo, consistente y exacto (sin ambigüedad).

• Modelo mental (o modelo de usuario): Es la abstracción del conocimiento interno que posee el usuario. Este modelo nos da una medida real de lo que el usuario piensa/conoce acerca del sistema informático. Este modelo guía las intenciones del usuario para realizar una tarea en el sistema. Además, este modelo mental se puede ir modificando conforme se interacciona con el sistema.

El modelo conceptual está basado en un conjunto de elementos y de relaciones que se pueden observar en un determinado sistema, representando el conocimiento que cualquier usuario debería adquirir sobre el sistema. Este modelo se deberá definir mediante una notación formal y comprensible que evite la ambigüedad del lenguaje.

Figura 3 Inconsistencia en el modelo mental

El modelo conceptual debe suministrar información al usuario acerca de qué hace el sistema y los mecanismos para llevarlo a cabo. Su importancia radica en que debe favorecer el aprendizaje del sistema, es una guía para predecir el comportamiento del sistema, y además, el usuario utilizará este modelo para establecer estrategias encaminada a resolver sus problemas. Los principios en los que debe estar basado el modelo conceptual serán por tanto que sea asimilable (mediante el uso de conceptos familiares), consistente (coherente y bien formulado) y simple (uso de descripciones comprensibles por un usuario medio).

Figura 4 Modelo conceptual (con notación formal)

Para poder realizar el modelo conceptual de un sistema, deberemos conocer y aplicar modelos teóricos cognitivos que están fundamentados en el mecanismo de razonamiento humano. Los más relevantes son:

Modelo de procesador humano

Card y Moran [CAR83] presentan este modelo en el que se expone la forma de percibir, procesar y manipular la información. Este modelo identifica diferentes procesadores y sistemas de memoria, donde cada uno de ellos tiene asignado parámetros cuantitativos importantes como ciclos de tiempo o capacidades. El modelo del procesador humano está compuesto de tres sistemas: el sistema perceptual, que maneja los estímulos sensoriales externos, el sistema motor, que controla las acciones y por último, el sistema cognitivo, que suministra el conocimiento suficiente para conectar ambos.

Modelo de desarrollo de tareas

Norman, en 1986, propone un modelo de desarrollo de tareas que identifica siete etapas de ejecución y evaluación de acciones de usuario. El modelo representa las etapas de actividad mental que implica que el usuario alcance un objetivo y que son:

• 1) establecer el objetivo que se quiere alcanzar,

• 2) formalizar la intención para la acción que alcanzará el objetivo,

• 3) especificar la secuencia de acción correspondiente a la intención,

• 4) ejecutar la acción,

• 5) percibir el estado del sistema,

• 6) interpretar el estado, y por último

• 7) evaluar la interpretación del estado con respecto al objetivo inicial.

Este modelo proporciona una base para representar y entender las consecuencias cognitivas de diseños particulares.

Modelo objeto–acción sintáctico–semántico (SSOA)

Este modelo descrito originalmente por Shneiderman en 1980 [SHN92], propone que los usuarios poseen un conocimiento sintáctico y semántico del dominio del problema y de los mecanismos de interacción. En este conocimiento se almacenan detalles de los dispositivos (tipos, modo de uso), conocimientos semánticos sobre las actividades y conceptos del ordenador. Este conocimiento se estructura mediante una colección de objetos que componen el sistema (cursor, icono, ventana..) y de las acciones que se pueden llevar a cabo sobre cada uno de esos objetos (mover, cambiar, redimensionar, etc.).

Estructura del modelo conceptual

El modelo conceptual es muy importante, ya que permiten identificar, organizar y realizar razonamientos sobre los componentes y comportamiento de un sistema interactivo, será la guía para el proceso de diseño del software y puede usarse posteriormente como una referencia para evaluar un diseño particular, razonar sobre la solución realizada y el posible espacio de soluciones existente. Por tanto, la correcta especificación del modelo conceptual será crucial en toda la etapa del proceso de diseño. Algunas de estas notaciones del modelo conceptual están basadas en métodos formales (con un fundamento basado en lógica matemática), lo que permitirá una descripción precisa y sin ambigüedad.

Partiendo de las teorías cognitivas presentadas anteriormente, se podría realizar la descripción conceptual del sistema mediante uno de estos modelos:

• Modelo de caja negra: El usuario no tiene idea del funcionamiento interno, y simplemente conoce que ciertas entradas producen una serie de resultados. Este es una visión "mágica" del sistema, en la cual el usuario no tiene bases para predecir nuevos comportamientos ni causas que provocan los errores. El usuario se ve forzado a considerar los resultados verdaderos, y no sabe cómo juzgar su validez.

• Modelo funcional jerárquico: Las funciones suministradas por el sistema se agrupan en jerarquías, permitiendo reducir la complejidad del sistema mediante la aplicación de técnicas de partición en el dominio del problema (método de divide y vencerás).

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

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.

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