MODELO DE USABILIDAD WEB ALINEADO CON SQUARE PARA PROCESOS

DE DESARROLLO DIRIGIDO POR MODELOS

Adrián Fernández Emilio Insfran Silvia Abrahão

1. INTRODUCCION

La usabilidad es un factor crucial en el desarrollo de aplicaciones Web debido a que la facilidad o dificultad que los usuarios experimentan con este tipo de sistemas determinará su éxito o su fracaso. En la actualidad, las aplicaciones Web se han convertido en un elemento esencial de toda actividad empresarial y de intercambio de información, y es por ello que surge la necesidad de emplear métodos de evaluación de usabilidad elaborados específicamente para la Web y tecnologías robustas que soporten dicha evaluación en el proceso de desarrollo.

Como bien afirma Nielsen (2000): “Es tan fácil ir a cualquier otra parte, que la competencia de todo el mundo está a tan sólo un click”, es decir, la usabilidad no es una opción, puesto que la empresa que no la considere como es debido verá cómo pierde su poder competitivo ipso facto. Esta necesidad ha motivado la aparición de una gran variedad de técnicas, métodos y herramientas para hacer frente a la usabilidad Web. Sin embargo, la mayoría de estos esfuerzos se centran en las fases de implementación e implantación de estas aplicaciones (Lopes y Carriço, 2008; Moraga et al., 2007; Olsina y Rossi, 2002). Para garantizar la usabilidad Web, las evaluaciones deben iniciarse en las

primeras fases del proceso de desarrollo y producirse repetidamente a lo largo del ciclo de vida, no sólo cuando el producto se ha finalizado.

Desde los comienzos de la ingeniería del software, se observó que la calidad está compuesta por un conjunto de muchas características, y precisamente, una de ellas es la usabilidad. Los modelos de calidad surgen para describir dichas características, sus relaciones, cómo pueden ser medidas y cómo las mediciones pueden ser interpretadas. Existe una gran variedad de modelos de calidad, sin embargo, la gran mayoría de las propuestas están dirigidas a productos software genéricos y a la evaluación sobre el producto final (Abran et al., 2003; Dromey, 1998; McCall et al., 1977; Nielsen, 1993; Van Welie et al., 1999), pocas de ellas se orientan al contexto de la Web (Calero et al., 2005; Lopes y Carriço, 2008; Moraga et al., 2007; Olsina y Rossi, 2002; Seffah et al., 2006) y menos aún, a arquitecturas dirigidas por modelos donde se deberían considerar artefactos intermedios del proceso de desarrollo para permitir una evaluación temprana (Abrahão e Insfran, 2006).

En este capítulo presentamos un Modelo de Usabilidad Web alineado con el estándar ISO/IEC 25000 SQuaRE (2005) para la mejora y evaluación de la usabilidad en procesos de desarrollo Web dirigido por modelos. Para su uso, este modelo debe ser operacionalizado en un método de desarrollo Web concreto (OO-H (Gómez et al., 2001), WebML (Ceri et al., 2000), UWE (Kraus et al., 2006),…). Dicha operacionalización consiste en relacionar los atributos y métricas del modelo de usabilidad con los distintos modelos y primitivas del método de desarrollo Web. Para ilustrar este proceso, presentamos un caso práctico donde el modelo de usabilidad ha sido aplicado en la evaluación de los modelos producidos durante el proceso de desarrollo de un portal Web.

Este capítulo está estructurado de la siguiente forma: la sección 2 recopila algunos de los modelos de calidad tradicionales que se han desarrollado en los últimos años, prestando especial interés a aquellos más orientados a productos Web. La sección 3 introduce brevemente las principales aportaciones a la evaluación de la calidad presentes en el estándar ISO/IEC 25000 (2005), también conocido como SQuaRE (Software Product Quality Requeriments and Evaluation), perteneciente a la segunda generación de estándares de calidad de un producto software. La sección 4 describe un Modelo de Usabilidad Web alineado con SQuaRE presentando sus características, subcaracterísticas, atributos y métricas. La sección 5 presenta la operacionalización del Modelo de Usabilidad Web en el método OO-H (Gómez et al., 2001) incluyendo un caso de estudio donde se ha aplicado el Modelo de Usabilidad propuesto en la evaluación de un portal Web a nivel de modelos e interfaz de usuario final. Finalmente, la sección 6 presenta las conclusiones y los trabajos futuros.

2. TRABAJOS RELACIONADOS

A lo largo de estos últimos años han ido surgiendo modelos de calidad que incluyen la usabilidad entre sus características. Estos modelos se pueden clasificar en dos

categorías: aquellos que han sido definidos siguiendo una estructura propuesta por el mismo autor, o bien, aquellos definidos en base a estándares existentes, tales como la ISO/IEC 9241-11 (1998) o la ISO/IEC 9126-1 (2001). La norma ISO 9241-11 (1998) explica cómo la usabilidad se puede especificar en términos de eficiencia, efectividad y satisfacción del usuario. La ISO/IEC 9126-1 (2001) proporciona un modelo de calidad del producto software donde la usabilidad es una de las características de primer nivel, y ésta a su vez es descompuesta en cinco subcaracterísticas: facilidad de entendimiento, facilidad de aprendizaje, operabilidad, grado de atracción y conformidad. Además, define el concepto “calidad en uso” como la capacidad del producto software para permitir a los usuarios alcanzar sus objetivos específicos con efectividad, productividad, satisfacción y seguridad. Estas subcaracterísticas serían las que estarían más cercanas a la ISO/IEC 9241-11 (1998). Estos modelos pueden resultar útiles principalmente como guías y recomendaciones, debido a que son muy genéricos, y es por ello que deben ampliarse y/o descomponerse en atributos medibles para su utilización en diferentes tipos de productos software.

Existe una gran variedad de modelos de calidad propuestos que contemplan la usabilidad como una de sus características, pero cada uno suele descomponerla en distintas subcaracterísticas. Entre los modelos de calidad definidos desde cero encontramos trabajos como los de McCall (1977), Nielsen (1993) y Dromey (1998). Uno de los primeros modelos de calidad existentes fue el de McCall (1977) donde los atributos claves de un producto final desde el punto de vista del usuario son los denominados factores de calidad. Estos factores fueron clasificados en tres grupos principales: revisión del producto (mantenibilidad, flexibilidad,…), transición del producto (portabilidad, interoperabilidad,…) y operación del producto (usabilidad, eficiencia,…).

Nielsen (1993) propone un modelo bastante detallado centrado en los conceptos de aceptabilidad social y aceptabilidad práctica. En él se define la usabilidad como una subcaracterística del concepto “utilidad”, que es a su vez, una subcaracterística de la aceptabilidad práctica. Mantiene que la usabilidad puede ser descompuesta en los siguientes atributos: facilidad de aprendizaje, eficiencia de uso, facilidad para recordar, errores mínimos, y atracción subjetiva.

Dromey (1998) plantea un modelo de calidad basado en comportamientos y usos. Donde un comportamiento es algo que exhibe el propio software en un determinado contexto (por ejemplo, la usabilidad), y los usos son las acciones de los usuarios con el software. Este modelo enumera atributos de calidad específicos y los clasifica asociándolos a determinadas características propias del software.

Las normas ISO existentes han contribuido como base a otros modelos de calidad como los de Van Welie (1999), Abran (2003) y, Franch y Carvallo (2003). Van Welie (1999) propone un modelo estructurado en tres capas. En la capa superior encontramos los tres atributos que pertenecen a la ISO/IEC 9241-11 (1998): eficiencia, efectividad y

satisfacción. La segunda capa contiene un conjunto de indicadores de uso de la usabilidad que se puede observar en la práctica, cuando los usuarios interactúan con el sistema (facilidad de aprendizaje, errores de seguridad, satisfacción, rendimiento y facilidad para recordar). Por último, la capa inferior contiene los mecanismos, los cuales no se pueden observar en las pruebas de usuario, pero que pueden ser utilizados en heurísticas para mejorar los indicadores de uso.

Abran (2003) toma como base de su modelo la norma ISO/IEC 9241-11 (1998), pero la integra con otras características, como por ejemplo aprendizaje y seguridad, provenientes de la ISO/IEC 9126-1 (2001). Su modelo posee una estructura jerárquica, compuesta por características, que se descomponen en subcaracterísticas, y que a su vez, se descomponen en atributos medibles.

Franch y Carvallo (2003) presentan un modelo de calidad orientado a productos software empaquetados (ERPs, bibliotecas de estructuras de datos, etc.). El modelo está basado en las características presentes en la norma ISO/IEC 9126-1 (2001): funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad. Estas características se descomponen en subcaracterísticas que toman como referencia la misma norma ISO/IEC 9126-1 (2001) pero se incorporan modificaciones (tales como añadir nuevas subcaracterísticas, refinar existentes, etc.) para adaptarlas según qué tipo de software empaquetado sea. Cada subcaracterística se descompone en atributos, definiendo las relaciones existentes entre ellos mismos y asociándoles métricas capaces de cuantificarlos.

Los modelos discutidos hasta el momento tienen como objetivo evaluar la calidad de un producto software genérico. Si bien es cierto que un producto Web es una concreción de un producto software, es interesante conocer qué modelos de calidad (o de usabilidad si sólo se centran en esta característica) han sido definidos específicamente para la Web. En torno a la Web, los modelos también pueden ser definidos siguiendo una estructura propuesta por el mismo autor, o pueden ser extensiones a estándares de calidad existentes. En la primera categoría, se encuentra el modelo propuesto por Lopes y Carriço (2008) donde se definen un conjunto de métricas universales aplicadas a diferentes segmentos de un sitio Web. El objetivo del modelo es determinar la usabilidad universal, aquella que contempla un amplio espectro de usuarios, sobre una aplicación Web final.

Con respecto a los modelos de calidad para la Web definidos en base a estándares, existen diversas propuestas como las de Olsina y Rossi (2002), Calero et al. (2005), Seffah et al. (2006) y Moraga et al. (2007). Olsina y Rossi (2002) presentan la metodología WebQEM cuyo objetivo es elaborar modelos de calidad específicos para las aplicaciones Web y evaluarlos posteriormente. Utiliza, como base, requisitos de calidad extraídos de normas como la ISO/IEC 9126-1 (2001) (usabilidad, funcionalidad, fiabilidad y eficiencia) incorporando necesidades extra de los usuarios. Además, se desarrolló la herramienta WebQEM para dar soporte a esta metodología poniéndola en práctica en la evaluación de una aplicación Web para la venta de libros.

