Esfuerzo De Ad

Esfuerzo de Usabilidad: un nuevo concepto para medir la usabilidad de un sistema interactivo basada en el Diseño Centrado en el Usuario Granollers, T.

Lorés, J.

University of Lleida GRIHO: HCI research group Avda. Jaume II, 69 +34 973 702720

University of Lleida GRIHO: HCI research group Avda. Jaume II, 69 +34 973 702720

[email protected]

[email protected]

RESUMEN La Usabilidad –término ambiguo y en ciertos aspectos subjetivo– es una característica relacionada con la calidad de los sistemas interactivos que las más prestigiosas sociedades internacionales de estándares de calidad como ISO o IEEE vienen considerando desde hace mucho tiempo. En el aspecto metodológico las propuestas de la Ingeniería de la Usabilidad que ofrecen modelos de Diseño Centrado en el Usuario, DCU, constituyen la alternativa de desarrollo mayormente aceptada, pues facilitan la incorporación de usuarios representativos a los equipos de desarrollo con la finalidad de conseguir sistemas usables. Existe sin embargo, una enorme separación entre tales modelos de DCU y las técnicas utilizadas para medir el grado de usabilidad de los sistemas software (métricas de usabilidad). Actualmente las mediciones se realizan sobre el producto finalizado sin tener en cuenta la metodología con la que se ha realizado. En este artículo se propone un nuevo método de medición que tiene un enfoque totalmente distinto a los actuales. El método que se presenta valora la usabilidad con datos obtenidos a partir del esfuerzo que el equipo de desarrollo ha realizado durante la implementación del sistema y siguiendo un modelo de proceso DCU. Con ello se consigue unir la metodología utilizada con el resultado que de ella se espera conseguir.

Keywords Usabilidad, Ingeniería de la Usabilidad, Diseño Centrado en el Usuario, Métricas de Usabilidad.

1. Introducción El término usabilidad, que coloquialmente suele asociarse a la propiedad que tiene un determinado sistema interactivo para que

Se concede el permiso para la reproducción digital o impreso total o parcial de este trabajo sin contraprestación económica únicamente para la utilización personal o en clase. En ningún caso se podrán hacer o distribuir copias para su explotación comercial. Todas las copias deben de llevar esta nota y la información completa de la primera página. Para cualquier otro uso, publicación, publicación en servidores, o listas de distribución de esta información necesitara de un permiso específico y/o el pago correspondiente. Interacción '04 – 3-7 Mayo, 2004, Lleida, España.

sea “fácil de utilizar y de aprender”, es definido por la Organización Internacional para la Estandarización en la norma ISO 9241-11 como “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” [16]. En la misma línea la norma ISO/IEC 9126-1 destaca la importancia de la usabilidad como un parámetro de calidad del software al incluirla entre las seis características de primer orden para el modelo de calidad externa e interna del software [18]. Funcionalidad, fiabilidad, eficiencia, mantenibilidad y portabilidad son las otras cinco. No obstante, como desarrollar un sistema interactivo altamente usable no es una tarea evidente ni fácil de conseguir, los equipos de desarrollo disponen de metodologías (del ámbito de la Ingeniería de la Usabilidad [10] basadas en las aproximaciones de Diseño Centrado en los Usuarios, DCU, [17], de Diseño Participativo [8] o de Diseño Contextual [5]) como las descritas en [6][9][21][25] o [28] que detallan procesos y técnicas que les guiarán a implementar sistemas usables. Además J. Nielsen, uno de los autores más destacados en el terreno de la usabilidad de los sistemas interactivos, asegura en un reciente estudio sobre el incremento de la usabilidad (AlertBox de marzo 2003) [23] que no existe la interfaz de usuario perfecta y, por tanto, el trabajo relacionado con su usabilidad nunca será completo. Argumenta que cualquier diseño siempre puede mejorarse y aunque llegásemos a disponer de una interfaz que cumpliese el 100% de las recomendaciones de alguna lista de guías de estilo (como las del propio autor) nunca alcanzaríamos la interfaz perfecta, pues, seguro que encontraríamos nuevas recomendaciones a añadir a dicha lista que ayudasen a mejorar la experiencia del usuario. Aun así, una vez disponemos de un nuevo sistema no nos conformaremos con decir que este es muy, poco o nada usable; desearemos conocer algún tipo de medida numérica que refleje cuantitativamente el nivel de usabilidad del sistema implementado. No obstante la usabilidad es en sí misma un atributo altamente subjetivo, relativo y, como consecuencia, es tan difícilmente medible que aventurarse a cuantificarla supone un reto verdaderamente difícil e interesante.

En el resto del artículo veremos como se aborda actualmente la problemática de medir la usabilidad para presentar nuestra alternativa desde un punto de vista totalmente diferente a los existentes.

ƒ

