prometheus: proceso metodológico para desarrollar...

PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSOFACULTAD DE INGENIERÍA

ESCUELA DE INGENIERÍA INFORMÁTICA

PROMETHEUS: PROceso METodológico paradesarrollar HEurísticas de USabilidad

CRISTHY NATALY JIMENEZ GRANIZO

Director de Tesis: Ismael FigueroaCo-Director de Tesis: Héctor Allende Cid

TESIS DE GRADODOCTORADO EN INGENIERÍA INFORMÁTICA

Agosto, 2017

Agradecimientos

Quiero expresar mi profundo agradecimiento a todas y cada una de laspersonas que de una u otra manera contribuyeron para la realización y cul-minación de este trabajo de investigación.

De manera especial agradezco a mis profesores guía y co-guía, Dr. IsmaelFigueroa y Dr. Héctor Allende Cid, por el apoyo incondicional y la predispo-sición brindada, llegando a convertirse en un pilar fundamental para alcanzareste sueño. Gracias in�nitas por compartir conmigo sus conocimientos, ex-periencias y consejos, pero sobretodo gracias por el carisma que poseen ytransmiten, permitiéndome fortalecer mi espíritu y ganar esta batalla deaciertos y fracasos, con las armas de la constancia y el aprendizaje contí-nuo, trazando y construyendo sobre mi propia experiencia el camino haciala consecución de una meta más en mi vida académica.

Mi reconocimiento de gratitud a la Ponti�cia Universidad Católica deValparaíso en especial a las autoridades de la Escuela de Ingeniería Informá-tica, por haberme permitido formarme en sus aulas, con excelentes docentesimpartiendo conocimientos con calidad y entusiasmo.

A la Escuela Superior Politécnica de Chimborazo (ESPOCH-Ecuador)y la Universidad Nacional de Chimborazo (UNACH-Ecuador) por las fa-cilidades prestadas para realización de las actividades de la investigacióndoctoral. A la Secretaría Nacional de Educación Superior, Ciencia y Tecno-logía (SENESCYT-Ecuador), por el apoyo brindado para llevar a cabo misestudios de doctorado.

Finalmente, a Chile porque durante gran parte de mi estadía ahí vivímomentos maravillosos y conocí gente sincera y amigos a quienes llevarésiempre en mi corazón, de manera muy especial a Claudia Riveros por suvalioso apoyo durante mi paso por este hermoso país.

Cristhy Nataly Jiménez Granizo

i

A Emilia por ser el regalo más valioso que Dios me dió y el motor que meimpulsa a seguir y ser mejor cada día

ii

Abstract

Usability is a key discipline related to the development of interactive soft-ware systems. Its goal is to assess the user-friendliness and e�ectiveness of asoftware product from the user point of view. Therefore, proper methodolo-gies and techniques to perform this assessment are de�nitely relevant. Heu-ristic evaluation is probably the most commonly used method for usabilityassessment. Developed initially by Nielsen and Molich in the 90s, traditio-nal heuristic evaluations rely on Nielsen's well-known 10 usability heuristics.However, recent evidence suggests that such heuristics are not su�cientlycomplete for dealing with new domains of application. In addition to thelack of suitability of the traditional heuristics, it has been stated in the pastyears the lack of a robust methodology or process to e�ectively develop andvalidate these new domain-speci�c heuristics. In this thesis, after identifyingand acknowledging existing gaps in the state-of-the-art regarding to the lackof suitability of traditional heuristics, as well as the need of a robust met-hodology for developing them, we present PROMETHEUS, a PROceduralMEThodology for developing HEuristics of USability. PROMETHEUS re-�nes the methodology of Rusu et al. (2011), and is composed of 8 stages.PROMETHEUS clearly de�nes the artifacts that are required and produ-ced by each stage, and also presents a set of quality indicators in order toassess the need for further re�nement in the development of new heuristics.As an initial validation of PROMETHEUS, we analyze the perception ofseveral researchers that have used the methodology of Rusu et al, and wehave also performed a retrospective study, computing the quality indicatorsof several previous studies. Later, we submitted PROMETHEUS to an ex-perimental validation through the empirical application over a real case ofstudy. Empirical validation of PROMETHEUS allowed us develop a newset of speci�c-domain heuristics that were �nally evaluated in order to indi-rectly evaluate the methodology. Our results suggest that PROMETHEUSis a very promising methodology for developing usability heuristics that canbe used in traditional usability evaluation methods for improving their per-formance.

Keywords: Heuristcs, methodology, evaluation methods, emerging techno-logies, usability.

iii

Resumen

La usabilidad es una disciplina clave relacionada con el desarrollo desistemas de software interactivos. El objetivo de la usabilidad es medir lafacilidad de uso y efectividad de un producto software desde el punto devista del usuario. Por lo tanto, contar con metodologías y técnicas adecua-das para realizar esta medición es de�nitivamente relevante. La evaluaciónheurística es probablemente el método más comunmente utilizado para eva-luar usabilidad. Desarrollado inicialmente por Nielsen y Molich en los 90s,las evaluaciones heurísticas tradicionales se basan en las 10 bien conocidasheurísticas de usabilidad de Nielsen. Sin embargo, evidencia reciente sugiereque tales heurísticas no son lo su�cientemente completas para hacer frente alos nuevos dominios de aplicación. Adicionalmente a la falta de adecuaciónde las heurísticas tradicionales, se ha a�rmado en los últimos años la falta deuna metodología o proceso robusto que permita desarrollar y validar efecti-vamente esas nuevas heurísticas de dominio-especí�co. En esta tesis, despuésde identi�car y reconocer las brechas existentes en el estado del arte respec-to a la falta de adecuación de las heurísticas tradicionales y la necesidad deuna metodología robusta de desarrollo, presentamos PROMETHEUS, co-mo un PROceso METodológico para desarrollar HEurísiticas de USabilidad.PROMETHEUS re�na la metodología propuesta por Rusu et al. (2011),y está compuesto de 8 etapas. PROMETHEUS de�ne claramente los arte-factos que son requeridos y producidos en cada una de las etapas y tambiénpresenta un conjunto de indicadores de calidad con el objetivo de evaluar lanecesidad de mayor re�namiento en el desarrollo de nuevas heurísticas. Comovalidación inicial de PROMETHEUS, analizamos la percepción de variosinvestigadores que habían utilizado la metodología de Rusu et al, y tambiénrealizamos un estudio retrospectivo, calculado los indicadores de calidad devarios estudios previos. Posteriormente, sometimos PROMETHEUS a unavalidación experimental a través de la aplicación empírica sobre un caso deestudio real. La validación empírica de PROMETHEUS nos permitió desa-rrollar un nuevo conjunto de heurísticas de dominio especí�co que fueron�nalmente evaluadas con el �n de evaluar indirectamente la metodología.Nuestros resultados sugieren que PROMETHEUS es una metodología muyprometedora para desarrollar heurísticas de usabilidad que puedan ser utili-zados en métodos tradicionales de evaluación, mejorando su rendimiento.

Palabras Clave: Heurísticas, metodología, métodos de evaluación, tecnolo-gías emergentes, usabilidad.

iv

Índice

1. Introducción 1

1.1. Resultados de la Investigación . . . . . . . . . . . . . . . . . . 3

2. Ejemplo Ilustrativo de Evaluación de Usabilidad 5

2.1. Producto a evaluar . . . . . . . . . . . . . . . . . . . . . . . . 52.2. Proceso de evaluación . . . . . . . . . . . . . . . . . . . . . . 52.3. Conlusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3. Marco Teórico 18

3.1. De�niciones de Usabilidad . . . . . . . . . . . . . . . . . . . . 183.2. Métodos de Evaluación de Usabilidad . . . . . . . . . . . . . . 243.3. Método de Evaluación Heurística . . . . . . . . . . . . . . . . 303.4. Cómo se Desarrollan las Heurísticas de Dominio . . . . . . . . 36

3.4.1. Recopilación y Transformación de Información. . . . . 363.4.2. Validación de las Heurísticas. . . . . . . . . . . . . . . 373.4.3. ¾Necesidad de experimentos controlados? . . . . . . . 38

4. Metodología para el Desarrollo de Heurísticas de Usabilidad 40

4.1. Metodología R3C . . . . . . . . . . . . . . . . . . . . . . . . . 404.1.1. Criterio de Evaluación. . . . . . . . . . . . . . . . . . . 41

4.2. PROMETHEUS . . . . . . . . . . . . . . . . . . . . . . . . . 424.2.1. Re�namientos a R3C. . . . . . . . . . . . . . . . . . . 424.2.2. Resumen del Camino Crítico. . . . . . . . . . . . . . . 43

5. Validación de PROMETHEUS 49

5.1. Cuestionario a Investigadores que Usaron R3C . . . . . . . . 495.2. Validación de Indicadores de Calidad . . . . . . . . . . . . . . 525.3. Validación Empírica de PROMETHEUS . . . . . . . . . . . 58

5.3.1. Descripción del Proceso de Validación Empírica. . . . 605.3.2. Análisis Intra-Heuristicas. . . . . . . . . . . . . . . . . 625.3.3. Análisis Inter-Heuristicas. . . . . . . . . . . . . . . . . 71

5.4. Validación Post-experimental . . . . . . . . . . . . . . . . . . 77

6. Conclusiones y trabajos futuros 79

A. Descripción Detallada de PROMETHEUS 92

A.1. Etapa 1: Búsqueda de información especí�ca. . . . . . . . . . 92A.2. Etapa 2: Búsqueda de heurísticas de usabilidad. . . . . . . . . 93A.3. Etapa 3: Especi�cidad de heurísticas. . . . . . . . . . . . . . . 94

v

A.4. Etapa 4: Normalización de heurísticas. . . . . . . . . . . . . . 94A.5. Etapa 5: Priorización de heurísticas. . . . . . . . . . . . . . . 95A.6. Etapa 6: Descripción detallada de heurísticas. . . . . . . . . . 96A.7. Etapas 7 y 8: Validación y Re�namiento. . . . . . . . . . . . . 98

B. Entrevista para validación inicial de PROMETHEUS 100

vi

Lista de Figuras

1. Ejemplo de CUMPLIMIENTO del principio Visibilidad delestado del Sistema. . . . . . . . . . . . . . . . . . . . . . . . . 6

2. Ejemplo de INCLUMPLIMIENTO del principio Visibilidaddel estado del Sistema. . . . . . . . . . . . . . . . . . . . . . . 6

3. Ejemplo de CUMPLIMIENTO del principio Consistencia en-tre el sistema y el mundo real. . . . . . . . . . . . . . . . . . . 7

4. Ejemplo de INCUMPLIMIENTO del principio Consistenciaentre el sistema y el mundo real. . . . . . . . . . . . . . . . . 7

5. Ejemplo de CUMPLIMIENTO del principio Control y libertaddel usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

6. Ejemplo de INCUMPLIMIENTO del principio Control y li-bertad del usuario. . . . . . . . . . . . . . . . . . . . . . . . . 8

7. Ejemplo de CUMPLIMIENTO del principio Consistencia yestándares. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

8. Ejemplo de INCUMPLIMIENTO del principio Consistenciay estándares. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

9. Ejemplo de CUMPLIMIENTO del principio Prevención deerrores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

10. Ejemplo de INCUMPLIMIENTO del principio Prevención deerrores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

11. Ejemplo de CUMPLIMIENTO del principio Reconocer antesque recordar. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

12. Ejemplo de INCUMPLIMIENTO del principio Reconocer an-tes que recordar. . . . . . . . . . . . . . . . . . . . . . . . . . 12

13. Ejemplo de CUMPLIMIENTO del principio Flexibilidad y e�-ciencia en el uso. . . . . . . . . . . . . . . . . . . . . . . . . . 13

14. Ejemplo de INCUMPLIMIENTO del principio Flexibilidad ye�ciencia en el uso. . . . . . . . . . . . . . . . . . . . . . . . . 13

15. Ejemplo de CUMPLIMIENTO del principio Diseño minima-lista y estético. . . . . . . . . . . . . . . . . . . . . . . . . . . 14

16. Ejemplo de INCUMPLIMIENTO del principio Diseño mini-malista y estético. . . . . . . . . . . . . . . . . . . . . . . . . . 14

17. Ejemplo de CUMPLIMIENTO del principio Ayudar a diag-nosticar, reconocer y recuperarse de errores. . . . . . . . . . . 15

18. Ejemplo de INCUMPLIMIENTO del principio Ayudar a diag-nosticar, reconocer y recuperarse de errores. . . . . . . . . . . 16

19. Ejemplo de CUMPLIMIENTO del principio Ayuda y docu-mentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

vii

20. Ejemplo de INCUMPLIMIENTO del principio Ayuda y docu-mentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

21. Diagrama de �ujo del proceso de selección de artículos de larevisión sistemática de literatura. . . . . . . . . . . . . . . . . 34

22. Mapeo entre las etapas de R3C y las de PROMETHEUS. . 4223. Flujo principal de proceso de PROMETHEUS . . . . . . . . . 4424. Visualización de indicadores de calidad en los estudios selec-

cionados donde fue posible su cálculo. . . . . . . . . . . . . . 5825. Número de problemas por conjunto de heurísticas HC y HD . . 6326. Comparación de problemas Totales, Comunes y Únicos entre

las heurísticas HC y HD . . . . . . . . . . . . . . . . . . . . . . 6527. Valores promedio de Severidad y Criticidad por grupo de eva-

luadores, usando HC y HD . . . . . . . . . . . . . . . . . . . . 6728. Distribución de problemas por heurística por grupo de eva-

luadores para las heurísticas de Control y las heurísticas deDominio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

29. Problemas Inter-heuristicas Totales (PT ∗), Comunes (PM ∗)y Únicos(PU ∗) . . . . . . . . . . . . . . . . . . . . . . . . . . 73

30. Severidad de los problemas identi�cados en las heurísticas deDominio y de Control. . . . . . . . . . . . . . . . . . . . . . . 74

31. Dispersión de problemas en HC y HD . . . . . . . . . . . . . . 7632. Problemas Comunes de HC y HD por Heurística de Dominio

Especí�co . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7733. Evaluación de las heurísticas de control (HC ) y heurísticas de

dominio (HD) respecto a las dimensiones de Utilidad, Clari-dad, Facilidad de uso y Necesidad de elementos adicionales. . 79

viii

Lista de Tablas

1. Atributos de usabilidad . . . . . . . . . . . . . . . . . . . . . 232. Clasi�cación de los métodos de evaluación de usabilidad según

Hom [27] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253. Comparación de los métodos de evaluación de usabilidad se-

gún Holzinger [26] . . . . . . . . . . . . . . . . . . . . . . . . 314. Preguntas de investigación para la revisión sistemática de heu-

rísticas de usabilidad [37] . . . . . . . . . . . . . . . . . . . . 335. Resumen de Resultados de la Validación Inicial a PROMET-

HEUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516. Resumen Análisis de E�cacia Heurísticas de Dominio HD vs

Heurísticas de Control HC . . . . . . . . . . . . . . . . . . . . 537. Per�l de los investigadores que participaron en la validación

empírica de PROMETHEUS. . . . . . . . . . . . . . . . . . 598. Mapeo entre las heurísticas para VLEs y las heurísticas de

Nielsen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619. Datos y Resultados del análisis estadístico t . . . . . . . . . . 6410. Datos y Resultados del análisis estadístico de Wilcoxon . . . . 6811. Número de problemas por heurística y por grupos (G), pro-

medio de desviación estándar en HC y HD . . . . . . . . . . . 6912. Resumen del los resultados de análisis estadísticos aplicados

a los parámetros Problemas totales, Problemas comunes, Pro-blemas únicos, Severidad promedio y Criticidad promedio . . 71

13. Promedio de Severidad y Cantidad de problemas por heurís-tica en HC y HD . . . . . . . . . . . . . . . . . . . . . . . . . 75

14. Indicadores de desempeño resultantes del análisis Inter-heurísticas 7715. Resultados de la encuesta post-evaluation de acuerdo a las

dimensiones Utilidad (D1), Claridad (D2), Facilidad de uso(D3) y Necesidad de elementos adicionales de evaluación (D4) 78

16. Ejemplo tabla especi�cidad inicial para contextos de uso . . . 9317. Índices de especi�cidad inicial para heurísticas desnormalizadas 9418. Ejemplo Matriz de Especi�cidad para Heurísticas . . . . . . . 9519. Especi�cidad para contextos de uso y cálculo de GSIUC . . . 9620. Plantilla estándar para describir heurísticas de usabilidad. . . 9721. Preguntas de la entrevista ejecutada en la validación inicial

de PROMETHEUS . . . . . . . . . . . . . . . . . . . . . . . 101

ix

1. Introducción

El constante desarrollo tecnológico se ve re�ejado por la construcción denuevas aplicaciones, muchas de ellas basadas en nuevas tecnologías de infor-mación o tecnologías emergentes llamados también dominios de aplicación, tales como dispositivos móviles, interfaces touch, aplicaciones distribuidas,entornos virtuales de aprendizaje, por nombrar algunas. Las aplicaciones desoftware se caracterizan por pertenecer a un dominio especí�co, que requiereel uso de diversos dispositivos físicos y lógicos para interactuar con ellas, asícomo también son utilizadas bajo contextos de uso especí�cos. Ya que es cadavez más frecuente que usuarios no especialistas requieran acceder y utilizartales aplicaciones de manera habitual, es necesario e importante facilitar laexperiencia de tales usuarios para mejorar sus niveles de satisfacción y dedesempeño en sus tareas. Por ejemplo, la aplicación móvil WhatsApp, quepertenece al dominio de las Aplicaciones de mensajería para smartphones,en su versión móvil puede requerir o utilizar el teclado virtual, pero en suversión web puede requerir el uso de un teclado físico. En esta aplicación,el rango de usuarios va desde puramente novatos hasta aquellos con vastaexperiencia en el uso de aplicaciones de mensajería, por lo que resulta nece-sario garantizar la interacción satisfactoria de los usuarios, cualquiera sea sunivel de experiencia y el o los dispositivos que utiliza para la interacción.

La usabilidad es una disciplina que, en el ámbito de la Ingeniería deSoftware, permite �estimar el grado en que un producto de software puedeser usado por usuarios especí�cos para conseguir objetivos especí�cos conefectividad, e�ciencia y satisfacción en un contexto de uso especí�co� [32].Por lo tanto, una de sus actividades principales es determinar problemas deusabilidad en aplicaciones especí�cas, con el �n de mejorar la calidad deeste atributo en futuras iteraciones. Dados los altos costos de los tests deusabilidad [26], donde se observa y evalúa el comportamiento de usuariosreales, en general se utilizan dos técnicas de menor costo para identi�carproblemas de usabilidad: la indagación y la inspección de usabilidad. Lasindagaciones de usabilidad se caracterizan por un enfoque cualitativo basadoen las opiniones de los usuarios, y contempla métodos como los cuestionarios,estudios de campo, y todo tipo de entrevistas. En cambio, las inspeccionesde usabilidad consisten en examinaciones detalladas realizadas por grupos deevaluadores, que informan sobre problemas especí�cos y generales respectoa una aplicación en particular.

Uno de los métodos de inspección más utilizados es el de evaluaciónheurística, propuesto por Nielsen y Molich [51]. En este método un grupopequeño de 3 a 5 evaluadores inspecciona la usabilidad de un determinado

1

sistema de software, guiados por una lista de criterios de usabilidad conoci-dos como heurísticas de usabilidad [51, 45]. La evaluación heurística es unmétodo de bajo costo, fácil de aplicar, y que puede usarse en diversas etapasdel desarrollo de una aplicación [51]. Es además un método efectivo, puespuede detectar alrededor del 75% de los problemas de usabilidad con gru-pos de 3 a 5 evaluadores [35]. Sin embargo, a pesar de que tradicionalmentelas evaluaciones heurísticas se realizan utilizando como criterios las 10 heu-rísticas de usabilidad de Nielsen [33], emerge cada vez más la necesidad dedesarrollar heurísticas de dominio especí�co, o simplemente heurísticas dedominio. En estudios recientes como el de Hermawati y Lawson [25], Qui-ñonez y Rusu [63] y Jiménez et al [38], se presentaron los resultados de lasrevisiones bibliográ�cas respecto a la existencia, uso y desarrollo de heurísti-cas de usabilidad. Los autores de estos tres trabajos, identi�caron entre otrosaspectos, la carencia y necesidad de una metodología o proceso robusto quepermita desarrollar heurísticas de usabilidad.

Con este antecedente, y tomando como hipótesis la necesidad de desarro-llar una metodología para la creación de heurísticas de usabilidad de dominio-especí�co que permitan mejorar el rendimiento del método tradicional de eva-luación heurística, planteamos como objetivo general el proponer una meto-dología para el desarrollo de heurísticas de usabilidad que permitan mejorar eldesempeño de los métodos tradicionales al evaluar aplicaciones de dominio-especí�co y, establecimos a su vez los siguientes objetivos especí�cos:

Analizar los conceptos de usabilidad, métodos de evaluación para cono-cer cómo se está llevando a cabo el proceso de desarrollo de heurísticasde dominio-especí�co.

Formalizar el proceso metodológico para el desarrollo heurísticas deusabilidad de dominio-especí�co.

Validar la propuesta metodológica a través de su aplicación práctica.

Es así, que sobre la base del estudio de Hermawati y Lawson [25], ytomando en cuenta los resultados de Quiñonez y Rusu [63] y Jiménez etal [38], desarrollamos PROMETHEUS, un PROceso METodológico paradesarrollar HEurísticas de USabilidad enfocado a solucionar los dos grandesproblemas evidenciados en el trabajo de Hermawati y Lawson [25]: (1) gran-des de�ciencias en los esfuerzos de validación de nuevas heurísticas, y (2)falta de rigurosidad, robustez y estandarización en el análisis de efectividadde las heurísticas de dominio. PROMETHEUS surge como un re�namien-to a la metodología existente de Rusu et al [66]�que denominamos R3C

2

en base a las iniciales de sus autores�para dar mayor formalidad, rigor yprecisión al proceso de construcción de nuevas heurísticas de dominio. PRO-METHEUS incorpora 8 etapas, en las que se describe detalladamente lasactividades a realizar, los artefactos esperados y producidos en cada una deellas, y los indicadores de calidad para heurísticas que guían el proceso dere�namiento continuo de las mismas. La propuesta fue validada y los resul-tados obtenidos permitieron corroborar la hipótesis respecto a la necesidaddel establecimiento de este proceso metodológico.

En este trabajo comenzamos presentando como Marco Teórico (Sec-ción 3), la revisión de los principales conceptos de usabilidad (Sección 3.1) ysus métodos de evaluación (Sección 3.2), para luego describir el método deevaluación heurística (Sección 3.3) y realizar una revisión general de cómo sehan generado hasta el momento heurísticas de dominio (Sección 3.4). Pos-teriormente, en el capítulo 3 presentamos la contribución principal de estatesis, que es PROMETHEUS, partiendo con la descripción y el análisis ala metodología R3C sobre la cual surgió nuestra propuesta. En el capítulo 4detallamos el proceso de validación al cual fue sometido PROMETHEUS y�nalizamos con las respectivas conclusiones y trabajos futuros (Sección 6).

1.1. Resultados de la Investigación

El principal resultado de la investigación corresponde fundamentalmen-te al PROceso METodológico para desarrollar HEurísticas de USabilidad(PROMETHEUS) y se mencionan las siguientes publicaciones relacionadasdirectamente con la investigación:

Jimenez, C., Cid, H. A., and Figueroa, I. (2017). PROMETHEUS:Procedural Methodology For Developing Heuristics Of Usability. IEEELatin America Transactions, 15(3), 541-549.

Jimenez C., Lozada P., and Rosas P. (2017). Speci�c-domain usabilityheuristics: Are they really necessary?. Revista Romana de InteractiuneOm-Calculator 10(1), pages 1-24, 2017.

Jimenez C., Lozada P., and Rosas P. (2016). Usability heuristics: Asystematic review. 2016 IEEE 11th Colombian Computing Conference(CCC), Popayan, 2016, pp. 1-8.

Jimenez, C.; Rusu, C.; Roncagliolo, S.; Inostroza, R.; Rusu, V. (2012).Evaluating a Methodology To Establish Usability Heuristics. JornadasChilenas de Computacion (JCC) 2012. The Chilean Computing Society(SCCC)

3

También es necesario mencionar las siguientes publicaciones relacionadasindirectamente con la investigación pero cuyos resultados fueron utilizadosdurante el desarrollo de la investigación.