Calero et al. (2005) presenta un modelo de calidad específico para la Web denominado Web Quality Model (WQM). Este modelo está definido en tres dimensiones: características de la Web (contenido, presentación y navegación), características de calidad basadas en la ISO/IEC 9126-1 (2001) (funcionalidad, fiabilidad, usabilidad, eficiencia, portabilidad y mantenibilidad) y los procesos del ciclo de vida de un sitio Web basándose en la ISO/IEC 12207 (1995) (desarrollo, operación, mantenimiento) incorporando además procesos que tienen que ver con la empresa que lleva a cabo el proyecto (gestión de proyecto y gestión de la reutilización). WQM incorpora un total de 326 métricas, específicas para productos Web, que han sido clasificadas en base a esas tres dimensiones. Un aspecto muy interesante de este trabajo es la valiosa información que aporta sobre qué métricas Web han sido validadas teorética y/o empíricamente, y cuáles de ellas se prestan mejor a automatizar su cálculo.

Seffah et al. (2006) propone un modelo de usabilidad consolidado denominado QUIM (Quality in Use Integrated Measurement) aplicable a diferentes tipos de interfaces, entre ellas las pertenecientes a un sitio Web. QUIM define un primer nivel incluyendo 10 subcaracterísticas que definen la usabilidad (eficiencia, efectividad, productividad, satisfacción, aprendizaje, seguridad, confianza, accesibilidad, universalidad y utilidad). En el segundo nivel, las subcaracterísticas se descomponen en 26 atributos o criterios medibles (controlabilidad, privacidad, familiaridad, etc.), pero éstos no son el resultado de ir descomponiendo una única subcaracterística en varios atributos, si no que un mismo atributo forma parte de la definición de varias subcaracterísticas del nivel superior. En el tercer nivel encontramos 127 métricas de usabilidad asociadas a los atributos. Una de las principales ventajas de este modelo es contar con una herramienta de gestión llamada QUIM Editor que permite la edición del modelo para posibles mejoras, acceder a un repositorio con todas las métricas de usabilidad categorizadas y proveer información sobre cómo aplicar esas métricas para evaluar productos software.

Moraga et al. (2007) presenta, al igual que en el trabajo anterior, un modelo exclusivo para la usabilidad pero orientado a la evaluación de los portlets que componen un portal Web. Los portlets son componentes modulares, pertenecientes a la interfaz de usuario, gestionadas y visualizadas en un portal Web. El modelo se basa en la ISO/IEC 9126-1 (2001) y en sus subcaracterísticas de usabilidad: facilidad de entendimiento, facilidad de aprendizaje, conformidad; sin embargo, la operabilidad se sustituye por personalización que se adapta más al contexto de los portlets. Cada una de estas subcaracterísticas se descompone en atributos a los que se les asocia una medida. Sin embargo, estas medidas suelen estar basadas en un ranking de puntuaciones determinando umbrales de aceptación para cada atributo.

Tras haber realizado una revisión de las aproximaciones existentes sobre modelos de calidad hemos notado que todavía hay mucho trabajo por hacer en el área de los modelos de usabilidad para aplicaciones Web. Existe la necesidad de un modelo de usabilidad basado en las últimas revisiones de las normas ISO (ISO/IEC 25000, 20050)

que permita evaluar una aplicación Web no únicamente cuando ésta está en su fase de implementación, sino que en todas las fases de desarrollo evaluando artefactos intermedios. El mejor camino para conseguir esto es definir un Modelo de Usabilidad Web que pueda ser integrado en las distintas fases de un proceso de desarrollo dirigido por modelos (DSDM) para evaluar los modelos que guían el desarrollo de éstas aplicaciones.

En trabajos anteriores, Abrahão e Insfran (2006) han propuesto un modelo de calidad basado en la ISO/IEC 9126-1 (2001), centrado sólo en la usabilidad, siendo el único modelo integrado en las fases tempranas de un proceso de desarrollo dirigido por modelos (DSDM). Se adoptó la misma estructura jerárquica pero descomponiendo con más detalle las subcaracterísticas que definen la usabilidad (facilidad de entendimiento, facilidad de aprendizaje, operabilidad, grado de atracción y conformidad) en otras subcaracterísticas, y éstas en atributos medibles. Los atributos han sido definidos teniendo en cuenta factores ergonómicos de interfaces de usuario (Bastien y Scapin, 1993). El principal valor añadido en este modelo fue integrar la aplicabilidad del modelo de usabilidad en un entorno basado en arquitecturas dirigidas por modelos pudiendo evaluar la usabilidad en fases tempranas del proceso de desarrollo. Se definieron las relaciones que poseían los atributos del modelo de usabilidad con los elementos de los modelos independientes y específicos de plataforma con tal de asignar posibles métricas. El modelo presentado en este capítulo toma, como punto de partida, este modelo de usabilidad realizado para productos software genéricos con el fin de adaptarlo y dotarlo de métricas específicas del contexto Web, para después operacionalizarlo en un método de desarrollo Web concreto, convirtiéndolo de esta forma, en un Modelo de Usabilidad Web específico para procesos DSDM.

3. LA NORMA SQUARE

Las características en las cuales descomponemos la calidad y sus medidas asociadas pueden ser de gran utilidad no sólo para la evaluación de un producto software, sino también a la hora de definir requisitos de calidad. Esta fue la razón por la cual la ISO/IEC 9126:1991 (1991) fue reemplazada por dos normas internacionales relacionadas: ISO/IEC 9126 (2001): Calidad del producto software, y la ISO/IEC 14598 (1999): Evaluación del producto software. Aspectos como el hecho de ser complementarias, o las inconsistencias entre los ciclos de vida de ambas, han propiciado el impulso necesario para la elaboración de la norma ISO/IEC 25000 (2005) conocida como SQuaRE. La meta perseguida en la creación de esta norma es dar un paso hacia un conjunto de estándares organizados de manera más lógica, enriquecidos con nuevas aportaciones y unificados con respecto a las normas anteriores para ser capaces de cubrir los dos principales procesos: especificación de requisitos de calidad del software y evaluación de la calidad del software, soportados por un proceso de medición. SQuaRE se centra exclusivamente en el producto software estableciendo criterios para su especificación, su medición y su evaluación.

La norma está compuesta de cinco divisiones bien diferenciadas: Gestión de la calidad (ISO/IEC 2500n), Modelo de calidad (ISO/IEC 2501n), Medidas de calidad (ISO/IEC 2502n), Requisitos de calidad (ISO/IEC 2503n) y Evaluación de calidad (ISO/IEC 2504n). Estas secciones pueden ser consultadas en más detalle en el Capítulo 2 de este libro.

Las principales ventajas con respecto a sus predecesores, ISO/IEC 9126 (2001) y ISO/IEC 14598 (1999) son:

• Mejor coordinación de la guía en la medición y evaluación de la calidad de losproductos de software.

• Mejor orientación para la especificación de requisitos de calidad de los productosde software.

• Armonización con la norma ISO/IEC 15939 (2000), en forma de modelo dereferencia en la medición de la calidad del producto presentado en la normaISO/IEC 25020.

• Mejor distinción entre las partes beneficiarias del producto software (usuariofinal, organización y equipo de mantenimiento) del sistema y sus necesidades.

Las principales diferencias con respecto a los mismos son:

• La introducción de un modelo de referencia general.• La introducción de guías detalladas y dedicadas a cada división.• La introducción de elementos de medidas de calidad dentro de la división de

medición de la calidad.• Incorporación y revisión de un modelo de calidad para los datos.• Incorporación y revisión del proceso de evaluación.• Coordinación y armonización del contenido de ISO/IEC 15939 (2000).• Introducción de guías para uso práctico en forma de ejemplos.• Renombramientos de algunas subcaracterísticas para evitar ambigüedades.• Incorporación de nuevas subcaracterísticas.

Con respecto al modelo de calidad planteado, existen tres vistas del modelo según el contexto donde se aplique: Modelo de Calidad de Software que será utilizado para evaluar un producto software concreto; Modelo de Calidad de Datos que será utilizado para evaluar la calidad de la información que maneja el software; y el Modelo de Calidad en Uso que pretende evaluar cómo las partes beneficiarias del producto alcanzan sus objetivos usando el producto en un contexto específico de uso. El modelo propuesto en este capítulo se corresponde con un Modelo de Calidad de Software puesto que el objetivo es la evaluación de la usabilidad del producto software como tal.

En cuanto a la estructura de la característica usabilidad, se mantiene igual que en la ISO/IEC 9126 (2001), sin embargo, existe como propuesta el renombramiento del término usabilidad por el de operabilidad, y el de operabilidad (subcaracterística de

usabilidad) por el de facilidad de uso. Sin embargo, en nuestro modelo no aplicaremos dicho renombramiento, debido a que los nombres anteriores son más conocidos y para evitar confusiones con la terminología empleada en trabajos relacionados.

4. MODELO DE USABILIDAD WEB

En esta sección presentamos un Modelo de Usabilidad Web alineado con el estándar ISO/IEC 25000 SQuaRE (2005) adaptando el modelo de usabilidad propuesto en Abrahão e Insfran (2006) e incluyendo aquellas métricas Web relacionadas con la usabilidad, sobre todo aquellas que han sido validadas teorética o empíricamente, pertenecientes a la clasificación realizada con WQM (Calero et al., 2005). En primer lugar, se describirá cómo un Modelo de Usabilidad Web puede ser empleado para la mejora y evaluación de la usabilidad en procesos de desarrollo Web dirigido por modelos, en segundo lugar, se definirán las subcaracterísticas y atributos que compondrán el modelo, y por último, se indicarán algunas de las métricas que se han asociado a los atributos definidos.

4.1 Incoporación de usabilidad en procesos DSDM

Un proceso de desarrollo, que sigue el enfoque de desarrollo de software dirigido por modelos (DSDM), básicamente transforma modelos independientes de detalles de implementación (modelos PIM - Platform Independent Model) en otros que aportan los aspectos específicos de una plataforma concreta (modelos PSM - Platform Specific Model), hasta llegar al código fuente (modelos CM - Code Model).