Este cuestionario surge como extensión de SUMI al intentar orientarlo hacia la medición de la usabilidad en la Web. WAMMI es un cuestionario basado en escenarios que trata de descubrir información acerca de lo que piensan los visitantes de los sitios Web en cuanto a su calidad de uso. Igual que el anterior está disponible en varios idiomas y es un cuestionario de pago.

2. Medición actual de la usabilidad Desde hace varios años existen diversas alternativas que permiten medir el atributo usabilidad de los sistemas software las cuales, básicamente, se engloban en dos categorías diferenciadas por el tipo de procedimiento utilizado: mientras unas utilizan únicamente cuestionarios orientados a conocer el nivel de satisfacción de los usuarios respecto a su experiencia con el uso sistema del cual queremos conocer su grado de usabilidad, otras utilizan herramientas software especializadas que facilitan una medición más precisa y automatizada.

ƒ

Los cuestionarios más relevantes en este ámbito son: ƒ

QUIS (Questionnaire for User Interface Satisfaction) [27][7][29]:

La principal ventaja de utilizar cuestionarios es que se consigue recoger respuestas concretas que aportan datos discretos comprobables mediante, por ejemplo, técnicas estadísticas.

2.2 Herramientas El terreno de las herramientas software desarrolladas específicamente para medir la usabilidad de los sistemas interactivos destacan: ƒ

Es una técnica de valoración subjetiva enfocada a medir el grado de satisfacción de los usuarios mientras interactúan con la interfaz. El cuestionario fue desarrollado a finales de los años 80 pero está sujeto a una constante renovación para adaptarlo a los tiempos actuales tan cambiantes. El cuestionario, orientado por los aspectos de la interfaz del usuario, consta de 5 secciones, la primera de las cuales valora las reacciones del usuario mientras utiliza el sistema. Las secciones restantes valoran la pantalla, la terminología, y el sistema de información, de aprendizaje y las capacidades del sistema. ƒ

1

MUSiC, Metrics for Usability Standard in Computing, es un proyecto europeo cuyo principal objetivo era desarrollar métodos para medir el rendimiento a partir de la medición de la calidad de uso y con ello dar soporte a los métodos de la Ingeniería de la Usabilidad [4][20].

PROKUS (PROgram system zur Kommunikations ergonomischen UnterSuchung rechnerunterstützer Verfahren –Program system to communication ergonomic examination of computer-aided procedures–) [32]: PROKUS es un software desarrollado por el Laboratorio del Instituto de Ingeniería Humana e Industrial de la Universidad de Karlsruhe (Alemania) que mide la usabilidad de un sistema basándose en la ergonomía cómo criterio de calidad principal. Concretamente se basa en el estándar ISO 9241-10 que especifica los principios de diálogo de los terminales visuales en términos ergonómicos. A pesar de que no se trata de un cuestionario una parte importante del método también está basado en un catálogo de preguntas que son rellenadas por el experto evaluador durante el procedimiento.

SUMI (Software Usability Measurement Inventory) [30][4]: Más que un simple cuestionario SUMI es un inventario de medidas de usabilidad que forma parte del proyecto global MUSiC1 [19]. El espíritu de este cuestionario es valorar la calidad de uso de un sistema o de un prototipo. Este cuestionario está referenciado en estándares de calidad ISO como el ISO 9241-10 (principios de dialogo) y en el ISO 6126-2 (métricas y características de la calidad del software). Se trata de un cuestionario, no gratuito, que se encuentra disponible en varios lenguajes (español entre ellos).

MUMMS (Measuring the Usability of Multi-Media Systems) [22]: MUMMS es otro cuestionario que surge también como una extensión de SUMI, concretamente trata de evaluar la usabilidad de los productos multimedia en general y es realizado por usuarios finales. Está enfocado a obtener el conocimiento adquirido por los usuarios, lo cual es consecuencia lógica de que el cuestionario esté desarrollado un grupo de investigación en Factores Humanos de la Universidad de Cork, Irlanda.

2.1 Cuestionarios La utilización de cuestionarios con preguntas especialmente diseñadas para conocer el uso que hacen los usuarios de un sistema determinado y, particularmente, cual es su grado de satisfacción es una de las técnicas que más éxitos ha logrado en el terreno de las métricas de la usabilidad. La idea es simple, se diseña un cuestionario donde es necesario contestar una serie de preguntas “tipo test” cada una de las cuales debe responderse escogiendo una opción única entre un rango de respuestas preestablecidas.

WAMMI (Web site Analysis and MeasureMent Inventory) [31]:

Finalmente los datos medidos pueden ser comparados con la definición de los requisitos del propio sistema o incluso compararlos con los requisitos de otros sistemas, por ejemplo los la competencia. ƒ

DRUM (Diagnostic Recorder for Usability Measurement) [15] Esta herramienta software que realiza el análisis de la usabilidad a partir de grabaciones en vídeo de sesiones de evaluación de la usabilidad. El programa se conecta a una videocámara y permite que el evaluador establezca una unión entre puntos interesantes de la evaluación con dicha grabación. La gran ventaja de este método está en que al tener marcados los tramos en la propia grabación permite reducir enormemente el tiempo de análisis de las sesiones de usabilidad grabadas.