Jimenez, C.; Rusu, C.; Gorgan, D.; Inostroza, R. (2013). Grid Appli-cations to Process, Supervise and Analyze Earth Science Related Phe-nomena: What About Usability?, Jornadas Chilenas de Computacion(JCC) 2013. The Chilean Computing Society (SCCC).

Jimenez, C. (2012). Usabilidad en Aplicaciones Basadas en NuevasTecnologías, XV Ibero-American Conference on Software Engineering(CIBSE) 2012. Doctoral Simposium

Jimenez, C.; Rusu, C.; Rusu, V.; Roncagliolo, S.; Inostroza, R. (2012).Formal speci�cation of usability heuristics: how convenient it is?, 2ndinternational workshop on Evidential assessment of software technolo-gies (EAST '12). ACM, New York, NY, USA, 55-60.

Adicionalmente, se está preparando un nuevo artículo, correspondiente ala validación empírica de PROMETHEUS.

4

2. Ejemplo Ilustrativo de Evaluación de Usabilidad

El diseño de la interfaz usuario es un elemento clave para el éxito de cual-quier sistema software interactivo. Independiente de la calidad del sistemasubyacente, una interfaz difícil de utilizar provocará reacciones adversas delusuario, las que pueden conducir incluso al rechazo del sistema.

Como parte previa al desarrollo del presente trabajo doctoral, en estasección presentamos un ejemplo de evaluación de usabilidad sobre una cono-cida aplicación de mensajería. Lo que pretendemos es ilustrar el proceso deevaluación de usabilidad, llevando a cabo una breve inspección en base a los10 principios de usabilidad de Nielsen, identi�cando casos de cumplimientoy/o inclumplimiento en la aplicación seleccionada Vs. otra aplicación o sitioweb.

2.1. Producto a evaluar

Aplicación: WhatsApp Versión 2.17.323 1

Descripción: Aplicación de mensajería instantanea para teléfonos in-teligentes, que hace uso de Internet para enviar y recibir mensajes dedistintos tipos y realizar llamadas entre usuarios.

Dominio: La aplicación seleccionada podría ser considerada en dosdominios: Aplicaciones de mensajería o Aplicaciones para smartphones.Al mismo tiempo, podríamos hablar de un dominio que conjugue ambascategorías, como por ejemplo el dominio de Aplicaciones de mensajeríapara smartphones.

2.2. Proceso de evaluación

Se inspeccionó la usabilidad de la aplicación buscando ejemplos de cum-plimiento o incumplimiento de cada uno de los 10 principios heurísticos deNielsen y en cada caso, se describieron los hallazgos. A continuación se pre-sentan las pantallas relacionadas con esta actividad.

1. Visibilidad del estado del sistema: Este principio se re�ere a lacapacidad de la aplicación de mantener informado al usuario respectoa lo que está sucediendo, proporcionando retroalimentación apropiaday en un intervalo de tiempo adecuado. En la Figura 1 podemos ob-servar un ejemplo de cumplimiento de la aplicación Whatsapp, ya que

1www.whatsapp.com

5

una vez iniciado un chat, es posible notar cuando el otro usuario estáescribiendo un mensaje. Por otra parte, en la Figura 2 podemos ver unejemplo de incumplimiento en una aplicación web de gestión educati-va, en la cual no es posible determinar el curso sobre el cual se estátrabajando.

Figura 1: Ejemplo de CUMPLIMIENTO del principio Visibilidad del estadodel Sistema.

Figura 2: Ejemplo de INCLUMPLIMIENTO del principio Visibilidad delestado del Sistema.

2. Consistencia entre el sistema y el mundo real: Este principio sere�ere a la capacidad de la aplicación de manejar un lenguaje apropia-do al usuario, a través de conceptos familiares acordes con el tipo deaplicación y haciendo que la información aparezca en un orden lógicoy natural. En la Figura 3 se muestra un ejemplo de cumplimiento de

6

WhatsApp respecto a este principio, al presentar de manera ordena-da según temporalidad, la interacción sostenida con los otros usuarios.En la Figura 4 en cambio, se muestra un ejemplo de imcumplimientoen una aplicación de gestión educativa en la cual se muestra un añoinconsistente con la realidad de los usuarios de la aplicación

Figura 3: Ejemplo de CUMPLIMIENTO del principio Consistencia entre elsistema y el mundo real.

Figura 4: Ejemplo de INCUMPLIMIENTO del principio Consistencia entreel sistema y el mundo real.

7

3. Control y Libertad del Usuario: Este principio implica brindarmecanismos para deshacer o rehacer acciones durante la interacción.La Figura 5 se muestra un ejemplo de cumplimiento de WhatsApprespecto a este principio, puesto que al elegir la opción �Archivar unaconversaci«�, el usuario puede deshacer la acción en caso de haberlaseleccionado por error. Sin embargo, este mismo principio es inclum-plido cuando se trata de eliminar conversaciones, ya que en este casoWhatsApp no proporciona la opción para deshacer la eliminación, sinoque las elimina inmediatamente tal como se puede ver en la Figura 6

Figura 5: Ejemplo de CUMPLIMIENTO del principio Control y libertad delusuario.

Figura 6: Ejemplo de INCUMPLIMIENTO del principio Control y libertaddel usuario.

8

4. Consistencia y Estándares: Este principio se relaciona con carac-terística de las aplicaciones de usar una plataforma de convencionesestablecidas. La Figura 7 ilustra como WhastApp cumple este princi-pio, ya que sigue la convención de representar las llamadas entrantescon una �echa hacia adentro, mientras que las llamadas salientes las re-presenta con la �echa hacia afuera. Por otra parte, la Figura 8 ilustra elincumplimiento de este principio en una aplicación de gestión médica,ya que en existe inconsistencia en la ubicación del botón �Submit�.

Figura 7: Ejemplo de CUMPLIMIENTO del principio Consistencia y están-dares.

Figura 8: Ejemplo de INCUMPLIMIENTO del principio Consistencia y es-tándares.

9

5. Prevención de Errores: Este principio se re�ere a tener un diseñocuidadoso de la interfaz que prevenga al usuario antes de cometer al-gún error que afecte su interacción con la aplicación. En la Figura 9 sepresenta un ejemplo de cumplimiento de este principio, ya que cuandoel usuario elige la opción de �Eliminar� una conversación, se le presentaun cuadro de con�rmación antes de ejecutar la acción. La Figura 10ilustra un ejemplo de incumplimiento de este principio en una aplica-ción de gestión personal, en la cual el usuario sólo es informado de lanecesidad de llenar todos los campos una vez que ha intentado enviarel formulario.

Figura 9: Ejemplo de CUMPLIMIENTO del principio Prevención de errores.

10

Figura 10: Ejemplo de INCUMPLIMIENTO del principio Prevención deerrores.

6. Reconocer antes que Recordar: Este principio se re�ere a la ca-pacidad de la aplicación de hacer que las acciones, y opciones seanentendidas por el usuario a simple vista, sin que tenga que recordar lafuncionalidad de los elementos o la interacción ejecutada. En la Figura11 se muestra un ejemplo característico de WhatsApp en cumplimientoa este principio, ya que con la implementación de las metáforas visua-les para el envío de mensajes, es posible identi�car cuando un mensajeha sido, entregado, recibido o leído. Por otra parte, la aplicación demensajería Viber presenta un ejemplo de incumplimiento a este prin-cipio, ya que en la parte superior muestra un ícono que no es sugerenteo conocido por los usuarios, principalmente por los usuarios novatos.Este ejemplo se puede apreciar en la 12.

11

Figura 11: Ejemplo de CUMPLIMIENTO del principio Reconocer antes querecordar.

Figura 12: Ejemplo de INCUMPLIMIENTO del principio Reconocer antesque recordar.

7. Flexibilidad y E�ciencia en el Uso: Este principio guarda relacióncon la capacidad de la aplicación de proporcionar atajos o funcionali-dades avanzadas para usuarios expertos, sin que éstos generen confusióen los principiantes. En la Figura 13 se presenta un ejemplo de cum-plimiento de este principio, ya que WhatsApp se adapta a los distintos

12

tipos de usuarios, proporcionándo por ejemplo la posibilidad de serutilizado a través de su opción de aplicación web o de escritorio y nosólo en el entorno de un smartphone. Por otra parte, la aplicación demensajería Snapchat incumple este principio ya que sólamente disponede una interfaz para ser utilizada mediante smartphones, tal como seobserva en la Figura 14

Figura 13: Ejemplo de CUMPLIMIENTO del principio Flexibilidad y e�-ciencia en el uso.

Figura 14: Ejemplo de INCUMPLIMIENTO del principio Flexibilidad y e�-ciencia en el uso.

13

8. Diseño Minimalista y Estético: Este principio se re�ere a lograrque la interfaz sea sencilla, evitando mostrar información irrelevante oinnecesaria. En general, la interfaz y funcionalidades WhatsApp cum-plen este principio y es quizá precisamente esta sencillez lo que haincidido en su éxito. En la Figura 15 se muestra un ejemplo de la sen-cillez en sus menús de opciones. En cambio, en la Figura 16 se muestracomo la aplicación de creación de ávatars Voki, incumple el principio dediseño minimalista, ya que presenta una interfaz sobrecargada dondela publicidad es en ocasiones confundida con opciones del menú.

Figura 15: Ejemplo de CUMPLIMIENTO del principio Diseño minimalistay estético.

Figura 16: Ejemplo de INCUMPLIMIENTO del principio Diseño minima-lista y estético.

14

9. Ayudar a Diagnosticar, Reconocer y Recuperarse de Errores:Este principio se re�ere a la capacidad de la aplicación para expresarlos errores en un lenguaje plano y claro, de modo que los usuariospuedan identi�car la causa y resolverlos sin invertir demasiado tiempoo esfuerzos. En la Figura 17 se muestra un ejemplo de cumplimientode este principio. Así, cuando se intenta realizar una llamada y no setiene disponible la conexión a Internet, WhatsApp informa claramenteal usuario que no se pudo llevar a cabo la acción y sugiere una solucióna este problema. Por otra parte, en la Figura 18, se muestra el errorproducido por una aplicación de gestión académica, cuando no se puedelleva a cabo algún proceso. En este caso, el error no es claro para elusuario ni lo ayuda a enteneder cómo solucionarlo.

Figura 17: Ejemplo de CUMPLIMIENTO del principio Ayudar a diagnosti-car, reconocer y recuperarse de errores.

15

Figura 18: Ejemplo de INCUMPLIMIENTO del principio Ayudar a diagnos-ticar, reconocer y recuperarse de errores.

10. Ayuda y Documentación: Este principio sugiere que las aplicacionesposeer documentación fácilmente accesible, centrada en las tareas delusuario, concreta y no ser demasiado extensa. En la Figura 19 se mues-tra un fragmento de la ayuda que brinda WhatsApp. Como se puedeobservar, el menú de ayuda contiene pocas opciones y la descripción esconcreta. En cambio, en la Figura 20 se muestra como la aplicación degestión académica incumple este principio al no porporcionar ningunaopción de acceso a la ayuda o documentación de la aplicación.

Figura 19: Ejemplo de CUMPLIMIENTO del principio Ayuda y documenta-ción

16

Figura 20: Ejemplo de INCUMPLIMIENTO del principio Ayuda y documen-tación

2.3. Conlusión

Luego de llevar a cabo el ejemplo de inspección de usabilidad en base alos 10 principios de Nielsen, es posible concluir que en términos generales,WhatsApp es una aplicación de mensajería cuya interfaz agradable y senci-lla facilita la interacción al usuario. Aunque no fue difícil encontrar ejemplosde cumplimiento de cada uno de los principios de usabilidad de Nielsen, esposible notar la falta de especi�cidad de estos principios para descubrir as-pectos relacionados directamente con el tipo de aplicación o su dominio enparticular. Así por ejemplo, no fue posible considerar aspectos especí�cosrelacionados con la calidad de transmisión en llamadas de audio o video,la transferencia de imágenes y otros contenidos multimedia, la capacidadde almacenamiento necesaria para los archivos multimedia, la seguridad ocifrado de contenidos durante la transmisión, entre otros aspectos que po-drían surgir y estar estrechamente relacionados con las características de lasaplicaciones de mensajería para smartphones. Este hecho, nos permite con-cluir que aunque los 10 principios de Nielsen ayudan a detectar problemasgenerales de usabilidad en las aplicaciones, resulta necesario proveer mayorespeci�cidad para identi�car problemas característicos del tipo de aplicaciónpara así evitar que sean pasados por alto.

17

3. Marco Teórico

La usabilidad es una disciplina que contempla las actividades, concep-tos y procesos que permitan el diseño de interfaces procurando satisfacer lasnecesidades de información de los usuarios de manera rápida y e�caz [23].Desde su aparición en la década de los 80's su desarrollo se ha centrado enestablecer principios o consideraciones de diseño, estándares, métodos y he-rramientas de evaluación e incluso procesos de ingeniería de usabilidad [74].Son diversos los autores que con sus trabajos han contribuido al desarrollode esta disciplina, pero sin duda uno de los grandes colaboradores ha sidoJakob Nielsen [35], quien ha contribuido signi�cativamente a desarrollar elmétodo de evaluación heurística en base a un conjunto de diez principiosgenerales de usabilidad, que aún siguen siendo ampliamente usados. Actual-mente, en la literatura se puede encontrar una vasta cantidad de trabajosde investigación de varios años atrás, dentro del área de la usabilidad, comopor ejemplo aquellos que fueron analizados y recopilados por Hermawati yLawson [25] o Quiñones y Rusu [63] por citar algunos. Algunos de los tra-bajos se re�eren a estudios de usabilidad de diversos tipos de aplicacionesutilizando métodos y elementos tradicionales de usabilidad, mientras que enotros es posible encontrar que estos conceptos o elementos han sido contex-tualizados a las diferentes áreas de estudio como por ejemplo grid computing[65], e-government [21], televisión interactiva [56], mundos virtuales [62],entre otros.

3.1. De�niciones de Usabilidad

Tal como lo cita la literatura, fue en la década de los 80 cuando se empleópor primera vez el término usabilidad [13]. Algunos autores señalan a Gouldy Lewis como los pioneros en utilizar este término durante la presentaciónde su artículo titulado �Designing for usability: Key Principles and WhatDesigners Think' ' en la conferencia enfocada a la relación de los factoreshumanos con los sistemas de computación, organizada por el Grupo Especialde Interés en Interacción Persona-Computador (SIGCHI por sus siglas eninglés) [19].

Fue en esa misma década, que a través de las conferencias anuales deSIGCHI continuaron apareciendo cada vez más trabajos relacionados con elhasta ese entonces poco conocido término �usabilidad�, que generalmente erautilizado para señalar la cualidad que tiene un producto, objeto o serviciopara ser usado con facilidad; pero que posteriormente obtuvo de�nicionesformales enunciadas por diversos autores y organismos.

18

a) De�nición ISO 9241

El estándar ISO 9241 [32] describe los requisitos ergonómicos para tra-bajo de o�cina con terminales de despliegue visual y explica algunosde los principios básicos subyacentes. Una extensión de este estándares ISO/DIS 9241-11, que establece lineamientos para especi�car y me-dir la usabilidad de productos y los factores que tienen efecto en ella.Según este estándar, la usabilidad se de�ne como [32]

�Medida en la que un producto puede ser usado por un grupo deusuarios determinados, para conseguir objetivos especí�cos con

efectividad, e�ciencia y satisfacción en un contexto de uso especí�co�

Donde:

Efectividad: es la exactitud con la que usuarios especí�cos logranobjetivos especí�cos en un ambiente en particular.

E�ciencia: se re�ere a los recursos empleados con relación a laexactitud de los objetivos logrados.

Satisfacción: es la comodidad y aceptabilidad del sistema detrabajo por parte de los usuarios y de las demás personas que seven afectadas por su uso.

Esta de�nición es sin duda una de las más aceptadas. No obstante alhablar de la usabilidad como una medida, se tiende a tomarla comouna propiedad cuantitativa de un producto, una medida que debe obte-nerse teniendo como base muy importante la característica cualitativade satisfacción al momento de ser usado. En base a esto, surgen du-das acerca de cómo cuanti�car algo que tiene componentes subjetivos.¾Cómo medir con mayor objetividad que algo es fácil o difícil de uti-lizar, si la usabilidad tiene que ver directamente con la percepción delos usuarios?

b) De�nición ISO�IEC 9126

De acuerdo al estándar ISO�IEC 9126 (Software Product Evaluation- Quality Characteristics and Guidelines for the User) [14], la usabili-dad se de�ne como:

�La capacidad de un software de ser comprendido, aprendido, usado yser atractivo para el usuario, en condiciones especí�cas de uso�

19

Este estándar ubica a la usabilidad como parte de la calidad del soft-ware, siendo ésta última de�nida en el estándar como: �Un conjunto deatributos de software que se sostienen en el esfuerzo necesitado para eluso y en la valoración individual de tal uso por un conjunto de usuariosdeclarados o implicados�.Aquí, la usabilidad es analizada en términos de su comprensibilidad,aprendizaje, operabilidad, atractividad y complacencia, tal como sedescribe a continuación:

Comprensibilidad: capacidad del producto software para per-mitir al usuario entender si el software es adecuado, y cómo puedeser usado para tareas y condiciones de uso particulares.

Aprendizaje: capacidad del producto software para permitir alos usuarios aprender a usar sus aplicaciones.

Operabilidad: capacidad del producto software para permitir alusuario operarlo y controlarlo.

Atractivo: capacidad del producto software para ser atractivoal usuario. Se re�ere principalmente al uso de colores y diseñográ�co del producto.

Conformidad a estándares y pautas: capacidad del productosoftware para adherirse a estándares, convenciones, guías de estiloo regulaciones relacionadas con la usabilidad.

Esta de�nición considera a la usabilidad más directamente relacionadacon la interfaz del usuario, incluye el término atractivo pero involu-cra además otros elementos que implican ser medidos o determinadosy que de alguna manera pueden ser valorados a través de elementoscuantitativos.

c) De�nición de Nielsen

Según Jakob Nielsen [35], la usabilidad es un término multidimensionalque mide la facilidad de uso de las interfaces de sistemas interactivos através de cinco atributos básicos: Capacidad de aprendizaje, e�cienciaen el uso, facilidad de recordar, tolerancia a errores y satisfacción sub-jetiva. Estos atributos de usabilidad corresponden a características delos sistemas interactivos que pueden ser medidos en términos cuantita-tivos; restándole de esta forma la subjetividad que involucra analizarla usabilidad de un sistema (Ver Tabla 1).

20

d) De�nición de Rogers et al. .Una de las de�niciones más cortas y posiblemente la más intuitiva esla desarrollada por Rogers et al. [64], en cuyo texto se de�ne a lausabilidad como:

�El desarrollo de productos interactivos fáciles, efectivos y agradablesde usar desde la perspectiva de los usuarios�

En esta de�nición se considera como un producto interactivo, a to-da clase de sistemas interactivos, tecnologías, entornos, herramientas,aplicaciones, servicios y dispositivos.

e) De�nición de Bevan

El experto en usabilidad con más de 15 años de experiencia en prestarservicios de consultoría de usabilidad Nigel Bevan, ha contribuido enla elaboración de muchas de las normas internacionales de usabilidad.Para Bevan et al. [52] la usabilidad se de�ne como:

�La facilidad de uso y la aceptabilidad de un producto para una claseparticular de usuarios que llevan a cabo tareas especí�cas en un

entorno especí�co�

En su trabajo �What is Usability?� [52], Bevan menciona que el tér-mino usabilidad apareció para reemplazar al concepto user-friendly,ya que había empezado a adquirir una serie de connotaciones vagas ysubjetivas.

f) De�nición de Krug

Otro profesional, experto en consultorías de usabilidad es Steve Krug,quien ha sido mejor conocido por su libro �No me hagas pensar: Unaaproximación a la usabilidad�, en el cual a través de un lenguaje notécnico y gran cantidad de ilustraciones orienta al lector respecto aldesarrollo de aplicaciones usables. Krug [42] mani�esta que:

�La usabilidad realmente signi�ca estar seguro de que algo funcionabien: que una persona con habilidades promedio, e incluso por debajodel promedio, pueda utilizar una cosa, ya sea un sitio web, un jet decombate, o una puerta rotatoria, para su �n sin terminar enormementefrustrado�

21

A través de las de�niciones citadas, es posible identi�car el esfuerzo devarios autores por tratar de de�nir la usabilidad desde sus propios puntos devista. Al realizar el análisis de todas estas de�niciones, se puede apreciar quela característica común entre ellas, es que enfatizan que la usabilidad de unsistema, es una medida de las percepciones de los usuarios que los utilizanbajo determinadas condiciones y contextos especí�cos de uso.

Aunque la de�nición ISO 9241 es una de las más aceptadas debido a susencillez y a que engloba tres características fundamentales de la usabilidad(efectividad, e�ciencia y satisfacción), la de�nición de Krug va más allá desimplemente mencionar al usuario como un ente general. En su de�nición,Krug enfatiza que los usuarios poseen distinto nivel en sus habilidades y queun sistema usable debería funcionar bien en cada caso.

En general, todas estas estas de�niciones se centran en analizar la faci-lidad de uso de un sistema interactivo, que es desarrollado para cumplir losobjetivos especí�cos de los usuarios. Es precisamente esa especi�cidad de usode los diferentes sistemas, lo que ha propiciado llegar a un cuestionamientorespecto a la aplicabilidad del clásico concepto de usabilidad en todos losdominios de las aplicaciones. Con el constante desarrollo tecnológico, las ca-racterísticas especí�cas de cada dominio de aplicación, han llegado a jugarun papel fundamental al momento de evaluar la usabilidad de los sistemas.Por lo tanto, considerando este aspecto de características particulares de lasaplicaciones, la usabilidad podría de�nirse como:

�El nivel de satisfacción que obtienen los usuarios, al interactuar con unsistema de software para cumplir sus objetivos especí�cos sin que la

especi�cidad de las características propias de los dominios de aplicación,inter�era en el desempeño de las tareas de los usuarios�.

Si bien el hablar de satisfacción de los usuarios ubica a la usabilidadcomo una disciplina subjetiva, existen elementos de usabilidad que han ser-vido como parámetros de medición de manera objetiva. Es así que Nielsen[35], considerando que la usabilidad es un concepto multidimensional, pro-puso un conjunto de cinco atributos que permiten caracterizar la usabilidaden términos �cuantitativos". La Tabla 1 resume los atributos de usabilidadpropuestos por Nielsen, especi�cando la medida cuantitativa de cada uno deellos.

Finalmente, es importante destacar que tal como lo menciona Molina[47], �la usabilidad, a través de sus atributos, no puede ser medida en abs-tracto (a priori), sino que debe ser validada a través de estudios empíricos(a posteriori)�.

22

Tabla 1: Atributos de usabilidad

Atributo Descripción Medida cuantitativaFacilidad deAprendizaje

Qué tan fácil de entenderes un sistema para que elusuario pueda empezar atrabajar con él inmediata-mente

Tiempo necesario paracumplir ciertas tareas

E�ciencia Productividad alcanzadauna vez que el usuario haaprendido a trabajar conel sistema.

Tiempo necesario para queusuarios �expertos� puedancumplir tareas típicas.

Facilidad deRecordar

Un usuario ocasional pue-de trabajar con un sistemadespués de un período deno haberlo utilizado, sin te-ner que volver a aprender autilizarlo.

Tiempo necesario para queusuarios ocasionales pue-dan cumplir tareas especí-�cas.

Errores Evitar que los usuarios co-metan errores al usar el sis-tema, pero si lo hacen, de-ben poder recuperarse fá-cilmente.

Número de ocurrencia deerrores en tareas típicas.

SatisfacciónSubjetiva

Usuarios que les agrada elsistema y se sienten sub-jetivamente satisfechos alutilizarlo.

Evaluación estadística decuestionarios aplicados alos usuarios.

23

3.2. Métodos de Evaluación de Usabilidad

En la actualidad, existen diversos métodos para evaluar la usabilidad deun sistema de software interactivo. Los diferentes métodos han sido propues-tos y clasi�cados por diversos autores, atendiendo a criterios como el gradode implicación del usuario, los objetivos de la evaluación y el empleo de reglasde usabilidad.