Estudios recientes indican que la adopción de DSDM ha crecido y actualmente existen varias metodologías de desarrollo Web que siguen este enfoque, como por ejemplo, OO-H (Gómez et al., 2001), WebML (Ceri et al., 2000) o UWE (Kraus et al., 2006). Estos métodos soportan la construcción de una aplicación Web mediante la definición de distintas vistas (modelos), incluyendo al menos un modelo estructural, un modelo de navegación y un modelo de presentación abstracta. Algunos métodos también proporcionan transformación de modelos y generación automática de código.

La usabilidad de una aplicación Web obtenida como resultado de ese proceso de transformación puede evaluarse en distintos momentos de un proceso DSDM. En este trabajo, proponemos el uso de un modelo de usabilidad que puede ser aplicado en las siguientes fases de un proceso de desarrollo dirigido por modelos: en el PIM, para evaluar los modelos de navegación o los modelos que representan el interfaz abstracto del usuario (modelo de presentación, modelos de diálogo, etc.); en el PSM, para evaluar los modelos de interfaz concreto (si los hay); y en el CM, para evaluar el interfaz de usuario final (Ver Figura 23-1).

La evaluación sobre el PIM (modelos de navegación, modelos de presentación, etc.) produce como salida un informe de usabilidad independiente de plataforma que realimentará el análisis del sistema (1). Por medio de las transformaciones entre modelos y la trazabilidad explícita entre éstos, los cambios realizados en el PIM son reflejados en el CM, evitando de esta forma problemas de usabilidad en la aplicación generada (CM). Este es un proceso iterativo que puede repetirse hasta que el PIM tenga el nivel de usabilidad requerido.

Figura 23-1. Incorporación de usabilidad en procesos DSDM

Por otro lado, existen otros atributos de usabilidad (uniformidad de colores de fuente, grado de atracción, etc.) que sólo pueden ser evaluados sobre una plataforma específica: sobre los componentes concretos del interfaz (PSM) o los componentes que conforman la interfaz gráfica resultante (CM).

Como resultado de la evaluación del PSM se produce un informe de usabilidad específico de plataforma. Si el PSM no posee el nivel de usabilidad requerido, el informe sugerirá modificaciones a realizar en los modelos independientes de plataforma (2A), en las estrategias de transformación de modelos PIM a modelos PSM o sobre el propio PSM (2B), de modo que esos problemas detectados puedan ser corregidos, de forma temprana, a nivel de modelos o a nivel de reglas de transformación entre modelos.

Por último, la evaluación del CM producirá como resultado un informe de usabilidad de la aplicación final, el cual en lugar de sugerir cambios en la capa de interfaz (CM), como es lo habitual en otros trabajos, en esta propuesta, los cambios sugeridos se realizan, al igual que en la evaluación del PSM, en los modelos independientes de plataforma (3A) y en las estrategias de transformación entre los modelos o sobre los modelos específicos de plataforma (3B).

4.2 Especificación de subcaracterísticas y atributos

El Modelo de Usabilidad Web propuesto es una adaptación y extensión del modelo de usabilidad presentado en Abrahão e Insfran (2006) para productos software genéricos siguiendo un enfoque basado en DSDM.

La usabilidad (referida como operabilidad en SQuaRE) se define en este trabajo como la capacidad, de una aplicación Web, de ser aprendida, comprendida, usada y atractiva para el usuario. Según la norma SQuaRE, este concepto se descompone en cinco subcaracterísticas:

1. Facilidad de aprendizaje: capacidad de una aplicación Web de ser aprendida yusada.

2. Facilidad de entendimiento: capacidad de una aplicación Web de ser entendidapor nuevos usuarios en términos de su propósito y cómo puede ser usada entareas específicas.

3. Operabilidad (referida como facilidad de uso en SQuaRE): la capacidad de unaaplicación Web de ser usada y controlada.

4. Grado de atracción: capacidad de una aplicación Web de ser atractiva para sususuarios.

5. Conformidad: capacidad de una aplicación Web para adherirse a los estándares,convenciones, guías de estilo o regulaciones relacionadas con la usabilidad.

Todas estas subcaracterísticas pueden ser descompuestas en otras subcaracterísticas y atributos más detallados basados en la interacción del usuario u otros atributos relacionados con la ayuda facilitada por la aplicación, la documentación de usuario y las instrucciones de uso. Esta descomposición se debe hacer con el fin de dar soporte a los métodos de inspección de usabilidad y, para identificar y corregir problemas de usabilidad.

Las tres primeras subcaracterísticas (facilidad de aprendizaje, facilidad de entendimiento y operabilidad) están relacionadas con el rendimiento del usuario y pueden ser cuantificadas de forma objetiva. La facilidad de aprendizaje hace referencia a todos aquellos atributos de la aplicación Web que permiten al usuario aprender a usarla. Su definición se recoge en la ISO 9241-10 (1996) como “adecuación para el aprendizaje”. En este modelo se ha descompuesto en las subcaracterísticas facilidad de ayuda (ayuda online, manuales de usuario, asistentes), previsibilidad (refiriéndose a la facilidad con la que el usuario puede determinar el resultado de las acciones que va a realizar), retroalimentación informativa (proporcionando información sobre el resultado de las acciones llevadas a cabo) y facilidad de recordar (rapidez y precisión con las que los usuarios pueden recordar cómo utilizar una aplicación que han utilizado antes.). La Tabla

I muestra, de forma más detallada, la descomposición de las subcaracterísticas anteriores en atributos medibles.

Subcaracterística Atributo Significado 1.1.1 Completitud de la documentación

Los documentos de ayuda contemplan todas las acciones que puede realizar el usuario.

1.1 Facilidad de ayuda 1.1.2 Documentación Multi-usuario

Todos los tipos de usuarios posibles están descritos junto a las acciones que pueden realizar.

1.2.1 Imágenes de enlaces/iconos significativos

Capacidad de predecir la acción que se va a realizar atendiendo a las imágenes.

1.2.2 Títulos de enlaces/iconos significativos

Capacidad de predecir la acción que se va a realizar atendiendo a los títulos de los enlaces. 1.2 Previsibilidad

1.2.3 Determinación de acciones

Las acciones se realizan conforme a la idea que teníamos de ella antes de ejecutarla.

1.3 Retroalimentación informativa

Capacidad de la aplicación Web de proporcionar a los usuarios el estado de las transacciones que se realizan (privacidad del sitio, tareas completadas con éxito, estado en una transacción, etc.).

1.4.1 Tiempo necesario para recordar

Tiempo necesario para que el usuario recuerde una funcionalidad de la Web usada anteriormente. 1.4 Facilidad para

recordar 1.4.2 Precisión Precisión con la que el usuario recuerda

acciones que ha realizado antes sobre la Web.

Tabla I. Descomposición de la subcaracterística “Facilidad de aprendizaje”

La facilidad de entendimiento hace referencia a todos aquellos atributos de la aplicación Web que facilitan su entendimiento. En este modelo se ha diferenciado entre subcaracterísticas que permitan la legibilidad visual de los textos e imágenes y la lectura de la información que se refiere a la densidad, complejidad y agrupación cohesionada de la información. Además, se ha descompuesto en otras subcaracterísticas como la familiaridad con la que un usuario reconoce aspectos de la interfaz de usuario, el ahorro de esfuerzo cognitivo (ej. reduciendo los pasos necesarios para completar tareas), orientación al usuario que sirva de guía de navegación a través de sus enlaces y mensajes de error o advertencias y retroalimentación inmediata que indique su posición actual o acciones que está realizando. La Tabla II muestra, de forma más detallada, la descomposición de las subcaracterísticas anteriores en atributos medibles.

Subcaracterística Atributo Significado

2.1.1 Tamaño de fuente Adecuación del tamaño de fuente al contexto.

2.1.2 Contraste del texto Texto siempre visible adecuadamente. 2.1 Legibilidad visual

2.1.3 Disposición Posición del texto visible en cualquier situación.

2.2.1 Información Cohesionada La información se presenta en grupos con un mismo núcleo temático.

2.2 Lectura de la información

2.2.2 Densidad de información Cantidad de información necesaria para evitar sobrecargas.

Subcaracterística Atributo Significado

2.2.3 Complejidad de la información

Dificultad de entendimiento de la información proporcionado por la aplicación Web.

2.3.1 Etiquetas significativas Uso de etiquetas fácilmente reconocibles. 2.3.2 Internacionalización Uso de elementos que siguen estándares. 2.3 Familiaridad 2.3.3 Metáfora Uso de metáforas que ayuden a hacer más

natural la interacción.

2.4.1 Brevedad Reducción del esfuerzo cognitivo (ej. realizar acciones en pocos pasos). 2.4 Ahorro de esfuerzo

2.4.2 Auto-descriptivo Elementos que transmitan un concepto de la forma más concisa posible

2.5.1 Calidad de los mensajes Los mensajes son útiles para que el usuario interactúe correctamente.

2.5.2 Retroalimentación inmediata

Guías al usuario sobre qué está explorando, cual es el progreso de sus acciones, etc. 2.5 Orientación al

usuario

2.5.3 Navegabilidad Facilidad con la que el usuario se mueve por el contenido Web accediendo a la información que le es relevante.

Tabla II. Descomposición de la subcaracterística “Facilidad de entendimiento”

La operabilidad hace referencia a todos aquellos atributos de la aplicación Web que permiten controlarla y operarla adecuadamente. Se corresponde con los términos: controlabilidad, tolerancia a fallos y conformidad con las expectativas del usuario definidos en la ISO 9241-10 (1996). En este modelo se ha descompuesto en facilidad de ejecución con la que el usuario comienza a usar la aplicación; validez de los datos introducidos por el usuario; controlabilidad en la ejecución de los servicios que se proveen; capacidad de adaptación diferenciando entre adaptabilidad, que se refiere a la capacidad de la aplicación Web de ser adaptada por el usuario, y adaptativo que se corresponde con la capacidad de la aplicación Web de adaptarse a las necesidades de los usuarios; consistencia en la ejecución de los servicios, prevención y gestión de errores y la capacidad de monitorización del sistema (útil para administradores Web). La Tabla III muestra, de forma más detallada, la descomposición de las subcaracterísticas anteriores en atributos medibles.

Subcaracterística Atributo Significado 3.1.1 Facilidad de comenzar a usar