Esta herramienta fue desarrollada cómo parte integrante del proyecto MUSiC [3].

2.3 Problemas de las actuales métricas de usabilidad A pesar de que los dos grupos de técnicas presentadas en el punto anterior han demostrado ser bastante eficientes evidencian los siguientes inconvenientes: 1. Las medidas que tanto cuestionarios como herramientas proporcionan se obtienen principalmente midiendo tan solo la satisfacción del usuario con el sistema2 [1], y no podemos olvidar que según la definición del estándar ISO 9241-11 [16] la satisfacción solo es uno de los parámetros que definen la usabilidad.

Concretamente la propuesta está basada en el Modelo de Proceso de la Ingeniería de la Usabilidad y de la Accesibilidad, MPIu+a [11][12] y su aplicación durante el desarrollo de un elevado número de casos experimentales. El MPIu+a (ver figura 1), que tiene sus cimientos, por una parte, en la Ingeniería del Software y, por otra, en la disciplina de la Interacción Persona-Ordenador y en la Ingeniería de la Usabilidad, proporciona las bases y la metodología que permiten conocer cómo debe proceder un equipo de desarrollo para diseñar aplicaciones interactivas usables y accesibles siguiendo enfoques de DCU claramente marcados.

2. Los cuestionarios son excelentes para medir cuantitativamente los aspectos reflejados en los mismos pero no dejan lugar para aspectos no enumerados en los mismos que pueden ser importantes desde el punto de vista de los usuarios, propiciando que estos no encuentren su mejor respuesta entre las que el test les ofrece. 3. Existe una fuerte dependencia entre los resultados obtenidos y la muestra de usuarios escogidos (cantidad, representatividad y motivación). 4. Se ha observado que los usuarios cuando contestan preguntas relacionadas con la usabilidad suelen confundir esta con la utilidad [14]. Fácilmente otorgan el sentido de usabilidad a alguna capacidad del sistema que les ha sido útil (olvidando si esta utilidad ha sido difícil de encontrar o suficientemente satisfactoria) y viceversa. Y a esta lista de inconvenientes debemos añadirle el siguiente:

Figura1. Modelo de proceso MPIu+a.

5. Aunque en la introducción se ha mencionado la conveniencia de utilizar metodologías procedentes del ámbito de la Ingeniería de la Usabilidad para desarrollar sistemas verdaderamente usables, ninguna de las métricas de la usabilidad existentes consideran para su evaluación dichas metodologías: las métricas presentadas pueden aplicarse indistintamente del procedimiento seguido. Consecuentemente, no disponemos de datos que aseguren que los resultados obtenidos desarrollando sistemas siguiendo estas metodologías sean mejores que los realizados siguiendo los procedimientos habituales de la Ingeniería del Software.

Resumidamente las principales características que definen el MPIu+a son:

Existe, por tanto, un vacío difícil de resolver que vamos a tratar de enmendar.

3. Base metodológica para una nueva propuesta para medir la usabilidad El principal objetivo del trabajo presentado en este artículo radica en explicar nuestra propuesta sobre un nuevo concepto para medir la usabilidad de un sistema interactivo a partir las actividades realizadas durante el desarrollo del mismo siguiendo un modelo DCU; enfoque radicalmente diferente a los existentes hoy en día.

2

SUMI si que tiene en cuenta otros factores como la eficacia, la ayuda, el aprendizaje, el control y el propio dispositivo.

ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ

es tecnológicamente independiente (se adecua a cualquier cambio tanto tecnológico como de paradigma de interacción), es aplicable a todo tipo de proyectos, independientemente de su clase y envergadura, se adapta a los diferentes modelos mentales de los integrantes de los equipos multidisciplinares, es muy simple, sigue los principios del Diseño Centrado en el Usuario, fomenta el desarrollo de sistemas evolutivo: iterativo e incremental, integra la metodología y los formalismos necesarios de la Ingeniería del Software con la de la Usabilidad, integra, a su vez, la accesibilidad cómo componente fundamental de todo el proceso, y es consistente con los estándares de calidad relacionados.

El modelo está organizado en una serie de fases (cada uno de los bloques de la figura 1) que repetidamente se van realizando, siendo el prototipado y la evaluación dos fases claves para la usabilidad y la accesibilidad que se aplican desde el mismo instante que comienza cada nuevo desarrollo. Además, en el modelo se utilizan algunos mecanismos de protección de la Ingeniería del Software [2] con la finalidad de garantizar la consistencia de las actividades, de asegurar el