Lograr que un producto tenga usabilidad es conseguir que pueda satisfa-cer las necesidades de los usuarios especí�cos, con e�cacia y e�ciencia en uncontexto de uso especí�co. Aunque el concepto de usabilidad resulta fácil deasimilar, conseguir que un producto llegue a ser fácil de usar es una tareacompleja que implica cierto nivel de di�cultad y varias iteraciones para lo-grarlo. Las evaluaciones de usabilidad se constituyen en el medio a través delcual se puede determinar si un producto o sistema es o no �usable�. Además,los resultados que se obtienen de las evaluaciones de usabilidad constituyenun material valioso que apoya a los desarrolladores en el diagnóstico y correc-ción de errores que impiden la satisfacción de los usuarios que interactúancon el sistema o aplicación.

Evaluar la usabilidad de un sistema, es analizar a los usuarios y el entornobajo el cual utilizan un determinado producto de sofware. Según Lorés et al.[44], �la evaluación de usabilidad comprende un conjunto de metodologías ytécnicas que analizan la usabilidad de un sistema interactivo en diferentesetapas del ciclo de vida�. Por los tanto, si las evaluaciones de usabilidad lo-gran ser integradas durante todo el proceso de desarrollo de software, encierta medida se estará trabajando para que los productos que se obtenganproduzcan mayor satisfacción al usuario reduciendo la necesidad de entrena-miento y minimizando costos de mantenimiento o rediseño del producto.

El costo asociado al fracaso de un producto debido a la insatisfacción delos usuarios �nales es considerable respecto al costo de invertir en evaluacio-nes de usabilidad previas a la entrega del producto [17], [22]. Es importanteseñalar, que aunque algunos métodos de evaluación pueden requerir un com-pleto y complejo laboratorio de usabilidad, otros sin embargo, pueden serllevados a cabo con una inversión relativamente pequeña y producirán resul-tados igualmente con�ables.

El propósito de llevar a cabo evaluaciones de usabilidad es medir o juzgaruno o más de sus atributos y en base a ello emitir criterios acerca de lafacilidad de uso de un producto e inferir el éxito e impacto que tendrá en losusuarios. Según Alva [2], las evaluaciones de usabilidad apuntan a conseguiral menos los siguientes propósitos:

1. Proporcionar retroalimentación para mejorar el diseño.

24

2. Veri�car que los objetivos de usuarios y organizaciones están siendologrados.

3. Monitorear el uso de productos o sistemas a largo plazo

No existe una clasi�cación única y rígida de los métodos de evaluaciónde usabilidad. Así por ejemplo, en [27], Hom realiza una clasi�cación de23 técnicas de evaluación, categorizadas en 4 grandes grupos: Métodos deIndagación, Métodos de Inspección, Métodos de Test y Técnicas Auxiliares.Los métodos de indagación utilizan técnicas de conversación con los usua-rios, observación en entornos de trabajo reales y obtención de respuestasa preguntas ya sea de manera verbal o escrita. Los Métodos de Inspecciónestán basados en la evaluación por parte de expertos, los cuales inspeccio-nan o examinan aspectos relacionados con la usabilidad de la interfaz. Losevaluadores expertos pueden ser especialistas en usabilidad, consultores dedesarrollo interfaces, usuarios �nales con conocimientos del tipo de aplica-ción; o incluso otro tipo de profesionales. Los Métodos de Test son llevadosa cabo por usuarios representativos, que realizan tareas utilizando el siste-ma y cuyo desempeño es analizado por uno o más evaluadores que debendeterminar si la interfaz apoya a los usuarios en la consecución de las tareasasignadas. Finalmente, las Técnicas Auxiliares no están diseñadas especí�-camente para evaluar la usabilidad de un sistema, sino que apoyan en laejecución de los distintos métodos y técnicas de evaluación de usabilidad. Enla Tabla 2 se presenta una breve descripción de la clasi�cación de métodosy técnicas de evaluación de usabilidad enunciada por Hom [27].

Tabla 2: Clasi�cación de los métodos de evaluación de usabi-lidad según Hom [27]

Categoría Nombre Descripción

Métodos deIndagación

Aproximacióncontextual

Consiste en una entrevista de campo es-tructurada. Especialmente aprovecha-ble en las primeras fases de desarrollo.No requiere laboratorios especializadosde usabilidad

Continúa en la siguiente página...

25

Categoría Nombre DescripciónEstudio etno-grá�co

Consiste en la observación del desempe-ño de los usuarios con el sistema dentrode su propio entorno de trabajo, no enun laboratorio. Comunmente utilizadoen las primeras fases del desarrollo pa-ra conocer factores del entorno laboralque puedan afectar a la utilización deun sistema

Aproximaciónpor grupos

Consiste en realizar entrevistas formal-mente programadas a grupos completosde usuarios, fomentando el intercambioy discusión de ideas para extraer con-clusiones respecto a aspectos concretosdel sistema que se evalúa.

Cuestionarios Son listas de preguntas que se entregana los usuarios para que las respondan.No se interactúa directamente con losusuarios quienes deben invertir tiempoadicional en leer y contestar las pregun-tas.

Encuestas Son entrevistas interactivas no necesa-riamente estructuradas que se realizana los usuarios, quienes deben responderuna lista de preguntas y sus respuestasson registradas

Aproximaciónindividual

Consiste en realizar entrevistas perso-nales a usuarios, quienes responden aun cuestionario de preguntas estableci-das. La aproximación no es estructura-da ni formalmente organizada, pero de-be ser cuidadosamente elaborada.

Capturas depantalla

Consiste realizar capturas de pantallaen diferentes momentos durante la eje-cución de las tareas de interacción.


26

Categoría Nombre DescripciónSesiones cap-turadas

Consisten en grabar a distancia las ac-ciones que realizan los usuarios mien-tras interactúan con el sistema. El prin-cipal inconveniente es que no permitecaptar las sensaciones, comentarios ysentimientos del usuario durante su in-teracción.

Logs auto-reportados

Consiste en un tipo de evaluación quese realizan a distancia, donde los usua-rios describen en formularios de papelespecí�camente diseñados, la secuenciade acciones llevadas a cabo para reali-zar cada una de las tareas solicitadas.

Métodos deInspección

Evaluaciónheurística

Consiste en que un conjunto de espe-cialistas de usabilidad juzgan cada ele-mentos de la interfaz de usuario, si-guiendo una lista de principios de usa-bilidad establecidos, conocidos comoheurísticas.

Recorrido cog-nitivo

Consiste en que a través de escenarios,un grupo de evaluadores analizan laaplicación buscando formas de mejorarel aprendizaje y facilidad de uso. Losevaluadores se enfocan en los procesoscognitivos y percepciones de los usua-rios para determinar los cambios quedeben ser realizados.

InspeccionesFormales

Consiste tomar la metodología de eva-luación de software y adaptarla a eva-luación de usabilidad. Básicamente setrata de una inspección de código queprovee mediciones cuantitativas quepueden ser analizadas de manera esta-dística.


27

Categoría Nombre DescripciónRecorridospluralistas

Consiste en reuniones en las cualesusuarios, desarrolladores y profesiona-les de atraviezan un escenario de tareas,discutiendo y evaluando cada elementode interacción.

Inspección deCaracterísticas

Consiste en analizar sólo el conjunto decaracterísticas de un producto en basea escenarios de usuarios, para al �nalestablecer la utilidad del producto.

Inspección deConsistencia

Consiste en garantizar la coherencia en-tre múltiples productos del mismo desa-rrollo. Un especialista analiza la usabi-lidad de los múltiples productos deter-minando consistencia entre las funcio-nes implementadas.

Inspección deEstándares

Consiste en que un profesional con vas-tos conocimientos en estándares, anali-ze y determine que los elementos de lala interfaz cumplen los estándares de�-nidos.

Listas de veri�-cación

Consiste en asegurar que los principiosde usabilidad son considerados en el di-seño. Generalmente, esta técnica usanlos especialistas cuando llevan a inspec-ciones de la interfaz del software.

Métodos deTest

Pensamientoen voz alta

Consiste en solicitrle al usuario que ver-balice sus pensamientos, sentimientos yopiniones mientras interactúa con el sis-tema a través de un escenario de tareas.

Co-Descubrimiento

Consiste en que dos usuarios interac-túan juntos con el sistema, para reali-zar un conjutno de tareas mientras es-tán siendo observados.

Preguntas yRespuestas

Consiste en realizar directamente pre-guntas respecto al sistema a los usua-rios durante la ejecución de sus tareas.


28

Categoría Nombre DescripciónMedidas derendimiento

Son utilizadas para determinar datoscuantitativos. La mayoría de veces, es-tos datos corresponden a métricas derendimiento, que son utilizadas a me-nudo como metas durante el diseño delproducto.

Eye-tracking Consisten en identi�car lo que los usua-rios observan mientras interactúan conel sistema. Requieren la utilización deequipos especializados por lo que resul-tan costosos de llevar a cabo.

TécnicasAuxiliares

Prototipado Consiste en elaborar modelos del pro-ducto �nal y probar sus característicasincluso antes de que el sistema esté fun-cionando.

Diagramas dea�nidad

Consiste en que los usuarios ordenanvarios conceptos en mútiples categoríaspara lograr establecer la relación natu-ral entre los elementos de la interfaz.

Votación ciega Consiste en un sistema de votación gru-pal que evita la in�uencia de unos usua-rios sobre otros. Se puede llevar a caboobteniendo de manera anónima la res-puesta de cada individuo que participade la votación.

Card-Sorting Consiste la organización de informacióny elementos representados a través detarjetas que representan las diferentesopciones o menús que contendrá el sis-tema.

Como se puede observar en la Tabla 2, la clasi�cación de Hom [27] esextensa y no existe una separación adecuada o delimitación respecto a lo quepuede ser considerado como un método o una técnica. Así, es posible observarque varias de las alternativas presentadas por este autor como métodos deevaluación corresponden en realidad a técnicas complementarias o de apoyoa otros métodos descritos. Tal es el caso de las listas de veri�cación que sonsimplemente material de apoyo para la ejecución de la evaluación heurística

29

por ejemplo.Por su parte, Holzinger [26] presenta una clasi�cación simple de los mé-

todos de evaluación de usabilidad, separándolos en dos categorías básicas:métodos de inspección y métodos de test. Las inspecciones son típicamenterealizadas por expertos de usabilidad, mientras que los tests son métodos deevaluación empírica llevados a cabo por usuarios representativos. Los 6 mé-todos de evaluación de usabilidad mencionados por Holzinger [26] incluyen 5de los métodos establecidos en la clasi�cación de Hom [27]: Recorrido cogni-tivo, Evaluación heurística, Pensamiento en voz alta, Observación de campoy Cuestionarios. El sexto método corresponde a un método de inspeccióndenominado Análisis de acciones, que consiste en un análisis formal de lasecuencia de acciones ejecutadas por los usuarios para completar las tareasasignadas. En la Tabla 3, se presenta la comparación de los métodos de eva-luación realizada por Holzinger [27] en base a distintos atributos como: laetapa de aplicación, el tiempo requerido, la cantidad de usuarios necesaria,la cantidad de evaluadores necesaria, el equipamiento requerido, el nivel deexpertise de los evaluadores y la intrusividad del método. Es posible observara partir de la Tabla 3, que el método que probablemente mayores ventajaso fortalezas presenta, es el método de evaluación heurística. Este método,destaca entre los demás debido a su simplicidad y bajo costo de aplicaciónya que, puede ser aplicado en cualquier etapa del desarrollo, su ejecución norequiere una gran cantidad de tiempo, no necesita usuarios reales, requierecomo mínimo únicamente 3 especialistas, requiere poco equipamiento, el ex-pertise de los evaluadores puede ser moderado, y no es un método intrusivo.

Sin duda, la amplia gama de métodos de evaluación proporciona distintasalternativas para evaluar un sistema o producto software y de esta maneratratar de garantizar la aceptación del usuario por el sistema o producto quese está desarrollando o se ha desarrollado.

Tal como lo a�rma Otaíza [54], en su análisis comparativo de los méto-dos de evaluación de usabilidad, �cada uno de los métodos tiene sus propiascaracterísticas, ventajas y desventajas que lo diferencian de los otros, lo quepermite captar las fortalezas y debilidades que determinarán cuándo y bajoqué parámetros será conveniente seleccionar uno de los métodos en lugar deotros�.

3.3. Método de Evaluación Heurística

El método de evaluación heurística fue desarrollado por Nielsen y Molichen 1990 [51], y consiste en una evaluación sistemática en la que variosevaluadores expertos o especialistas, analizan la interfaz del sistema en base

30

Tabla 3: Comparación de los métodos de evaluación de usabilidad segúnHolzinger [26]

a un conjunto de heurísticas de usabilidad reconocidas. El objetivo de laevaluación heurística es descubrir problemas de usabilidad en el diseño dela interfaz de usuario, de tal manera que puedan ser solucionados a tiempocomo parte del proceso de desarrollo iterativo de software.

De acuerdo al protocolo de evaluación heurística propuesto por Nielseny Molich [51], el método de evaluación heurística requiere la participaciónde entre 3 y 5 evaluadores expertos o especialistas, que son coordinadospor una persona encargada de veri�car el desarrollo sistemático del procesode evaluación. Así, la evaluación heurística, requiere como etapa inicial elanálisis individual de la interfaz del producto, por parte de cada uno de losevaluadores participantes. A los evaluadores se les encarga analizar el sistemaprimero de forma general y luego en detalle, tratando de descubrir problemasde usabilidad en la interfaz. Al �nalizar esta etapa, los evaluadores entreganal coordinador los conjuntos de problemas identi�cados para que puedan sertransformados en un listado único que no contenga problemas repetidos osolapados.

Durante la siguiente etapa, el coordinador entrega a cada uno de losevaluadores, el listado único de problemas y les solicita asignar a cada unode ellos, cali�caciones en una escala entre 1 y 4, respecto a la Severidad yFrecuencia de ocurrencia de cada problema. Posteriormente, en base a estascali�caciones, se calcula la Criticidad de cada problema, como la suma de

31

los valores de Severidad y Frecuencia de ocurrencia.Como resultado del proceso de evaluación heurística, se obtiene el conjun-

to de problemas de diseño de la interfaz que, en otras palabras, representanla vulneración de alguno de los principios o heurísticas de usabilidad consi-derada.

Tal como se había mencionado en la sección anterior (Sección 3.2), una delas ventajas del método de evaluación heurística es el corto tiempo requeridopara su realización. Así, una típica sesión de evaluación heurística puedecompletarse entre aproximadamente 1 y 2 horas. En ocasiones, cuando serequiere la evaluación de un producto complejo o extenso, es recomendabledividir el proceso de evaluación en varias sesiones diferentes de acuerdo afuncionalidades o módulos establecidos [51].

Probablemente, una de las principales desventajas de la evaluación heu-rística es la posibilidad de omitir problemas especí�cos del dominio cuandono se usa un conjunto adecuado de heurísticas, que sea representativo de lascaracterísticas especí�cas de las aplicaciones [20]. El método de evaluaciónheurística ha sido por años adaptado a distintos contextos de aplicación. Asípor ejemplo, Pierotti [59], González [18] e Inostroza [29]; realizaron adap-taciones a los principios, la forma de evaluar los problemas y, las etapas delmétodo de evaluación heurística respectivamente. El objetivo de estas adap-taciones era lograr que este método de evaluación se ajuste a las necesidadesde evaluación en sus correspondientes estudios.

De lo anterior se deriva, que el conjunto de heuristicas de usabilidad uti-lizado en el método de evaluación heurística, juega un paper fundamentalpara su desempeño. Tal como fue validado en [39], dependiendo de la �expe-riencia� de los evaluadores y la �especi�cidad� de la aplicación a ser evaluada,un conjunto más especí�co o al menos más detallado de heurísticas podríaser necesario.

Junto con el método de evaluación heurística, Nielsen [35] proporcionóun conjunto de 10 heurísticas generales de usabilidad que incluso hoy en díasiguen siendo ampliamente utilizadas [69]. Sin embargo, otras propuestas deheurísticas se han ido desarrollando contínuamente con el objetivo de cubrirlas características especí�cas de los diferentes dominios de aplicación. Con elobjetivo de categorizar y resumir el conocimiento generado respecto al desa-rrollo y uso de heurísticas de usabilidad en diferentes dominios de aplicación,se llevó a cabo una una revisión sistemática de literatura a través de la cualse logró determinar ciertos conjuntos de heurísticas especí�cas existentes y elproceso a través del cual fueron generadas. El proceso de revisión sistemáticase llevó a cabo bajo los lineamientos de las ocho etapas propuestas por Okoliet al. [53], que en general, constituyen un desglose de las tres etapas de

32

revisión sistemática presentadas por Kitchenham y Charters [40], y se esta-blecieron como base un conjunto de 4 preguntas de investigación, las cualesson presentadas en la Tabla 4 junto con la motivación de su planteamiento.

Tabla 4: Preguntas de investigación para la revisión sistemática de heurísticasde usabilidad [37]

Pregunta de Investigación Motivación

1. ¾Cuáles conjuntos de heurísti-cas están siendo utilizados paraevaluar la usabilidad de los siste-mas de software?

Identi�car la existencia y uso dedistintos conjuntos de heurísticas

2. ¾Qué piensan los evaluadoresrespecto a la utilidad de las heu-rísticas

Resumir ventajas y desventajasde los conjuntos de heurísticasidenti�cados

3. ¾Qué procesos metodológicosexisten para desarrollar heurísti-cas de usabilidad?

Detectar procesos a partir de loscuales se desarrollan las heurísti-cas de usabilidad

4. ¾Qué tipo de validación es uti-lizada para analizar el desempeñode las heurísticas de usabilidad?

De�nir procesos exitosos para va-lidar las heurísticas de usabilidad

La revisión de literatura consideró como fuente de información primaria,el catálogo de artículos cientí�cos ScienceDirect. Se recolectaron artículoscomprendidos en un período de 7 años (2008 - 2015) debido a que se consideróque ese período de tiempo proporcionaría el conocimiento su�ciente respectoal desarrollo y actualización de las heurísticas de usabilidad.

El protocolo de la revisión de literatura consideró la búsqueda de todoslos artículos que tenían relación con la cadena �heurísticas de usabilidad�.Como resultado de esta etapa se obtuvo un conjunto de potenciales artículosque posteriormente pasaron por un proceso de inclusión-exclusión en basea un conjunto de criterios relacionados con las preguntas de investigaciónde�nidas en la tabla 4.

Los artículos que superaron el proceso de inclusión-excusión, fueron so-metidos un proceso de extracción de información en base a distintos criteriosque permitiría analizar y responder las preguntas de investigación de la ta-bla 4. Finalmente, los resultados fueron sintetizados para cada pregunta deinvestigación.

Durante la primera etapa de la revisión, se obtuvo un total de 124 estu-

33

Estudios potenciales124 artículos

¿Superaron el proceso de

Inclusión-Exclusión?

Excluídos: 59 artículos

¿Superaron el proceso de Extracción

de Información?

Excluídos: 8 artículos

Incluídos: 65 artículos

Total de artículos incluídos:

57 artículos

NO

NO

SI

SI

Figura 21: Diagrama de �ujo del proceso de selección de artículos de larevisión sistemática de literatura.

34

dios primarios potenciales para ser analizados. Sólo 65 artículos superaronel proceso de inclusión-exlusión debido a que los 59 excluídos no conteníaninformación relevante consistente con el propósito de la revisión. Los 65 ar-tículos fueron sometidos a un proceso de extracción de información pararesponder a las preguntas de investigación presentadas en la Tabla 4. Du-rante este proceso, un total de 8 artículos fueron excluidos ya que no porpor-cionaban información relevante para ninguna de las preguntas planteadas,obteniéndose un total de 57 artículos �nalmente incluídos en el estudio. LaFigura 21 diagrama el �ujo del proceso de selección de artículos de la revi-sión sistemática realizada. La descripción completa del proceso de revisiónsistemática así como los resultados obtenidos fueron publicados en [37] y[38], sin embargo, a continuación se resumen los principales hallazgos:

Las heurísticas de Nielsen siguen siendo ampliamente utilizadas hoyen día. No obstante, existen trabajos de investigación enfocados endesarrollar y proporcionar nuevos sets de heurísticas para evaluar apli-caiones de dominio especí�co como por ejemplo mundos virtuales[48],televisión interactiva [71], realidad aumentada [15], etc.

Generalmente, las heurísticas de Nielsen son utilizadas como base parael desarrollo o adaptación de nuevos sets de heurísticas de usabilidad.Actualmente, existen muy pocos trabajos que mencionan la utilizaciónde las heurísticas de Nielsen sin ninguna clase de adaptación. Los resul-tados de la revisión permitieron evidenciar que el desarrollo de nuevosconjuntos de heurísticas es un campo que va en aumento.

Las nuevas propuestas de heurísticas de usabilidad pretenden solucio-nar el problema de falta de especi�cidad que presentan las heurísticasde Nielsen cuando se trata de evaluar apliaciones de dominio especí�co.La revisión realizada permitió concluir que el uso de heurísticas espe-cí�cas de usabilidad pueden proporcional mejores resultados durantela evaluación de los sistemas de software de dominio especí�co.

No se evidenció una metodología o proceso explícito para el desarrollode heurísticas de usabilidad. La mayor parte de los sets de heurísticasfueron obtenidos de la adaptación o combinación de otros conjuntos deheurísticas existentes.

La mayoría de los conjuntos de heurísticas desarrollados fueron apli-cados únicamente por sus propios desarrolladores. Es decir, no se en-contró evidencia de un proceso formal de validación de las heurísticasdesarrolladas.

35

Por su parte, otros autores también llevaron a cabo revisiones sistemáti-cas dentro del mismo contexto. Así, se puede mencionar el trabajo de Herma-wati y Lawson [25] y el trabajo de Quiñonez y Rusu [63]. Ambos trabajosposeen objetivos similares, en el primer caso [25] el objetivo fue revisarlos procesos que han sido aplicados para establecer heurísticas de usabili-dad en dominios especí�cos, identi�car las brechas existenten y proporcionarrecomendaciones para superarlas. En el segundo caso [63], el objetivo fueidenti�car los enfoques que están siendo usados para crear heurísticas deusabilidad y si éstos involucran procesos sistemáticos o formales.

Los resultados de las tres revisiones sistemáticas de heurísticas de usa-bilidad ([38], [25] y [63]) guardan cierta similitud. En los tres estudios, sedestacó la necesidad de desarrollar heurísticas de usabilidad atendiendo alas características particulares de los diferentes dominios de aplicación. Seevidenció la carencia de un proceso formal o metodología robusta que guieel desarrollo y/o validación de las heurísticas de usabilidad que están siendodesarrolladas. Además se identi�có que en la mayoría de los casos, las nue-vas heurísticas de usabilidad estaban siendo desarrolladas como parte de unproceso de adaptación de las tradicionales heurísticas de Nielsen.

3.4. Cómo se Desarrollan las Heurísticas de Dominio

Existe una vasta literatura sobre evaluaciones heurísticas y el desarrollode heurísticas de usabilidad. De hecho, tal como se mencionó en la secciónanterior, en el estudio de Hermawati y Lawson [25], se citan al menos 70estudios relevantes en cuanto al desarrollo de heurísticas de dominio. Lasprincipales conclusiones obtenidas a partir de este estudio, se constituyen enel pilar fundamental para la propuesta de una metodología de desarrollo deheurísticas de usabilidad, con artefactos y etapas bien de�nidas.

Es así, que en base al análisis realizado al estudio de Hermawati y Law-son [25], se extrajeron los principales aportes respecto al proceso de desarrollode heurísticas de dominio, los cuales se resumen en las siguientes subseccio-nes.

3.4.1. Recopilación y Transformación de Información.

El primer punto a destacar es que la mayoría de los estudios analizadosen [25] contemplan dos grandes etapas: recopilación de información sobreheurísticas, y transformación de esa información en heurísticas de dominio.Hermawati y Lawson describen 4 estrategias para la recopilación de infor-mación:

36

1. Adoptar teorías existentes.

2. Estudiar los contextos de uso.

3. Analizar reportes existentes sobre casos de estudio.

4. Analizar y/o crear un conjunto común de problemas de usabilidad.

Luego, el proceso de transformación sigue alguna de las 3 siguientes es-trategias:

1. Realizar un listado de toda la información, eliminando redundacias ysolapamientos, y utilizando el resultado �nal como las nuevas heurísti-cas de dominio.

2. Realizar el mismo proceso de normalización, y clasi�car la informaciónresultante en categorías, que luego se transforma en heurísticas.

3. Extender y/o modi�car las heurísticas de Nielsen.

3.4.2. Validación de las Heurísticas.