Necesidad de instalar otros elementos software para el correcto funcionamiento.

3.1.2 Multiplicidad de plataformas

Visualización correcta en distintos navegadores Web.

3.1.3 Actualizable Siempre se está usando la última versión.

3.1 Facilidad de ejecución

3.1.4 Transparencia de las actualizaciones

El usuario no invierte esfuerzo en actualizaciones manuales.

3.2 Validez de los datos Se proveen mecanismos que verifiquen la validez datos que introduce el usuario.

3.3.1 Edición posterior Los contenidos insertados por el usuario se pueden editar en cualquier momento. 3.3 Controlabilidad

3.3.2 Soporte a operaciones de cancelación

Las acciones se pueden cancelar sin efectos perjudiciales al funcionamiento normal.

Subcaracterística Atributo Significado

3.3.3 Ejecución explícita No ocultar información acerca de las acciones que se están llevando a cabo.

3.3.4 Soporte a la interrupción Las acciones se pueden interrumpir sin perjudiciales al funcionamiento normal.

3.3.5 Soporte a operaciones de deshacer

Las acciones se pueden deshacer sin perjudiciales al funcionamiento normal.

3.3.6 Soporte a operaciones de rehacer

Las acciones se pueden rehacer para ahorrar trabajo al usuario.

3.4.1 Adaptabilidad Capacidad de la aplicación Web de ser adaptada por los usuarios 3.4 Capacidad de

adaptación 3.4.2 Adaptativo Capacidad de la aplicación Web para adaptarse a las necesidades de los distintos usuarios.

3.5.1 Comportamiento constante de los controles

Los controles siempre se comportan de la misma forma.

3.5.2 Permanencia de los controles

Los controles aparecen siempre que las acciones asociadas a ellos se puedan realizar.

3.5.3 Estabilidad de los controles Los controles realizan las acciones correctamente.

3.5.4 Consistencia en el orden Los controles respetan el orden de aparición para no confundir al usuario.

3.5 Consistencia

3.5.5 Consistencia en las etiquetas

Las etiquetas se corresponden con las acciones que representan.

3.6.1 Prevención de errores Capacidad de la aplicación Web de proporcionar mecanismos para prever errores comunes. 3.6 Gestión de errores

3.6.2 Recuperación ante errores Capacidad de la aplicación Web de volver a un estado estable tras un error.

3.7 Monitorización del estado de la Web Se permite conocer información referente a cómo se ejecutan los procesos en la Web.

Tabla III. Descomposición de la subcaracterística “Operabilidad”

Las dos últimas subcaracterísticas están relacionadas con la percepción subjetiva del usuario final (grado de atracción) o del evaluador (conformidad). Sin embargo, el grado de atracción se ha descompuesto en uniformidad del color de fondo, uniformidad del color de fuente, uniformidad del estilo de fuente, uniformidad del tamaño de fuente, uniformidad de la posición de la interfaz que representarían aquellos aspectos medibles en los que no es necesaria la intervención del usuario; y grado de atracción subjetiva cuya medición requiere la participación del usuario final y puede ser medida a través de cuestionarios estándares tales como SUMI, SUS y QUIS.

Por último, en la subcaracterística conformidad se han incluido la conformidad a la ISO/IEC 25000 SQuaRE (2005) por ser ésta la norma en la que se basa; y algunas guías de diseño Web como conformidad a la “Microsoft Web Design Guidelines” (2009), conformidad a la “Sun Guide to Web Style” (2009) y conformidad a la “IBM Web Design Guidelines” (2009) por ser algunas de las guías de diseño Web más relevantes.

4.3 Definición de Métricas

Una vez definido el modelo de usabilidad, el siguiente paso es asociar métricas que nos permitan cuantificar los atributos en los cuales hemos descompuesto las subcaracterísticas anteriores. Para esta labor, hemos tomado como punto de partida el conjunto de métricas Web clasificadas con WQM en Calero et al. (2005).

El procedimiento llevado a cabo para asociar métricas a atributos del modelo de usabilidad ha sido, en primer lugar, seleccionar aquellas métricas del conjunto presentado en Calero et al. (2005) que fueron clasificadas como relativas a la usabilidad en la dimensión características de calidad de WQM. En segundo lugar, seleccionar del conjunto resultante aquellas que habían sido validadas teorética y/o empíricamente. Y por último, estudiar cada métrica seleccionada en base a los criterios propuestos por SQuaRE (objetivo, interpretación, método de cálculo, artefactos y fase del proceso en los que se aplica, evidencias de su validez, etc.). Si la métrica se emplea sobre la aplicación Web final, se estudia además la posibilidad de adaptarla para que sea aplicable en modelos independientes o específicos de plataforma.

El estudio completo de cada métrica permitirá entender qué atributo del modelo de usabilidad está relacionado con el concepto que se pretende medir con dicha métrica. Por ejemplo, la métrica Número de enlaces de navegación (Abrahão et al., 2003) tiene como objetivo cuantificar el total de enlaces que existen entre contextos navegacionales aplicándose a modelos navegacionales (PIM), por lo tanto, será asociada al atributo navegabilidad (para medir una dimensión de esta subcaracterística); mientras que la métrica estilo de fuente (Ivory, 2001) que se encarga de contabilizar las diferentes combinaciones de estilos de fuente y es aplicable inicialmente sobre la interfaz de usuario final, podría relacionarse con el atributo uniformidad del estilo de fuente. Además, esta métrica podría adaptarse para ser aplicable en modelos de presentación (PIM) o de diseño (PSM) que incorporen elementos que definan estilos.

Tras la incorporación de las métricas anteriores se detectaron atributos sin métricas asociadas (como por ejemplo, la retroalimentación inmediata, soporte a operaciones de cancelación, etc.). Para solventar estas carencias se ha recurrido a incorporar métricas propuestas por SQuaRE, referentes a la ISO/IEC 9126-2,3 (2002) realizando el mismo estudio descrito anteriormente para cada métrica, y además, se han propuesto otras métricas potenciales que se podrían emplear, las cuales necesitarían ser validadas teorética y empíricamente. La Tabla IV muestra algunas de las asociaciones establecidas entre atributos del modelo de usabilidad y métricas incorporadas describiendo éstas e indicando sobre qué niveles de abstracción (modelos en un proceso DSDM) podrían aplicarse. Por ejemplo, la métrica “número de enlaces de navegación” podría ser medida a nivel del PIM si la navegación es modelada como un grafo donde los nodos representan la información a la que se accede y las aristas representan dichos enlaces navegacionales, y a nivel del CM (aplicación final) si se contabilizaran los elementos del código final

(etiquetas HTML, elementos javascript, etc.) que representan enlaces. El Modelo de Usabilidad Web completo puede ser consultado en la Tabla V del Anexo A.

Atributo Métrica Descripción Aplicable

1.2.2 Títulos de enlaces/iconos significativos

Proporción de títulos escogidos adecuadamente para cada icono o enlace (propuesta)

Ratio entre el número total de títulos adecuados al enlace/icono que están asociados y el número total de títulos asociados a enlaces o iconos existentes. (Valor real entre 0 y 1)

PIM, PSM o CM

2.4.1 Brevedad

Disponibilidad de valores por defecto (ISO/IEC 9126-2,3, 2002)

Ratio entre los elementos (atributos de clase, datos solicitados en la interfaz de usuario, etc.) que poseen valor(es) por defecto y el total de atributos potenciales a tener valores por defecto. (Valor real entre 0 y 1)

PIM, PSM o CM

Proporción de mensajes de error significativos (Abrahão e Insfran, 2006)

Ratio entre mensajes explicando un error detalladamente y total de contextos donde se puede producir un error. (Valor real entre 0 y 1)

PIM, PSM o CM

2.5.1 Calidad de los mensajes Proporción de

mensajes de aviso significativos (Abrahão e Insfran, 2006)

Ratio entre mensajes explicando un aviso detalladamente y total de contextos donde se puede producir advertencias al usuario. (Valor real entre 0 y 1)

PIM, PSM o CM

2.5.2 Retroalimentación inmediata

Proporción de elementos que muestran estado del usuario en la interfaz (propuesta)

Ratio entre el total de elementos que necesitan información sobre su estado y número de elementos que muestran dicha información al usuario. (Valor real entre 0 y 1)

PIM, PSM o CM

Número de clases navegacionales* (Abrahão et al., 2003)

Número total de clases navegacionales que existen en un modelo navegacional. (Valor entero mayor o igual que 0)

PIM

Números de enlaces de navegación* (Abrahão et al., 2003)

Número total de enlaces que existen entre los nodos navegacionales (PIM) o páginas de la aplicación final (CM). (Valor entero mayor o igual que 0)

PIM o CM

Amplitud del mapa navegacional* (Abrahão et al., 2003)

Número total de destinos navegacionales de primer nivel del mapa navegacional. (Valor entero mayor o igual que 0)

PIM

2.5.3 Navegabilidad

Profundidad del mapa navegacional* (Abrahão et al., 2003)

Longitud del camino más largo entre la raíz de un mapa navegacional y sus hojas. (Valor entero mayor o igual que 0)

PIM

3.3.2 Soporte a operaciones de cancelación

Operaciones de usuario cancelables (ISO/IEC 9126-2,3, 2002)

Ratio entre el número de funciones cancelables por el usuario y el número total de funciones que requieren la capacidad de cancelación. (Valor real entre 0 y 1)

PIM, PSM o CM

4.3 Uniformidad del estilo de fuente

Estilo de fuente (Ivory, 2001)

Ratio entre combinación de estilos de fuente y el número total de interfaces. (Valor real entre 0 y 1)

PIM, PSM o CM

* Los conceptos: “mapa navegacional, “destino navegacionl”, “clase navegacional” y “enlace navegacional”hacen referencia al método OO-H en concreto y se definirán en la sección 5.1

Tabla IV. Ejemplos de métricas incluidas en el modelo

5. OPERACIONALIZACIÓN DEL MODELO

Un proceso de desarrollo de una aplicación Web en un entorno DSDM (Ver Figura 23-1) puede ser realizado usando distintas metodologías. A modo de ejemplo, hemos escogido el método Object-Oriented Hypermedia (OO-H) (Gómez et al., 2001) para realizar la operacionalización del Modelo de Usabilidad Web presentado en la sección 4.2. Este método está soportado por la herramienta VisualWade (www.visualwade.com) que automatiza todos los procesos llevados a cabo en el método.