impacto del cambio y de minimizar el riesgo de errores. Entre estos mecanismos destaca (por su relación con este artículo) una particularización de la Gestión de la Configuración, denominada en el MPIu+a Hoja de Trabajo de la Gestión de la Configuración, HT-GC, [12] en la que una tabla bidimensional refleja cronológicamente todas las actividades realizadas durante el desarrollo del sistema a la vez que permite relacionar dichas actividades entre sí. La estructura de esta HT-GC es la siguiente: ƒ

ƒ

ƒ

Existe una columna para cada fase del MPIu+a y en cada una de ellas se emplazan las actividades realizadas correspondientes a la fase del encabezado. Las columnas son: (1) Análisis de Requisitos, (2) Diseño, (3) Implementación, (4) Lanzamiento, (5) Prototipado y (6) Evaluación. El número de filas es variable: a medida que avanza cada proyecto en concreto se van disponiendo, en la columna correspondiente, todas las actividades realizadas. Ello aporta información rápida y visual sobre la secuencialidad temporal del proyecto, desde el inicio hasta su finalización. Opcionalmente, la representación gráfica puede mejorarse uniendo con flechas cada actividad con su antecesora y su predecesora.

La figura 2 muestra la HT-GC de una determinada aplicación [13] en la que podemos seguir todas las actividades del MPUu+a realizadas.

4. Nueva métrica para la usabilidad: el Esfuerzo de Usabilidad (EU) La idea de partida es bien simple: deseamos encontrar la manera de valorar (con un número comprendido entre un rango de valores como por ejemplo entre 0 y 10) el grado de su usabilidad de un sistema interactivo cualquiera. No obstante factores como la subjetividad de la propia usabilidad o de los usuarios y/o evaluadores de cada sistema, la dificultad de cuantificar numéricamente cuál es su usabilidad o relativizar dicho valor entre unos límites recondujeron el enfoque de la idea inicial para intentar valorar la dedicación o el esfuerzo realizado durante el desarrollo de una determinada aplicación en conseguir que una esta sea usable. Surge así el concepto del “Esfuerzo de Usabilidad”.

4.1 Definición El diccionario de la lengua española define esfuerzo cómo el “empleo de elementos costosos en la consecución de algún fin”. Contextualizando este enunciado a nuestro propósito definimos el término Esfuerzo de Usabilidad como la medida que indica los recursos empleados y las actividades realizadas durante el desarrollo de una aplicación interactiva con la finalidad de conseguir un determinado nivel de usabilidad. Veamos, por tanto, como procedemos para calcular dicha medida.

4.2 Obtención Somos conscientes que para cualquier desarrollo software los resultados que se obtienen nunca son directamente proporcionales al esfuerzo dedicado durante su realización: puede obtenerse, en el mejor de los casos, un resultado óptimo con un esfuerzo mínimo o por el contrario el resultado de un enorme esfuerzo puede ser catastrófico. No obstante la experiencia indica que habitualmente, y en cualquier ámbito de la vida de las personas, un mayor esfuerzo se ve recompensado con la obtención de mejores resultados. Con esta reflexión queremos remarcar que aunque las probabilidades de mayor usabilidad serán mayores para aquella aplicación con un EU elevado nunca estaremos completamente seguros de esta afirmación.

4.2.1 El EU intuitivamente Hemos visto que disponemos por una parte de una metodología de desarrollo de sistemas software basada en el DCU y por otra de un valor que pretendemos calcular a partir de la las actividades realizadas al aplicar dicha metodología; concretamente, calcularemos el valor utilizando la HT-GC anteriormente explicada.

Figura 2: HT-GC correspondiente a un determinado proyecto. Presentamos a continuación la propuesta partiendo de la idea inicial, la idea intuitiva y finalmente su resolución matemática con las conclusiones obtenidas.

No obstante antes de ver el cálculo numérico del EU observaremos algunos aspectos relacionados con la HT-GC del método que nos serán útiles para comprender el origen del estudio y el resultado esperado. El conjunto de actividades realizadas tras la finalización de un sistema dibuja una determinada zona sobre la HT-GC que intuitivamente nos revela información relacionada con la posible usabilidad del sistema. Concretamente en el ejemplo de la figura 3, a juzgar por la

empresas que desarrollan de software conocen la teoría y maquillan el resultado final de sus productos realizando una evaluación en la fase final del proyecto, tras la cual mejoran un poco la usabilidad del producto implementando aquellos cambios sugeridos por la evaluación que no afectan a la estructura interna del sistema.

elevada y uniformemente repartida cantidad de actividades de prototipado y evaluación realizadas podemos intuir que el esfuerzo realizado para conseguir la usabilidad de este sistema ha sido considerablemente elevado, siendo además muy regular desde su inicio, lo cual nos hace pensar que el sistema tendrá un alto grado de usabilidad, o cómo mínimo el valor del EU será alto.