Un resultado importante de [25] es que detectaron una de�ciente vali-dación de las heurísticas de dominio. En resumen, 34% de los estudios queanalizaron no reportaron ningún tipo de validación. Del 66% restante, losmétodos más usados para validar las heurísticas de dominio son:

1. Aplicación de las heurísticas de dominio por expertos (24 estudios).

2. Comparación de los resultados con los de otras heurísticas (20 estu-dios).

3. Comparación de los resultados, en base a pruebas con usuarios reales(5 estudios).

Por otro lado, son pocos los estudios que intentan determinar la efecti-vidad de las nuevas heurísticas. Según lo reportado en [25] solo 19 de los70 casos estudiados presentan una comparación en cuanto a la efectividad.Es decir, los otros casos no presentan validación, no ocupan un grupo deheurísticas de control, o bien no realizan ninguna comparación o análisiscuantitativos. No obstante lo anterior, en los casos donde se estudian lasnuevas heurísticas de dominio versus un conjunto de heurísticas de control,se identi�caron las siguientes categorías de técnicas de validación:

37

1. Cuanti�car el total de problemas de usabilidad, por heurísticas, y com-parar con una evaluación usando heurísticas de control.

2. Cuanti�car y comparar la frecuencia, severidad y distribución de losproblemas por cada heurística especí�ca y por cada conjunto de heu-rísticas.

3. Identi�car y cuanti�car problemas detectados en ambos conjuntos deheurísticas, y problemas únicos detectados en forma disjunta por losconjuntos de heurísticas.

Sin embargo, hay gran variabilidad en la extensión y el rigor de los análisiscuantitativos. Por otro lado, sólo 3 estudios utilizaron las métricas prede�-nidas propuestas por Hartson et al. [23]. Como conclusión de este resumen,los autores de [25] identi�can 3 áreas para mejorar la rigurosidad y robustezde la validación en la heurísticas de dominio:

1. Adoptar métricas de validación robustas y rigurosas, para determinarla efectividad de las nuevas heurísticas de dominio.

2. Crear nuevas heurístias de dominio en base a heurísticas ya existentesen dicho dominio.

3. Mejorar la de�nición y categorización de experto, para así controlar lavariabilidad introducida por los evaluadores.

3.4.3. ¾Necesidad de experimentos controlados?

Los experimentos controlados se utilizan cada vez más para obtener evi-dencia empírica acerca de distintos fenómenos de ingeniería de software [24].Si bien el uso de experimentos controlados resultan efectivos a la hora devalidar hipótesis, midiendo el efecto de las variables independientes sobre lasvariables dependientes; en el ámbito del desarrollo de heurísticas de usabi-lidad, la literatura no re�eja la aplicación de este tipo de experimentos demanera habitual. Tras un análisis retrospectivo sobre el trabajo de otros au-tores que desarrollaron heurísticas de dominio, fue posible identi�car el usode varias técnicas y/o actividades pero en ninguna de éstas se contempló eluso de experimentos controlados per se. Así, en el campo Metodología de laTabla 6, presente en la Sección 5.2, se puede observar de manera resumida,los procesos utilizados por otros autores para desarrollar heurísticas de usabi-lidad. Se observa que en general una práctica común es realizar adaptaciones

38

o re�namientos a heurísticas conocidas y considerar procesos de evaluaciónde usabilidad sobre los distintos tipos de aplicaciones.

Aunque el área de usabilidad maneja un alto grado de subjetividad, dadoque considera la percepción de los usuarios y/o evaluadores respecto a lafacilidad de usar las aplicaciones, la literatura menciona el uso de métodosformales para llevar a cabo procesos de evalución. Sin embargo, la mayorparte de estos métodos de evaluación consideran fuertemente el componentesubjetivo de la facilidad de uso de las aplicaciones.

Una de las principales razones para no considerar la ejecución de experi-mentos formales de manera explícita en esta investigación, es precisamente lanaturaleza de la misma. Hemos desarrollado una investigación de tipo Mixtacon un enfoque cualitativo dominante. No obstate, hemos podido identi�carla necesidad de incluir validación experimental en el proceso de construcciónde heurísticas, por lo que precisamente una de las principales contribucio-nes de PROMETHEUS es añadir y enfatizar la necesidad de actividadesde validación experimental que permitan garantizar de cierta manera quelas heurísticas que se están construyendo son adecuadas a cada uno de losdominios en particular.

39

4. Metodología para el Desarrollo de Heurísticas deUsabilidad

Diversos estudios o revisiones sistemáticas respecto al desarrollo de heu-rísticas de usabilidad, evidenciaron la carencia de una metodología robusta oproceso formal que guíen el desarrollo de heurísticas de dominio. No obstantelo anterior, en [38], [25] y [63], se hace refrencia a la propuesta de Rusuet al [66] como un intento de formalizar el proceso metodológico de cons-trucción de heurísticas de usabilidad; así como también se presentan otraspropuestas o etapas seguidas con este mismo propósito.

Como solución al problema de la falta de una metodología, en este capítu-lo presentamos PROMETHEUS, un PROcesoMETodológico para desarro-llar HEurísticas de USabilidad, que re�na la metodología existente de Rusuet al [66]�que denominamos R3C en base a las iniciales de sus autores�para dar mayor formalidad, rigor y precisión al proceso de construcción denuevas heurísticas de dominio. PROMETHEUS incorpora 8 etapas, en lasque se describe detalladamente las actividades a realizar, los artefactos es-perados y producidos en cada una de ellas, y los indicadores de calidad paraheurísticas que guían el proceso de re�namiento continuo de las mismas.

4.1. Metodología R3C

En esta sección, y con el objetivo de contextualizar la contribución dePROMETHEUS, describimos la metodología R3C. Ésta es una metodolo-gía consistente en 6 etapas, las cuales citamos textualmente [66]:2

1. Exploratoria: se recolecta información bibliográ�ca relacionada conel tema principal de la investigación: aplicaciones especí�cas, sus ca-racterísticas, heurísticas de usabilidad generales o relacionadas (si lashay).

2. Descriptiva: para resaltar las características más importantes de la in-formación previamente recolectada, para formalizar los conceptos prin-cipales asociados a la investigación.

3. Correlacional: para identi�car las características que deberían tenerlas heurísticas de usabilidad para aplicaciones especí�cas, basado enheurísticas tradicionales y análisis de estudios de casos.

2Hacemos una traducción libre del texto original en inglés

40

4. Explicativa: para especi�car formalmente el conjunto de heurísticaspropuestas, utilizando una plantilla estándar.

5. Validación: para revisar las nuevas heurísticas contra las heurísticastradicionales, mediante experimentos, evaluaciones heurísticas realiza-das en casos de estudio seleccionados, y complementado con pruebas ausuarios.

6. Re�namiento: basada en la retroalimentación de la etapa de valida-ción.

4.1.1. Criterio de Evaluación.

R3C identi�ca y de�ne tres clases de problemas que pueden detectarseen la etapa experimental, considerando grupos de evaluadores que utilizanlas nuevas heurísticas, y grupos de evaluadores que utilizan las heurísticas decontrol. Nótese que usamos una nueva notación para referirnos a estas clasesde problemas.

Problemas comunes, P∗: Problemas comunes identi�cados por ambosgrupos de evaluadores.

Problemas de dominio, PD : Problemas identi�cados solamente por elgrupo de evaluadores que utiliza las nuevas heurísticas.

Problemas de control, PC : Problemas identi�cados solamente por elgrupo de evaluadores que usa las heurísticas de Nielsen (u otras sicorrespondiere) como control.

Dada esta clasi�cación, R3C establece que las nuevas heurísticas funcio-nan bien cuando P∗ y/o PD incluyen el más alto porcentaje de problemas.En la práctica, también se considera la severidad de los problemas especí�cosy generales. Finalmente, cabe destacar que R3C es una metodología sencilla,que ha sido aplicada exitosamente hasta el momento en al menos 13 trabajos([67], [48], [71], [12], [60], [10], [49], [77], [55], [16], [31], [68] y [6]), ademásofrece un marco de trabajo que fomenta la validación experimental, evitandoasí algunos de los problemas descritos en la Sección 3.4.2. Es precisamentepor esto que tomamos R3C como punto de partida para el desarrollo dePROMETHEUS.

41

II. DESCRIPTIVA

3. Especificidad de heurísticas

I. EXPLORATORIA1. Búsqueda de

información específica

2. Búsqueda de heurísticas de usabilidad

III. CORRELACIONAL4. Normalización de

heurísticas

5. Priorización de heurísticas

IV. EXPLICATIVA

6. Descripción detallada de heurísticas

V. VALIDACIÓN( 7 )

VI. REFINAMIENTO( 8 )

Etapa R3C Etapa PROMETHEUS Etapa refinada PROMETHEUS

Figura 22: Mapeo entre las etapas de R3C y las de PROMETHEUS.

4.2. PROMETHEUS

PROMETHEUS es un PROcesoMETodológico para desarrollarHEurísticasde USabilidad que surge como un re�namiento de R3C. Decimos que es unproceso metodológico pues describe con precisión los pasos a seguir�y losartefactos a construir�durante el proceso de elaboración de nuevas heurísti-cas de dominio. El origen de PROMETHEUS se basa en una investigaciónanterior de Jiménez et al. [36] para determinar la facilidad de uso de R3C.Para ello, aplicaron un cuestionario a los investigadores que desarrollaronheurísticas utilizando R3C, en los dominios de grid computing [67], televi-sión interactiva [71], mundos virtuales [48], y dispositivos touchscreen [30].En la parte cuantitativa, los resultados agregados son poco concluyentes puesse evaluó la facilidad de uso como �neutral�. Sin embargo, se observaron di�-cultades especí�cas en la etapa explicativa, experimental y de re�namiento.Lo anterior fue con�rmado en los comentarios de los encuestados, que indicanfalta de claridad en estas etapas, y especialmente en la de re�namiento.

A continuación presentamos PROMETHEUS, comenzando por su con-textualización respecto a R3C, y luego describiendo el camino crítico deutilización de la metodología. La descripción detallada de PROMETHEUSse presenta en el Apéndice.

4.2.1. Re�namientos a R3C.

La Figura 22 presenta un diagrama con las etapas de R3C y las etapas dePROMETHEUS. A simple vista, la diferencia principal es que PROMET-

42

HEUS desglosa las etapas exploratoria y correlacional, cada una en dosnuevas etapas. Además, se renombran las etapas descriptiva y explicativa, yse re�nan las etapas de validación y re�namiento. Los aportes especí�cos dePROMETHEUS a las etapas de R3C son:

Exploratoria: PROMETHEUS especi�ca las etapas Búsqueda de in-formación especí�ca y Búsqueda de heurísticas de usabilidad. La pri-mera considera 4 dimensiones características para describir el dominioespecí�co: contexto de uso, dispositivos lógicos, dispositivos físicos, yper�les de usuario. La segunda etapa otorga guías para una búsque-da sistemática de literatura que produzca un conjunto de heurísticasaplicables al dominio.

Descriptiva: PROMETHEUS especi�ca una tabla de codi�cación deíndices de especi�cidad, en base a las dimensiones características deldominio.

Correlacional: en PROMETHEUS se proponen dos etapas: normali-zación de heurísticas y priorización de heurísticas. En la primera etapase resuelven casos de duplicidad o solapamiento en las heurísticas en-contradas, y en la segunda se crea un ranking de especi�cidad de cadaheurística, también considerando las dimensiones características, entreotros factores.

Explicativa: se mantiene la etapa explicativa de R3C, aunque evi-dencia reciente sugiere que es posible mejorar esta etapa [39], e.g. con-siderando evaluadores novatos.

Validación: se mantiene la idea de R3C de realizar validación expe-rimental. Sin embargo, PROMETHEUS requiere al menos una eva-luación heurística utilizando las heurísticas de dominio y un grupo deheurísticas de control. Además, PROMETHEUS especi�ca indicado-res de calidad de las heurística en base a este experimento.

Re�namiento: en PROMETHEUS se utilizan los indicadores de ca-lidad obtenidos durante la validación para sugerir las etapas en quedeben hacerse cambios y/o solucionar problemas especí�cos.

4.2.2. Resumen del Camino Crítico.

La Figura 23 ilustra las 8 etapas de PROMETHEUS para desarrollarheurísticas de dominio. La �gura muestra para cada etapa los artefactos

43

Heurísticas sin normalizar

3Especificidad de heurísticas

Búsqueda de información específica

2Búsqueda de heurísticas de

usabilidad

4Normalización de heurísticas

5Priorización de

heurísticas

6Descripción detallada de heurísticas

7Validación

Refinamiento

Dominio específico

keywords

N sets de heurísticas

, . . ,Heurísticas de

dominio existentes / Heurísticas de control

Heurísticas aplicables al

dominio , . . ,Heurísticas normalizadas, . . ,

Set priorizado de heurísticas , . . , Heurísticas

de dominio

Heurísticas descritas en

plantilla estándar

Heurísticas de control , . . ,

Set validado de heurísticasIndicadores

de calidad , , ,

< 1< 1

< 1< 1

< 1

< 1

< 1 < 1 < 1

Dimensiones características

, . . , , . . , , . . , , . . ,

Entrada artefacto

. Salida artefacto

Camino crítico

Salida intermedia

Artefacto

Figura 23: Flujo principal de proceso de PROMETHEUS

requeridos como entrada, y los producidos como salida. Además muestra po-tenciales salidas intermedias, en caso de encontrar heurísticas adecuadas, y

44

que no sea necesario construir nuevas heurísticas. Sin embargo, el caminocrítico de la metodología consiste en todos los pasos realizados por un inves-tigador para el desarrollo efectivo de nuevas heurísticas de usabilidad para undominio especí�co. Es decir, a pesar de considerar situaciones de salida in-termedias, PROMETHEUS está enfocado en situaciones donde es necesariocrear nuevas heurísticas de dominio.

Para comenzar, se espera que en una primera iteración se apliquen se-cuencialmente todas las etapas. Luego, en base a la retroalimentación de laetapa de re�namiento es posible una mayor adaptabilidad y �exibilidad enlas etapas ejecutadas durante el perfeccionamiento progresivo de las nuevasheurísticas. Evidentemente, la cantidad de iteraciones y las etapas que de-ben volver a ejecutarse dependerá de las necesidades del investigador, de losresultados de la validación, y otros factores especí�cos de cada proyecto. Noobstante, los indicadores generados en la etapa de validación permiten deci-dir informadamente el continuar o no con el re�namiento. El camino críticose resume en cuatro grandes fases:

1. Búsqueda sistemática: El proceso parte con la elección de un do-minio para el cual se desea desarrollar el conjunto de heurísticas deusabilidad especí�cas. Las etapas 1 a 5 consisten en un proceso sis-temático de búsqueda, codi�cación de especi�cidad, y priorización deuno o más conjuntos de heurísticas existentes, en base a las dimensio-nes características del dominio, utilizando una plantilla estándar.

2. De�nición heurísticas de dominio: Al �nalizar la etapa 5 el inves-tigador tendrá un conjunto de heurísticas aplicables al dominio, dondeno debieran existir problemas de duplicación o de solapamiento. Escrucial destacar que es en esta etapa donde el investigador puede crearnuevas heurísticas en base a los datos existentes. Luego, la etapa 6consiste en describir las heurísticas utilizando una plantilla estándar,tal como en R3C. El objetivo de la descripción detallada es facilitar latarea de los evaluadores que realizarán la validación experimental. Elresultado de la etapa 5 y/o 6 son las nuevas heurísticas de dominio.

3. Validación experimental: A continuación, la etapa 7 consiste envalidar experimentalmente las heurísticas de dominio. A diferencia deR3C, y en línea con las sugerencias de Hermawati y Lawson [25], PRO-METHEUS requiere la realización de al menos una evaluación heurís-

45

tica en un caso de estudio especí�co del dominio. Esta evaluación debeconsiderar las heurísticas de dominio, y un conjunto de heuristicas decontrol, que por defecto pueden ser las 10 heurísticas de Nielsen, paraasí generar los indicadores que se detallan a continuación. Sería idealademás contar con varios grupos de evaluadores para cada conjuntode heurísticas, para minimizar las diferencias entre los grupos. Otradiferencia respecto a R3C, es que los evaluadores que usen las heurís-ticas de control deben asignar a cada problema encontrado un puntajede especi�cidad respecto al dominio. Este puntaje usa la misma escalautilizada por el investigador en la etapa 3.

La etapa de validación culmina con el cálculo de los siguientes indica-dores:

Tasa de problemas únicos, ΦP = PD/PC : Representa cuál de losgrupos de heurísticas encontraron más problemas únicos. Si ΦP >1, se encontraron más problemas en las heurísticas de dominio.

Tasa de dispersión de problemas: Para medir la distribución de losproblemas en los grupos de heurísticas consideramos los valores δC

y δD , que representan la desviación estándar de dicha distribuciónpara los problemas de las heurísticas de control y de dominio,respectivamente. Dado lo anterior, de�nimos la tasa de dispersionδP = δC /δD . Si δP > 1, los problemas están mejor distribuidosen las heurísticas de dominio que en las de control.

Tasa de severidad : De manera similar a la tasa de dispersión, de�-nimos la tasa de severidad λP = λD/λC que representa la relaciónentre la severidad promedio λD de los problemas encontrados conlas heurísticas de dominio, versus la severidad promedio λC de losproblemas encontrados con las heurísticas de control. Si λP > 1,signi�ca que en promedio las heurísticas de dominio encontraronproblemas más severos que las heurísticas de control.

Tasa de especi�cidad : Finalmente, de�nimos la tasa de especi�ci-dad εP = εD/εC , que relaciona los promedios de especi�cidad εD

y εC , de los problemas encontrados respectivamente con las heu-rísticas de dominio y de control. Si εP > 1, entonces los problemasencontrados por las heurísticas de dominio son en promedio másespeci�cos que los encontrados por las heurísticas de control.

Es importante destacar que los indicadores son uniformes, es decir,cuando su valor es mayor que 1, se considera positivo, y cuando es

46

menor que 1, se considera que hay potenciales problemas de e�cacia.Esto es útil, por ejemplo, para realizar visualizaciones como las dela Figura 24, donde se comparan los valores de los indicadores paradiversos estudios existentes.

4. Re�namiento: Tal como se muestra en la Figura 23, la etapa dere�namiento toma en consideración los indicadores de calidad de lasheurísticas, ΦP , δP , εP y λP , para proponer posibles re�namientos a lasheurísticas de dominio. Tales re�namientos involucran volver a trabajaren alguna etapa especí�ca de PROMETHEUS, y luego continuar conel camino crítico según sea necesario. La necesidad de re�namientonace, al menos, de los siguientes escenarios problemáticos, o cualquiercombinación de los mismos.

ΦP < 1, es decir, las heurísticas de dominio encontraron menosproblemas únicos. Esto puede indicar que las heurísticas no es-tán bien ajustadas al dominio, que la aplicación examinada tieneprincipalmente problemas generales, o bien que las explicacionesdetalladas para las heurísticas de dominio no fueron bien enten-didas por los evaluadores.

δP < 1, es decir, los problemas están peor distribuidos en lasheurísticas de dominio que en las de control. Esto puede ser sín-toma de heurísticas solapadas, que abarcan muchos problemas, otambién de heurísticas demasiado especí�cas, que no presentanproblemas o que son difíciles de aplicar para los evaluadores.

εP < 1, es decir, los problemas encontrados por las heurísticasde control son considerados más especi�cos al dominio que losencontrados por las heurísticas de dominio. Este problema puedeapuntar a problemas en la priorización de las heurísticas de do-minio, o a problemas en el diseño experimental, por ejemplo enla selección de grupos de evaluadores.

λP < 1, es decir, los problemas encontrados por las heurísticas decontrol son más severos que los de las heurísticas de dominio. Engeneral esto puede indicar problemas en el diseño experimental,en particular con la selección de los grupos de evaluadores.

La decisión �nal de determinar cuándo las heurísticas de dominio sonconsideras validadas depende �nalmente de los investigadores, el do-minio, y las aplicaciones especí�cas bajo estudio. Sin embargo, PRO-

47

METHEUS ofrece un proceso metodológico preciso, con indicadoresde calidad objetivos, que fomentan la retroalimentación contínua y danun soporte cuantitativo para tomar tal decisión.

48

5. Validación de PROMETHEUS

En este capítulo presentamos las actividades realizadas con la �nali-dad de validar el PROceso METodológico para desarrollar HEurísticas deUSabilidad. Como validación inicial de PROMETHEUS hemos tomado unenfoque cualitativo, mediante un breve cuestionario aplicado a investigado-res que utilizaron R3C en sus trabajos, y un enfoque cuantitavo, calculandoretrospectivamente los indicadores de calidad, descritos en la Sección 4.2.2,sobre estudios compilados en el trabajo de Hermawati y Lawson [25], se-gún fue posible de acuerdo a los datos disponibles. Posteriormente, llevamosa cabo la validación empírica de PROMETHEUS a través de su aplica-ción a un caso de estudio para desarrollar heurísticas especí�cas del dominiode los Entornos Virtuales de Aprendizaje (VLEs por sus siglas en inglés).Finalmente, concluimos las actividades de validación mediante el análisispost-experimental de las heurísticas para VLEs (obtenidas en la validaciónexperimental) Vs. el conjunto de heurísticas tradicionales de Nielsen, res-pecto a la Utilidad, Claridad, Facilidad de uso y Necesidad de elementosadicionales de evaluación. Los resultados obtenidos en cada una de las eta-pas de validación permitieron retroalimentar PROMETHEUS, detectandofalencias y oportunidades de mejora de las etapas que lo componen.

5.1. Cuestionario a Investigadores que Usaron R3C

Aplicamos un cuestionario (ver Apéndice B) a 5 investigadores que utili-zaronR3C en casos de estudio relacionados con los dominios de:U-Learning [8],aplicaciones para tablets [3], aplicaciones web transaccionales [55], y aplica-ciones para smartphones [31]. Al momento de realizar el cuestionario, cuatrode los encuestados eran memoristas de Ingeniería Informática de la Ponti�-cia Universidad Católica de Valparaíso, y uno, Inostroza el autor de [31], eratesista de doctorado. Dos encuestados trabajaron en el dominio de tablets,pero se consideran como expertos de manera individual para los �nes de estavalidación. El objetivo del cuestionario es tener una evaluación de expertosrespecto a los siguientes criterios:

Objetivo del estudio

Etapas Aplicables

Etapas de fácil aplicación

Etapas de difícil aplicación

49

Recomendación de agregar nuevas etapas

Recomendación de eliminar etapas

Comprensión general de PROMETHEUS

Comprensión especí�ca de cada etapa

Pertinencia de los indicadores de calidad

Facilidad de cálculo de los indicadores de calidad

Otras recomendaciones

Entregamos a cada participante un documento con una descripción preli-minar de PROMETHEUS, con el objetivo de que evaluaran la aplicabilidadde la metodología en sus casos de estudio. Además, realizamos sesiones in-dividuales para clari�car dudas. Después de estas sesiones, los participantestuvieron 3 meses para la evaluación de aplicabilidad.

Resultados: La Tabla 5 resume los principales resultados respecto delos cuestionarios aplicados. Así, es posible destacar la siguiente información:

3 de los 5 participantes tenía como objetivo la construcción de nuevasheurísticas, mientras que los 2 restantes buscaban re�nar heurísticasexistentes. Esto in�uye en la cantidad de etapas potencialmente aplica-bles, pues los investigadores del primer grupo consideraron más etapasde PROMETHEUS como aplicables a sus proyectos. En el caso deU-Learning, se consideran 6 de las 8 etapas como aplicables. En cam-bio, en las aplicaciones sobre web transaccionales y smartphones sólose consideró aplicable la etapa 6.

En general, los participantes consideraron que las etapas aplicablestambién serían fáciles de aplicar. El único caso explícito es el de laetapa 4 (normalización de heurísticas), en el dominio de U-Learning.

Todos los participantes señalaron que no consideraban necesario agre-gar ni quitar etapas a la metodología, que se comprendía la aplicacióngeneral de la metodología, y que la metodología era útil. Sobre la com-prensión particular de cada etapa, sólo en el caso de web transaccio-nales se indica problemas para comprender la etapa 6.

50

Tabla 5: Resumen de Resultados de la Validación Inicial a PROMETHEUS

Caso

de

estudio

Objetivo

Aplicables

Fáciles

Difíciles

¾Agregaría?

¾Quitaría?

¾Comprende

engeneral?

¾Comprende

cadaetapa?

¾Útil?

¾Ind.

perti-

nen-

tes?