La operacionalización el modelo de usabilidad Web consiste en la instanciación de dicho modelo en un método de desarrollo Web dirigido por modelos concreto (OO-H en nuestro caso de estudio). Esto se realiza relacionando los elementos pertenecientes a los Modelos Independientes y Específicos de Plataforma (PIMs y/o PSMs) del método de desarrollo Web utilizado con los atributos y métricas del modelo de usabilidad para cuantificar dichos atributos y realizar una evaluación temprana de la usabilidad.

5.1 El método OO-H

OO-H (Gómez et al., 2001) es un método de desarrollo Web dirigido por modelos, basado en el paradigma orientado a objetos, que proporciona la semántica y la notación necesaria para especificar interfaces de usuario en el contexto Web. Se puede modelar una aplicación Web mediante dos vistas complementarias: un Modelo Navegacional que captura propiedades de navegación e interacción; y un Modelo de Presentación que captura los conceptos asociados a la estructura final de la aplicación Web y los detalles específicos de presentación.

La figura 23-2 muestra esquemáticamente el proceso de desarrollo de OO-H. El proceso comienza definiendo un modelo de requisitos (CIM), a partir del cual se definen los Modelos Independientes de Plataforma (PIM) que permitirán representar la aplicación Web en sus principales dimensiones: Contenido (Modelo de Clases) y Navegación (Modelo Navegacional - NAD).

Partiendo de los modelos anteriores se obtiene la dimensión Presentación (Modelo de Presentación Abstracta - APD), que puede ser modificado manualmente y utilizado para la generación de código de la aplicación Web final. Del APD se obtienen automáticamente los modelos específicos de plataforma (PSMs), a partir de los cuales, se puede generar el código fuente de la aplicación Web final (CM).

Figura 23-2. Proceso de desarrollo Web de OO-H

A continuación, se detallan algunos conceptos básicos pertenecientes a los Modelos Independientes de Plataforma del método OO-H: Modelo de Clases, Modelo Navegacional y Modelo de Presentación Abstracta. El Modelo de Clases es exactamente análogo a un Modelo de Clases UML que representa el dominio de la aplicación Web y está compuesto de clases, atributos, métodos y relaciones entre clases. Además, se pueden especificar fórmulas OCL sobre el modelo para definir restricciones adicionales.

El Modelo Navegacional (NAD) está definido por un conjunto de mapas navegacionales. Cada mapa navegacional representa una vista del sistema para un tipo específico de usuario y tiene un único punto de entrada (entry point) que indica donde comienza la navegación. Un mapa navegacional está compuesto por dos tipos de elementos: nodos navegacionales y enlaces navegacionales. Un nodo navegacional representa una vista parcial de Modelo de Clases y puede ser de cuatro tipos: un destino navegacional, una clase navegacional, una colección o una etiqueta. Un destino navegacional agrupa elementos del modelo (clases navegacionales, enlaces navegacionales, colecciones) que colaboran cubriendo los requisitos funcionales de un usuario.

Una clase navegacional presenta una vista parcial de atributos y métodos de una clase procedente del Modelo de Clases. Una colección es una estructura jerárquica que agrupa un conjunto de enlaces navegacionales. Una etiqueta es un nodo especial que muestra información derivada de otros nodos navegacionales. Un enlace navegacional define qué nodos son accesibles dentro de una mapa navegacional, es decir, los caminos de acceso que un usuario puede seguir a través de la interfaz de usuario, y atendiendo a la localización del efecto producido, éstos pueden ser de dos tipos: origen cuando el efecto se agrega a la vista (se representa mediante una flecha de punta hueca), y destino cuando el efecto se proporciona en una nueva vista (se representa mediante una flecha de punta sólida).

Por último, el Modelo de Presentación Abstracta representa una colección de páginas abstractas. Una página abstracta es conjunto de información relacionada que se visualiza en un único paso de navegación. Estas páginas son generadas automáticamente a partir de los Modelos Navegacionales, apoyándose además, en un catálogo de patrones y plantillas, proporcionando una especificación de la interfaz de usuario más cercana a un modelo de implementación de aplicación Web, basado en fuentes (ficheros) que permiten: refinar la aplicación Web, proveer una unidad de prototipado en OO-H, y presentar la interfaz de usuario en términos fácilmente comprensibles por diseñadores gráficos.

5.2 Caso de estudio: Gestor de tareas

La aplicación Web a utilizar como caso de estudio es un gestor de tareas (Task Manager) desarrollada para el control y seguimiento de proyectos de desarrollo Web. Un proyecto de desarrollo Web implica una serie de tareas (tasks) que se asignan a un usuario (user), que es un programador de la empresa. En cada tarea se registra la fecha de inicio, la estimación de la fecha de finalización, prioridad, etc. El director del proyecto organiza las tareas en carpetas (folders) de acuerdo a ciertos criterios: las tareas pendientes, tareas críticas, etc. Además, se pueden asociar archivos externos (files) a una tarea (por ejemplo, documentos de requisitos, código, etc.). Los programadores pueden también incorporar comentarios (comments) a las tareas y enviar mensajes (messages) a otros programadores. Todos los días laborables, los programadores pueden generar un informe (Daily Report), incluyendo la información relacionada con las tareas en las que están trabajando. Por último, los clientes (stakeholders) del proyecto se registran como Contactos (contacts) en la aplicación.

Para ilustrar la aplicación del Modelo de Usabilidad Web hemos considerado sólo un fragmento del caso de estudio, concretamente el acceso a la aplicación, gestión de tareas y el registro de contactos. En la Figura 23-3 (a) se muestra un fragmento del Modelo de Clases (PIM) donde sólo se contempla la información de las tareas (clase Task) a realizar por los distintos programadores (clase User) y la información perteneciente a los contactos que son registrados en la aplicación Web.

La información de las clases se representa mediante sus atributos. Los atributos marcados con el icono de una llave indican atributos identificadores, mientras que los atributos marcados con ‘/’ indican atributos derivados que se calcularán mediante los valores de otros atributos. En la Figura 23-3 (b) se muestra un ejemplo de cómo en VisualWade se puede definir un atributo en base a su meta-información como su nombre (Name), dominio de valores (Domain), valores por defecto (Default value), visibilidad (Visibility), etc.

Figura 23-3. Fragmento del Modelo de Clases (PIM) de la aplicación Task Manager (a) y cuadro de diálogo de VisualWade para la definición de atributos (b)

Considerando un mapa navegacional asociado a un tipo de usuario de la aplicación (programador) cuya vista parcial se define sobre la clase Task de este Modelo de Clases, y suponiendo que el mapa navegacional muestra todos sus atributos y sólo los métodos (New, Destroy y modify_percentage), podríamos aplicar, a modo de ejemplo, la siguiente métrica descrita en la sección 4.3:

• Disponibilidad de Valores por defecto (ver Tabla IV, atributo 2.4.1): Sóloconsideraremos aquellos atributos que potencialmente tendrían valores pordefecto (para determinar qué atributos serían potenciales podríamos basarnos enrequisitos funcionales o navegacionales del usuario). Los atributos potencialesconsiderados en este caso serían: start_date, priority, ended_percentage, yconsiderando también aquellos atributos que sólo por el hecho de seridentificadores o derivados siempre se garantiza un valor por defecto calculadoautomáticamente (un total de 10 atributos potenciales). En la vista depropiedades del atributo se observó que tres atributos (start_date, priority yended_percentage), presentan sus campos “Default value” vacío. Por motivos deespacio, en la Figura 23-3 (b) sólo se muestra a modo de ejemplo el atributostart_date. Por lo tanto, debido a que existen 7 atributos con valores por defecto,la métrica obtendría el valor 7/10= 0.7. Este resultado es bastante positivo debidoa que valores más próximos a 1 indican que la mayoría de atributos querequieren un valor por defecto se han considerado correctamente, reduciendo asíel esfuerzo y tiempo que el usuario necesitaría si tuviera que introducirlos élmismo (ver Tabla II, atributo 2.4.1). Obviamente, esta métrica podría aplicarse acada una de las páginas Web abstractas de una aplicación y el resultado sería unindicador del grado en que la aplicación proporciona valores por defecto.

En la Figura 23-4 (a) se muestra un fragmento el Modelo Navegacional de nivel 0 (NAD) que representa el acceso a la aplicación, y en la Figura 23-4 (b) el Modelo de Presentación Abstracta generado a partir del Modelo de Clases y el Modelo Navegacional.

Figura 23-4. Modelo Navegacional de nivel 0 (a) y Modelo de Presentación Abstracta generado (b)

En el Modelo Navegacional (Figura 23-4 (a)) se representa el acceso de un programador de la empresa (User) mediante el enlace Entry point User. El primer nodo (clase navegacional User) se corresponde con un formulario a través del cual el programador podrá iniciar sesión en la aplicación. Este proceso implica un perfil de usuario (profile), un nombre de usuario (user_name) y una contraseña (password). Si el usuario existe (condición que se refleja en el enlace navegacional LI4) se muestra un menú con enlaces a cada uno de los tres destinos navegacionales posibles (Tasks, Contacts, Reports), y si no existe, se muestra un mensaje de error (LI2) volviendo al formulario inicial (LI6). Este menú se representa mediante la colección denominada restricted home que agrupa los caminos de acceso (LI63, LI19, LI75, LI28). Además, mediante la etiqueta denominada connected as, se muestra la información referente al inicio de sesión (LI92).

El Modelo de Presentación Abstracta (Figura 23-4 (b)) incluye tres páginas abstractas generadas a partir del Modelo Navegacional (Figura 23-4 (a)). La clase navegacional User produce una página abstracta que muestra el acceso a la aplicación (1). El enlace navegacional LI2, al ser de localización de efecto destino, genera el mensaje de error, representado en la colección error, en otra página abstracta (2). Por último, la colección home restringido se accede mediante el enlace navegacional LI4, que al ser de efecto destino, genera el home del usuario en otra página abstracta (3) representando los destinos navegacionales posibles (Tasks, Reports, Contacts). Sin embargo, la etiqueta connected as, al ser accesible mediante un enlace navegacional origen (LI96), se muestra en la misma página abstracta.

En este Modelo Navegacional se han aplicado, a modo de ejemplo, las siguientes métricas descritas en la sección 4.3:

• Amplitud del mapa navegacional (ver Tabla IV, atributo 2.5.3): La amplitud delmapa navegacional sería 4, debido a que el número de destinos navegacionalesde primer nivel es 4 (Home, Tasks, Contacts y Reports).

• Profundidad del mapa navegacional (ver Tabla IV, atributo 2.5.3): Laprofundidad del mapa navegacional sería 2, debido a que la longitud del caminomás largo entre la raíz del mapa navegacional (destino navegacional Home) y lashojas (destinos navegacionales: Tasks, Contacts y Reports) pasa por dos enlacesnavegacionales: LI4 y uno que accede al destino navegacional hoja (LI19, LI75,LI28)

Estos valores obtenidos son de gran relevancia para que la navegabilidad de una aplicación Web sea adecuada, puesto que si el mapa navegacional de la aplicación Web es demasiado estrecho y profundo, los usuarios tienen que hacer click un número excesivo de veces y navegar varios niveles para encontrar lo que están buscando, mientras que si mapa navegacional es demasiado amplio y poco profundo, los usuarios pueden perderse debido a la excesiva cantidad de información a la que pueden acceder. Para aplicaciones Web de gran tamaño que poseen una estructura jerárquica, el valor recomendado suele ser una profundidad menor de 5 niveles y una amplitud menor de 9 niveles. Puesto que la aplicación Web del ejemplo obtiene valores por debajo de esos umbrales, el mapa navegacional tendrá una navegabilidad adecuada (ver Tabla II, atributo 2.5.3).

Mientras que en el Modelo de Presentación Abstracta (Figura 23-4 (b)) podemos aplicar métricas (descritas en la sección 4.3) más cercanas a las empleadas en interfaces de usuario finales:

• Proporción de mensajes de error significativos (ver Tabla IV, atributo 2.5.1):Sólo existe un mensaje de error que se describe como “Login or passwordincorrect. Please try again”. Puesto que el mensaje explica correctamente cuáles el error, el valor de la métrica sería 1/1 = 1. Este resultado es muy positivodebido a que valores más próximos a 1 indican que los mensajes de error sonmuy significativos, orientando de esta forma al usuario hacia un uso correcto dela aplicación Web (ver Tabla II, atributo 2.5.1).

• Proporción de títulos escogidos adecuadamente para cada icono o enlace (verTabla IV, atributo 1.2.2): A modo de ejemplo nos centraremos en los títulos delos enlaces que aparecen en los modelos APD de la Figura 23-4 (b). Estos títulosson cuatro (Enter, Return, Whats new, y exit). Puesto que todos los títulos noshacen prever intuitivamente el destino de esos enlaces, la métrica obtendría elvalor 4/4=1. Este resultado es muy positivo debido a que valores más próximos a1 indican que los títulos escogidos están adecuados a los iconos o enlaces,permitiendo al usuario prever qué acciones tendrán lugar a continuación (verTabla I, atributo 1.2.2).

Obviamente, estas métricas podrían aplicarse a cada un de las páginas Web abstractas de una aplicación para determinar el grado en que ésta proporciona títulos adecuados y mensajes de error significativos. En la Figura 23-5 (a), se muestra el Modelo Navegacional de nivel 1 (NAD) para el registro de contactos y en la Figura 23-5 (b) el Modelo de Presentación Abstracta generado a partir del Modelo de Clases y el Modelo Navegacional

Figura 23-5. Modelo Navegacional “registro de contactos” (a) y Modelo de Presentación Abstracta generado (b)

En el Modelo Navegacional (Figura 23-5 (a)) se muestra la expansión del destino navegacional “Contacts”. El programador (user) accede al menú de contactos donde podrá consultar la información (name, surname, etc.) de todos los contactos registrados, o bien, hacer una búsqueda específica indicando las iniciales del contacto o una cadena de texto. Estas funcionalidades están representadas por tres enlaces navegacionales (todosContactos, porInicial y porCadena) que conectan la colección menú contactos con la clase navegacional Contacto donde se muestra qué información está visible para el usuario. Si la búsqueda no produce ningún resultado (LI83) se muestra un mensaje de advertencia. Además, el programador podrá añadir nuevos contactos ejecutando el método new de la clase navegacional Contacto1 accediendo a ella a través del enlace nuevoContacto.

El Modelo de Presentación Abstracta (Figura 23-5 (b)) incluye cuatro páginas abstractas generadas a partir del Modelo Navegacional (Figura 23-5 (a)). La colección menú contactos contiene cuatro enlaces navegacionales (nuevoContacto, todosContactos, porInicial, porCadena) generándose a partir de ellos, una página abstracta con las opciones que representan esos enlaces (1). A partir del enlace nuevoContacto y la clase navegacional Contacto1 se genera el formulario de registro de un nuevo contacto en otra página abstracta (2). Los resultados de la búsqueda realizada gracias a los enlaces (todosContactos, porInicial, porCadena) se corresponden con otra página abstracta (3)

que detalla la información mostrada en la clase navegacional Contacto para cada contacto encontrado. Para finalizar, si la búsqueda no ha producido ningún resultado, a través de la colección No hay coincidencias, se genera un mensaje de advertencia (4).

En este Modelo Navegacional se han aplicado, a modo de ejemplo, las siguientes métricas descritas en la sección 4.3:

• Número de clases navegacionales (ver Tabla IV, atributo 2.5.3): Existen 2 clasesnavegacionales (contacto y contacto1) que representan la consulta y creación decontactos respectivamente.

• Números de enlaces de navegación (ver Tabla IV, atributo 2.5.3): Existen 7enlaces navegacionales (nuevoContacto, todosContactos, porInicial, porCadena,LS16, LI82, LI83).

Estos valores obtenidos se pueden emplear para determinar la densidad del destino navegacional Contacts (ratio entre el número de enlaces y clases navegacionales dentro de un mismo destino navegacional). La densidad puede afectar negativamente a la navegabilidad si ésta es demasiado elevada (del orden de 10 enlaces/clase). En este ejemplo, la densidad sería 7/2 = 3.5 enlaces/clase. Por lo tanto, la navegabilidad de la aplicación Web no se vería afectada negativamente (ver Tabla II, atributo 2.5.3).

Mientras que en el Modelo de Presentación Abstracta podemos aplicar métricas tales como (ver sección 4.3):

• Proporción de mensajes de aviso significativos (ver Tabla IV, atributo 2.5.1):Sólo existe un mensaje de aviso detallado como “No results has been found”.Puesto que el mensaje explica correctamente que no se han encontrado losresultados esperados, el valor de la métrica sería 1/1 = 1. Este resultado es muypositivo debido a que valores más próximos a 1 indican que los mensajes deadvertencia son muy significativos, orientando de esta forma al usuario hacia unuso correcto de la aplicación Web. (ver Tabla II, atributo 2.5.1).

• Estilo de fuente (ver Tabla IV, atributo 4.3): Las propiedades del Modelo dePresentación Abstracta permiten mantener los mismos estilos de fuente en todaslas interfaces generadas, por lo tanto el valor de la métrica sería 1. Este resultadoes muy positivo debido a que valores más próximos a 1 indican que existe ciertauniformidad en los estilos de fuente, de esta forma se evita confundir al usuariohaciendo la aplicación Web resultante más atractiva para su uso. (ver Tabla II,atributo 4.3).

Finalmente, y para ilustrar el uso del modelo de usabilidad sobre una aplicación final, en la Figura 23-6 se muestra la interfaz de usuario para el registro de contactos generada a partir de los Modelos de Presentación Abstracta mostrados en las Figuras 23-4 (b) y 23-5 (b).

Figura 23-6. Interfaz de usuario generada para el registro de contactos (Aplicación Web Final)

En esta Interfaz de Usuario sólo se muestra la interfaz final, tras la generación de código, correspondiente a tres páginas abstractas: 23-4 (b-3), 23-5 (b-1) y 23-5 (b-2). A modo de ejemplo, es posible aplicar algunas de las métricas, descritas en la sección 4.3, sobre esta interfaz:

• Proporción de elementos que muestran estado del usuario en la interfaz (verTabla IV, atributo 2.5.2): En la figura 23-6, el usuario necesita saber,principalmente, en qué sección de la aplicación se encuentra y qué estárealizando en ese momento. En este ejemplo, la interfaz de usuario indica que elusuario se encuentra en la sección Contactos gracias a elementos gráficos comolas pestañas. Además, el usuario es capaz de saber qué campos de un nuevocontacto está rellenando gracias al resaltado de todos los campos de texto y alcambio de forma del cursor cuando se está editando su contenido. Puesto quetodos los elementos gráficos contemplan el estado del usuario, el valor de lamétrica sería 1. Este resultado es muy positivo debido a que valores máspróximos a 1 indican que se proveen los mecanismos necesarios que hacenposible una retroalimentación inmediata hacia el usuario (ver Tabla II, atributo2.5.2).

• Operaciones de usuario cancelables (ver Tabla IV, atributo 3.3.2): En estainterfaz no se provee ningún control explícito que permita cancelar la inserciónde un contacto en caso de haber introducido datos erróneos, por lo tanto, el valor

obtenido de esta métrica sería 0. Este resultado es muy negativo debido a que valores más próximos a 0 indican que el usuario no puede cancelar operaciones, impidiéndole corregir errores cometidos (ver Tabla III, atributo 3.3.2). Este aspecto se podría mejorar en el Modelo Navegacional de la Figura 23-5 (a) si se pudiera acceder mediante un nuevo enlace navegacional (ej. eliminarContacto) a una nueva clase navegacional (ej. Contacto2) que hiciera visible el método Destroy definido en la clase Contact del Modelo de Clases.

En este ejemplo de aplicación sólo se ha mostrado un fragmento del caso de estudio, sin embargo, el Modelo de Usabilidad Web es enteramente aplicable a una aplicación Web completa que siga un enfoque dirigido por modelos. Aunque se haya presentado la operacionalización del modelo en OO-H, esto no exime que el modelo propuesto pueda operacionalizarse sobre otras metodologías de desarrollo Web dirigida por modelos como WebML (Ceri et al., 2000) o UWE (Kraus et al., 2006). El aspecto clave es relacionar los atributos del Modelo de Usabilidad Web con aquellos elementos pertenecientes a los Modelos Independientes de Plataforma (PIMs), a los Modelos Específicos de Plataforma (PSMs) y/o al código final de la aplicación Web (CM). Para establecer estas relaciones es imprescindible conocer el propósito de las métricas existentes (para entender qué conceptos pretenden medir) y posteriormente identificar qué elementos de los modelos proporcionan la semántica necesaria para soportarlas.