Es más, en la mayoría de casos esta evaluación final suele ser una evaluación heurística [26], que si bien es cierto que es una de las técnicas que aportan mejores resultados, no podemos olvidar que en ella no interviene ningún usuario y, si además se realiza como procedimiento único al final del desarrollo poco podremos cambiar para mejorar la usabilidad del sistema. Cierto es que esta situación es mejor que la comentada en el caso anterior pero no deja de ser un puro maquillaje de la realidad que responde más a estrategias de marketing comercial que al beneficio real que la usabilidad aporta a la solución final. En la figura 4 (c) podemos ver el esquema correspondiente a esta situación.

(a) EU mínimo

(b) EU máximo

(c) EU maquillado

Figura 4: Visiones gráficas del Esfuerzo de Usabilidad.

Figura 3: Área determinada por las actividades realizadas durante el desarrollo del sistema interactivo. Siguiendo en esta línea en los gráficos de la figura 4 veremos cuáles serian las situaciones extremas del EU analizando tan solo el área dibujada por cada desarrollo en la HT-GC: a) Esfuerzo de usabilidad mínimo: Correspondería a aquella aplicación para la cual no se ha realizado ninguna acción meritoria para mejorar la usabilidad de la misma. La gráfica correspondiente a esta situación es la de la figura 4 (a), y desafortunadamente, es la situación más frecuente del desarrollo del software actual. Este apartado incluye todas aquellas aplicaciones cuyos autores etiquetan como “userfriendly” sin que hayan sido evaluadas por tan solo un usuario. b) Esfuerzo de usabilidad máximo: Sería el caso contrario del anterior, y evidentemente sería el caso para una situación ideal. En la figura 4 (b) se observa que la superficie tanto en la parte de prototipado y evaluación como también en el análisis de requisitos y el diseño está ocupada por actividades que responden a la aplicación sistemática, constante y repetitiva del MPIu+a. c) Esfuerzo de usabilidad “maquillado”. Actualmente el tema de la usabilidad de los sistemas interactivos está, por decirlo de alguna manera, de moda. Los responsables de muchas

Analizando de nuevo el ejemplo de las figuras 2 y 3 parece claro que el EU de la aplicación está muy cerca del máximo posible, lo cual es sinónimo de un gran esfuerzo para mejorar la usabilidad y, presumiblemente, la aplicación será fácilmente utilizable.

4.2.2 Análisis del cálculo matemático Para el cálculo matemático del valor del EU utilizamos la siguiente simplificación: buscaremos una función matemática para ponderar tan solo las actividades de la columna de la evaluación y, a partir de los resultados parciales de estas ponderaciones, obtener el EU del sistema completo. Los motivos de esta consideración son: ƒ

ƒ

A pesar de ser cierto que la base de la consecución de la usabilidad del sistema es fruto de repetidas actividades de prototipado y de evaluación realizadas durante el desarrollo, también es cierto que de poco sirve un prototipo no es evaluado. O sea, el resultado de la función de ponderación para un prototipo que no es evaluado es cero. Por otra parte, algunos métodos de evaluación no precisan de prototipos para realizarse, y para aquellos que si lo necesitan puede incluirse el “factor prototipo” en la ponderación de cada método de evaluación, con lo cual se valora también la relación que existe entre ambos.

4.2.2.1 Función de ponderación de cada método de evaluación. Cada método o técnica de evaluación de la usabilidad tiene condicionantes propios que les diferencian entre sí y,

consecuentemente, condicionan directamente el valor de su correspondiente función de peso. No obstante tras realizar un minucioso análisis de dichos condicionantes hemos encontrado un conjunto único de parámetros comunes que son suficientes para definir las características particulares de cada uno de ellos. Utilizaremos, por tanto, este conjunto de parámetros para definir el valor resultante. Este conjunto único de parámetros es el siguiente: -

-

-

-

medir exactamente lo mismo” de cada método. -

Acotación idéntica: el rango de valores posibles para un mismo parámetro es el mismo para todos los métodos (por ejemplo entre 0 y 100).

La tabla 1 muestra la asignación de valores para los diferentes parámetros (columna Resultado Función) realizada para el método de evaluación Focus Group [25]. Tabla 1. Asignación de valores para los parámetros correspondiente a una evaluación del tipo “Focus Group”.

La fase del MPIu+a en la que se aplica. Las propias características de cada técnica indican que su aplicación es más apropiada en unas fases del proyecto que en otras y este parámetro refleja esta peculiaridad, el valor del cual será mayor en la o las fases más apropiadas y menor en las demás.

Nombre parámetro

El número de usuarios que intervienen en la prueba. Igual que antes, las características individuales de cada técnica definen el número óptimo de usuarios necesarios para obtener los mejores resultados. Por tanto con este parámetro se pretende valorar la optimización de los recursos humanos.

A1: Fase

A2 # usuarios

El número de implicados que participan de la evaluación. Los implicados en un sistema interactivo [20] tienen un papel vital en algunas de las evaluaciones, importancia que es reflejada por este parámetro.

A3: #implicados