¾Ind.

fáciles

decal-

cular?

U-Learning

Obtener

nuevas

heurísticas

1,2,3,4,

7,8

1,2,3,

4,7,8

4No

No

33

33

3

Tablets

#1

Obtener

nuevas

heurísti-

cas,

re�nar

heurísticas

existentes,

describir

detalla-

damente

heurísticas

1,2,6,7

6,7

�No

No

33

3n/a

n/a

Tablets

#2

Obtener

nuevas

heurísti-

cas,

re�nar

heurísticas

existentes,

describir

detalla-

damente

heurísticas

1,2,6,7

1,2,6,

7�

No

No

33

3n/a

n/a

Web

tran-

saccionales

Re�nar

heurísticas

existentes,

describir

detalla-

damente

heurísticas

66

�No

No

37

3n/a

n/a

Smartphones

Re�nar

heurísticas

existentes,

describir

detalla-

damente

heurísticas

66

�No

No

33

3n/a

n/a

n/a=

noloscalculó

51

Lamentablemente, los indicadores de calidad sólo se consideraron apli-cable, pertinentes y fáciles de calcular en el caso de U-Learning. Engeneral, los otros investigadores no estaban interesados en calcularlos.

Dentro de las sugerencias recibidas, se destacan:

• Incluir en un ejemplo de llenado de plantilla para la etapa dedescripción detallada de heurísticas.

• Explicar de mejor manera los diferentes cálculos incluidos en lametodología.

• Incluir un ejemplo real de aplicación.

5.2. Validación de Indicadores de Calidad

Preliminares: Antes de mostrar los resultados obtenidos, recordemosla clasi�cación de problemas propuesta en R3C (Sección 4.1):

Problemas comunes, P∗: Problemas comunes identi�cados por ambosgrupos de evaluadores.

Problemas de dominio, PD : Problemas identi�cados solamente por elgrupo de evaluadores que utiliza las nuevas heurísticas.

Problemas de control, PC : Problemas identi�cados solamente por elgrupo de evaluadores que usa las heurísticas de Nielsen (u otras sicorrespondiere) como control.

Ahora, sea P el conjunto total de problemas encontrados al aplicar tantolas heurísticas de control y las heurísticas de dominio, se tiene que:

Problemas heurísticas de dominio: P∗D = PD ∪ P∗

Problemas heurísticas de control: P∗C = PC ∪ P∗

Total problemas: P = PD ∪ PC ∪ P∗ = P∗D ∪ P∗C

Por otro lado, y de forma análoga, consideramos el promedio de severidadλ∗D de los problemas en P∗D , y el promedio de severidad λ∗C de los proble-mas en P∗C . Tomando en cuenta todo lo anterior, de�nimos los indicadoresΦ∗P = P∗D/P∗C y λ∗P = λ∗D/λ

∗C que aproximan las tasas de unicidad y severi-

dad, respectivamente, en casos en que no se separan los problemas comunes

52

P∗ entre los dos grupos de heurísticas.

Considerando las de�niciones anteriores, el segundo punto de la valida-ción inicial de PROMETHEUS consiste en analizar los datos de los 19estudios identi�cados por Hermawati y Lawson [25] que intentan determinarla efectividad de las nuevas heurísticas, y 2 estudios adicionales publicadosrecientemente [45, 7]. Para cada de uno de ellos, calculamos los indicadoresde calidad de heurísticas según lo posible de acuerdo a la información publi-cada, y destacamos las conclusiones sobre si las heurísticas desarrolladas sono no más efectivas que las de control. La Tabla 6 resume la metodología, loscriterios usados por los autores, los indicadores que fue posible calcular, y silos autores concluyen o no que las heurísticas de dominio desarrolladas sonmás efectivas que las heuristicas de control utilizadas.

Tabla 6: Resumen Análisis de E�cacia Heurísticas de Dominio HD vs Heurís-ticas de Control HC

Dominio #Hs

Criterio Metodología Indicadores ¾HD me-jores queHC ?

Grid Compu-ting [67]

12 Cantidad de proble-mas únicos, especí�cosy generales. Severidadde problemas especí�-cos vs generales

R3C Caso 1:

ΦP = 2,0,δP = 0,97,λP = 1,16

Caso 2:

ΦP = 1,83,δP = 1,11

3

Mundos virtua-les [48]


R3C Caso 1:

ΦP = 1,93,δP = 0,71,λP = 0,91

Caso 2:

ΦP = 2,75,δP = 0,78,λP = 1,07

3

Sitios web inter-culturales [12]


R3C Caso 1:

ΦP = 1,97,λP = 1,11

Caso 2:

ΦP = 1,71,λP = 1,25(cálculo basado

en porcentajes)

3


53

Dominio #H


Televisión Digi-tal [72]


R3C

ΦP = 5,0,δP = 1,28

3

Sistemas de noti-�cación [4]

8 Cantidad de problemasencontrados en 3 in-terfaces usadas comocaso de estudio. Ni-vel de cumplimiento delas heurísticas desarro-lladas

En base a pro-blemas de usabili-dad relacionadoscon sistemas denoti�caciones

Caso 1:

ΦP = 0,93

Caso 2:

ΦP = 1,64

Caso 3:

ΦP = 1,23

3

Robótica asis-tencial [75]

9 Cantidad total de pro-blemas y problemasúnicos

Adaptaciónde heurísticasexistentes

ΦP = 4,333

Aplicaciones degestión de segu-ridad [34]

7 Cantidad y severidadde problemas, efectivi-dad, minuciosidad, va-lidez y �abilidad de lasheurísticas

Utiliza grounded

theory analysis

para generarheurísticas

ΦP = 1,037

Sitios web edu-cacionales [1]

n/d Cantidad y severidadde problemas, efectivi-dad, minuciosidad, va-lidez, e�ciencia y �abi-lidad de las heurísticas,tiempo empleado y cos-to asociado

Metodología pro-pia de 4 etapasque analiza lascaracterísticas deldominio y evalúacasos de a tra-vés de expertos yusuarios

ΦP = 9,173

Aplicaciones ba-sadas en móvi-les [50]

11 Cantidad y Severidadde problemas

Extensión de lasheurísticas deNielsen

ΦP = 1,93

Computaciónmóvil [5]

8 Cantidad y severidadde problemas, cantidadde problemas por heu-rística, tiempo emplea-do por los evaluadores

Metodología pro-pia de 3 etapasbasadas en el aná-lisis de 3 expertos

Caso 1:

P∗D = 26,

P∗C = 22

Φ∗P = 1,18

Caso 2:

P∗D = 38,

P∗C = 28

Φ∗P = 1,36

Casos combi-

nados:

δP = 0,57

3


54

Dominio #H


Aprendizaje ba-sado en casos clí-nicos [7]

22 Cantidad de problemasy severidad en heurísti-cas especí�cas vs gene-rales

Utiliza grounded

theory analysis

para generarheurísticas

Caso 1:

P∗D = 27,

P∗C = 37

Φ∗P = 0,73,

λ∗D < λ∗C

Caso 2:

P∗D = 74,

P∗C = 56

Φ∗P = 1,32,

λ∗D > λ∗C

3

Juegos enred [61]

10 Cantidad y Severidadde problemas, cantidady severidad promediode problemas por heu-rística

Basado en el aná-lisis de problemasde usabilidad enjuegos

P∗D = 67,

P∗C = 49,

Φ∗P = 1,37

λ∗D = 2,30,λ∗C = 2,39,λ∗P = 0,96σ(P∗

D ) = 3,16

3

Aplicaciones demapas móvi-les [43]

10 Cantidad y Severidadde problemas

Adaptación delas heurísti-cas de Nielsenusando un en-foque teórico-conceptual

P∗D = 19,

P∗C = 15,

Φ∗P = 1,27

3

Smartphones [31] 12 Cantidad de proble-mas únicos, especí�cosy generales. Severidadde problemas especí�-cos vs generales

R3C

P∗D = 28 ,33 ,

λ∗D = 2 ,36

σ(P∗D ) = 2 ,24

3

Groupware [45]3 24 Problemas encontradosen caso de estudio y suseveridad

En base a patro-nes de diseño

P∗D = 39,

σ(P∗D ) = 1,85

λ∗D = 2,15

3 SinHC ,concluyepositiva-mente

Dispositivos mó-viles táctiles [28]


R3C Caso 1:

λP = 1,37

Caso 2:

λP = 0,83

3

AplicacionesERP [70]

5 Media, mediana y mo-da de Severidad de pro-blemas por heurística

Basado en 5 crite-rios de evaluaciónde sistemas ERP

λ∗D = 1,76,λ∗C = 0,88,λ∗P = 2,

3


55

Dominio #H


Ambient dis-play [46]

12 Porcentaje y severidadde problemas identi�-cados con ambos gru-pos de heurísticas

Adaptación deheurísticas deNielsen tomandoen cuenta ca-racterísticas deldominio y opi-nión de expertosy diseñadores

Los resultadospresentados nopermiten calcu-lar los indica-dores

3

Juegos decompu-tador [11]3

18 Tipos de problemas,cantidad y severidad

Basado en la li-teratura y la re-visión de exper-tos en jugabilidady diseñadores dejuegos


3

Presentaciónde informaciónen pantallasgrandes [73]

8 Cantidad de proble-mas, cantidad de pro-blemas reales, minucio-sidad, validez, e�caciay �abilidad de las heu-rísticas

Utiliza pará-metros críticosmediante dise-ño basado enescenarios


3

Sitios Web [9] 13 Cantidad de proble-mas, tiempo empleadopor los evaluadores

Adaptación delas heurísticas deNielsen

Los resultadospresentadosno permiten elcálculo de losindicadores

3

De los resultados obtenidos a partir del cálculo de indicadores en lostrabajos descritos en la Tabla 6, a continuación presentamos los principaleshallazgos:

Sobre cantidad de problemas: De los 21 estudios analizados, fueposible calcular algún indicador en 17 de ellos. En esos 17 casos, elindicador más utilizado corresponde a la tasa de unicidad ΦP , usadaen 9 casos, o bien a la tasa aproximada de unicidad Φ∗P , usada en 4casos. En otros 2 casos se consideró solamente la cantidad de problemasen base a las heurísticas de dominio, es decir, sólo se considero P∗D . Enlos 2 casos restantes no se pudo calcular ningún indicador en base a lacantidad de problemas detectados.

Sobre la dispersión de los problemas: En un lejano segundo lugar,en 4 casos fue posible calcular la tasa de dispersión δP , mientras queen 2 casos sólo hay información sobre la dispersión de los problemasde las heurísticas de dominio, es decir σ(P∗D).

3 No compara con heurísticas de control

56

Sobre la severidad y especi�cidad de los problemas: De manerasimilar, en 4 casos se logra calcular la tasa de severidad λP , en 2 casosse puede calcular una aproximación λ∗P , y en otros 2 casos se considerasólo la severidad de problemas de las heurísticas de dominio, es decirλ∗D . Por otra parte, en ninguno de los casos analizados fue posiblecalcular la tasa de especi�cidad εP de los problemas.

Heurísticas de dominio vs heurísticas de control: En 20 de los 21casos los autores concluyen que las heurísticas de dominio desarrolladas(o re�nadas) tienen mayor e�cacia que las heurísticas de control. Elcaso donde esto no ocurre es en el dominio de aplicaciones de gestiónde seguridad [34]; en este caso sólo se pudo calcular ΦP = 1,03, lo quees un valor difícil de interpretar sin información adicional.

Relación entre indicadores y conclusiones positivas: La Figu-ra 24 muestra los indicadores calculados en la Tabla 6, desglosandocada subcaso como una entrada independiente en el grá�co, teniendoasí 23 casos. En todos los casos los autores concluyen que las heurísticasde dominio son mejores que las de control. Se omite un caso extremocon ΦP = 9,17. La línea punteada indica el valor 1, que discriminaentre una interpretación positiva o negativa del indicador. Cada líneavertical corresponde a casos de estudio que involucran más de un indi-cador. Una observación fundamental es que la condición ΦP > 1, o biensu aproximación Φ∗P > 1, parece ser el mejor predictor para validar lae�cacia de las heurísticas de dominio. En sólo 2 casos esto no es así,para ΦP = 0,93 y Φ∗P = 0,73. Bajo el esquema de PROMETHEUS,estos casos son difíciles de interpretar y requerirían de un re�namien-to, además del cálculo de los otros indicadores especi�cados. Además,es posible que otros factores cualitativos contribuyan a la evaluaciónpositiva en estos casos de estudio. Respecto a las tasas de dispersióny de severidad, se observan valores cercanos a 1, y que complementanlas tasas de unicidad. En sólo 3 casos se tiene que se considera sólo laseveridad, en ausencia de otros datos cuantitativos.

Finalizando esta sección, observamos que el análisis retrospectivo de loscasos seleccionados en que se han desarrollado heurísticas de dominio so-porta la pertinencia de los indicadores propuestos en PROMETHEUS. Enparticular, es claro que el indicador más importante es la tasa de unicidad,y que los otros indicadores son más bien complementarios y pueden ayudara discriminar en casos menos concluyentes. También observamos que existenestudios que basan sus conclusiones positivas en un argumento cuantitativo

57

Figura 24: Visualización de indicadores de calidad en los estudios seleccio-nados donde fue posible su cálculo.

más bien débil, lo que sugiere que las recomendaciones para el re�namientoen PROMETHEUS están en la línea correcta.

5.3. Validación Empírica de PROMETHEUS

La siguiente etapa de validación de PROMETHEUS, consistió en apli-carla a un caso especí�co de estudio para obtener heurísticas de usabilidadespecí�cas para evaluar Entornos Virtuales de Aprendizaje (VLEs por sussiglas en inglés). La validación se llevó a cabo utilizando un grupo de 3investigadores con similar nivel educativo y profesional. Se trataba de 3 es-tudiantes del noveno semestre de la Carrera de Ingeniería en Sistemas de laESPOCH 4, cuyo per�l especí�co se resume en la Tabla 7

El experimento de validación empírica, fue dividido en las siguientes tresetapas principales:

1. Entrenamiento previo respecto a PROMETHEUS.

2. Aplicación detallada de PROMETHEUS.

3. Validación experimental de las heurísticas obtenidas mediante PRO-METHEUS.

4Escuela Superior Politécnica de Chimborazo (http://www.espoch.edu.ec)

58

Tabla 7: Per�l de los investigadores que participaron en la validación empíricade PROMETHEUS.

Durante la primera fase de la validación, se solicitó al grupo de investi-gadores participar en una corta sesión en la cual fueron capacitados acercade PROMETHEUS, los objetivos que se persigue al aplicar esta metodo-logía, las etapas que la conforman, y la manera de llevarlas a cabo. Pos-teriormente, los investigadores tuvieron un plazo de 2 meses para aplicarPROMETHEUS y entregar las heurísticas resultantes para evaluar Entor-nos Virtuales de Aprendizaje (VLEs). Finalmente, el conjunto resultante deheurísticas fue validado de manera empírica gracias a la participación de 14grupos de evaluadores. Cada grupo de evaluador estaba conformado por 5especialistas.

Como resultado de la primera etapa de validación de PROMETHEUS,el grupo de investigadores desarrolló un conjunto de 18 heurísticas de usa-bilidad aplicables al dominio de los VLEs. Básicamente, el nuevo conjuntode heurísticas corresponde a una extensión de las diez heurísticas generalesde Nielsen, pero incorpora otras heurísticas relacionadas directamente concaracterísticas propias del dominio de los VLEs. En la Tabla 8 se presenta unresumen de las heurísticas para VLEs desarrolladas, así como el mapeo conlas heurísticas de Nielsen. Como se puede observar en la Tabla 8, 12 de las 18heurísticas guardan alguna relación con las heurísticas de Nielsen; mientrasque 6 de ellas (V12, V13, V14, V15, V16 y V18) se relacionan directamente

59

con características especí�cias del dominio en estudio (VLEs).

5.3.1. Descripción del Proceso de Validación Empírica.

La validación empírica se realizó mediante la comparación del rendimien-to de las heurísticas para VLEs con el rendimiento de las tradicionales heurís-ticas de Nielsen. Tal como se estableció en PROMETHEUS, con la �nalidadde validar el desempeño de las heurísticas de domino especí�co, la etapa 7 dela metodología recomienda realizar al menos una evaluación heurística a uncaso de estudio especí�co del dominio, usando por una parte las heurísticasde dominio especí�cas desarrolladas a través de PROMETHEUS (HD) ypor otra parte un conjunto de heurísticas de control (HC ). En nuestro proce-so de validación hemos considerado como heurísticas de control el conjuntode 10 heurísticas de Nielsen, y como heurísticas de dominio, el conjunto de18 heurísticas desarrolladas para evaluar VLEs.

El entorno virtual de aprendizaje de la Escuela Superior Politécnica deChimborazo (ESPOCH)5 fue seleccionado como caso de estudio para la eje-cución de las evaluaciones heurísticas. La principal razón de esta selecciónresponde a que, a la fecha de la realización de este experimento, todos losevaluadores participantes formaban parte de esta institución de educaciónsuperior, por lo que tenían acceso a la aplicación para realizar la evaluación.

Un conjunto de 70 evaluadores participaron en el experimento. Todos losparticipantes tenían similar per�l profesional y educativo. Todos ellos eranestudiantes de 8vo semestre de la carrera de Ingeniería en Sistemas y enese momento cursaban la asignatura obligatoria �Interfaces and Multimedia"en la Escuela Superior Politécnica de Chimborazo de Riobamba-Ecuador.Además, poseían un nivel similar de conocimientos tanto de usabilidad comode desarrollo de software.

El total de 70 evaluadores fue distribuido de manera aleatoria en 14grupos de 5 evaluadores cada uno; 7 grupos evaluaron el caso de estudioutilizando las heurísticas de control mientras que los otros 7 grupos utiliza-ron las heurísticas de dominio. Es importante mencionar, que la asignaciónlos conjuntos de heurísticas a cada grupo fue también mediante un procesoaleatorio. Aunque PROMETHEUS recomienda realizar la validación conal menos una evaluación heurística, nosotros decidimos llevar a cabo esteproceso con 14 grupos de evaluadores a �n de controlar la variabilidad deresultados y obtener resultados concluyentes del proceso de validación.

El análisis de resultados de la validación empírica fue dividido en doscategorías:

5https://elearning.espoch.edu.ec/

60

Tabla 8: Mapeo entre las heurísticas para VLEs y las heurísticas de NielsenHeuristics para VLEs Heuristics de Nielsen

ID De�nición ID De�nición

V1 Visibilidad del estado del sis-tema

N1 Visibilidad del estado del sis-tema

V2 Consistencia entre el sistemay el mundo real

N2 Consistencia entre el sistemay el mundo real

V3 Control y libertad del usuario N3 Control y libertad del usuarioV4 Consistencia y Estándares N4 Consistencia y EstándaresV5 Prevención de errores N5 Prevención de erroresV6 Reconocer antes que recordar N6 Reconocer antes que recordarV7 Flexibilidad y e�ciencia en el

usoN7 Flexibilidad y e�ciencia en el

usoV8 Diseño estético y minimalista N8 Diseño estético y minimalistaV9 Ayudar a los usuarios a reco-

nocer, diagnosticar y recupe-rarse de errores

N9 Ayudar a los usuarios a reco-nocer, diagnosticar y recupe-rarse de errores

V10 Ayuda y Documentación N10 Ayuda y DocumentaciónV11 Consistencia en los elementos

del Sistema VLEN4 Consistencia and Estándares

V12 Simbología y estándares Web - -V13 Indicadores del procesos de

enseñanza-aprendizaje- -

V14 Con�guración �exible de losobjetos y recursos de apren-dizaje

- -

V15 Capacidad de almacenamien-to

- -

V16 Comunicación Interactiva - -V17 Adaptación a múltiples dispo-

sitivosN7 Control y libertad del usaurio

V18 Medida del aprendizaje - -

61

Análisis de resultados intra-heurísticas, correspondiente a los resulta-dos identi�cadas por aquellos grupos de evaluadores que utilizaron elmismo conjunto de heurísticas

Análisis de resultados inter-heurísticas, correspondiente a los resulta-dos identi�cados entre ambos conjuntos de heurísticas.

5.3.2. Análisis Intra-Heuristicas.

En esta fase analizamos los parámetros: número de problemas totales,número de problemas comunes, número de problemas únicos, severidad pro-medio, criticidad promedio y dispersión de problemas por heurística; tantopara las heurísticas de dominio (HD) como para las heurísticas de control(HC ), con el objetivo de determinar si las heurísticas de dominio (VLEs)presentan un mejor rendimiento que las heurísticas de control (Nielsen). Elanálisis de los parámetros de número de problemas, severidad y criticidadse llevó a cabo a través de un estudio de diferencia de medias [57], en basea la distribución estadística presentada en la ecuación (1). Por otra parte,el análisis del parámetro de dispersión de problemas por heurística se llevóa cabo mediante la comparación de las desviaciones estándar promedio dela cantidad de problemas asociados a cada heurística dentro del grupo deheurísticas de control y del grupo de heurísticas de dominio. No se realizó eltest estadístico del parámetro dispersión de problemas por heurística, dadoque si bien el tamaño de la muestra era el mimso (7 grupos de evaluadores)la cantidad de heurísticas de cada uno de los grupos es diferente (10 heurís-ticas de control y 18 heurísticas de dominio). En las secciones subsiguientesdetallamos los resultados y presentamos nuestras conclusiones.

XHD −XHC√[(nHD−1)S2

HD+(nHC−1)S2HC

nHD+nHC−2

].[nHD+nHCnHD.nHC

] ∼ tnHD + tnHC − 2 (1)

a) Análisis del Número de Problemas: Para ambos conjuntos de heu-rísticas (HD y HC ) se analizó la cantidad de problemas totales (PT ),problemas comunes (PM ) y problemas únicos (PU ) identi�cados en-tre los 7 grupos de evaluadores. La Figura 25 muestra la distribuciónde problemas por cada grupo de evaluadores que utilizaron el mismoconjunto de heurísticas (HD or HC ). Aparentemente, existe una dis-tribución similar respecto a la cantidad de problemas identi�cados porlos evaluadores en ambas categorías o conjuntos de heurísticas.

62

Figura 25: Número de problemas por conjunto de heurísticas HC y HD .

Como se puede observar en la Figura 26, las heurísticas de dominio per-mitieron a los evaluadores encontrar una mayor cantidad de problemasque los encontrados con las heurísticas de control. Sin embargo, la can-tidad de problemas únicos fue similar en ambas categorías. Este hechoparece indicar que no existen diferencias signi�cativas al usar un con-junto particular de heurísticas respecto al número de problemas. Con la�nalidad de apoyar o rechazar esta hipótesis, realizamos las pruebas es-tadísticas considerando las siguientes hipótesis nula (H0 : µHC

= µHD)

y alternativa (H1 : µHC6= µHD

):

H0 : µHC= µHD

: Los dos conjuntos de heurísticas (HC y HD) son

63

equivalentes para identi�car problemas totales, comunes y únicos;en el sentido de que las medias de estos parámetros son iguales.

H1 : µHC6= µHD

: Los dos conjuntos de heurísticas (HC y HD) sonequivalentes para identi�car problemas totales, comunes y únicos;en el sentido de que las medias de estos parámetros son distintas.

Para el análisis, usamos la distribución estadística t para comparar ladiferencia de medias en base a la cantidad de problemas observada en laTabla 9), bajo la hipótesis H0 : µHC

= µHDversus H1 : µHC

6= µHDy

considerando el nivel de signi�cancia α = 0 ,05 . Los siguientes parrafosresumen los resultados obtenidos tras la ejecución de los t tests.

Tabla 9: Datos y Resultados del análisis estadístico tPT PM PU Severidad Criticidad

Grupo HD HC HD HC HD HC HD HC HD HC

Grupo 1 25 13 20 9 5 4 2.57 2.11 5.54 5.68Grupo 2 30 14 25 8 5 6 2.77 2.36 5.64 4.72Grupo 3 21 18 18 15 3 3 2.81 2.19 6.39 5.47Grupo 4 21 13 20 7 4 2 2.75 2.90 5.52 5.85Grupo 5 24 9 20 7 4 2 2.93 2.55 5.90 4.81Grupo 6 26 11 21 8 5 3 2.16 3.01 4.43 6.24Grupo 7 25 15 23 10 2 5 2.55 2.12 5.19 4.16Total 172 93 147 68 25 25