6. CONCLUSIONES Y TRABAJOS FUTUROS

Tras un estudio previo de los modelos de calidad existentes para productos software y específicos para la Web, se ha detectado la necesidad de un modelo de usabilidad que pueda ser aplicado a las fases iniciales de un proceso de desarrollo Web, y concretamente, a artefactos intermedios como los PIM o PSM obtenidos en un proceso de desarrollo dirigido por modelos.

En este capítulo se ha presentado un Modelo de Usabilidad Web alineado con el estándar ISO/IEC 25000 - SQUARE (2005) para la mejora y evaluación de la usabilidad en procesos de desarrollo Web dirigido por modelos. Gracias a este modelo, es posible realizar evaluaciones de usabilidad de las aplicaciones Web, no sólo cuando éstas están finalizadas, sino además, en fases tempranas del desarrollo. De esta forma, la usabilidad se tiene en cuenta en todo el proceso, permitiendo obtener aplicaciones Web de mejor calidad junto con todas las ventajas inherentes de un desarrollo dirigido por modelos. Además de la evaluación, el modelo podría ser usado para detectar limitaciones en la expresividad de los modelos PIM o PSM, y/o para mejorar las reglas de transformación entre modelos. Por ejemplo, durante la fase de operacionalización del modelo de usabilidad hemos observado que el método OO-H puede ser extendido para soportar algunos atributos de usabilidad tal como “Centros de asociación semántica” a través de la incorporación de mecanismos para agrupar atributos semánticamente en el Modelo Navegacional, evitando de este modo la generación de formularios con una extensa lista de atributos que no estén agrupados por ningún criterio.

Aunque el modelo de usabilidad Web ha sido operacionalizado en el método OO-H, a través de la evaluación de los modelos PIM (Modelo de Clase, Modelo Navegacional y Modelo de Presentación Abstracta) e interfaces finales de usuario, éste puede ser igualmente operacionalizado en otros métodos de desarrollo Web dirigido por modelos (UWE, WebML,…).

Entre los trabajos futuros se pretende aplicar el modelo propuesto en varios casos prácticos y en otras metodologías de desarrollo Web para detectar posibles nuevos atributos y métricas que contribuyan al enriquecimiento del modelo. Se pretende también validar teórica y empíricamente las métricas propuestas así como el modelo de usabilidad en general. Además, se pretende estudiar mecanismos de agregación para los valores obtenidos por métricas individuales; realizar análisis de impacto sobre cómo las mediciones de los atributos afectan positiva o negativamente a otros atributos del Modelo de Usabilidad; crear un repositorio de métricas catalogadas siguiendo las pautas de SQuaRE junto con guías de interpretación acerca de los resultados numéricos obtenidos; crear una herramienta que permita gestionar el modelo de usabilidad simulando el comportamiento de un repositorio de métricas Web y automatizar la evaluación de los modelos PIM, PSM o aplicación Web final; elaborar un Modelo de Calidad de Datos y un Modelo de Calidad en Uso acorde a la norma SQuaRE para evaluar otros aspectos complementarios de la usabilidad de las aplicaciones Web.

AGRADECIMIENTOS

Este trabajo ha sido financiado por el proyecto META (TIN2006-15175-C05-05), el proyecto Transformación de Modelos Dirigida por Atributos de Calidad de la Universidad Politécnica de Valencia y por la red CALIPSO (TIN2005-24055-E). Los autores agradecen a Jaime Gómez de la Universidad de Alicante por su valiosa colaboración al proporcionar los modelos y la aplicación Web generada utilizados en el caso de estudio.

REFERENCIAS