El número de evaluadores que realizan la prueba. Como pasa con los usuarios, el resultado de cada método está directamente relacionado con el número de evaluadores que han intervenido. No por poner más evaluadores obtenemos mejores resultados, sino que cada método tiene su óptimo y este parámetro refleja este factor.

A4: #evaluadores C: completitud

F(Focus Group) Valor Resultado parámetro Función R 80 D 80 I 80 L 100 1a5 80 6a9 100 >9 80 1a3 40 4a6 65 7 a 10 70 > 10 70 1a3 40 4a6 65 7 a 10 70 > 10 70 % Papel 75 StoryBoard 50 Maqueta 75 Escenario 75 Vídeo 100 S/W horiz. 100 S/W vert. 100 S/W 100

-

El prototipo utilizado. Considerando que una misma prueba de evaluación consigue obtener mejores o peores resultados en función del prototipo utilizado, o incluso que alguna no requiere de prototipo alguno, con este parámetro se pretende reflejar la adecuación del prototipo utilizado.

-

La completitud es un parámetro porcentual que pondera la cantidad de las características interactivas (relacionadas con la usabilidad de la parte del sistema evaluado) que se han probado. El sentido de este parámetro es distinto a los anteriores pues con él se pretende medir si se han comprobado todos los objetivos determinados o solo una parte de los mismos. Este mismo parámetro refleja, para aquellos casos que precisan de prototipo, si éste implementa todos los requisitos determinados que son necesarios para la evaluación o solo los implementa parcialmente.

Una vez asignados los valores de los parámetros para todos los métodos de evaluación de la usabilidad disponemos de información suficiente para calcular el peso para cada una de las actividades de la columna evaluación de la HT-GC. Para ponderar el EU de cada actividad de evaluación hemos escogido la siguiente función real que toma valores sobre el espacio de parámetros:

Una vez determinados los parámetros es necesario asignarles valores concretos para caracterizar los distintos métodos de evaluación de manera que los resultados sean comparables. Con tal propósito la asignación de valores en cada método de evaluación se ha otorgado a partir de la propia experiencia y siguiendo los siguientes principios:

donde, j es la evaluación que se está ponderando, mj es cada una de las subevaluaciones que pueden componer una misma evaluación3, Ck es el parámetro completitud para la subevaluación k-ésima y Ai,k es el parámetro i de la subevaluación k.

A5: Prototipo

fj =

1 mj

n ⎛ mj ⎞ ⎜ ∑ Ck ·∑ Ai ,k ⎟ ⎜ k =1 ⎟ i =1 ⎝ ⎠

4.2.2.2 Cálculo del EU del sistema desarrollado.

-

Uniformidad y coherencia: cada parámetro, para ser válido para todos los métodos, debe ponderarse siguiendo exactamente los mismos criterios.

Con la fórmula anterior seremos capaces de calcular los valores de todas las evaluaciones reflejadas en la HT-GC. Ahora tan solo nos queda sumar estos valores parciales para obtener el Esfuerzo de Usabilidad de la aplicación de la siguiente forma:

-

Equitatividad: el valor de cada parámetro será asignado de manera totalmente imparcial. El mismo parámetro “debe

3

Normalmente mj es 1 y la fórmula se reduce considerablemente

son equivalentes aunque la complejidad de ambos proyectos es muy distinta.

N

EU = ∑ f j j =1

-

Los proyectos con un ratio bajo corresponden a los que tienen más horas de codificación, o sea, mayor complejidad. Lo cual es debido a que no existe una relación directamente proporcional entre la complejidad del proyecto y el EU invertido en el mismo. Consecuentemente es en estos proyectos en los que la repercusión de la inversión realizada en el esfuerzo es menor.

-

El parámetro de la completitud es altamente determinante pues si no se aplica correctamente puede distorsionar mucho los resultados obtenidos.

-

Como resultado de todo el estudio realizado hemos podido determinar un número mínimo de iteraciones en el modelo de proceso con actividades perfectamente definidas que definen un EU mínimo. Éste, aunque no garantiza la usabilidad total del sistema, permite afirmar que si no se llega a este valor la usabilidad del sistema queda de la mano de la particular inspiración del equipo de desarrollo y no es fruto de la aplicación de un proceso metodológico de ingeniería.

donde, fj son las funciones de ponderación de cada evaluación j, N es el número total de evaluaciones y, evidentemente, EU es el Esfuerzo de Usabilidad total.

4.2.2.3 Significado. Llegados a este punto se abre un interesante debate. Disponemos de una manera sistemática y precisa que permite cuantificar uniformemente el esfuerzo realizado para procurar que el sistema disponga de la dosis de usabilidad lo más elevada posible. Este cálculo, que como hemos visto se obtiene de valorar una forma de proceder altamente recomendada como es el DCU, supone la primera aproximación conocida de valorar la usabilidad de un sistema a partir de ligar el procedimiento con el resultado. Conceptualmente estaremos de acuerdo en que el valor del EU de un determinado proyecto no es más que un número indicativo de un cierto esfuerzo para la consecución de un determinado objetivo; en nuestro caso la usabilidad. De todas formas se ha aplicado el concepto un gran número de desarrollos reales de características muy diversas (desarrollados todos ellos siguiendo el MPIu+a) con la intención de obtener datos empíricos procedentes de la experimentación que permitan extraer conclusiones sobre la verdadera utilidad de este nuevo planteamiento.