Media X 24.57 13.27 21.00 9.71 3.51 3.51 2.65 2.46 5.52 5.28Varianza S2 9.62 8.24 5.33 7.24 2.62 2.29 0.06 0.14 0.37 0.54

Tamaño muestral n 7 7 7 7 7 7 7 7 7 7coe�ciente de Pearson 8.93 6.29 2.45 0.10 0.45

Diferencia hipotética de medias 0 0 0 0 0Grados de libertad 12 12 12 12 12

valor t 7.07 8.42 0.00 1.09 0.67t Crítico 2.18 2.18 2.18 2.18 2.18

Diferencias Signi�cativas si si no no no

PT = Problemas TotalesPM = Problemas ComunesPU = Problemas Únicos

Prueba de hipótesis para Problemas Totales (PT ) : Como se puedeobservar en la Tabla 9, el valor t (7.07) para los problemas tota-les está localizado dentro del área crítica (>2.18). En este caso, lahipótesis nula (H0 : µHC

= µHD) es rechazada y aceptamos por

lo tanto la hipótesis alternativa (H1 : µHC6= µHD

). De esta for-ma, es posible concluir que no hay evidencia estadísticapara a�rmar que la media del total de problemas identi-

�cados con las heurísticas de control (Nielsen) y la mediadel total de problemas identi�cados con la heurísticas de

64

Figura 26: Comparación de problemas Totales, Comunes y Únicos entre lasheurísticas HC y HD .

dominio (VLE) son iguales. En otras palabras, existen diferen-cias signi�cativas entre el número total de problemas encontradosutilizando ambos conjuntos de heurísticas.

Prueba de hipótesis para Problemas Comunes (PM ): A partir dela Tabla 9 podemos observar que el valor t (8.42) para problemascomunes está localizado dentro del área crítica (>2.18). La hipóte-sis nula (H0 : µHC

= µHD) es rechazada y aceptamos la hipótesis

alternativa (H1 : µHC6= µHD

). Este hecho nos permite con-

cluir que no hay evidencia estadística para a�rmar que

la media de los problemas comunes identi�cados con las

heurísticas de dominio(VLE) y la media de los proble-

mas comunes identi�cados con las heurísticas de control

(Nielsen) son iguales. En otras palablas, existen diferenciassigni�cativas entre el número de problemas comunes encontradosal utilizar ambos conjuntos de heurísticas.

Prueba de hipótesis para Problemas Únicos (PU ): La Tabla 9muestra que el valor t para problemas únicos es cero (0). Por lotanto, el valor t está localizado fuera del área crítica (<2.18). Eneste caso, se acepta la hipótesis nula H0 : µHC

= µHDy conclui-

mos que no existe evidencia de la presencia de diferen-cias signi�cativas entre el número de problemas únicos

encontrados con ambos conjuntos de heurísticas.

b) Análisis de Severidad y Criticidad promedio: Durante esta eta-pa, se analizaron los valores promedios de severidad y criticidad quecada grupo de evaluadores registró al utilizar tanto las heurísticas decontrol (HC ) como las heurísticas de dominio (HD). En la Figura 27

65

podemos observar los valores promedio de severidad y criticidad re-gistrados por los 7 grupos de evaluadores que usaron las heurísticasde Nielsen así como también los valores promedios de estos mismosparámetros, registrados por los 7 grupos de evaluadores que utilizaronlas heurísticas para VLEs. Aparentemente, las heurísticas de dominio(VLEs) permitieron identi�car problemas más severos y más críticosque aquellos identi�cados con las heurísticas de control(Nielsen). Sinembargo, debido a que el número total de problemas identi�cados noes igual en ambas categorías de heurísticas, llevamos a cabo Tests dehipótesis de medias con la �nalidad de comprobar la hipótesis nula deque los dos conjuntos de heurísticas (HC y HD) tienen un com-

portamiento equivalente para descubrir problemas críticos y

severos, en el sentido que las medias de estos dos paráme-

tros son iguales. La hipótesis alternativa considera que las mediasson diferentes.

Para llevar a cabo este análisis, utilizamos la distribución estadísti-ca t para comparar la diferencia de medias en base a los valorespromedios de severidad (S ) y criticidad(C ), enfrentando la hipóte-sis H0 : µHC

= µHDversus H1 : µHC

6= µHDy considerando un nivel de

signi�cancia α = 0 ,05 . Los datos resultantes de este análisis se presen-tan en la Tabla 9 y los siguientes párrafos resumen las conclusiones delas pruebas t ejecutadas.

Prueba de hipótesis para Severidad (S): A partir de la Tabla 9 po-demos observar que el valor t (1.09) para el promedio de severidadestá localizado fuera del área crítica (<2.18). En este caso, se acep-ta la hipótesis nula H0 : µHC

= µHDy concluimos que no existe

evidencia de la presencia de diferencias signi�cativas entre la se-veridad de los problemas identi�cados utilizando las heurísticasde dominio (VLEs) y la severidad de los problemas identi�cadosmediante las heurísticas de control (Nielsen).

Prueba de hipótesis para Criticidad (C ): En la Tabla 9 podemosobservar que el valor t (0.67) para criticidad promedio está lo-calizado fuera del área crítica (<2.18). En este caso, se acepta lahipótesis nula H0 : µHC

= µHDy concluimos que no existe eviden-

cia de la presencia de diferencias signi�cativas entre la criticidadde los problemas identi�cados utilizando las heurísticas de do-minio (VLEs) y la criticidad de aquellos problemas identi�cadosutilizando las heurísticas de control (Nielsen).

66

Figura 27: Valores promedio de Severidad y Criticidad por grupo de evalua-dores, usando HC y HD

COMPROBACIÓN DE LOS TESTS DE HIPÓTESIS: Laspruebas estadísticas realizadas sobre los parámetros número de proble-mas totales, número de problemas comunes, número de problemas úni-cos severidad promedio y criticidad promedio fueron ejecutadas asu-miendo el �supuesto de Normalidad� de la población. Sin embar-go, con la �nalidad de corroborar los resultados obtenidos, decidimosllevar a cabo, sobre los estos mismos parámetros, el test no paramétricode Wilcoxon para muestras pareadas [76], con un nivel de signi�canciade dos colas p < 0,05 para todas las comparaciones. Los resultados

67

de la aplicación del test de Wilcoxon permitieron determinar la exis-

tencia de diferencias signi�cativas en los parámetros número deproblemas totales y número de problemas comunes, coincidiendo conlos resultados obtenidos al aplicar los t tests. La Tabla 10 sintetiza losresultados obtenidos tras la aplicación de los tests no paramétricos deWilcoxon.

Tabla 10: Datos y Resultados del análisis estadístico de WilcoxonPT PM PU Severidad Criticidad

Grupo HD HC HD HC HD HC HD HC HD HC

Grupo 1 25 13 20 9 5 4 2.57 2.11 5.54 5.68Grupo 2 30 14 25 8 5 6 2.77 2.36 5.64 4.72Grupo 3 21 18 18 15 3 3 2.81 2.19 6.39 5.47Grupo 4 21 13 20 7 4 2 2.75 2.90 5.52 5.85Grupo 5 24 9 20 7 4 2 2.93 2.55 5.90 4.81Grupo 6 26 11 21 8 5 3 2.16 3.01 4.43 6.24Grupo 7 25 15 23 10 2 5 2.55 2.12 5.19 4.16Total 172 93 147 68 25 25

Media X 24.57 13.27 21.00 9.71 3.51 3.51 2.65 2.46 5.52 5.28Tamaño muestral n 7 7 7 7 7 7 7 7 7 7

Dif. medias Hodges-Lehmann -11.75 -12 0 -0.3875 -0-385Intervalo de Con�anza 95% -15.5000 a -6.5000 -15.0000 a -7.0000 -2.0000 a 2.0000 -0.5250 a 0.2350 -1.0300 a 0.9750

Diferencias + 0 0 3 2 3Diferencias - 7 7 3 5 4

Rangos más pequeños 0 0 10 8 10Probalilidad bilateral 0.016 0.016 1.000 0.375 0.578

Diferencias Signi�cativas si si no no no

PT = Problemas TotalesPM = Problemas ComunesPU = Problemas Únicos

c) Análisis de dispersión de problemas por heurística: En la Ta-bla 11 se muestra el número de problemas de usabilidad identi�cadospor los 7 grupos de evaluadores en cada una de las heurísticas delconjunto de heurísticas de control (HC ); y el número de problemasde usabilidad identi�cados por los 7 grupos de evaluadores en cadauna de las heurísticas del conjunto de heurísticas de dominio (HD).La Tabla 11 también presenta el número promedio de problemas entregrupos y la desviación estándar de estos valores. Para las heurísticasde dominio (HD), la desviación estándar entre grupos resulta ser rela-tivamente estable (0.83) comparada con la desviación estándar de lasheurísticas de control (1.19). Este hecho parece indicar que al utilizarlas heurísticas de dominio (VLEs), los grupos de evaluadores son ca-paces de descubrir un número más uniforme de problemas asociados acada una de las heurísticas utilizadas.

La Figura 28 ilustra grá�camente los datos de la Tabla 11. Así, es po-sible observar la distribución de los problemas identi�cados por cada

68

grupo de evaluadores de acuerdo a cada heurística de la categoría deHeurísticas de Control y de Dominio respectivamente. Se puede apre-ciar, en el caso de las Heurísticas de Control, que la heurística N8acumuló la mayor cantidad de problemas y los cuales fueron identi�ca-dos por los 7 grupos de evaluadores. Por otra parte, para la heurísticaN9 únicamente el grupo 7 fue capaz de identi�car problemas. En elcaso de las heurísticas de dominio, la mayoría de los grupos de evalua-dores fueron capaces de identi�car problemas asociados a cada una delas heurísticas de esta categoría.

Tabla 11: Número de problemas por heurística y por grupos (G), promediode desviación estándar en HC y HD

HEURISTICAS DE CONTROL HC

ID G1 G2 G3 G4 G5 G6 G7 Promedio de problemas por G Desviación Estándar

N1 0 0 2 0 0 1 0 0.43 0.79N2 1 0 0 0 3 0 2 0.86 1.21N3 2 0 2 0 0 1 0 0.71 0.95N4 3 1 4 6 0 1 1 2.29 2.14N5 0 2 1 0 0 1 1 0.71 0.76N6 0 3 1 1 1 3 2 1.57 1.13N7 1 4 2 1 0 2 2 1.71 1.25N8 5 2 5 5 5 1 2 3.57 1.81N9 0 0 0 0 0 0 2 0.29 0.76N10 1 2 1 0 0 1 3 1.14 1.07Total 13 14 18 13 9 11 15 Promedio entre grupos: 13.29 Promedio: 1.19

HEURISTICAS DE DOMINIO HD

ID G1 G2 G3 G4 G5 G6 G7 Promedio de problemas por G Desviación Estándar

V1 1 0 0 2 0 1 1 0.71 0.76V2 1 0 0 2 0 1 1 0.71 0.76V3 2 0 0 1 1 0 2 0.86 0.90V4 2 1 0 0 0 1 0 0.57 0.79V5 1 1 2 0 4 1 0 1.29 1.38V6 0 2 0 2 1 1 1 1 0.82V7 5 9 6 6 8 6 7 6.71 1.38V8 1 0 0 0 1 1 0 0.43 0.53V9 1 2 2 0 1 2 1 1.29 0.76V10 1 0 1 0 0 0 1 0.43 0.53V11 3 7 2 2 3 4 4 3.57 1.72V12 2 2 0 2 2 1 2 1.57 0.79V13 1 1 0 0 1 1 1 0.71 0.49V14 1 2 2 0 0 2 2 1.29 0.95V15 1 1 2 1 1 0 1 1.00 0.58V16 1 1 2 1 1 3 0 1.29 0.95V17 1 1 1 1 0 1 1 0.86 0.38V18 0 0 1 1 0 0 0 0.29 0.49Total 25 30 21 21 24 26 25 Promedio entre grupos: 24.57 Promedio: 0.83

Amodo de resumen del análisis Intra-heurísticas, en la Tabla 12 se sinteti-

69

Figura 28: Distribución de problemas por heurística por grupo de evaluadorespara las heurísticas de Control y las heurísticas de Dominio.

zan los resultados obtenidos tras la ejecución de los Tests estadísticos efectua-dos sobre los parámetros: Problemas totales, Problemas comunes, Problemasúnicos, Severidad promedio y Criticidad promedio. Es importante destacarque sólamente en el caso de los parámetros Problemas totales y Problemascomunes los test de hipótesis efectuados demostraron la existencia de dife-rencias signi�cativas; que se comprobaron al aplicar el test no paramétrico deWilcoxon. Aunque el análisis de los parámetros Problemas únicos, Severidad

70

Tabla 12: Resumen del los resultados de análisis estadísticos aplicados a losparámetros Problemas totales, Problemas comunes, Problemas únicos, Seve-ridad promedio y Criticidad promedio

Parámetro ¾Diferencias Signi�ca-tivas t test?

¾Diferencias Signi�ca-tivas Wilcoxon test?

Problemas totales (PT ) 3 3

Problemas comunes (PM ) 3 3

Problemas únicos (PU ) Sin evidencia Sin evidencia

Severidad promedio (S) Sin evidencia Sin evidencia

Criticidad promedio (C ) Sin evidencia Sin evidencia

promedio y Criticidad promedio no presentaron evidencias su�cientes respec-to a la existencia o no de diferencias signi�cativas, los resultados obtenidosfueron su�cientemente concluyentes para determinar que efectivamente, lasheurísticas de dominio, tienen un mejor desempeño que las heurísticas decontrol, en el sentido que permiten detectar una mayor cantidad de proble-mas, incluyendo además aquellos problemas detectados por las heurísticasde control. Cabe mencionar que las evidencias signi�cativas se presentaronen dos de los parámetros más objetivos analizados (Número de problemastotales y comunes) y problablemente, no fue posible determinar diferenciassigni�cativas en los parámetros Severidad y Criticidad debido a la subjetivi-dad de estos parámetros que muchas veces depende del nivel de experienciade los evaluadores que realizan la evaluación heurísticas; y que en este casose trató de grupos de evaluadores poco experimentados.

Por otra parte, cabe recordar que para el análisis de la dispersión deproblemas por heurística no se efectuó prueba de hipótesis, debido a quesi bien el tamaño de la muestra es el mismo (7 grupos), la cantidad deheurísticas de control di�ere de la cantidad de heurísticas de dominio. Así,se optó por realizar un análisis comparativo en base al número promedio deproblemas entre grupos y la desviación estándar de estos valores tanto paralas heurísticas de control como para las heurísticas de dominio, resultando ladesviación estándar de estas últimas más estable que la desviación estándarde las heurísticas de control, permitiendo llegar a la conclusión de que losproblemas están mejor distribuidos en las heurísticas de dominio.

5.3.3. Análisis Inter-Heuristicas.

Durante esta etapa de la validación, se realizó una re-clasi�cación de to-dos los problemas identi�cados por los 14 grupos de evaluadores. El objetivode esta reclasi�cación, fue llevar a cabo un análisis conjunto de los proble-mas de usabilidad detectados, independientemente del conjunto de heurísti-

71

cas utilizado (HD y HC ). Para evitar que la clasi�cación de problemas fuerasesgada hacia uno u otro conjunto de heurísticas, el proceso de reclasi�caciónno fue llevado a cabo por ninguno de los 14 evaluadores que participaron enla validación empírica sino que fue desarrollado por la autora del presen-te trabajo de investistigación bajo la supervisión y asesoría de los profesoresguía y co-guía quienes posteriormente llevaron a cabo el mismo procedimien-to y cuyos resultados están siendo procesados para su presentación en unafutura publicación de la validación.

Así, el total de 172 problemas identi�cados con las heurísticas de Domi-nio y el total de 93 problemas identi�cados con las heurísticas de Controlfueron analizados y codi�cados como un nuevo conjunto de 91 problemas.Este nuevo conjunto de problemas, agrupó a todos los problemas pertene-cientes a ambas categorías tomando en cuenta las similitudes y resolviendoposibles solapamientos entre ellos.

Durante el proceso de re-clasi�cación, cada uno de los problemas iden-ti�cados con las heurísticas de control (HC ) y cada uno de los problemasidenti�cados con las heurísticas de dominio (HD) fue asociado al menos aun problema del nuevo conjunto global de 91 problemas. Así mismo, cadauno de los 91 problemas del nuevo conjunto global fue relacionado con enincumplimiento de una heurística de dominio y una heurística de control.

De los 91 problemas globales, se dedujo que 51 de ellos fueron identi-�cados al utilizar las heurísticas de control (HC ) y 72 fueron identi�cadosmediante las heurísticas de dominio. Esta nueva codi�cación global de pro-blemas, permitió identi�car tres nuevas categorías de problemas:

Problemas Totales Inter-heuristicas (PT ∗)

Problems Comunes Inter-heuristicas (PM ∗)

Problemas Únicos Inter-heuristicas (PU ∗)

La Figura 29 presenta en número de problemas perteneciente a cada unade las categorías mencionadas anteriormente. Es posible observar que la can-tidad de PT ∗y PU ∗es superior para HD , con lo cual se puede concluir que lasheurísticas de Dominio permitieron identi�car una gran parte de problemasque no fueron identi�cados por las heurísticas de control. Es importante se-ñalar, que en este caso, el número de problemas comunes es equivalente paralas heurísticas de Dominio y de Control, debido a que comparamos ambascategorías sobre el mismo conjunto de 91 problemas.

a) Análisis de Problemas Únicos Inter-heurísticas: Con la �nalidad de darsoporte a la la conclusión acerca del mejor rendimiento de las heurís-

72

Figura 29: Problemas Inter-heuristicas Totales (PT ∗), Comunes (PM ∗) yÚnicos(PU ∗)

ticas de dominio (HD) versus las heurísticas de control (HC ), se llevóa cabo el análisis del parámetro de Problemas Únicos. En la etapa7 (Validación) de PROMETHEUS, la cantidad de problemas únicosidenti�cados tanto con las heurísticas de control como con las heu-rísticas de dominio, son parámetros requeridos para calcular el índiceTasa de problemas únicos (ΦP). A partir de la Figura 29 y tomando encuenta la etapa 7 de PROMETHEUS, podemos deducir lo siguiente:

P∗ = 32 debido a que es equivalente a PM ∗

PD = 40 porque corresponde al número de problemas únicos iden-ti�cados con las heurísticas de dominio.

PC =19 porque es el número de problemas únicos identi�cadoscon las heurísticas de control.

Así, utilizamos los parámetros PD y PC (cantidad de problemas úni-cos en las heurísticas de Dominio y de Control respectivamente) paracalcular la tasa de problemas únicos (ΦP) que está de�nida por la ex-presión ΦP =PD/ PC . Después de reemplazar los valores de PD =40 yPC =19, encontramos que ΦP = 2.105. Según la descripción de PRO-METHEUS, si ΦP >1, entonces las heurísticas de dominio tienen unbuen desempeño ya que permitieron encontrar mayor cantidad de pro-blemas únicos que las heurísticas de control.

73

Figura 30: Severidad de los problemas identi�cados en las heurísticas deDominio y de Control.

b) Análisis de Severidad Inter-heurísticas: En base al conjunto global de91 problemas, se calculó el valor promedio de severidad por cada setde heurísticas. El objetivo de este cálculo fue obtener el índice tasade Severidad (λP) el cual está de�nido por la expresión λP = λD/λC . Una vez que se reemplazaron los valores de λD = 2.58 y λC =2.56, correspondientes a la severidad promedio de los problemas en lasheurísticas de control y dominio respectivamente (Ver Tabla 13), en-contramos una tasa de severidad λP = 1.049. De acuerdo a la etapa7 de PROMETHEUS, si λP >1, entonces es posible deducir que lasheurísticas de dominio tienen un buen desempeño ya que permitieronencontrar problemas más severos que las heurísticas de control. Grá�-camente, es posible observar a partir de la Figura 30, que efectivamenteen las heurísticas de Dominio (HD), los problemas identi�cados alcan-zaron mayor niveles de Severidad que los problemas identi�cados conlas heurísticas de Control (HC ).

c) Análisis de dispersión de problemas: La Figura 31 ilustra la dispersiónde problemas entre las heurísticas de Control y de Dominio. Como sepuede observar, aparentemente, existe una distribución más uniformede problemas en las heurísticas de dominio (HD) que en las heurísticasde control (HC ). Sin embargo, con la �nalidad de apoyar o refutaresta apreciación, calculamos la tasa de dispersión (δP) tal como serecomienda en la etapa 7 de PROMETHEUS. El cálculo de la tasa dedispersión se realizó utilizadon la expresión δP = δC /δD . Donde, δC yδD corresponden a los valores de desviación estándar de los problemasdistribuidos en HC y HD respectivamente (Ver Tabla 13). Una vez quese reemplazaron los valores de δC = 3.20 y δD = 3.09, encontramosque δP = 1.037. Según la etapa 7 de PROMETHEUS, si δP >1,

74

Tabla 13: Promedio de Severidad y Cantidad de problemas por heurística enHC y HD

HD (VLEs) HC (Nielsen)

ID Severidad problemas ID Severidad problemas

V1 2.23 3 N1 2.10 3V2 2.32 2 N2 2.42 5V3 1.93 4 N3 2.70 2V4 2.10 2 N4 2.34 6V5 2.07 6 N5 2.90 3V6 2.29 4 N6 2.69 7V7 1.88 14 N7 2.59 9V8 2.70 2 N8 2.13 11V9 2.25 4 N9 2.40 2V10 2.67 3 N10 2.38 3V11 2.00 8V12 3.32 5V13 3.08 2V14 2.83 5V15 3.68 2V16 3.18 4V17 3.10 1V18 2.80 1

Indicadores λD =2.58 δD =3.09 Indicadores λC =2.46 δC =3.20

λD es la tasa de severidad de los problemas identi�cados con las heurísticas de Dominio HD

λC es la tasa de severidad de los problemas identi�cados con las heurísticas de Control HC

δD es la distribución de los problemas en las heurísticas de Dominio HD

δC es la distribución de los problemas en las heurísticas de Control HC

75

Figura 31: Dispersión de problemas en HC y HD

entonces, las heurísticas de dominio tienen un buen desempeño porquelos problemas se encuentran mejor distribuidos en éstas que en lasheurísticas de control.

d) Análisis de especi�cidad: Con la �nalidad de determinar la especi�ci-dad de las heurísticas, realizamos el análisis de especi�cidad sobre losproblemas comunes P∗ que guardan relación con características espe-cí�cas del dominio de aplicación (Entornos Virtuales de Aprendizaje).Tomando en cuenta el mapeo realizado entre las heurísticas de Controly las heurísticas de Dominio presentado en la Tabla 8, excluímos deeste análisis aquellas que que consideramos genéricas por ser similareso estar contenidas en alguna de las heurísticas de control (heurísticasde Nielsen). De esta manera, únicamente 6 de las 18 heurísticas de do-minio fueron incluidas en esta parte del análisis, y las hemos llamadoHeurísticas de Dominio Especí�co. Las 6 heurísticas seleccionadas fue-ron V12, V13, V14, V15, V16 y V18 (Ver Tabla 8). En la Figura 32,se puede observar la cantidad de problemas comunes clasi�cados deacuerdo a una o más Heurísticas de Dominio Especí�co. La línea azulrepresenta la cantidad de problemas comunes PM ∗ asociados a lasheurísticas de dominio especí�co. Es posible observar que únicamente6 de los 32 problemas comunes (PM ∗) fueron associados a alguna delas heurísticas de dominio especí�co. Se llevó a cabo un análisis inde-pendiente de la cantidad de problemas identi�cados con las heurísticasde dominio (línea naranja) y las heurísticas de control (línea gris) yobservamos que básicamente, las heurísticas de Dominio permitieronidenti�car mayor cantidad de problemas especí�cos que las heurísticasde Control.

En la Tabla 14 se resumen los indicadores de desempeño calculados du-rante el análisis Inter-Heurísticas, en base a las consideraciones presentadasen la etapa 7 de PROMETHEUS. Es posible observar, que en los tres casos(Tasa de problemas únicos, Tasa de severidad, Tasa de dispersión), los valo-

76

Figura 32: Problemas Comunes de HC y HD por Heurística de DominioEspecí�co

res obtenidos fueron mayores a 1, lo cual permite deducir el buen desempeñode las heurísticas de Dominio versus las heurísticas de control.

Tabla 14: Indicadores de desempeño resultantes del análisis Inter-heurísticasIndicador Valor ¾Buen desempeño?

Tasa de problemas únicos ΦP = 2.105 3