ABRAHÃO, S., CONDORI-FERNÁNDEZ, N., OLSINA, L. y PASTOR, O. (2003). “Defining and Validating Metrics for Navigational Models”. Proceedings of the 9th International Software Metrics Symposium (METRICS'03), IEEE. pp. 200-210.

ABRAHÃO, S. e INSFRAN, E. (2006). “Early Usability Evaluation in Model-Driven Architecture Environments”. Proceedings of the 6th IEEE International Conference on Quality Software (QSIC), Beijing, China. IEEE Computer Society, ISBN 0-7695-2718-3, pp. 287-294.

ABRAN, A., KHELIFI, A., SURYN, W. y Seffah, A. (2003). “Usability Meanings and Interpretations in ISO Standards”, Software Quality Journal, 11 (4) 325-338.

BAJAJ, A. y KRISHNAN, R. (1999). “CMU-WEB: A Conceptual Model for Designing Usable Web Applications”. Journal Database Management, nº 10(4), pp. 33-43.

BARESI, L., MORASCA, S. y PAOLINI, P. (2003). “Estimating the Design Effort of Web Applications”. Proceedings of the 9th International Metrics Symposium (METRICS’03) IEEE, pp. 62-72.

BASTIEN, J. M. y SCAPIN, D. L. (1993). “Ergonomic Criteria for the Evaluation of Human-Computer Interfaces”, version 2.1.

BOTAFOGO, R., RIVLIN, E. y SHNEIDERMAN, B. (1992). “Structural analysis of hypertexts: Identifying hierarchies and useful metrics”. ACM Trans. Inform. Systems, 10(2), pp. 142-180.

CALERO, C., RUIZ, J. y PIATTINI, M. (2005). “Classifying Web metrics using the Web quality model”. Emerald Group Publishing Limited. ISSN: 1468-4527. Vol.29, nº 3, pp. 227-248.

CERI, S., FRATERNALI, P. y BONGIO, A. (2000). “Web Modeling Language (WebML): a modeling language for designing Web sites”. Proceedings of the 9th World Wide Web Conference (WWW 2000), Amsterdam, The Netherlands, pp. 137-157.

DROMEY, R.G. (1998). “Software Product Quality: Theory, Model and Practice”. Software Quality Institute, Griffith University, Nathan, Brisbane, Australia.

FINK, D. (2001). “Web Site Effectiveness: A Measure of Information and Service Quality”. Information Resource Management Association International Conference, Toronto, Canada. pp. 144-147.

FRANCH, X. y CARVALLO, J. P. (2003). “Using Quality Models in Software Package Selection”. IEEE Software 20 (1), pp. 34-41.

GOMEZ, J., CACHERO, C. y PASTOR, O. (2001). “Conceptual Modeling of Device-Independent Web Applications”. IEEE MultiMedia 8(2), pp. 26-39.

HERDER, E. (2002). “Metrics for the Adaptation of Site Structure”. Proceedings of the German Workshop on Adaptivity and User Modeling in Interactive Systems ABIS02 - Hannover, pp. 22-26.

IBM. “IBM Web Design Guidelines”. Disponible en https://www-01.ibm.com/software/ucd/ [último acceso: Enero 2009]

ISO/IEC (1991). “ISO/IEC-9126:1991. Information Technology - Software Product Evaluation - Quality Characteristics and Guideline for their Use”.

ISO/IEC (1995). “ISO/IEC 12207. Information Technology. Software Life Cycle Processes”.

ISO/IEC (1996). “ISO/IEC 9241-10, Ergonomic Requirements for Office Work with Visual Display Terminals (VDTs), Part 10: Dialogue principles”.

ISO/IEC (1998). “ISO/IEC 9241-11, Ergonomic Requirements for Office Work with Visual Display Terminals (VDTs), Part 11: Guidance on Usability”.

ISO/IEC (1999). “ISO/IEC 14598-1, Information technology - Software product evaluation - Part 1: General overview”.

ISO/IEC (2000). “ISO/IEC 15939: Information Technology - Software Measurement Process”.

ISO/IEC (2001). “ISO/IEC 9126-1 Standard, Software engineering – Product quality - Part 1: Quality model,”.

ISO/IEC (2002). “ISO/IEC 9126-2-3 Standard, Software engineering – Product quality - Part 2-3: External & Internal Metrics”.

ISO/IEC (2005). “ISO/IEC 25000:2005, Software Engineering - Software Product Quality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE”.

IVORY, M.Y. (2001). “An Empirical Foundation for Automated Web Interface Evaluation”. PhD Thesis, University of California, Berkeley, Computer Science Division.

KRAUS, A., KNAPP, A. y KOCH, N. (2006). “Model-Driven Generation of Web Applications in UWE”. 3rd International Workshop on Model-Driven Web Engineering MDWE.

LOPES, R. y CARRIÇO, L. (2008). “A model for universal usability on the Web”. Proceedings of the First International Workshop on Understanding Web Evolution, pp. 63-70.

McCALL, J. A., RICHARDS, P. K. y WALTERS, G. F. (1977). “Factors in software quality”. Vols. IIII, Rome Aid Defense Centre, Italy.

MENDES, E., MOSLEY, N. y COUNSELL, S. (2001). “Estimating design and authoring effort”. IEEE MultiMedia, special issue on Web Engineering, January-March, pp. 50-57.

MENDES, E., MOSLEY, N. y COUNSELL, S. (2003). “Early Web Size Measures and Effort Prediction for Web Costimation”. Proceedings of the 9th International Metrics Symposium (METRICS’03). pp. 18-29.

MICROSOFT CORPORATION (2009). “Microsoft Web Design Guidelines”. Disponible en http://www.microsoft.com /spain /empresas /guias /usabilidad /home.mspx [último acceso: Enero 2009]

MORAGA, M.A, CALERO, C., PIATTINI, M. y DIAZ, O. (2007). “Improving a portlet usability model”. Software Quality Control, v.15 n.2, pp. 155-177.

NIELSEN, J. (1993). “Usability Engineering”. Academic Press, London.

NIELSEN, J. (2000). “Usabilidad diseños de sitios Web”. (Ed.): PrenticeHall.

OLSINA, L. (2000). “Quantitative Methodology for Evaluation and Comparison of Web Site Quality”. PhD Thesis, Ciencias Exactas School, UNLP, La Plata, Argentina.

OLSINA, L. y ROSSI, G. (2002). “Measuring Web Application Quality with WebQEM”. IEEE Multimedia, Vol. 9, nº 4, pp. 20-29.

SEFFAH, A., DONYAEE, M., KLINE, R.B. y PADDA, H.K. (2006). “Usability measurement and metrics: A consolidated model”. Software Quality Journal 14(2), pp. 159-178, 2006.

SUN MICROSYSTEMS (2009). Sun Guide to Web Style. Disponible en http://www.sun.com/Webdesign/ [último acceso: Enero 2009]

VAN WELIE, M., VAN DER VEER, G. C. y ELIËNS, A. (1999). “Breaking down Usability”. Proceedings of INTERACT 99, Edinburgh, pp. 613-620.

ANEXO A: MODELO DE USABILIDAD WEB

A continuación se muestra el modelo de usabilidad Web completo indicando las características, subcaracterísticas, atributos, métricas asociadas. Si la métrica se puede aplicar a modelos (M), a la aplicación final (A) o a ambos (M/A) junto a las referencias de los autores que las han propuesto.

Característica Subcaracterística / Atributo Métrica Web Ap. Ref Efectividad del sistema de ayuda M/A [9] Legibilidad del tutorial A [9] Facilidad de uso del sistema de ayuda

A [9]

1.1.1 Completitud de la documentación

Idiomas disponibles* M/A + 1.1.2.1 Capacidad

Efectividad de la documentación del usuario

A [9]

1.1 Facilidad de ayuda

1.1.2 Documenta-ción Multi-usuario

1.1.2.1 Roles

Proporción de usuarios que tengan todas sus acciones contempladas*

A +

1.2.1 Imágenes de enlaces/iconos significativos

Proporción de imágenes escogidas adecuadamente para cada icono o enlace*

M/A +

1.2.2 Títulos de enlaces/iconos significativos

Proporción de títulos escogidos adecuadamente para cada icono o enlace*

M/A +

1.2 Previsibilidad

1.2.3 Determinación de acciones

Número de acciones realizadas con éxito sin acceder al tutorial*

A +

Proporción de elementos indicadores de páginas seguras*

M/A +

Proporción de elementos que muestran progreso en una transacción*

M/A +

1.3 Retroalimentación informativa

Proporción de elementos que muestran el éxito de una operación*

M/A +

1.4.1 Tiempo necesario para recordar

Facilidad de la función de aprendizaje

A [9]

1. Facilidad deaprendizaje

1.4 Facilidad para recordar

1.4.2 Precisión Facilidad de realizar tareas de aprendizaje

A [9]

2.1.1 Tamaño de fuente Tamaños de fuente adecuados a cada contexto*

M/A +

Número de cluster textuales A [11] 2.1.2 Contraste del texto Número de palabras enfatizadas A [11]

2.1 Legibilidad visual

2.1.3 Disposición Número de posicionamiento del texto

A [11]

Proporción de información agrupada por tipo*

M [2]

Centros de asociación semántica M [4] Cohesión* M/A [3]

2.2.1 Información Cohesionada

Acoplamiento* M/A [3] Número de componentes M [4] Número de InfoSlots M [4] Asociación semántica de slots M [4] Centro de colección de slots M [4] Secciones A [4]

2. Facilidadde entendimiento

2.2 Lectura de la información

2.2.2 Densidad de la información

Número de palabras A [11]

Núm. total de animaciones flash A [13] Núm. total de iconos/botones A [13] Duración media de clips de audio A [13] Duración media de clips de video A [13] Número de páginas A [12] Número de elementos multimedia A [12] Número de CGI scripts, archivos JavaScript, Java applets

A [12]

Espacio total usado por la Web A [12] Número de imágenes A [15] Estructura A [12] Complejidad de la página A [12] Complejidad del audio A [12] Complejidad del vídeo A [12] Complejidad de las animaciones A [12] Complejidad de los scripts (CGI scripts, java scripts)

A [12]

2.2.3 Complejidad de la información

Complejidad de los gráficos A [12] 2.3.1 Etiquetas significativas

Proporción de elementos con nombres significativos*

M/A [2]

2.3.2 Internacionalización Núm. comandos estandarizados* M/A +

2.3 Familiaridad

2.3.3 Metáfora Núm. de metáforas reconocidas* M/A + Disponibilidad de demostraciones M/A [9] Funciones evidentes para el usuario A [9] Funciones fáciles de entender por el usuario

A [9]

Entradas/Salidas fáciles de entender

M/A [9]

2.4.1 Brevedad

Disponibilidad de valores por defecto.

M/A [9]

Completitud de descripciones M/A [9]

2.4 Ahorro de esfuerzo

2.4.2 Auto-descriptivo Claridad de elementos de interfaz M/A [9] Proporción de mensajes de error significativos*

M/A [2]

Proporción de mensajes de avisos significativos*

M/A [2]

Legibilidad de los mensajes M/A [9] Mensajes de error auto-explicativos

M/A [9]

2.5.1 Calidad de los mensajes

Claridad de los mensajes M/A [9] Proporción de elementos que muestran estado del usuario en la interfaz*

M/A + 2.5.2 Retroalimentación inmediata

Retroalimentación orientada al sujeto*

A [15]

Núm. de contextos de navegación M [1] Núm. de enlaces de navegación M/A [1] Densidad del mapa de navegación M [1] Profundidad del mapa de navegación

M [1]

Amplitud del mapa de navegación M [1] Camino mínimo entre contextos de navegación

M [1]

Número de caminos entre contextos de navegación

M [1]

2.5 Orientación al usuario

2.5.3 Navegabilidad

Compactness de un mapa de navegación

M [1]

Entradas de un contexto de navegación

M [1]

Salidas de un contexto de navegación

M [1]

Número de nodos de navegación M [1] Nodos M [4] Slots de navegación M [4] Cluster de nodos M [4] Slots de nodos M [4] Clusters M [4] Distancia M [7] Profundidad M [7] Amplitud M [7] Diámetro M [7] Radio M [7] Distancia media de conexión M [7] Densidad de la conectividad A [12] Número total de enlaces A [15] Número de enlaces rotos A [15] Distancia de salida convertida M/A [5] Distancia de entrada convertida M/A [5] Distancia convertida M/A [5] Centralidad relativa de salida M/A [5] Centralidad relativa de entrada M/A [5] Compactness M/A [5]

3.1.1. Facilidad de comenzar a usar

Número de plugins necesarios* A +

3.1.2. Multiplicidad de plataformas

Número de navegadores compatibles*

A +

3.1.3. Actualizable Información actualizada A [6] Número de actualizaciones realizadas por el usuario*

A +

3.1 Facilidad de ejecución

3.1.4. Transparencia de las actualizaciones

Indicador de última actualización* A [15] Información adecuada A [6] Número de propiedades definidas para detectar errores en IU*

M/A [2]

Proporción de patrones aplicados a validación de datos*

M/A [2]

3.2 Validez de los datos

Chequeo de datos introducidos. M/A [9] 3.3.1. Edición posterior Corrección de errores A [9] 3.3.2. Soporte a operaciones de cancelación

Operaciones de usuario cancelables M/A [9]

Adecuación del tiempo de operación al usuario

A [9] 3.3.3. Ejecución explícita

Guías en ejecuciones M/A [9] 3.3.4. Soporte a la interrupción

Número de controles que permiten abortar una acción*

M/A +

3.3.5. Soporte a operaciones de deshacer

Habilidad de deshacer M/A [9]

3.3 Controlabilidad

3.3.6. Soporte a operaciones de rehacer

Número de controles que permiten rehacer una acción*

M/A +

3.4.1. Adaptabilidad Accesibilidad física M/A [9] Personalización M/A [9]

3. Operabilidad

3.4 Capacidad de adaptación 3.4.2. Adaptativo

Reducción de procesos operativos M/A [9]

3.5.1. Comportamiento constante de los controles

Proporción de controles con comportamiento similar en cada interfaz de usuarios UI*

M/A +

Permanencia de controles directos* M/A [15] 3.5.2. Permanencia de los controles Permanencia de controles

indirectos* M/A [15]

3.5.3. Estabilidad de los controles

Estabilidad* A [15]

3.5.4. Consistencia en el orden

Proporción de acciones en el mismo orden a través de IU relacionadas*

M/A [2]

3.5 Consistencia

3.5.5. Consistencia en las etiquetas

Proporción de navegaciones en el mismo orden a través de IU relacionadas*

M/A [2]

3.6.1. Prevención de errores

Tiempo entre errores humanos A [9] 3.6 Gestión de errores

3.6.2. Recuperación ante errores

Recuperación operacional de errores

A [9]

3.7 Monitorización del estado de la Web Capacidad de monitorización del estado

M/A [9]

4.1 Uniformidad del color de fondo Número de colores de fondo M/A [11] 4.2 Uniformidad del color de fuente Número de colores de fuente* M/A + 4.3 Uniformidad del estilo de fuente Estilo de fuente* M/A [11] 4.4 Uniformidad del tamaño de fuente Tamaño medio de fuente* M/A [11] 4.5 Uniformidad de la posición de la interfaz Posición de los marcos de la

interfaz* M/A [11]

Interfaz atractiva A [9] Personalización de la apariencia A [9] Uso frecuente del usuario A [9]

4. Grado deatracción

4.6 Grado de atracción subjetiva

Interacción atractiva A [9] 5.1 Conformidad a la ISO/IEC 25000 SQuaRE

Ratio de satisfacción cubierto A [10]

5.2 Conformidad a la “Microsoft Web Design Guidelines”

Ratio de satisfacción cubierto A [14]

5.3 Conformidad a la “Sun Guide to Web style”

Ratio de satisfacción cubierto A [16]

5. Conformidad

5.4 Conformidad a la “IBM Web Design Guidelines”

Ratio de satisfacción cubierto A [8]

Leyenda: * Métricas que no han sido validadas + Métricas propuestas

Referencias citadas (Ver sección Referencias):

[1] Abrahão et al., 2003 [5] Botafogo et al., 1992 [9] ISO 9126-2,3, 2002 [13] Mendes et al., 2003

[2] Abrahão e Insfran, 2006 [6] Fink, 2001 [10] ISO 25000, 2005 [14] Microsoft C., 2009

[3] Bajaj y Krishnan, 1999 [7] Herder, 2002 [11] Ivory, 2001 [15] Olsina, 2000

[4] Baresi et al., 2003 [8] IBM, 2009 [12] Mendes et al., 2001 [16] Sun Micro. 2009

Tabla V. Modelo de usabilidad Web completo