Este EU mínimo es un valor comprendido en el rango [1200, 1600] aunque los valores comprendidos entre [2200, 2500] son los que mejor recogen la experiencia del usuario y contribuyen a optimizar la usabilidad del sistema. -

Los datos de la tabla revelan que el EU de algunos proyectos es muy alto mientras que su coste sin usabilidad es muy bajo. Ello puede hacer pensar que para este tipo de proyectos no compensa invertir ni tan solo el EU mínimo. No obstante los estudios relacionados con el Retorno en la Inversión [24] demuestran que la inversión en usabilidad siempre está justificada y recompensada.

-

Contrariamente a lo que podíamos esperar, tomar el EU como parámetro para comparar dos proyectos distintos aporta muy poca información. Únicamente podremos indicar que el equipo de desarrollo ha puesto más o menos énfasis en intentar conseguir la usabilidad de un sistema respecto al otro.

-

El valor del EU no es equivalente al dinero invertido en la usabilidad del sistema. Esto es debido a que la metodología seguida para conseguir este valor puntúa la realización de las actividades y no el precio que cuesta realizarlas. Lo importante son las actividades bien realizadas, pues su coste económico puede variar mucho en función de parámetros como la aptitud del evaluador, su experiencia o su “caché” personal.

La tabla 2 refleja el EU junto a otros datos adicionales correspondientes a nueve de los casos estudiados más relevantes. Los parámetros adicionales considerados han sido los costes económicos del proyecto (con las actividades de usabilidad y sin ellas) y la relación o ratio entre este coste y el EU. Tabla 2. Esfuerzo de Usabilidad y otros valores comparativos calculados en varios proyectos de sistemas implementados. EU

Coste CON usabilidad SIN usabilidad* (CU) (SU)

Ratio (EU/CU)

P1 1.320 5.220 € 660 € 0,253 P2 2.194 20.540 € 17.440 € 0,107 P3 1.460 15.460 € 240 € 0,094 P4 1.800 14.700 € 13.440 € 0,122 P5 3.453 17.980 € 12.380 € 0,192 P6 2.600 34.360 € 33.860 € 0,076 P7 2.600 17.880 € 14.140 € 0,145 P8 2.491 23.640 € 15.860 € 0,105 P9 2.595 26.020 € 17.800 € 0,100 * El coste “sin usabilidad” se ha estimado eliminando aquellas actividades que no se hubiesen realizado si se hubiese seguido un modelo de la Ingeniería del Software y añadiendo un porcentaje a las horas de codificación extraído de estudios como los que aparecen en [24].

Siendo las siguientes las principales conclusiones extraídas del trabajo experimental resumido en la tabla anterior: -

El EU es tan solo un valor indicativo de la realización de una serie de actividades orientadas a la consecución de la usabilidad que, si no se compara con el ratio puede conducir a conclusiones erróneas. Por ejemplo los proyectos P6 y P7 tienen el mismo EU mientras que el ratio de P6 es la mitad que el de P7, lo cual es debido a que las actividades de evaluación

5. Conclusiones Partiendo de la propia definición del concepto usabilidad de un sistema interactivo, de sus principales características y del estado del arte actual sobre las técnicas que actualmente prevalecen en el campo de las métricas de la usabilidad de los sistemas software, en el artículo se presenta una idea novedosa en este ámbito que propone cuantificar del esfuerzo que el equipo de desarrollo realiza durante la implementación de un determinado sistema interactivo con la intención de obtener información acerca del grado de usabilidad del mismo. Esta cuantificación, denominada Esfuerzo de usabilidad (EU), se

plantea desde la óptica de la disciplina Interacción PersonaOrdenador y utilizando una metodología concreta de Diseño de sistemas interactivos Centrado en el Usuario.

[15] Hammontree, M.; Hendrickson, J. J.; Hensley, B. W. (1992). Integrated data capture and analysis tools for research and testing on graphical user interfaces. CHI’92, ACM Press, pág. 431-432.

En el artículo se explica y se razona el proceso seguido para llegar a la formulación que permite calcular el EU de un determinado proyecto software.

[16] International Standard (1998) ISO 9241-11:1998. Ergonomic

Finalmente se exponen las conclusiones obtenidas tras realizar un extenso trabajo experimental donde se aplica el concepto especificado a un número considerable de casos reales desarrollados siguiendo la metodología mencionada.

[17] International Standard (1999). ISO 13407. Human-centred