Tasa de Severidad λP = 1.049 3

Tasa de dispersión δP = 1.037 3

5.4. Validación Post-experimental

Mediante un proceso similar al aplicado en [39] y [31], después de habercompletado la evaluación heurística al caso de estudio de Entorno Virtual deAprendizaje (VLE), se aplicó una encuesta a los 70 evaluadores participantes(35 evaluadores que usaron las heurísticas de Dominio y 35 evaluadores queutilizaron las heurísticas de Control). La encuesta fue diseñada con la �nali-dad de capturar las percepciones de los evaluadores respecto a las heurísticasde Dominio y de Control, en base a cuatro dimensiones Utilidad (D1 ), Cla-ridad (D2 ), Facilidad de uso (D3 ) y Necesidad de elementos adicionalesde evaluación (D4 ). A través de la encuesta, se solicitó a los evaluadores,cali�car las cuatro dimensiones de cada una de las heurísticas utilizadas,

77

utilizando una escala Likert de 5 puntos. La escala Likert contemplaba valo-res que partían desde 1 (Fuertemente en desacuerdo) hasta 5 (Fuertementedeacuerdo).

Tabla 15: Resultados de la encuesta post-evaluation de acuerdo a las dimen-siones Utilidad (D1), Claridad (D2), Facilidad de uso (D3) y Necesidad deelementos adicionales de evaluación (D4)

HD (VLEs) HC (Nielsen)

ID D1 D2 D3 D4 ID D1 D2 D3 D4

V1 3.74 3.89 3.54 2.94 N1 3.51 3.49 3.17 2.49V2 3.80 3.97 3.54 2.69 N2 3.43 3.49 3.17 2.49V3 3.74 3.80 3.60 2.69 N3 3.37 3.34 3.31 2.43V4 3.74 3.77 3.40 2.71 N4 3.26 3.17 3.23 2.43V5 3.77 3.86 3.77 2.89 N5 3.37 3.11 3.09 2.26V6 3.80 3.89 3.66 2.71 N6 3.43 3.26 3.17 2.66V7 3.69 3.71 3.46 2.71 N7 3.54 3.17 3.37 2.31V8 3.66 3.80 3.63 2.57 N8 3.51 3.20 3.57 2.46V9 3.74 3.69 3.57 2.83 N9 3.31 3.26 3.03 2.37V10 3.86 3.71 3.71 2.71 N10 3.00 3.20 3.29 2.43V11 3.80 3.97 3.77 2.69V12 3.77 3.83 3.63 2.57V13 3.89 3.80 3.51 2.54V14 3.80 3.80 3.31 2.66V15 3.97 3.89 3.57 2.63V16 3.83 3.91 3.49 2.57V17 3.94 3.86 3.54 2.74V18 4.03 3.91 3.37 2.63

Promedio 3.81 3.84 3.56 2.69 Promedio 3.37 3.25 3.25 2.44

A partir de los datos presentados en la Tabla 15 comparamos los valorespromedios de cada una de las dimensiones propuestas, tanto para las heurís-ticas de control (HC ) como para las heurísticas de dominio (HD). En todaslas dimensiones (D1, D2, D3 and D4 ), los evaluadores colocaron cali�cacio-nes mayores a las heurísticas de dominio HD que a las heurísticas de controlHC , como se puede apreciar grá�camente en la Figura 33. Lo anterior, per-mitió concluir que las heurísticas de dominio (VLEs), fueron percibidas porlos evaluadores como: más útiles, más fáciles de usar, más claras y con me-nor necesidad de elementos de evaluación adicionales que las heurísticas decontrol (Nielsen).

78

Figura 33: Evaluación de las heurísticas de control (HC ) y heurísticas dedominio (HD) respecto a las dimensiones de Utilidad, Claridad, Facilidad deuso y Necesidad de elementos adicionales.

6. Conclusiones y trabajos futuros

PROMETHEUS es un PROceso METodológico para desarrollar HEu-rísticas de USabilidad propuesto para fortalecer la robustez de las inves-tigaciones que tienen por objetivo el desarrollo de nuevas heurísticas deusabilidad para dominios especí�cos. En base al estudio de Hermawati yLawson [25], considerando las revisiones de literatura de Jiménez [38] yQuiñones [63], y partiendo desde la base de la metodología R3C [66], pro-ponemos un proceso consistente en 7 etapas principales, y un ciclo contínuode re�namiento que consiste en la 8va y última etapa. El análisis previo dela literatura respecto a cómo se desarrollan las heurísticas de usabilidad, asícomo la validadación de la metodología R3C, permitieron responder antici-padamente de manera positiva a la principal pregunta de investigación deesta tesis, relacionada con la necesidad de formalizar un proceso metodológicoque permita desarrollar heurísticas de usabilidad para los diferentes dominiosde aplicación.

Las principales contribuciones de PROMETHEUS son: (i) la especi�-cación detallada de los distintos artefactos consumidos y generados en cada

79

una de las etapas, (ii) la de�nición de indicadores de calidad cuantitativos,y (iii) la de�nición del re�namiento en base a la retroalimentación otorga-da por los indicadores. Estas características hacen de PROMETHEUS unproceso robusto que supera los principales problemas detectados en otras pro-puestas o procesos de desarrollo de heurísticas de usabilidad. Así, utilizandoPROMETHEUS, los investigadores que necesitan desarrollar heurísticas deusabilidad para dominios especí�cos, estarán en capacidad de determinarclaramente las entradas y salidas de cada una de las etapas, a través de unproceso guiado de desarrollo. Por otra parte, los indicadores de calidad pro-porcionan un soporte cuantitativo al proceso, minimizando de cierta forma lasubjetividad presente en este tipo de estudios tradicionalmente cualitativos.Además, el proceso de re�namiento se torna más claro dándole las pautas alinvestigador respecto a las etapas que deben ser re-ejecutadas o re�nadas a�n de lograr establecer un conjunto adecuado de heurísticas. Estas caracte-rísticas sumadas a la �exibilidad de aplicación que brinda PROMETHEUShacen de esta metodología un proceso con�able en donde los investigadoresno necesariamente deben aplicar el camíno crítico de manera completa, sinoque incluso cada una de las etapas pueden ser aplicadas de manera indepen-diente de acuerdo a las necesidades de cada caso de estudio.

Para determinar la validez de PROMETHEUS se llevaron a cabo algu-nas actividades de validación, iniciando con la aplicación de un cuestionarioa investigadores expertos respecto a la utilidad de la metodología R3C. Estaactividad se realizó debido a que R3C fue la base del desarrollo de PRO-METHEUS y consideramos necesario realizar este análisis para determinarlas debilidades y fortalezas que nos permitiera desarrollar nuestra propuestacon mayor robustez y utilidad que su antecesora. Posteriormente, realizamosun análisis retrospectivo de casos relevantes en el estado del arte del dearrolloy uso de heurísticas de usabilidad, cuyos resultados nos permitieron calcularindicadores de calidad para veri�car si nuestra propuesta marchaba por buencamino y realizar los ajustes necesarios a las etapas de PROMETHEUS.Si bien, la validación inicial a través de la aplicación del cuestionario y elanálisis retrospectivo de indicadores a nuestro parecer resultó muy positiva ysugirió nuevas e inmediatas líneas de trabajo de re�namiento de PROMET-HEUS, posteriormente consideramos necesario llevar a cabo una validaciónadicional y completa de nuestra propuesta. Es así, que se procedió a validarPROMETHEUS de manera empírica aplicándolo en un caso de estudio realque tuvo por objetivo el desarrollo de nuevas heurísticas de usabilidad para eldominio de los Entornos Virtuales de Aprendizaje (VLEs). La aplicación dePROMETHEUS en este caso de estudio, permitió seguir el camino críticoy obtener retroalimentación especí�ca en cada una de las etapas propuestas,

80

obteniéndose como producto �nal un conjunto de 18 heurísticas de usabilidadpara evaluar Entornos Virtuales de Aprendizaje que aunque incluyó las 10heurísticas de Nielsen, también consideró aspectos especí�cos de este domi-nio de aplicación que no estaban explicitamente descritos en las heurísticasde Nielsen.

La validación empírica de PROMETHEUS contó inicialmente con laparticipación de 3 investigadores quienes fueron los encargados de aplicar lametodología y obtener el conjunto de heurísticas para Entornos Virtuales deAprendizaje, que posteriormente fueron sometidas a una validación compara-tiva de su rendimiendo frente al rendimiento de otro conjunto tradicional deheurísticas que sirvió como grupo de control. Esta fase de validación compa-rativa, contó con la participación de 70 evaluadores organizados en 14 gruposde 5 personas cada uno. A cada uno de los 14 grupos se les encomendó rea-lizar la evaluación de usabilidad de un entorno virtual de aprendizaje. Sietede los 14 grupos debieron utilizar las heurísticas de control y los otros sietegrupos debieron utilizar las heurísticas de dominio. Aunque todos los par-ticipantes en esta etapa tenían similar per�l académico y profesional, tantola conformación de los grupos como la asignación de tal o cual conjunto deheurísticas se realizó de manera aleatoria con la �nalidad de reducir el sesgoque prodría producir una repartición no al azar. El análisis experimental delos resultados consistió en evaluar el desempeño de ambos grupos de heurís-ticas y compararlo en base a un conjunto de parámetros que fueron de�nidoscomo parte de un análisis intra e inter conjunto de heurísticas.

Con la �nalidad de aportar objetividad a la validación experimental, sellevaron a cabo análisis estadísticos de varios parámetros de�nidos. Así, en elanálisis intra-heurísticas se aplicaron tests de diferencia hipotética de mediasrespecto a los parámetros: Problemas totales, Problemas comunes, Problemasúnicos, Severidad promedio y Criticidad promedio. Los resultados fueron con-cluyentes respecto al mejor desempeño de las heurísticas de dominio frenteal desempeño de las heurísticas de control, para la detección de problemastotales y comunes. En cuanto a los otros parámetros, no se encontraron evi-dencias su�cientes para concluir la existencia de diferencias signi�cativas. Lostest de hipótesis fueron ejecutados asumiendo el supuesto de normalidad ypara corroborar los resultados obtenidos, decidimos aplicar sobre los mismosparámetros, un test estadístico con mayor poder de inferencia, llamado testno-paramétrico para muestras pareadas de �Wilcoxon�. Al aplicar el test deWilcoxon, obtuvimos coincidencia en todos los parámentros analizados an-teriormente con los test de hipótesis, logrando validar el análisis estadísticoefectuado.

Como complemento a los resultados obtenidos en el análisis intra-heurísticas

81

y, debido a la insu�ciente evidencia para determinar diferencias sigini�cativasen todos los parámetros analizados, procedimos a efectuar un análisis inter-heurísticas que consistió en un proceso de re-clasi�cación de todos los pro-blemas indenti�cados por los 14 grupos de evaluadores, en un nuevo listadogeneral de problemas sobre los cuales se calcularon los diferentes indicadoresde calidad recomendados en la etapa 7 de PROMETHEUS. Los resultadosevidenciaron un mejor desempeño de las heurísticas de dominio frente a lasheurísticas de control; lo que implícitamente permitió validar la efectividadde PROMETHEUS para el desarrollo de las heurísticas de dominio.

Una de las pricipales limitaciones de la etapa de validación, fue que elanálisis inter-heurísticas fue realizado por la autora de esta tesis, lo que po-dría llegar a suponer un sesgo en los resultados obtenidos. Para superar estalimitación, se solicitó la participación de 3 personas adicionales que efectura-ron el mismo proceso de re-clasi�cación de problemas y cálculo de indicadorespara posteriormente proceder a contrastar los resultados. Al momento, losresultados están siendo procesados y serán incluidos en una futura publi-cación relacionada con el presente trabajo de investigación. No obstante, lavalidación de PROMETHEUS realizada hasta el momento, nos ha permi-tido a�anzar el hecho de que PROMETHEUS es un proceso metodológicoválido para desarrollar heurísticas de usabilidad especí�cas que mejoren elrendimiento de los métodos tradicionales de evaluación de usabilidad.

Las perspectivas respecto al trabajo futuro de esta investigación se orien-tan hacia al menos tres potenciales líneas de investigación: (i) validaciónempírica adicional, (ii) desarrollo de herramientas de software como apoyoal proceso metodológico propuesto, y (iii) adecuación de PROMETHEUSpara el desarrollo de otros elementos de diseño y/o evaluación de interfaces.Respecto a la primera línea de trabajo futuro, al momento se ha procedido autilizar PROMETHEUS en el desarrollo de heurísticas de usabilidad paraaplicaciones de realidad virtual ; para ello se está trabajando con un estu-diante memorista de la Carrera de Ingeniería en Sistemas y Computaciónde la Universidad Nacional de Chimborazo (UNACH) en Riobamba-Ecuador6 quien preliminarmente ha obtenido un conjunto de 20 heurísticas y se en-cuentra en la etapa de re�namiento del conjunto resultante. En cuanto ala segunda línea de trabajo futuro, se plantea la construcción de una herra-mienta de software sencilla y fácil de utilizar que permita automatizar PRO-METHEUS, básicamente en las etapas de Especi�cidad, Normalización yPriorización de heurísticas, así como también en el cálculo de indicadoresde calidad de la etapa de Validación, para apoyar a los investigadores en

6http://www.unach.edu.ec

82

una tarea que puede resultar tediosa y/o propensa a errores. Por otra parte,tomando en cuenta que PROMETHEUS no propone desarrollar heurísticasde usabilidad desde cero sino que se basa en utilizar el conocimiento existen-te y otros conjuntos de heurísticas de usabilidad relacionados a los dominiosespecí�cos, se propone la creación de una ontología de dominio de lasheurísticas de usabilidad existentes que pueda ser consultada, compartiday nutrida por la comunidad cientí�ca para que a su vez sirva de apoyo ala etapa Búsqueda de heurísticas de usabilidad de PROMETHEUS; dan-do la posibilidad a los investigadores de encontrar conjuntos de heurísticasclasi�cados en base su signi�cado y relación con los diferentes dominios deaplicación. Finalmente, como parte de la tercera línea de trabajo futuro, sepropone analizar la efectividad de PROMETHEUS para desarrollar ele-mentos de diseño de usabilidad de aplicaciones de dominio especí�co. Es así,que hasta el momento se está trabajando en transformar en patrones de usa-bilidad las 18 heurísticas para Entornos Virtuales de Aprendizaje (VLEs)obtenidas durante la etapa de Validación empírica presentada en la Sección5.3. Este trabajo también está siendo realizado por dos memoristas de la Ca-rrera de Ingeniería en Sistemas y Computación de la Universidad Nacionalde Chimborazo (UNACH) en Riobamba-Ecuador y actualmente se encuetranvalidando los patrones obtenidos aplicándolos al VLE de la UNACH 7 parasu posterior evaluación. Es así, que en base a este trabajo se plantea anali-zar la adecuación de PROMETHEUS como un proceso para el desarrollode patrones de usabilidad de aplicaciones de dominio especí�co, donde comoparte de las etapas se incluiría la identi�cación de problemas recurrentesdel dominio de aplicación y se deberán establecer los indicadores de calidadadecuados a esta nueva temática.

7http:moodle.unach.edu.ec

83

Referencias

[1] Roobaea Alroobaea, Ali H Al-badi, and Pam J Mayhew. A Frameworkfor Generating Domain-Speci�c Heuristics for Evaluating Online Edu-cational Websites. International Journal of Information Technology &Computer Science, 8(2):75�84, 2013.

[2] María Elena Alva. Metodología de medición y evaluación de la usabilidaden sitios web educativos. Universidad de Oviedo, 2005.

[3] Francisca Bagnara and Natalia Muñoz. Usabilidad en dispositivos mó-viles táctiles de tipo tablet. In Informe Final Proyecto de Titulación.Ponti�cia Universidad Católica de Valparaíso, 2014.

[4] Brandon Berry. Adapting heuristics for noti�cation systems. In 41stAnnual ACM Southeast Conference, pages 144�149, 2003.

[5] Enrico Bertini, Silvia Gabrielli, and Stephen Kimani. Appropriating andassessing heuristics for mobile computing. In Proceedings of the workingconference on Advanced visual interfaces, pages 119�126. ACM, 2006.

[6] Aníbal Campos, Cristian Rusu, Silvana Roncagliolo, Fabiola Sanz, RaúlGálvez, and Daniela Quiñones. Usability heuristics and design recom-mendations for driving simulators. In Information Technology: NewGenerations, pages 1287�1290. Springer, 2016.

[7] APGD Carrare, CC Hernandez, C Kochi, IF Silveira, and CA Longui.Usability heuristics for clinical case-based learning assessment systemsapplied to medical education. IEEE LATIN AMERICA TRANSAC-TIONS, 13(3):892�898, 2015.

[8] Juan Cofré. Usabilidad en u-learning. In Tesis de Magíster. Ponti�ciaUniversidad Católica de Valparaíso, 2013.

[9] T. Conte, J. Massolar, E. Mendes, and G.H. Travassos. Web usabi-lity inspection technique based on design perspectives. IET Software,3(2):106, 2009.

[10] Kamila Rios da Hora Rodrigues, Cesar Augusto Camillo Teixeira, andVânia Paula de Almeida Neris. Heuristics for assessing emotional res-ponse of viewers during the interaction with tv programs. In Inter-national Conference on Human-Computer Interaction, pages 577�588.Springer, 2014.

84

[11] Heather Desurvire and Charlotte Wiberg. Game usability heuristics(play) for evaluating and designing better games: the next iteration.In Online communities and social computing, pages 557�566. Springer,2009.

[12] Jaime Díaz, Cristian Rusu, J Antonio Pow-Sang, and Silvana Ronca-gliolo. A cultural-oriented usability heuristics proposal. In Proceedingsof the 2013 Chilean Conference on Human-Computer Interaction, pages82�87. ACM, 2013.

[13] Joe Dumas. The great leap forward: The birth of the usability profession(1988-1993). Journal of Usability Studies, 2(2):54�60, 2007.

[14] International Organization for Standardization and International Elec-trotechnical Commission. Software Engineering�Product Quality: Qua-lity model, volume 1. ISO/IEC, 2001.

[15] Fernanda Freire Franklin. Heurísticas de usabilidad para sistemas cola-borativos remotos de realidade aumentada. Diseratacion de Maestria,2014.

[16] Nathan Gale, Pejman Mirza-Babaei, and Isabel Pedersen. Heuristic gui-delines for playful wearable augmented reality applications. In Procee-dings of the 2015 Annual Symposium on Computer-Human Interactionin Play, pages 529�534. ACM, 2015.

[17] Juan Gómez Reynoso and Marcelo Perez Ramos. Evaluación de la ca-lidad del portal de egobierno en méxico. In CTwenty-second AmericasConference on Information Systems (AMCIS), San Diego, California,USA, 2016.

[18] Marta González, Llúcia Masip, Antoni Granollers, and Marta Oliva.Análisis cuantitativo en un experimento de evaluación heurística. In IXCongreso Internacional Interacción, pages 9�11, 2008.

[19] John D Gould and Clayton Lewis. Designing for usability: key principlesand what designers think. Communications of the ACM, 28(3):300�311,1985.

[20] Andrina Grani¢, Ivica Mitrovi¢, and Nikola Maranguni¢. Exploring theusability of web portals: A croatian case study. International journal ofinformation management, 31(4):339�349, 2011.

85

[21] Cristhy Jimenez Granizo, Pablo Lozada Yanez, Danilo Pastor Ramirez,and Patricia Cordovez Machado. Usability in e-government sites. InInformation Technology: New Generations (ITNG), 2011 Eighth Inter-national Conference on, pages 453�458. IEEE, 2011.

[22] Xavier Ferré Grau. Principios básicos de usabilidad para ingenierossoftware. In JISBD, pages 39�46, 2000.

[23] H. Rex Hartson, Terence S. Andre, and Robert C. Williges. Criteriafor evaluating usability evaluation methods. International Journal ofHuman-Computer Interaction, 15(1):145�181, 2003.

[24] Florian Häser, Michael Felderer, and Ruth Breu. An integrated tool en-vironment for experimentation in domain speci�c language engineering.In Proceedings of the 20th International Conference on Evaluation andAssessment in Software Engineering, page 20. ACM, 2016.

[25] Setia Hermawati and Glyn Lawson. Establishing usability heuristics forheuristics evaluation in a speci�c domain: Is there a consensus? AppliedErgonomics, 56:34 � 51, 2016.

[26] Andreas Holzinger. Usability engineering methods for software develo-pers. Communications of the ACM, 48(1):71�74, 2005.

[27] James Hom. The usability methods toolbox handbook. Fuente:http://www.idemployee.id.tue.nl/g.w.m.rauterberg/lecturenotes /usabi-litymethodstoolboxhandbook.pdf (Consultado el 27-07-17), 1998.

[28] R. Inostroza, C. Rusu, S. Roncagliolo, C. JimÃ c©nez, and V. Rusu. Usa-bility heuristics validation through empirical evidences: A touchscreen-based mobile devices proposal. In Chilean Computer Science Society(SCCC), 2012 31st International Conference of the, pages 60�68, Nov2012.

[29] Rodolfo Inostroza. Usabilidad en dispositivos móviles táctiles. Trabajode Titulación, 2014.

[30] Rodolfo. Inostroza, Cristia. Rusu, Silvana. Roncagliolo, Cristhy. Jime-nez, and Virginica. Rusu. Usability heuristics for touchscreen-basedmobile devices. In Information Technology: New Generations (ITNG),2012 Ninth International Conference on, pages 662�667, April 2012.

86

[31] Rodolfo Inostroza, Cristian Rusu, Silvana Roncagliolo, Virginica Rusu,and CÃ c©sar A. Collazos. Developing smash: A set of smartphone'susability heuristics. Computer Standards and Interfaces, 43:40 � 52,2016.

[32] W ISO. 9241-11. ergonomic requirements for o�ce work with visualdisplay terminals (vdts). The international organization for standardi-zation, 45, 1998.

[33] Jackob Nielsen. 10 Heuristics for User Interface Design: Article by JakobNielsen, 1995.

[34] Pooya Jaferian, Kirstie Hawkey, Andreas Sotirakopoulos, Maria Velez-Rojas, and Konstantin Beznosov. Heuristics for evaluating IT securitymanagement tools. SOUPS '11: Proceedings of the Seventh Symposiumon Usable Privacy and Security, pages 1�20, 2011.

[35] Nielsen Jakob. Usability engineering. Fremont, California: Morgan,1993.

[36] C. Jimenez, C. Rusu, S. Roncagliolo, R. Inostroza, and V. Rusu. Evalua-ting a methodology to establish usability heuristics. In Chilean Compu-ter Science Society (SCCC), 2012 31st International Conference of the,pages 51�59, Nov 2012.

[37] Cristhy Jimenez, Pablo Lozada, and Pablo Rosas. Usability heuristics:A systematic review. In Computing Conference (CCC), 2016 IEEE 11thColombian, pages 1�8. IEEE, 2016.

[38] Cristhy Jimenez, Pablo Lozada, and Pablo Rosas. Speci�c-domain usa-bility heuristics: Are they really necessary?. Revista Romana de Inter-actiune Om-Calculator 10(1), pages 1�24, 2017.

[39] Cristhy Jimenez, Cristian Rusu, Virginica Rusu, Silvana Roncagliolo,and Rodolfo Inostroza. Formal speci�cation of usability heuristics: Howconvenient it is? In Proceedings of the 2Nd International Workshop onEvidential Assessment of Software Technologies, EAST '12, pages 55�60, New York, NY, USA, 2012. ACM.

[40] Sta�s Keele et al. Guidelines for performing systematic literature re-views in software engineering. In Technical report, Ver. 2.3 EBSE Tech-nical Report. EBSE. sn, 2007.

87

[41] Barbara A. Kitchenham. Systematic review in software engineering:Where we are and where we should be going. In Proceedings of the 2NdInternational Workshop on Evidential Assessment of Software Techno-logies, EAST '12, pages 1�2, New York, NY, USA, 2012. ACM.

[42] Steve Krug. Don't make me think!: a common sense approach to Webusability. New Riders, 2005.

[43] Liisa Kuparinen, Johanna Silvennoinen, and Hannakaisa Isomäki. Intro-ducing Usability Heuristics for Mobile Map Applications. Proceedingsof the 26th International Cartographic Conference (ICC 2013)., 2013.

[44] Jesús Lorés, Toni Granollers, and Sergi Lana. Introducción a la inter-acción persona-ordenador. Universidad de Lleida, 2002.

[45] Huizilopoztli Luna, Ricardo Mendoza, Miguel Vargas, Jaime Munoz,Francisco J Alvarez, and Laura C Rodriguez. Using design patterns asusability heuristics for mobile groupware systems. IEEE Latin AmericaTransactions, 13(12):4004�4010, 2015.

[46] Jennifer Manko�, Anind K Dey, Gary Hsieh, Julie Kientz, Scott Lede-rer, and Morgan Ames. Heuristic evaluation of ambient displays. InProceedings of the SIGCHI conference on Human factors in computingsystems, pages 169�176. ACM, 2003.

[47] Pedro Juan Molina Moreno. Especi�cación del interfaz de usuario: delos requisitos a la generación automática. PhD thesis, Universitat Poli-tècnica de València, 2003.

[48] Roberto Munoz and Virginia Chalegre. De�ning Virtual Worlds Usa-bility Heuristics. 2012 Ninth International Conference on InformationTechnology - New Generations, pages 690�695, apr 2012.

[49] Edvar Vilar Neto and Fábio FC Campos. Evaluating the usability onmultimodal interfaces: a case study on tablets applications. In Inter-national Conference of Design, User Experience, and Usability, pages484�495. Springer, 2014.

[50] Olibário Machado Neto and Maria Da Graça Pimentel. Heuristics forthe Assessment of Interfaces of Mobile Devices. Proceedings of the 19thBrazilian symposium on Multimedia and the web - WebMedia '13, pages93�96, 2013.

88

[51] Jakob Nielsen and Rolf Molich. Heuristic evaluation of user interfaces. InProceedings of the SIGCHI Conference on Human Factors in ComputingSystems, CHI '90, pages 249�256, New York, NY, USA, 1990. ACM.

[52] Bevan Nigel, K Jurek, and M Jonathan. What is usability. In 4thInternational Conference on HCI, pages 1�6, 1991.

[53] Chitu Okoli and Kira Schabram. A guide to conducting a systematicliterature review of information systems research. Available at SSRN1954824, 2010.

[54] R Otaiza. Metodología de evaluación de usabilidad para aplicacionesweb transaccionales. Magíster en Ingeniería Informática Tesis de Gra-do, Escuela de Ingeniería Informática, Ponti�cia Universidad Católicade Valparaíso, Valparaíso, Chile, 2008.

[55] F. Paz, F. A. Paz, J. A. Pow-Sang, and L. Collantes. Usability heuristicsfor transactional web sites. In Information Technology: New Generations(ITNG), 2014 11th International Conference on, pages 627�628, April2014.

[56] Lyn Pemberton and Richard Gri�ths. Usability evaluation techniquesfor interactive television. In Proceedings of HCI International, volume 4,pages 882�886, 2003.

[57] S Pértega Díaz and S Pita Fernández. Métodos paramétricos para lacomparación de dos medias. t de student. Cad Aten Primaria, 8:37�41,2001.

[58] Kai Petersen, Robert Feldt, Shahid Mujtaba, and Michael Mattsson.Systematic mapping studies in software engineering. In Proceedingsof the 12th International Conference on Evaluation and Assessment inSoftware Engineering, EASE'08, pages 68�77, Swinton, UK, UK, 2008.British Computer Society.

[59] Deniese Pierotti. Heuristic evaluation-a system checklist. Xerox Corpo-ration, 1995.

[60] Mariano Pimentel, Ronaldo Goldbach, and Allan Telles Bessa. Heu-rísticas de usabilidade orientadas às redes sociais. IV Encuentro deAdministracion de Informacion, 2013.

89

[61] David Pinelle, Nelson Wong, Tadeusz Stach, and Carl Gutwin. Usabilityheuristics for networked multiplayer games. Proceedings of the ACM2009 international conference on Supporting group work, pages 169�178,2009.

[62] Derek Poppink. Evaluating international usability of virtual worlds. InCHI'00 Extended Abstracts on Human Factors in Computing Systems,pages 343�344. ACM, 2000.

[63] Daniela Quiñones and Cristian Rusu. How to develop usability heuris-tics: A systematic literature review. Computer Standards & Interfaces,53:89�122, 2017.

[64] Yvonne Rogers, Helen Sharp, and Jenny Preece. Interaction design:beyond human-computer interaction. John Wiley & Sons, 2011.

[65] Silvana Roncagliolo, Virginica Rusu, Cristian Rusu, Gonzalo Tapia, Da-nae Hayvar, and Dorian Gorgan. Grid computing usability heuristics inpractice. In Information Technology: New Generations (ITNG), 2011Eighth International Conference on, pages 145�150. IEEE, 2011.

[66] Cristian Rusu, Silvana Roncagliolo, Virginica Rusu, and Cesar Collazos.A methodology to establish usability heuristics. In Proc. 4th Internatio-nal Conferences on Advances in Computer-Human Interactions (ACHI2011), IARIA, pages 59�62, 2011.

[67] Cristian Rusu, Silvana Roncagliolo, Gonzalo Tapia, Danae Hayvar, Vir-ginica Rusu, and Dorian Gorgan. Usability heuristics for grid compu-ting applications. In Proceedings of The 4th International Conferenceson Advances in Computer-Human Interactions ACHI, 2011.

[68] Fabiola Sanz, Raúl Galvez, Cristian Rusu, Silvana Roncagliolo, Virgi-nica Rusu, César A Collazos, Juan Pablo Cofré, Aníbal Campos, andDaniela Quiñones. A set of usability heuristics and design recommen-dations for u-learning applications. In Information Technology: NewGenerations, pages 983�993. Springer, 2016.

[69] Gavin Sim, Janet C Read, and Gilbert Cockton. Evidence based designof heuristics for computer assisted assessment. In IFIP Conference onHuman-Computer Interaction, pages 204�216. Springer, 2009.

[70] Akash Singh and Janet Wesson. Evaluation criteria for assessing theusability of ERP systems. Proceedings of the 2009 Annual Research

90

Conference of the South African Institute of Computer Scientists andInformation Technologists, 125(October):87�95, 2009.

[71] Andres Solano, Cristian Rusu, Cesar Collazos, Silvana Roncagliolo, Jo-se Luis Arciniegas, and Virginica Rusu. Usability heuristics for interacti-ve digital television. In The Third International Conference on Advancesin Future Internet, pages 60�63, 2011.

[72] Andres Solano, Cristian Rusu, Cesar A Collazos, and Jose Arciniegas.Evaluating interactive digital television applications through usabilityheuristics/evaluando aplicaciones de television digital interactiva a tra-ves de heuristicas de usabilidad. Ingeniare: Revista Chilena de Ingenie-ria, 21(1):16, 2013.

[73] Jacob Somervell and D. Scott McCrickard. Better discount evaluation:Illustrating how critical parameters support heuristic creation. Interac-ting with Computers, 17(5):592�612, 2005.

[74] María del Carmen Suárez Torrente, Doctor D Juan Manuel Cueva Lo-velle, and Doctora Dña Ana Belén Martínez Prieto. Sirius: Sistemade evaluación de la usabilidad web orientado al usuario y basado en ladeterminación de tareas críticas. Universidad de Oviedo, 2011.

[75] Katherine M Tsui, Kareem Abu-Zahra, Renato Casipe, Jason M Sa-doques, and Jill L Drury. Developing heuristics for assistive robotics.In Human-Robot Interaction (HRI), 2010 5th ACM/IEEE InternationalConference on, pages 193�194. IEEE, 2010.

[76] Frank Wilcoxon. Individual comparisons by ranking methods. Biome-trics bulletin, 1(6):80�83, 1945.

[77] Rosa Yáñez Gómez, Daniel Cascado Caballero, and José-Luis Sevillano.Heuristic evaluation on mobile interfaces: a new checklist. The Scienti�cWorld Journal, 2014, 2014.

91

A. Descripción Detallada de PROMETHEUS

A continuación presentamos una explicación detallada de cada una delas 8 etapas de PROMETHEUS. Para cada una de ellas se describe supropósito, se especi�can los artefactos de entrada y de salida, y se discutesobre su relevancia. Tal como se muestra en la Figura 23, las 8 etapas dePROMETHEUS son:

1. Búsqueda de información especí�ca

2. Búsqueda de heurísticas de usabilidad

3. Especi�cidad de heurísticas

4. Normalización de heurísticas

5. Priorización de heurísticas

6. Descripción detallada de heurísticas

7. Validación

8. Re�namiento

A.1. Etapa 1: Búsqueda de información especí�ca.

La primera etapa tiene un carácter exploratorio, y su objetivo principales determinar las dimensiones características de un dominio especí�co D .Las dimensiones características propuestas son las siguientes:

1. Contextos de uso, UC .

2. Dispositivos lógicos de interacción, LD .

3. Dispositivos físicos de interacción, PD .

4. Per�les de usuario, UP .

Entrada Se requiere el nombre o descripción del dominio D para comen-zar a determinar las dimensiones características. Por ejemplo: �grid compu-ting�, �e-learning�, etc.

Salida Esta etapa produce dos artefactos. El primero es un listado dekeywords relevantes para la búsqueda bibliográ�ca en la siguiente etapa (Ap-pendix A.2). El segundo es el listado de dimensiones características y sus

92

indices de especi�cidad iniciales, que se resume en tablas como la Tabla 16,una para cada dimensión característica. Los valores de especi�cidad siguenuna escala de Likert estándar de 5 niveles, donde 0 es Nada especí�co y 4es Absolutamente especí�co. Los puntajes de especi�cidad se consumen en laetapa 5 (Appendix A.5) para el cálculo del índice de especi�cidad �nal.

Tabla 16: Ejemplo tabla especi�cidad inicial para contextos de usoContexto de Uso Especi�cidad

Indoor 3Outdoor 2Ruidoso 2Silencioso 4

Un objetivo inmediato para trabajos futuros es confeccionar un listadocon sugerencias predeterminadas para cada dimensión característica. Porejemplo, sugerir dispositivos físicos tales como computadores de escritorio,tablets, celulares, touchscreen, etc., para agilizar la realización de esta etapa.

A.2. Etapa 2: Búsqueda de heurísticas de usabilidad.

El objetivo de esta etapa es realizar una búsqueda bibliográ�ca paraidenti�car conjuntos de heurísticas de usabilidad relacionadas con el dominioD en estudio. En general, y como práctica recomendada de investigación, sesugiere la realización de un mapeo sistemático o una revisión sistemática deliteratura [58, 41].

Entrada En esta etapa se utilizan los keywords relacionados al dominio,provenientes de la etapa 1 (Appendix A.1).

Salida En esta etapa se obtienen conjuntos de heurísticas S1, . . . , Sn, queson potencialmente aplicables al dominio. Se debe asignar a cada heurísticaun identi�cador único, por ejemplo, HS1

1 representa la primera heurísticadel conjunto S1. En caso de existir un conjunto de heurísticas validado pa-ra el dominio y que esté acorde a las necesidades de los investigadores, esposible terminar la aplicación de PROMETHEUS en este punto. Dichasheurísticas también pueden servir como heurísticas de control en la etapa 7(Appendix A.7), en caso que se de�nan nuevas heurísticas para el dominio.

En general las etapas 1 y 2 especi�can cómo realizar a cabo el proceso deextracción de información, reportado por Hermawati y Lawson [25], dandorecomendaciones especí�cas sobre cómo llevar a cabo la búsqueda, y tomandoen consideración los aspectos determinantes del dominio en estudio.

93

A.3. Etapa 3: Especi�cidad de heurísticas.

Con el �n de realizar un �ltrado inicial, en esta etapa se asigna un índicede especi�cidad inicial ISI , asociado a cada heurística encontrada en la etapaanterior.

Entrada Se requieren los conjuntos de heurísticas S1, . . . , Sn identi�ca-dos en la etapa anterior.

Salida En esta etapa se obtiene una tabulación de las heuristicas juntoa sus índices de especi�cidad inicial, como se ejempli�ca en la Tabla 17. Sedice que estas heurísticas están desnormalizadas ya que aún no se resuelvencon�ictos de duplicidad y/o solapamiento entre las heurísticas. Sin embargo,es posible hacer un ránking de heurísticas y eliminar aquellas consideradaspoco aplicables para el dominio.

Tabla 17: Índices de especi�cidad inicial para heurísticas desnormalizadasHeurística ISI

HS11 3...

...HS1k1

4...

...HSnkn

5

A.4. Etapa 4: Normalización de heurísticas.

El objetivo de esta etapa es resolver posibles casos de solapamiento, oduplicidad en las heurísticas obtenidas hasta el momento.

Entrada Como entrada se reciben las heurísticas desnormalizadas, juntoa sus indicadores iniciales de especi�cidad.

Salida En esta etapa se produce un conjunto preliminar de heurísticasaplicables al dominio, con la garantía de que no existen problemas de sola-pamiento o duplicidad entre las heurísticas. Cada heurística contará con unpuntaje ISI , posiblemente revisado luego de la normalización.

En general, los casos de multiplicidad pueden ser resueltos a través dealguna de las siguientes alternativas:

Mantener una de las heurísticas que presentan similitud y descartar lasotras.

94

Descartar las heurísticas similares y reformular una nueva heurística,que combine las características de aquellas que la componen.

Asimismo, los casos de solapamiento pueden ser resueltos mediante algunade estas estrategias:

Mantener una heurística general que agrupe las heuristicas solapadas.

Separar las heurísticas solapadas en varias heurísticas individuales.

Este proceso de resolución de solapamiento y multiplicidad debe ser eje-cutado iterativamente hasta obtener un conjunto normalizado de heurísticas,es decir, un conjunto sin solapamientos o multiplicidades. Nótese que si secrean nuevas heurísticas al aplicar las estrategias descritas, éstas deben te-ner también un identi�cador único. Finalmente, es recomendable revisar yreconsiderar los valores de especi�cidad ISI para cada una de las heurísticasnormalizadas.

A.5. Etapa 5: Priorización de heurísticas.

El objetivo de esta etapa es sintetizar la aplicabilidad de las heurísticasnormalizadas considerando la especi�cidad de cada una de ellas respecto alos contextos de uso, además de los indicadores iniciales de especi�cidad,para tener un listado rankeable de heurísticas aplicables al dominio.

Entrada Esta etapa recibe las heurísticas normalizadas obtenidas en laetapa anterior, junto a los indicadores ISI respectivos. Además, trabaja conlas dimensiones características, UC , PD , LD , UP ; obtenidas en la etapa 1.

Salida El producto principal de esta etapa es la matriz de especi�cidad,tal como la que se ejempli�ca en la Tabla 18, la que permite realizar unúltimo proceso de ránking y de selección de las heurísticas que se considerenmás aplicables al dominio.

Tabla 18: Ejemplo Matriz de Especi�cidad para HeurísticasHeurística ISI GSIUC GSIPD GSILD GSIUP FSI

HS32 3 4 2 1 3 1.875

HS33 1 1 2 4 0 0.4375

HS42 1 3 2 3 0 0.5

......

......

......

...

95

Esta matriz contiene, para cada heurística Hj , el resumen de los siguientesindicadores de especi�cidad:

ISI : indicador inicial de especi�cidad, generado en la etapa 1 y re�nadoen la etapa 4.

GSIUC , GSIPD , GSILD y GSIUP : indicadores globales de especi�cidadde cada dimensión característica. Para ejempli�car el cálculo de estosindicadores, consideremos la dimensión UC para la cual se elabora unatabulación tal como en la Tabla 19. A cada contexto de uso se le asignaun puntaje de especi�cidad, y el puntaje GSIUC es el promedio de cada�la. De manera similar, se construyen tablas para las otras dimensionescaracterísticas.

Tabla 19: Especi�cidad para contextos de uso y cálculo de GSIUC

Heurística Indoor Outdoor Ruidoso Silencioso GSIUC

HS32 4 4 4 4 4

HS33 4 0 0 0 1

HS24 4 2 2 4 3

......

......

...

Finalmente, el índice �nal de especi�cidad FSI sintetiza en un sólo valorla especi�cidad y aplicabilidad al dominio de las distintas heurísticas, consi-derando la valoración inicial y la valoración en cada una de las dimensionescaracterísticas. Para una heurística Hj , el indice se calcula con la siguientefórmula:

FSIHj = 4 ∗ISIHj ∗

∑GSI {UC ,LD ,PD ,UP}

64

El valor �nal de FSI varía entre 0 y 4 y, en general, se espera que un altovalor FSI indique alta aplicabilidad de la heurística, aunque el criterio �nalde selección queda siempre en poder de los investigadores involucrados, perocon el respaldo metodológico que otorga PROMETHEUS.

A.6. Etapa 6: Descripción detallada de heurísticas.

En esta etapa se formaliza la descripción de las heurísticas seleccionadasen la etapa anterior, ya con el �n de diseñar el protocolo de validación expe-

96

rimental para la etapa 7. Dicha descripción formal permite proveer, particu-larmente a los evaluadores notavos, información necesaria para comprendery aplicar las heurísticas de dominio al realizar una evaluación heurística,tal como se evidencia en [39]. La Tabla 20 presenta un formato de plantillaque puede usarse en esta etapa. Esta plantilla toma la base propuesta porR3C [66], y agrega un nuevo campo, Checklist, con la intención de facilitaraún más la aplicación, siguiendo las sugerencias en [39].

Entrada Conjunto de heurísticas seleccionadas para su aplicación al do-minio.

Salida Descripción formal de cada una de las heurísticas, en base a laplantilla estándar.

Tabla 20: Plantilla estándar para describir heurísticas de usabilidad.Identi�cador de la Heurística

Nombre Nombre que identi�ca a laheurística

Descripción Explicación detallada de laheurística.

Ejemplos Ejemplos de violación y cum-plimiento de la heurística.

Bene�cios Bene�cios esperados de usabi-lidad cuando se cumple la heu-rística.

Problemas Problemas anticipados pormal entender la heurística du-rante las evaluaciones de usa-bilidad.

Contexto de aplicación Información Adicional respec-to a la aplicabilidad de lasheurísticas.

Heurísticas relacionadas Referencia a otras heurísti-cas que tienen relación consu cumplimiento o incumpli-miento.

Checklist Desagregación de la heurísticaen términos o criterios especí-�cos según las característicasde la aplicación.

97

A.7. Etapas 7 y 8: Validación y Re�namiento.

El propósito �nal de PROMETHEUS culmina en las etapas de valida-ción y re�namiento, en las cuales se busca validar empíricamente que lasheurísticas de dominio seleccionadas son más efectivas que un grupo de heu-rísticas de control. Tal como se explicó en la Sección 4.2, PROMETHEUSde�ne indicadores cuantitativos de calidad para realizar esta comparación, ypara guiar el proceso de re�namiento iterativo en caso de ser necesario. Porsupuesto, siempre es recomendable realizar validaciones adicionales, sobretodo de tipo cualitativo; PROMETHEUS provee una base sólida para lavalidación de las heurísticas de dominio.

Entrada Las heurísticas de dominio seleccionadas, junto a su descripciónformal. Además, el conjunto de heurísticas de control a utilizar. Por defectodeben usarse las heurísticas de Nielsen [33] como grupo de control, a menosque existan heurísticas más especí�cas y que ya estén validadas.

Salida Luego de la evaluación experimental se obtienen los siguientesartefactos:

Conjunto de problemas detectados en la(s) evaluación(es) heurísticas.Los problemas se clasi�can en problemas comunes, P∗, problemas es-pecí�cos de las heurísticas de dominio, PD , y problemas especí�cosde las heurísticas de control PC . Cada problema está asociado a unaheurística en particular.

Para cada problema se especi�ca su severidad, usando una escala deLikert con 5 niveles.

Para cada problema en P∗ = P∗ ∪PC , un coe�ciente de especi�cidad,con una escala similar a la de severidad.

Además, con dicha información se calculan los siguientes indicadores de ca-lidad:

Tasa de problemas únicos ΦP .

Tasa de dispersión de problemas δP .

Tasa de severidad de problemas λP .

Tasa de especi�cidad de problemas εP .

En cuanto a los indicadores, éstos ya fueron descritos en la Sección 4.2,y sólo nos basta precisar la de�nición de la tasa de especi�cidad εP . Recor-demos que este indicador se de�ne como sigue:

98

εP = εD/εC

donde εD y εC son los promedios de especi�cidad de los problemas encon-trados, respectivamente, por las heurísticas de dominio y las heurísticas decontrol.

El punto que debemos explicar es que las maneras de calcular εD y εC sondiferentes, aunque apuntan a cuanti�car el mismo fenómeno: cuán especí�cosson los problemas encontrados. El problema es que cuando las heurísticas decontrol son muy generales, por ejemplo como las de Nielsen, es difícil decidircuándo un problema es especí�co al dominio. Es por eso que se requiereque los problemas en P∗C estén cali�cados en cuanto a su especi�cidad. Estoquiere decir, que εC corresponde al promedio simple de la especi�cidad decada problema. Sin embargo, por otro lado, las heurísticas de dominio hansido diseñadas y seleccionadas en base a sus indices de especi�cidad�enparticular el FSI que sintetiza esta característica, a nivel de heurística. Portanto, εD corresponde a una suma ponderada de la cantidad de problemasen cada heurística, multiplicada por el FSI asociado a ella. En resumen, setiene que:

εD =

∑Hj

(|P ∈ HDj | ∗ FSI j)

|P∗D |

εC =

∑ni=1 ε(Pi)

|P∗C |

para toda heurística de dominio Hj , donde:

|P ∈ Hj | es la cantidad de problemas asociados a dicha heurística.

|P∗D | y |P∗| corresponden respectivamente a la cantidad de problemasde dominio y de control.

FSI j es el índice de especi�cidad �nal para dicha heurística Hj .

n es la cantidad total de problemas en P∗C

ε(Pi) es la especi�cidad individual de un problema Pi dado, y asociadoa los problemas del grupo de control.

99

B. Entrevista para validación inicial de PROMET-HEUS

En esta sección se presenta la entrevista realizada como parte de la va-lidación inicial de PROMETHEUS, que estuvo diseñada para recoger in-formación respecto a la percepción de PROMETHEUS como metodologíapara la creación de heurísticas de usabilidad, en base a los siguientes aspectosy cuyas preguntas se resumen en la tabla 21.

Modo de aplicación

Interés o producto �nal

Etapas aplicadas

Etapas más fáciles y/o más difíciles

Utilidad

Cuanti�cación del tiempo de aplicación

Mecanismos de validación de los productos generados

Planes futuros de aplicación del proceso

100

Tabla 21: Preguntas de la entrevista ejecutada en la validación inicial dePROMETHEUS

Pregunta Propósito¾Cuál es su tema de estudio? Determinar el dominio especí�co

sobre el que el investigador estátrabajando

¾Qué producto o productos esperaobtener en su investigación?

Conocer si el interés delinvestigador era obtener nuevasheurísticas, re�nar existentes ollevar a cabo una descripcióndetallada de las heurísticas

¾Qué etapas de PROMETHEUScree usted son aplicables a suinvestigación?

Determinar la aplicabilidadpotencial de las etapas dePROMETHEUS en el proyectodel investigador

Considerando las etapaspotencialmente aplicables, ¾cuálesconsidera serían las más fáciles deaplicar?

Determinar la facilidad deaplicación de las etapasconsideradas aplicables

Considerando las etapaspotencialmente aplicables, ¾cuálesconsidera serían las más difícilesde aplicar?

Determinar la di�cultad deaplicación de las etapasconsideradas aplicables

¾Considera necesario agregarnuevas etapas o actividades en lametodología?

Obtener opinión de experto sobre lacantidad adecuada de etapas paraPROMETHEUS

¾Considera necesario quitar oconsolidar etapas o actividades enla metodología?

Obtener opinión de experto sobre lacantidad adecuada de etapas paraPROMETHEUS

¾Se entiende la manera de aplicarla metodología en general?

Identi�car la percepción sobre laclaridad de la descripción generaldel proceso

¾Se entiende la manera de aplicarcada etapa en particular?

Identi�car la percepción sobre laclaridad de la descripción especí�cade cada etapa del proceso

¾Considera útil la metodología engeneral y cada una de las etapas?

Identi�car la percepción sobre lautilidad del proceso

¾Considera que los indicadores decalidad de�nidos enPROMETHEUS son perinentesy apuntan a una validacióncuantitativa efectiva?

Identi�car opinión sobre pertinenciade los indicadores

¾Considera que los indicadores decalidad de�nidos enPROMETHEUS son fáciles decalcular?

Obtener opinión sobre facilidad decálculo de los indicadores de calidad

101

prometheus: proceso metodológico para desarrollar...

Documents