6. REFERENCIAS [1] Alva, M.E.; Martinez, A.B.; Cueva, J.M. (2003). Usabilidad: Medición a través de métodos y Herramientas. Interacción 2003, Vigo. AIPO.

[2] Babich, W. (1986). Software Configuration Management. Addison-Wesley.

[3] Bevan, N.; Macleod, M. (1994). Usability measurement in context. National Physical Laboratory, Teddington, Middlesex, UK. Behaviour and Information Technology, 13, 132-145.

[4] Bevan, N. (1995). Measuring Usability as Quality of Use. Software Quality Journal, 4, 115-150.

[5] Beyer, H.; Holtzblatt, K. (1998). Contextual Design. Defining Customer-Centered Systems. Morgan Kaufmann.

[6] Brink, T.; Gergle, D.; Wood, S.D. (2002). Design web sites that work: Usability for the Web. Morgan-Kaufmann.

[7] Chin, J.P.; Diehl, V.A.; Norman, K. (1987). Development of an instrument measuring user satisfaction of the humancomputer interface. Proc. ACM CHI '88, pp. 213-218.

[8] Gaffney, G. (1999). Usability Techniques series: Participatory design workshops. Information & Design.

[9] Gerrit, C. van der Veer; Lenting, B.F.; Bergevoet, B.A.J. (1996). GTA:Groupware Task Analysis - Modeling Complexit.y Acta Psychologica. 91, pp. 297-322.

[10] Good, M.; Spine, T.M.; Whiteside, J.; George, P. (1986). User-derived impact analysis as a tool for usability engineering. Proceedings of Human Factors in Computing Systems. CHI’86. NY: ACM

[11] Granollers, T. (2003). User Centred Design Process Model. Integration of Usability Engineering and Software Engineering. Proceedings of INTERACT 2003 (Doctoral Consortium), Zurich (Suiza).

[12] Granollers, T.; Lorés, J. Perdrix F. (2003). Usability Engineering Process Model. Integration with Software Engineering. Proceedings of HCI Intl. 2003. Crete (Greece).

[13] Granollers, T.; Lorés, J.; Solà, J., Rubió, X. (2003). Developing a Ubiquitous reception-hall using the UserCentred design Usability Engineering Process Model. Proceedings of HCI International 2003. Crete (Greece).

[14] Grudin, J. (1991). Interactive systems: Bridging the gaps between developers and users. Computer, vol. 24 n.4, 59-69.

requirements for office work with visual display terminals (VDTs) -- Part 11: Guidance on usability. design processes for interactive systems.

[18] International Standard (2001). ISO/IEC 9126-1. Software engineering —Product quality— Part 1: Quality model.

[19] Kirakowski, J.; Porteous, M.; Corbett, M. (1992). How to use the software usability measurement inventory: the user’s view of software quality. Proceedings of European Conference on Software Quality, November 1992, Madrid.

[20] Macleod, M. (1994). Usability in Context: Improving Quality of Use. Proceedings of the International Ergonomics Association 4th International Symposium on Human Factors in Organizational Design and Management, Stockholm.

[21] Mayhew, D.J. (1999). The Usability Engineering Lifecycle: A practitioner’r Handbook for User Interface Design. Morgan Kaufman.

[22] MUMMS: Measuring the Usability of Multi-Media Systems, web page at: http://www.ucc.ie/hfrg/questionnaires/mumms/index.html.

[23] Nielsen J. (2003). PR on Websites: Increasing Usability. March, 2003 Jakob Nielsen's Alertbox. Disponible en: http://www.useit.com/alertbox/20030310.html.

[24] Nielsen, J.; Gilutz, S. (2003) Usability Return on Investment. Nielsen Norman Group Report.

[25] Nielsen, J. (1993). Usability Engineering. Academic Press Professional, Boston, MA

[26] Nielsen, J.; Mack, R.L. (1994). Usability Inspection Methods. John Wiley & Sons, New York, NY.

[27] QUIS: Questionnaire for User Interface Satisfaction. Human Computer Interaction Lab, University of Maryland. Disponible en: http://www.lap.umd.edu/QUIS/index.html.

[28] Rosson, M.B.; Carroll, J.M. (2002). Usability Engineering: scenario-based developement of HCI. Morgan Kaufmann.

[29] Shneiderman, B. (1992). Designing the user interface: Strategies for effective human-computer interaction. 2nd edn, Reading, MA: Addison-Wesley.

[30] SUMI: Software Usability Measurement Inventory, web page at: http://www.ucc.ie/hfrg/questionnaires/sumi/index.html.

[31] WAMMI: Web site Analysis and MeasureMent Inventory, web page at: http://www.wammi.com.

[32] Zülch, G.; Stowasser, S. (2000). Usability Evaluation of User Interfaces with the Computer-aided Evluation Tool PROKUS. MMI-Interaktiv, Nr. 3, Juni/00, ISSN 1439-7854