Miim estudio usabilidad_idiomamoderno_juancarloshernandezgutierrez ok

M´ster en Inform´tica Interactiva y Multimedia
a
a
Escuela T´cnica Superior de Ingenier´ Inform´tica
e
ıa
a
Curso acad´mico 2011-2012
e

Trabajo Fin de Master

ESTUDIO DE USABILIDAD DEL SISTEMA
´
TELEMATICO “IDIOMA MODERNO” EN LA
UNIVERSIDAD REY JUAN CARLOS

Autor:

Juan Carlos Hern´ndez Guti´rrez
a
e

Tutora:

Estefan´ Mart´ Barroso
ıa
ın

Julio 2012

A mis padres, hermano y Lorena

Agradecimientos

Agradezco a todos mis compa˜eros del M´ster y a sus profesores la realizaciń de este
n
a
o
m´ster, que me ha enseãdo conceptos que normalmente no se ven en el trabajo diario y
a
n
son muy importantes.
Quiero hacer una menciń especial a Lorena y Saray quienes han estado en todo
o
momento ayudńdome.
a
A todos vosotros, gracias.

Licencia de este documento

El presente documento se distribuye bajo la licencia Creative Commons Reconocimiento no comercial - compartir bajo la misma licencia 2.5, cuyos
t´rminos pueden encontrarse en la Web1 . La presente licencia, le otorga permiso para:
e
Copiar, distribuir y publicar libremente la obra
Hacer obras derivadas
Bajo las condiciones siguientes:
Reconocimiento: Debe reconocer los cr´ditos de la obra de la manera especificada por
e
el autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o
apoyan el uso que hace de su obra).
No comercial. No puede utilizar esta obra para fines comerciales.
Compartir bajo la misma licencia. Si altera o transforma esta obra, o genera una obra
derivada, s´lo puede distribuir la obra generada bajo una licencia idńtica a ´sta.
o
e
e

1

http://creativecommons.org/licenses/by-nc-sa/2.5/es/

Resumen

En la actualidad podemos observar que aunque Internet y los ordenadores estń
a
totalmente introducidos en nuestras vidas diarias y prćticamente todo est´ informatizado,
a
a
existen ciertas tareas que bien por comodidad, bien por falta de presupuestos para
modernizarse, ań se realizan de forma manual. En el caso de la Universidad Rey Juan
u
Carlos, se est´ haciendo el esfuerzo para que, en la medida de lo posible, la mayor´ de
a
ıa
los procesos que se realizan, estń informatizados. Es por ello que este proyecto se centra
e
en la generaciń de una herramienta de trabajo para uno de los departamentos de esta
o
universidad.
Desde el Centro Universitario de Idiomas, a partir de ahora le llamaremos CUI, se
gestiona una de las asignaturas obligatorias para todos los grados, que existe desde la
instauraciń del nuevo Plan de Bolonia. Esta asignatura se llama Idioma Moderno y el
o
objetivo de la misma es que los alumnos posean un conocimiento m´
ınimo en un idioma, de
los que se hablan en la Uniń Europea, cuando finalicen sus estudios de grado. Los alumnos
o
deben inscribirse un grupo de un idioma en concreto para poder examinarse a final del
semestre y obtener as´ un t´
ı
ıtulo oficial dependiendo del idioma elegido, por ejemplo TOEIC
para el caso del ingl´s. La asignatura de Idioma Moderno, tiene una serie de particularidades
e
que hacen que su tratamiento sea diferente respecto al resto de asignaturas. Dentro de
estas particularidades, nos encontramos que los estudiantes deben realizar antes de poder
cursar la asignatura una prueba de nivel cuyo resultado condicionar´ el grupo en el que
a
finalmente el estudiante reciba sus clases. As´ mismo, el sistema de convocatorias en las que
ı
un estudiante puede realizar el examen es diferente respecto al sistema de convocatorias
del resto de asignaturas.
ix

Todos estos hechos, implica un conjunto de tareas que requieren mucho trabajo
y que hasta ahora se gestionaban de forma manual. Por lo que se ha diseãdo una
n
herramienta que satisface las necesidades tanto de los estudiantes, los profesores y personal
de administraciń de la asignatura. El desarrollo de la herramienta lo podemos englobar
o
dentro de un proceso de diseõ iterativo centrado en el usuario donde se desarroll´ una
n
o
herramienta que se fue perfeccionando gracias a los estudios de usabilidad que se realizaron.
En este trabajo se presentan los detalles del diseõ centrado en el usuario realizado as´ como
n
ı
el estudio de usabilidad realizado incluyendo dos tipos de evaluaciones: una heur´
ıstica con
usuarios expertos y una emp´
ırica con usuarios finales.

x

´
Indice general

1. Motivaciń
o

1

2. Dise˜ o e implementaciń
n
o

5

2.1. Diseõ centrado en el usuario . . . . . . . . . . . . . . . . . . . . . . . . .
n

5

2.1.1. Usabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.2. Especificaciń funcional
o

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.2.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . .

7

3. Estudio de usabilidad

11

3.1. Metodolog´ empleada . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ıa

11

3.1.1. Evaluaciń heur´
o
ıstica . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.1.2. Evaluaciń emp´
o
ırica . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.1.3. Participantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.1.4. Instrumentos de Medida . . . . . . . . . . . . . . . . . . . . . . . .

14

4. Evaluaciń de resultados
o

17

4.1. Evaluaciń heur´
o
ıstica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

4.1.1. An´lisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
a

17

4.1.2. Resultados y mejoras . . . . . . . . . . . . . . . . . . . . . . . . . .

22

4.2. Evaluaciń emp´
o
ırica

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

4.2.1. M´tricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
e

23

4.2.2. Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

4.2.3. An´lisis de los resultados . . . . . . . . . . . . . . . . . . . . . . . .
a

26

xi

´
INDICE GENERAL

´
INDICE GENERAL

5. Conclusiones

39

A. Contenido del CD-ROM

43

B. Formulario de consentimiento

45

C. Cuestionarios

47

C.1. Cuestionario del estudiante . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

C.2. Cuestionario del profesor . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

C.3. Cuestionario del administrador

51

. . . . . . . . . . . . . . . . . . . . . . . .

xii

´
Indice de figuras

4.1. Regla 1 de la evaluaciń heur´
o
ıstica. Cabecera de todos los perfiles . . . . .

18

o
ıstica. Perfil del estudiante . . . . . . . . . . .

19

o
ıstica. Perfil del profesor . . . . . . . . . . . .

19

o
ıstica. Ejemplo de mensaje de error a un
estudiante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

o
ıstica. Ejemplo de un mensaje de informaciń
o

22

4.6. Valoraciń sobre la usabilidad y facilidad de uso de la aplicaciń . . . . . .
o
o

26

4.7. Valoraciń de las tareas del estudiantes - Puntuaciones con una escala Likert 27
o
4.8. Valoraciń de las tareas del profesor - Puntuaciones con una escala Likert .
o

27

4.9. Valoraciń de las tareas del administrador - Puntuaciones con una escala
o
Likert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

4.10. Tiempo empleado en la realizaciń de tareas de administraciń . . . . . . .
o
o

30

4.11. Muestra de las respuestas obtenidas en el cuestionario de usabilidad. . . . .

31

4.12. Filtros de las convocatorias en el m´dulo de administraciń . . . . . . . . .
o
o

32

4.13. Ordenaciń y marcado de datos . . . . . . . . . . . . . . . . . . . . . . . .
o

33

4.14. M´dulo de administraciń. Unificar varios grupos . . . . . . . . . . . . . .
o
o

34

4.15. M´dulo de administraciń. Cambiar alumnos de grupo . . . . . . . . . . .
o
o

35

4.16. M´dulo de administraciń. Buscador de alumnos . . . . . . . . . . . . . . .
o
o

35

4.17. M´dulo de administraciń. Cierre de grupos . . . . . . . . . . . . . . . . .
o
o

36

4.18. Listado de alumnos calificados como no aptos . . . . . . . . . . . . . . . .

37

4.19. Listado de alumnos sin inscripciń de convocatorias . . . . . . . . . . . . .
o

38

xiii

´
INDICE DE FIGURAS

´
INDICE DE FIGURAS

C.1. Preguntas sobre las caracter´
ısticas de los usuarios . . . . . . . . . . . . . .

48

C.2. Preguntas sobre la usabilidad de la aplicaciń . . . . . . . . . . . . . . . .
o

49

C.3. Preguntas sobre la tareas que debe realizar el estudiante en la aplicaciń .
o

50

C.4. Preguntas sobre la tareas que debe realizar el profesor en la aplicaciń . . .
o

51

C.5. Preguntas sobre la tareas que debe realizar el administrador en la aplicaciń 52
o

xiv

Cap´tulo
ı

1

Motivaciń
o
Dentro del Espacio Europeo de Educaciń Superior, todas las nuevas titulaciones
o
de grado, contienen una asignatura llamada “Idioma Moderno”(ingl´s, franc´s, alemń
e
e
a
e italiano) cuyo objetivo fundamental es proporcionar a los estudiantes de las nuevas
titulaciones de grado la preparaciń necesaria para superar un examen oficial de uno de
o
dichos idiomas. Los alumnos tienen que presentarse a la convocatoria oficial del examen
establecido para cada idioma (TOEIC para ingl´s, TFI para franc´s, CILS para italiano
e
e
y Zertifikat Deutsch para alemń). El centro encargado en gestionar esta asignatura es el
a
Centro Universitario de Idiomas, llamado CUI.
Inicialmente, los alumnos una vez se matriculaban de la asignatura, deb´ realizar
ıan
una prueba de nivel para que la Universidad pudiera asignarles un grupo espec´
ıfico para
cursar la asignatura. Esta prueba de nivel deb´ hacerse de forma presencial a una hora
ıa
indicada por el CUI. Una vez finalizado el examen, los miembros del CUI ten´ que calificar
ıan
manualmente las pruebas y publicar un listado con las calificaciones. En base a ese listado,
los alumnos posteriormente tendr´ que seleccionar un grupo que fuese del mismo idioma
ıan
y nivel obtenidos en la prueba anterior. El CUI se encargar´ de gestionar todas estas
ıa
solicitudes y comprobar que los alumnos hab´ elegido correctamente su grupo.
ıan
Durante el curso, los profesores de cada uno de los grupos, ten´ que apuntar la
ıan
asistencia a clase de los alumnos, para que en caso de no asistir un alumno a al menos
el 80 % de las clases, ´ste no tendr´ la posibilidad de inscribirse en una convocatoria de
e
ıa
examen.
Este proceso, dado el alto n´mero de alumnos involucrados, alrededor de 3000 alumnos,
u
1

implica mucho trabajo manual y un gasto de tiempo a todos los usuarios involucrados en
el proceso. Adem´s, requiere que los alumnos estń desplazńdose en varias ocasiones al
a
e
a
CUI, lo que para los que pertenecen al Campus de Vic´lvaro, donde se encuentra el CUI,
a
no implica desplazamiento alguno; pero supone un gran perjuicio para el resto de alumnos
de la Universidad que estń en los campus de Alcorcń, Fuenlabrada y M´stoles.
a
o
o
Por ello se ha decidido realizar una aplicaciń de manera que se minimice el trabajo
o
de los alumnos, el profesorado o el personal del CUI. Esta aplicaciń ser´ la encargada
o
a
de almacenar toda la informaciń que implique el proceso, permitiendo gestionar todas
o
las tareas de una forma m´s eficiente. Adem´s, se elimina el uso de documentaciń y su
a
a
o
posterior almacenamiento.
En resumen, la nueva aplicaciń permitir´ que:
o
a
Los estudiantes puedan inscribirse a trav´s de la aplicaciń de Idioma Moderno
e
o
disponible en la p´gina principal de Universidad en uno de los cursos de Idioma
a
Moderno ofertados en el primer o en el segundo cuatrimestre.
Los cursos se activen si se alcanza el n´mero m´
u
ınimo de alumnos. Este n´mero m´
u
ınimo
ser´ configurable para cada curso por el administrador.
a
En el proceso de inscripciń, el alumno puede realizar la prueba de nivel para uno
o
de los 4 idiomas que oferta actualmente el CUI: Alemń, Franc´s, Ingl´s e Italiano.
a
e
e
Dependiendo del idioma elegido en la prueba de nivel, el alumno se puede inscribir en
un grupo de dicho idioma, que estar´ a su vez gestionado por un profesor asignado
a
a dicho grupo. El profesor ser´ el encargado de calificar a los estudiantes al final
a
del curso de manera que esta calificaciń permitir´ que el estudiante realice o no un
o
a
examen oficial en caso de haber obtenido una calificaciń de APTO.
o
El alumno puede solicitar la convalidaciń de la asignatura e inscribirse tanto a grupos
o
como a convocatorias de examen.
Los profesores podrń ver el listado de los alumnos de cada uno de los grupos de
a
los que sea responsable as´ como evaluar a los alumnos con las calificaciones de
ı
APTO/NO APTO. De esta manera, se permitir´ a los alumnos o no, segń la nota,
a
u
inscribirse en una convocatoria de examen.
Trabajo Fin de M´ster
a

2

Universidad Rey Juan Carlos

´
CAP´
ITULO 1. MOTIVACION
Existir´ un perfil de administraciń de la aplicaciń que permitir´ generar nuevos
a
o
o
a
grupos, asignar profesores para cada uno de esos grupos, ver los alumnos inscritos en
los diferentes grupos as´ como visualizar las calificaciones obtenidas en las pruebas
ı
de nivel.
La gestiń de los grupos, profesores asignados, convocatorias de examenes,
o
calificaciones de actas y control de las pruebas de nivel la llevarń a cabo los usuarios
a
con perfil administrador.
Un requisito imprescindible de esta aplicaciń es que ´sta sea usable para todos los
o
e
perfiles de usuario. Por este motivo el trabajo fin de m´ster no s´lo se centra en el diseõ
a
o
n
e implementaciń de dicha aplicaciń, sino en la usabilidad de la misma. Adem´s, hay que
o
o
a
tener en cuenta que la mayor´ de los usuarios que utilizarń esta aplicaciń no tendrń
ıa
a
o
a
un perfil tecnol´gico. Por lo tanto, la usabilidad de la aplicaciń es un aspecto clave.
o
o
En los cap´
ıtulos siguientes se mostrar´ por un lado, el diseõ e implementaciń de
a
n
o
la aplicaciń inform´tica; y por otro el estudio de usabilidad realizado, el cual incluye
o
a
tanto una evaluaciń heur´
o
ıstica como emp´
ırica. Por ultimo, se presentarń las conclusiones
´
a
extra´
ıdas de la realizaciń de este trabajo.
o

Juan Carlos Hernńdez
a

3

ETSI Inform´tica
a

a

4


Cap´tulo
ı

2

Diseõ e implementaciń
n
o
En este cap´
ıtulo se detalla la funcionalidad del sistema, indicando cada una de las tareas
que tienen los diferentes perfiles de usuario que utilizan la aplicaciń. Adem´s se describen
o
a
las caracter´
ısticas principales del diseõ centrado en el usuario que se han tenido en cuenta
n
a la hora de diseãr e implementar la aplicaciń de Idioma Moderno.
n
o

2.1.

Dise˜ o centrado en el usuario
n

La consecuciń de los objetivos perseguidos a trav´s de la puesta a disposiciń del
o
e
o
p´blico de cualquier aplicaciń web est´ condicionada por la satisfacciń del usuario final.
u
o
a
o
Los factores o atributos de calidad de una aplicaciń o sitio web que influirń en dicha
o
a
satisfacciń podemos clasificarlos en aquellos relacionados con: la calidad y utilidad de los
o
contenidos; la calidad del servicio y asistencia del proveedor; y la calidad del diseõ de la
n
aplicaciń.
o
La importancia del diseõ de la aplicaciń se basa en que ´ste ser´ el que modele la
n
o
e
a
interacciń entre usuario y aplicaciń, y por tanto posibilitar´ o no la consecuciń de los
o
o
a
o
objetivos perseguidos por el usuario.
Un buen diseõ deber´ ser comprensible, fćil de usar, amigable, claro, intuitivo y de
n
a
a
fćil aprendizaje para el usuario. Para poder asegurar que un diseõ cumple con estos
a
n
requisitos no basta simplemente con que el diseãdor conozca la semńtica del problema.
n
a
Es necesario la adopciń por parte de ´ste de tćnicas, procedimientos y m´todos que
o
e
e
e
aseguren emp´
ıricamente la adecuaciń del diseõ a las necesidades, habilidades y objetivos
o
n
5

˜
2.1. DISENO CENTRADO EN EL USUARIO
del usuario.

2.1.1.

Usabilidad

Tomaremos para este trabajo la definiciń m´s extendida, que es la ofrecida por la ISO
o
a
[4], y que define usabilidad como el “grado de eficacia, eficiencia y satisfacciń con la que
o
usuarios espec´
ıficos pueden lograr objetivos espec´
ıficos, en contextos de uso espec´
ıficos”.
La usabilidad se compone de dos tipos de atributos:
Atributos cuantificables de forma objetiva: como son la eficacia o n´mero de
u
errores cometidos por el usuario durante la realizaciń de una tarea, y la eficiencia o
o
tiempo empleado por el usuario para la consecuciń de una tarea.
o
Atributos cuantificables de forma subjetiva: como es la satisfacciń de uso,
o
medible a trav´s de la interrogaciń al usuario.
e
o
El diseõ Web centrado en el usuario se caracteriza por asumir que todo el proceso de
n
diseõ y desarrollo del sitio web debe estar conducido por el usuario, sus necesidades,
n
caracter´
ısticas y objetivos. Centrar el diseõ en los usuarios, implica involucrar desde
n
el comienzo a los usuarios en el proceso de desarrollo del sitio; conocer c´mo son,
o
qu´ necesitan, para qu´ usan el sitio; probar el sitio con los propios usuarios, investigar
e
e
c´mo reaccionan ante el diseõ, c´mo es su experiencia de uso; e innovar siempre con el
o
n
o
objetivo claro de mejorar la experiencia del usuario.
Los beneficios derivados de aplicar la usabilidad en el desarrollo de una aplicaciń son:
o
Disminuciń de los tiempos necesarios para realizar las tareas.
o
Disminuciń del tiempo de aprendizaje que necesitar´ el usuario para manejar la
o
a
aplicaciń.
o
Mejora el servicio ofrecido a los usuarios finales, lo que implica una mayor satisfacciń
o
de los mismos.
Detecciń temprana de errores, lo que implica un menor mantenimiento de la
o
aplicaciń y soporte en la fase de implementaciń.
o
o
Aumento de la productividad de los usuarios.
a

6


˜
´
CAP´
ITULO 2. DISENO E IMPLEMENTACION

2.2.

Especificaciń funcional
o

A continuaciń indicaremos una breve especificaciń de la aplicaciń desarrollada, cuyo
o
o
o
objetivo principal es definir cuales son los diferentes conceptos que aparecen en el desarrollo,
as´ como los requisitos funcionales que debe cumplir la aplicaciń para satisfacer las tareas
ı
o
que realizarń los usuarios con la herramienta.
a
La terminolog´ que a partir de ahora debemos conocer ya que utilizaremos
ıa
frecuentemente a lo largo de este documento es:
PDI: Personal Docente Investigador.
Profesor: PDI responsable de uno o varios grupos de la asignatura de Idioma
Moderno.
Alumno: Estudiante matriculado en una titulaciń de Grado.
o
Administrador: Persona responsable de administrar la aplicaciń.
o
RFi: Requisito funcional i.
La herramienta ser´ utilizada por usuarios que pueden no tener experiencia previa
a
en la utilizaciń de herramientas inform´ticas, aunque si ser´ necesario que conozcan el
o
a
a
procedimiento de la asignatura de Idioma Moderno. Se han definido tres tipos de perfiles
de usuario: Estudiante, Profesor y Administrador.

2.2.1.

Requisitos funcionales

El acceso del usuario a la aplicaciń se realizar´ a trav´s del usuario de dominio unico de
o
a
e
´
la Universidad Rey Juan Carlos. Cada uno de los usuarios podr´ tener uno o varios de los
a
siguientes perfiles, por lo que tendr´ la opciń de realizar las funcionalidades dependiendo
a
o
de los perfiles que tenga asignados.
En t´rminos generales, el sistema deber´ poder realizar las siguientes tareas, que estarń
e
a
a
divididas y explicadas para cada uno de los perfiles existentes en la aplicaciń.
o

a

7

ETSI Inform´tica
a

´
2.2. ESPECIFICACION FUNCIONAL
REQUISITOS GENERALES
RF001. Control de acceso: Se deber´ controlar qu´ usuarios podrń acceder a la
a
e
a
aplicaciń.
o
RF002. Desconexiń de la aplicaciń. El usuario debe poder desconectarse de la
o
o
aplicaciń.
o
REQUISITOS FUNCIONALES DEL ADMINISTRADOR
RF002. El administrador podr´ configurar los par´metros principales del sistema.
a
a
Entre ellos estarń el curso acad´mico, el semestre, fechas de apertura y cierre
a
e
de matr´
ıcula y textos configurables relacionados con las diferentes pantallas a
las que accede el alumno.
RF003. El administrador debe poder crear grupos.
RF004. El administrador debe poder dar de alta nuevos profesores.
RF005. El administrador debe poder asignar profesores a grupos.
RF006. El administrador debe poder ver el resultado de las pruebas de nivel.
RF007. El administrador debe poder borrar una prueba de nivel de un alumno.
RF008. El administrador debe poder crear convocatorias de examen.
RF009. El administrador debe poder crear y asignar aulas a una convocatoria de
examen.
RF010. El administrador debe poder cambiar de grupo a un alumno.
RF011. El administrador debe poder cambiar varios alumnos a la vez de un mismo
grupo a otro.
RF012. El administrador debe poder buscar toda la informaciń relativa a un
o
alumno.
RF013. El administrador debe poder dividir un grupo.
RF014. El administrador debe poder unificar los alumnos de uno o varios grupos.
RF015. El administrador debe poder sacar diferentes tipos de listados.
RF016. El administrador debe poder ver los asistentes a un grupo.
a

8


˜
´
CAP´
ITULO 2. DISENO E IMPLEMENTACION
RF017. El administrador debe poder ver los asistentes a una convocatoria.
RF018. El administrador debe poder ver los asistentes a un aula de una
convocatoria.
RF019. El administrador debe poder calificar a los alumnos de una convocatoria.
REQUISITOS FUNCIONALES DEL PROFESOR
RF020. El profesor debe poder ver los alumnos que estń inscritos en los grupos en
a
los que est´ asignado.
e
RF021. El profesor debe poder evaluar a sus alumnos con la calificaciń APTO o
o
NO APTO.
REQUISITOS FUNCIONALES DEL ALUMNO
RF022. El alumno debe poder realizar una prueba de nivel para uno de los idiomas
ofertados.
RF023. El alumno debe poder inscribirse en un grupo.
RF024. El alumno debe poder inscribirse en una convocatoria de examen.
RF025. El alumno debe poder solicitar la convalidaciń de la asignatura.
o
RF026. El alumno debe poder visualizar sus calificaciones.

a

9

ETSI Inform´tica
a

´
2.2. ESPECIFICACION FUNCIONAL

a

10


Cap´tulo
ı

3

Estudio de usabilidad
El objetivo de la realizaciń de un estudio de usabilidad [3] sobre la herramienta de
o
Idioma Moderno es conseguir que una aplicaciń que va a ser utilizada por un gran n´mero
o
u
de personas que no tiene conocimientos tćnicos, pueda ser usarse de forma sencilla y
e
sin necesidad de ayuda externa. Adicionalmente, esto implicar´ una reducciń de los
a
o
costes de aprendizaje y un aumento en la satisfacciń y productividad de los usuarios.
o
En este cap´
ıtulo se detalla el estudio de usabilidad realizado en la aplicaciń de Idioma
o
Moderno. Para ello se indica la metodolog´ empleada, los participantes que intervienen
ıa
en la evaluaciń y los instrumentos de medida utilizados.
o

3.1.

Metodolog´ empleada
ıa

Para realizar el estudio de usabilidad de la aplicaciń han sido utilizadas dos
o
evaluaciones distintas. Inicialmente se ha realizado una evaluaciń heur´
o
ıstica, con el
objetivo de mejorar la usabilidad de la aplicaciń antes de realizar pruebas con usuarios
o
finales. A continuaciń, se procedi´ a mejorar la aplicaciń incluyendo los defectos
o
o
o
detectados durante la evaluaciń heur´
o
ıstica. Finalmente, se hizo una evaluaciń emp´
o
ırica,
donde se realiza un an´lisis de la aplicaciń en busca de problemas en la interfaz de usuario,
a
o
en el diseõ o problemas de usabilidad.
n
11

3.1. METODOLOG´ EMPLEADA
IA

3.1.1.

Evaluaciń heur´
o
ıstica

La evaluaciń heur´
o
ıstica es un an´lisis de experto en el cual se hace una inspecciń
a
o
minuciosa a las interfaces o sistemas con el fin de determinar si cada uno de sus elementos
se adhieren o no a los principios de usabilidad, diseõ o arquitectura de informaciń
n
o
comńmente aceptados en sus respectivas disciplinas. Los especialistas valoran si cada
u
elemento del diseõ cumple los principios de usabilidad establecidos. Se ha utilizado el
n
trabajo que realiz´ Jackob Nielsen, quien define la usabilidad como el atributo de calidad
o
que mide lo fćiles que son de usar las interfaces Web. Para ello defini´ 10 reglas que han
a
o
sido contrastadas con la aplicaciń para poder comprobar cuales se cumplen y cuales no,
o
y as´ realizar las modificaciones que se consideren oportunas, con el objetivo de mejorar la
ı
usabilidad de la aplicaciń.
o

3.1.2.

Evaluaciń emp´
o
ırica

La evaluaciń emp´
o
ırica consiste en realizar un an´lisis, con ayuda de una serie de
a
participantes, que permita comprobar si una aplicaciń tiene problemas en la interfaz de
o
usuario, en el diseõ o en la implementaciń, problemas de usabilidad o problemas que no
n
o
permitan que una tarea concreta se pueda realizar. Para poder obtener estos datos, se han
definido una serie de tareas que se consideran b´sicas para que la herramienta sea funcional.
a
Dichas tareas las realizarń los participantes en el estudio, que a su vez estarń agrupados
a
a
por perfiles, teniendo en cuentas los roles dentro de la aplicaciń. Adem´s se establecen una
o
a
serie de m´todos para recopilar la informaciń: cuestionarios on-line, observaciń directa e
e
o
o
indirecta.
Al finalizar esta evaluaciń, se facilitar´ a cada uno de los usuarios un formulario en el
o
a
que se detallan cada una de las tareas a realizar y en el que tendrń que indicar c´mo les
a
o
result´ de complicado realizar la tarea propuesta as´ como el grado de satisfacciń con la
o
ı
o
herramienta inform´tica.
a
Metas de usabilidad
Los objetivos principales que persigue esta experiencia son los siguientes:
1. Evaluar la sencillez de uso de la herramienta.
a

12


CAP´
ITULO 3. ESTUDIO DE USABILIDAD
2. Comprobar que los usuarios aprenden a utilizarla de una forma sencilla.
3. Observar si la herramienta les recuerda o les resulta familiar con respecto al uso de
otras herramientas que existen en la Universidad Rey Juan Carlos.
4. Detectar si el usuario se siente en algń momento frustrado a partir de algo que
u
esperaba poder hacer. Es decir, se trata de saber si hay algo que no ha conseguido
porque le ha resultado dif´ o porque la herramienta no le ha proporcionado los
ıcil
medios para llevarlo a cabo.

3.1.3.

Participantes

Cuando se ha tenido que determinar qu´ participantes se iban a necesitar para cada
e
una de las evaluaciones se ha tenido en cuenta en qu´ tipo de evaluaciń iban a participar.
e
o

Evaluaciń heur´
o
ıstica
Para la evaluaciń heur´
o
ıstica, aunque Jackob Nielsen [3] indica que con tres personas se
puede encontrar cerca del 75 % de los fallos, en nuestro caso hemos contado con un experto
en usabilidad y con otras dos personas expertas en todo lo referente a la asignatura de
Idioma Moderno.
La interacciń de dos expertos en la asignatura de Idioma Moderno, nos ha ayudado a
o
detectar errores en la interfaz de usuario asi como errores de funcionamiento en las tareas.

Evaluaciń emp´
o
ırica
La selecciń de los participantes en la prueba de usabilidad se basa en la identificaciń
o
o
de las caracter´
ısticas que se consideran importantes para lograr que los usuarios utilicen
nuestro sistema de manera sencilla. Esta fase coincide con la elaboraciń del perfil de los
o
usuarios donde se destacan las caracter´
ısticas que los usuarios comparten y aquellas que
los distinguen.
Para el uso de la aplicaciń de Idioma Moderno, existen diferentes perfiles de usuario.
o
Teniendo cada uno de ellos diferentes acciones posibles y roles dentro de la aplicaciń,
o
se ha tenido que definir diferentes tareas para cada uno de ellos a la hora de realizar las
a

13

ETSI Inform´tica
a

IA
pruebas. Los roles de los usuarios que participaron en el estudio as´ como sus caracter´
ı
ısticas
generales se presentan a continuaciń:
o
1. Estudiante: 10 personas entre 18 y 24 aõs. 50 % hombres y 50 % mujeres. Se
n
han seleccionado de diferentes Escuelas/Facultades ya que el nivel tćnico de los
e
estudiantes en relaciń a las aplicaciones inform´ticas puede variar segń la titulaciń
o
a
u
o
que estudien. El 40 % de los alumnos utilizan normalmente Internet Explorer como
navegador web, un 30 % Mozilla Firefox y el 30 % restante Google Chrome. En el caso
de esta aplicaciń inform´tica, un 70 % acude a la documentaciń cuando tiene una
o
a
o
duda y el 30 % consulta a otra persona en caso de duda sobre el uso de la aplicaciń.
o
2. Profesor: 7 personas entre 30 - 50 aõs. 40 % hombres y 60 % mujeres
n
aproximadamente. Pertenecientes al Campus de Vic´lvaro, debido a que la asignatura
a
de Idioma Moderno pertenece a un Departamento del Campus de Vic´lvaro.
a
3. Administrador: 2 personas de 24 y 30 aõs, ambas mujeres, ya que serń las
n
a
administradoras del sistema.
Esta evaluaciń emp´
o
ırica fue pensada tanto para usuarios que no tuvieran experiencia
en el manejo con aplicaciones web como para usuarios experimentados.
A continuaciń, se presentan los instrumentos de medida utilizadas en ambas
o
evaluaciones.

3.1.4.

Instrumentos de Medida

Evaluaciń heur´
o
ıstica
Como instrumento de medida en esta primera evaluaciń, se utilizaron las 10 reglas de
o
Jackob Nielsen que se siguieron para detectar posibles problemas en la aplicaciń. Estas
o
reglas son las siguientes:
1. Visibilidad del estado del sistema. El sistema debe siempre mantener a los usuarios
informados de su estado, con una realimentaciń apropiada y en un tiempo razonable.
o
2. Utilizar el lenguaje de los usuarios. El sistema debe hablar el lenguaje de los usuarios,
con las palabras, las frases y los conceptos familiares, en lugar de que los t´rminos
e
a

14


CAP´
ITULO 3. ESTUDIO DE USABILIDAD
estń orientados al sistema. Hay que utilizar convenciones del mundo real, haciendo
e
que la informaciń aparezca en un orden natural y l´gico.
o
o
3. Control y libertad para el usuario. Los usuarios eligen a veces funciones del sistema
por error y necesitan a menudo una salida de emergencia claramente marcada, esto es,
salir del estado indeseado sin tener que pasar por un di´logo extendido. Es importante
a
disponer de las opciones de deshacer y rehacer.
4. Consistencia y estńdares. Los usuarios no deben tener que preguntarse si las diversas
a
palabras, situaciones, o acciones significan la misma cosa. En general siga las normas
y convenciones de la plataforma sobre la que est´ implementando el sistema.
a
5. Prevenciń de errores. Es importante prevenir la apariciń de errores antes que
o
o
generar buenos mensajes de error.
6. Minimizar la carga de la memoria del usuario. El usuario no deber´ tener que recordar
ıa
la informaciń de una parte del di´logo a la otra. Es mejor mantener objetos, acciones,
o
a
y las opciones visibles que memorizar.
7. Flexibilidad y eficiencia de uso. Las instrucciones para el uso del sistema deben ser
visibles o fćilmente accesibles siempre que se necesiten. Es importante que el sistema
a
permita personalizar acciones frecuentes.
8. Los di´logos deben ser est´ticos y el diseõ minimalista. No deben contener,
a
e
n
informaciń que sea inaplicable o se necesite raramente. Cada unidad adicional de
o
informaciń en un di´logo compite con las unidades relevantes de la informaciń y
o
a
o
disminuye su visibilidad relativa.
9. Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de los errores. Los
mensajes de error deben expresarse en un lenguaje claro. Se debe indicar exactamente
el problema y deben ser constructivos.
10. Ayuda y documentaciń. Aunque es mejor si el sistema se puede usar sin
o
documentaciń, puede ser necesario disponer de ayuda y documentaciń. Esta tiene
o
o ´
que ser fćil de buscar, centrada en las tareas del usuario, tener informaciń de las
a
o
etapas a realizar y que no sea muy extensa.
a

15

ETSI Inform´tica
a

IA
Evaluaciń Emp´
o
ırica
Para la realizaciń de esta evaluaciń, se han utilizado tres tipos de observaciń para
o
o
o
recoger informaciń de los participantes:
o
Observaciń directa: El observador ha ido tomando notas de los principales problemas
o
que han tenido los usuarios a la hora de interactuar con la aplicaciń.
o
Observaciń indirecta: Se han grabado la pantalla del ordenador del usuario,
o
analizando posteriormente las interacciones de los usuarios con la aplicaciń.
o
Cuestionarios: Se han definido 3 tipos de cuestionarios diferentes dependiendo del
tipo de perfil de usuario (estudiantes, profesores, administrador). El motivo en que
se hayan definido varios cuestionarios en vez de un unico para todos es porque las
´
tareas que tienen que realizar cada uno de los perfiles son diferentes entre s´ Los
ı.
cuestionarios detallados se pueden consultar en las siguientes direcciones Web o en
los anexos C, D y E respectivamente:
1. Cuestionario para los estudiantes: http://goo.gl/TmNN8
2. Cuestionario para los profesores: http://goo.gl/728XX
3. Cuestionario para el administrador: http://goo.gl/Su0Nc
Este cuestionario se centr´ en recoger los datos generales del usuario (por ejemplo:
o
edad, Facultad/Escuela), una valoraciń sobre la realizaciń de tareas propuestas y
o
o
la facilidad de uso del sistema. En los dos ultimos casos, se ha utilizado una escala
´
de Likert para recoger los datos.

a

16


Cap´tulo
ı

4

Evaluaciń de resultados
o
En este cap´
ıtulo se explican los resultados obtenidos en las dos evaluaciones realizadas
junto con un an´lisis de los mismos que incluir´ la mediciń de la usabilidad en base
a
a
o
a tres par´metros: efectividad, eficiencia y satisfacciń del usuario con la herramienta
a
o
desarrollada. Para ello, se definirń en una serie de m´tricas en el caso de la evaluaciń
a
e
o
emp´
ırica con usuarios finales. A continuaciń se detalla las m´tricas utilizadas y veremos los
o
e
resultados obtenidos despu´s de realizar la evaluaciń heur´
e
o
ıstica y la evaluaciń emp´
o
ırica.

4.1.
4.1.1.

Evaluaciń heur´
o
ıstica
An´lisis
a

Jackob Nielsen defini´ la usabilidad como el atributo de calidad que mide lo fćiles que
o
a
son de usar las interfaces Web, para ello defini´ 10 reglas [1] que son las que se usarń para
o
a
realizar la evaluaciń heur´
o
ıstica. Los resultados de la evaluaciń heur´
o
ıstica realizada son
los siguientes:
1. Visibilidad del estado del sistema. El sistema debe siempre mantener a los
usuarios informados de su estado, con una realimentaciń apropiada y en
o
un tiempo razonable.
Algunas de las funcionalidades como la generaciń de ficheros Excel o la
o
representaciń de las tablas que contienen datos, no funcionan correctamente en el
o
navegador Internet Explorer, lo cual ocasiona muchos problemas a los usuarios puesto
17

´
4.1. EVALUACION HEUR´
ISTICA
que para un correcto funcionamiento de la aplicaciń se les obliga a la utilizaciń de
o
o
otros navegadores web.
Para todos los perfiles podemos comprobar que para cumplir esta regla, la aplicaciń
o
tiene una serie de caracter´
ısticas como las siguientes: se indica en la cabecera el lugar
donde se encuentra el usuario tal y como se puede ver en la figura 4.1, de manera que
cumple esta regla. En el perfil del profesor y en del administrador, se hace uso de una
lista lineal con la sucesiń de las p´ginas por las que ha navegado el usuario. Adem´s,
o
a
a
en el perfil del administrador, se marca en el men´ la operaciń que est´ realizando.
u
o
a
No obstante, hemos comprobado como existen diferencias entre los perfiles que hacen
que no cumplan del todo esta regla. Se ha detectado en los perfiles de estudiante y
de profesor que no se marca en el men´ la operaciń que est´ realizando. Adem´s,
u
o
a
a
en el perfi de estudiante no se indican de ninguna manera las pantallas por las que
va navegando. Lo que ocasiona que no se cumpla correctamente esta regla para los
perfiles indicados.
En las figuras 4.2 y 4.3 se han marcado con c´
ırculos rojos los errores detectados.

Figura 4.1: Regla 1 de la evaluaciń heur´
o
ıstica. Cabecera de todos los perfiles
2. Utilizar el lenguaje de los usuarios. El sistema debe hablar el lenguaje
de los usuarios, con las palabras, las frases y los conceptos familiares, en
lugar de que los t´rminos estń orientados al sistema. Hay que utilizar
e
e
convenciones del mundo real, haciendo que la informaciń aparezca en un
o
orden natural y l´gico.
o
Dependiendo del perfil de usuario con el que se entre en la aplicaciń, se utilizar´ un
o
a
lenguaje m´s o menos tćnico. En el caso del perfil estudiante y del profesor, la
a
e
nomenclatura trata de ser lo m´s coloquial posible. Sin embargo en el perfil de
a
a

18


´
CAP´
ITULO 4. EVALUACION DE RESULTADOS

o
ıstica. Perfil del estudiante

o
ıstica. Perfil del profesor
administrador existen conceptos y t´rminos que requieren un conocimiento previo
e
del funcionamiento de la asignatura de Idioma Moderno.
3. Control y libertad para el usuario. Los usuarios eligen a veces funciones
del sistema por error y necesitan a menudo una salida de emergencia
claramente marcada, esto es, salir del estado indeseado sin tener que pasar
por un di´logo extendido. Es importante disponer de deshacer y rehacer.
a
Independientemente del perfil con el que entre en la aplicaciń el usuario podr´ en
o
a
cualquier momento salir de la aplicaciń a trav´s de la opciń de la cabecera
o
e
o
“Desconectar” o cancelar la operaciń que est´ realizando en un momento
o
e
determinado pulsando en cualquier otro enlace del men´ situado en la parte izquierda
u
a

19

ETSI Inform´tica
a

´
ISTICA
de la p´gina. No existe la posibilidad de deshacer o rehacer los cambios en todas las
a
operaciones implementadas.
4. Consistencia y estńdares. Los usuarios no deben tener que preguntarse
a
si las diversas palabras, situaciones, o acciones significan la misma cosa.
En general siga las normas y convenciones de la plataforma sobre la que
est´ implementando el sistema.
a
En relaciń a este punto no se encuentra ninguna inconsistencia de estńdares, puesto
o
a
que en todas las pantallas se utilizan los mismos nombres y los iconos tienen el mismo
significado.
5. Prevenciń de errores. Es importante prevenir la apariciń de errores antes
o
o
que generar buenos mensajes de error.
Para evitar errores en la aplicaciń existen una serie de controles que evitan que
o
una operaciń se realice si no cumple una serie de requisitos. En caso de no cumplir
o
uno de esos requisitos se informa al usuario con un mensaje sobre c´mo solucionar
o
el problema. Por ejemplo, en la figura 4.4 se puede ver un mensaje tanto en la parte
superior e inferior indicando al usuario que no puede volver a realizar una inscripciń
o
puesto que ya tiene una anterior. Por motivos de confidencialidad de datos se ha
ocultado el nombre del profesor y parte de la direcciń de correo electrńico.
o
o

o
ıstica. Ejemplo de mensaje de error a un estudiante

6. Minimizar la carga de la memoria del usuario. El usuario no deber´ tener
ıa
que recordar la informaciń de una parte del di´logo a la otra. Es mejor
o
a
mantener objetos, acciones, y las opciones visibles que memorizar.
a

20


´
CAP´
Los usuarios no tienen la necesidad de memorizar ningń dato. Todo est´ indicando
u
a
correctamente en la interfaz de la aplicaciń.
o
7. Flexibilidad y eficiencia de uso. Las instrucciones para el uso del sistema
deben ser visibles o fćilmente accesibles siempre que se necesiten. Es
a
importante que el sistema permita personalizar acciones frecuentes.
La aplicaciń no permite personalizar acciones creadas por el usuario experto. De
o
manera que no puede realizar acciones personalizadas que puedan ser m´s complejas
a
y le “ahorre” tiempo, sino que debe usar siempre las mismas (por ejemplo, aãdir
n
atajos de teclado para opciones m´s comunes).
a
8. Los di´logos deben ser est´ticos y el dise˜ o minimalista. No deben
a
e
n
contener informaciń que sea inaplicable o se necesite raramente. Cada
o
unidad adicional de la informaciń en un di´logo compite con las unidades
o
a
relevantes de informaciń y disminuye su visibilidad relativa.
o
El sistema tiene un diseõ minimalista, contiene s´lo la informaciń m´
n
o
o
ınima necesaria
por pantalla para no hacer dudar al usuario o disminuir la atenciń en la pantalla en
o
la que se encuentra.
9. Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de los
errores. Que los mensajes de error deben expresarse en un lenguaje claro.
Se debe indicar exactamente el problema y deben ser constructivos.
Para evitar errores en la aplicaciń, existen una serie de controles que evitan que
o
una operaciń se realice si no cumple una serie de requisitos. En caso de no cumplir
o
uno de esos requisitos, se informa al usuario sobre c´mo solucionar el problema. En
o
caso de caerse la base de datos o fallar algo en el sistema se mostrar´ un mensaje
a
indicando que la aplicaciń est´ fuera de servicio por labores de mantenimiento. Por
o
a
ejemplo en la figura 4.5 se muestra el error generado al guardar un profesor sin haber
introducido el DNI, campo obligatorio a la hora de dar de alta un nuevo profesor en
la aplicaciń.
o
10. Ayuda y documentaciń. Aunque es mejor si el sistema se puede usar sin
o
documentaciń, puede ser necesario disponer de ayuda y documentaciń.
o
o
a

21

ETSI Inform´tica
a

´
ISTICA

o
ıstica. Ejemplo de un mensaje de informaciń
o
´
Esta tiene que ser fćil de buscar, centrada en las tareas del usuario, tener
a
informaciń de las etapas a realizar y que no sea muy extensa.
o
En ninguna parte el usuario tiene acceso a una pequeã informaciń de ayuda sobre
n
o
la pantalla en la que se encuentra.

4.1.2.

Resultados y mejoras

Una vez realizado la evaluaciń heur´
o
ıstica, se han encontrado dos errores graves que se
procedieron a solucionar antes de realizar la evaluaciń emp´
o
ırica con usuarios finales. Estos
errores son los siguientes:
1. No funciona correctamente el 100 % de la aplicaciń bajo Internet Explorer, obligando
o
al usuario a utilizar otros navegadores Web. Por ello se ha realizado la modificaciones
pertinentes en el sistema.
2. No existe el acceso a una ayuda en cualquiera de las pantallas, por lo que sobre todo en
la parte de administrador supone un grave problema ya que existen funcionalidades
de naturaleza compleja que suelen conllevar la necesidad en ocasiones de consultar su
funcionamiento. Para solucionar este punto se ha creado un pantalla de ayuda para
cada una de estas funcionalidades que se encuentra accesible en todo momento.
a

22


´
CAP´

4.2.

Evaluaciń emp´
o
ırica

Una vez solucionados los problemas detectados gracias a la evaluaciń heur´
o
ıstica, se
realiz´ un estudio con usuarios finales. En este apartado se muestran las tareas que tuvieron
o
que realizar, las m´tricas que utilizaron en la evaluaciń as´ como los resultados obtenidos.
e
o
ı

4.2.1.

M´tricas
e

Podr´
ıamos definirlas como aquellos criterios o variables que son medibles de forma
objetiva. Mientras que la interpretaciń de una opiniń es un an´lisis cualitativo o
o
o
a
subjetivo por parte del experto, la interpretaciń de datos objetivos responde a un an´lisis
o
a
cuantitativo. Este an´lisis se estructura en tres grupos:
a
1. Efectividad: variables que nos permiten medir la exactitud y la plenitud con la que
se alcanzan los objetivos de una tarea concreta. Algunas de las variables utilizadas
son:
Porcentaje total de tareas completadas.
Porcentaje de usuarios que completan las tareas.
N´mero de veces que los usuarios solicitan ayuda por no saber c´mo realizar
u
o
una tarea.
Porcentaje o n´mero de errores cometidos.
u
Porcentaje o n´mero de veces que se acude a las ayudas.
u
2. Eficiencia: se refiere al esfuerzo que un usuario tiene que hacer para conseguir un
objetivo, y generalmente tiene que ver con el tiempo empleado en completar cada
tarea.
3. Satisfacciń: se refiere a aquellas que tienen que ver m´s con lo emocional o subjetivo.
o
a
Algunas de las variables utilizadas son:
Porcentaje de usuarios que califican el producto c´mo fćil de usar.
o
a
N´mero de veces que el usuario expresa satisfacciń con el uso de la herramienta.
u
o
a

23

ETSI Inform´tica
a

´
4.2. EVALUACION EMP´
IRICA

4.2.2.

Tareas

Para la identificaciń de las tareas, se tuvo en cuenta dos criterios:
o
Tareas que exploran problemas potenciales de usabilidad.
Tareas que los usuarios realizarń con la herramienta.
a
A continuaciń se presenta una lista depurada con las tareas principales a realizar
o
catalogadas dependiendo del perfil del usuario final:
ESTUDIANTE
• No dar m´s de 3 acciones para realizar la prueba de nivel del idioma seleccionado.
a
• Debe poder localizar con exactitud el idioma del que desee realizar la prueba.
• Debe poder saber cuanto tiempo tiene disponible para realizar la prueba.
• Debe saber c´mo guardar los resultados una vez que ha respondido a todas las
o
preguntas.
• Debe ser capaz de inscribirse en un grupo en un m´ximo de 3 acciones.
a
• Debe ser capaz de localizar la calificaciń obtenida.
o
• Debe ser capaz de inscribirse a una convocatoria en un m´ximo de 3 acciones.
a
• Debe ser capaz de borrarse de una convocatoria en un m´ximo de 3 acciones.
a
PROFESOR
• Debe ser capaz de visualizar los grupos que imparte docencia en un m´ximo de
a
2 acciones.
• Debe ser capaz de calificar a los alumnos de un grupo.
• Debe ser capaz de guardar las calificaciones de los alumnos.
ADMINISTRADOR
• Debe ser capaz de configurar los par´metros de la aplicaciń.
a
o
• Debe ser capaz de visualizar los idiomas disponibles de la aplicaciń.
o
a

24


´
CAP´
• Debe ser capaz de visualizar los niveles de los idiomas disponibles de la
aplicaciń.
o
• Debe ser capaz de aãdir un profesor.
n
• Debe ser capaz de eliminar un profesor.
• Debe ser capaz de mostrar un listado de profesores.
• Debe ser capaz de editar un profesor.
• Debe ser capaz de aãdir una convocatoria.
n
• Debe ser capaz de editar una convocatoria.
• Debe ser capaz de mostrar todas las convocatorias de un curso acad´mico y de
e
un semestre concretos.
• Debe ser capaz de visualizar los asistentes a una convocatoria.
• Debe ser capaz de aãdir un aula a una convocatoria.
n
• Debe ser capaz de editar un aula de una convocatoria.
• Debe ser capaz de ver los alumnos de un aula de una convocatoria.
• Debe ser capaz de eliminar un aula de una convocatoria.
• Debe ser capaz de aãdir un grupo.
n
• Debe ser capaz de editar un grupo.
• Debe ser capaz de cambiar un profesor de un grupo.
• Debe ser capaz de mostrar todos los grupos de un curso acad´mico y de un
e
semestre concreto.
• Debe ser capaz de aãdir un grupo.
n
• Debe ser capaz de generar un fichero Excel con los alumnos asistentes a un
grupo.
• Debe ser capaz de dividir un grupo en un n´mero determinado de grupos
u
indicando el n´mero de asistentes de cada grupo nuevo.
u
• Debe ser capaz de unificar uno o varios grupos.
• Debe ser capaz de cambiar el grupo de un alumno.
a

25

ETSI Inform´tica
a

´
IRICA
• Debe ser capaz de cambiar el grupo de varios alumnos de un mismo grupo.
• Debe ser capaz de cerrar los grupos una vez finalizado el plazo de inscripciń.
o
• Debe ser capaz de buscar la prueba de nivel de un alumno determinado.

4.2.3.

An´lisis de los resultados
a

A trav´s de la observaciń directa, as´ como de los resultados obtenidos y los comentarios
e
o
ı
dados a trav´s de los cuestionarios que cumplimentaron los usuarios, podemos realizar un
e
an´lisis en dos vertientes. Por un lado veremos las puntuaciones obtenidas en aquellas
a
preguntas que trataban sobre la usabilidad y la facilidad de uso de la herramienta y por
otro lado las respuestas obtenidas referentes a las preguntas acerca de la realizaciń de las
o
tareas propuestas. Antes de mostrar los resultados debemos indicar que en los cuestionarios
se ha utilizado la escala de Likert; que es una escala muy popular para realizar encuestas.
En nuestro caso se ha establecido un baremo de 1 a 5 siendo 1 el valor m´s negativo,
a
desacuerdo, y 5 el valor m´s positivo, de acuerdo, para valorar cada una de las preguntas.
a

Figura 4.6: Valoraciń sobre la usabilidad y facilidad de uso de la aplicaciń
o
o
Tal y como se puede ver en la figura 4.6 la opiniń general de los usuarios respecto
o
a

26


´
CAP´
a la usabilidad y la facilidad de uso de la aplicaciń es bastante alta. Se ha obtenido
o
una calificaciń media de 3.77 siendo 3 el valor m´
o
ınimo que esper´bamos como aceptable.
a
Aunque la diferencia no es muy grande, podemos observar como el perfil del administrador
est´ por debajo de las calificaciones del resto de perfiles. Esto se debe a los errores que se
a
comentarń en apartado “Tiempo empleado en completar cada tarea”.
a
Porcentaje total de tareas completadas y porcentaje de usuarios que completan
las tareas
Tras comprobar las respuestas de los cuestionarios, tal y como se presenta en las figuras
4.7, 4.8 y 4.9 el 100 % de las tareas propuestas han sido completadas por los usuarios de
los diferentes perfiles y el 100 % de los usuarios ha sido capaz de realizar las tareas que
les fueron asignadas. Por tanto, la aplicaciń permite realizar todas las tareas que se han
o
considerado como funcionalidad imprescindible en esta aplicaciń.
o

Figura 4.7: Valoraciń de las tareas del estudiantes - Puntuaciones con una escala Likert
o

Figura 4.8: Valoraciń de las tareas del profesor - Puntuaciones con una escala Likert
o

a

27

ETSI Inform´tica
a

´
IRICA

Figura 4.9: Valoraci´n de las tareas del administrador - Puntuaciones con una escala Likert
o

a

28


´
CAP´
N´ mero de veces que los usuarios solicitan ayuda para realizar una tarea
u
En los perfiles de estudiante y profesor, ninguno de los usuarios tuvo dudas a la hora
de ejecutar las tareas. No obstante, los usuarios administradores tuvieron dudas cuando
quer´ cambiar de grupo a varios alumnos, identificar en qu´ grupo estaba inscrito un
ıan
e
alumno en concreto as´ como realizar el “Cierre de los Grupos”. En el caso del cierre de
ı
grupos el problema ven´ en parte debido a que como es una tarea que se ejecuta en varias
ıa
fases, no hab´ ningń texto explicativo sobre c´mo iniciar el proceso. Para estas tareas
ıa
u
o
solicitaron la ayuda en 8 ocasiones.
Tiempo empleado en completar cada tarea
Para cada una de las tareas se hab´ definido un tiempo ´ptimo de realizaciń de las
ıa
o
o
tareas. En la mayor´ este tiempo est´ en torno a los 3 minutos para que se considere
ıa,
a
aceptable. Para poder comprobar estos valores se ha hecho uso principalmente de la
observaciń directa. Estos tiempos se han cumplido en los perfiles de estudiante y profesor.
o
En cambio en el perfil de administrador se han encontrado varias deficiencias en este
aspecto. En la tarea propuesta “Debe ser capaz de dividir un grupo en un n´mero
u
determinado de grupos indicando el n´mero de asistentes de cada grupo nuevo” se ha
u
detectado que a la hora de interactuar con la aplicaciń el usuario ha tenido bastantes
o
problemas para realizar dicha tarea. Este problema se ha detectado mediante la observaciń
o
directa y por los comentarios realizados por los usuarios.
Adicionalmente, los usuarios han indicando que iban a existir problemas de tiempo en
realizar algunas tareas; como por ejemplo, cambiar a un alumno de grupo o cambiar todos
los alumnos de un grupo a otro; ya que para realizar estas tareas se tienen que realizar de
alumno en alumno, lo que implica que para acciones que engloben muchos alumnos pod´
ıa
demorarse el tiempo de realizaciń de la tarea.
o
En el perfil Administrador, el tiempo medio empleado en ejecutar las tareas est´ en
a
torno a 2 minutos. Si tenemos en cuenta que el tiempo estimado m´ximo es de 3 minutos,
a
el valor obtenido es satisfactorio. La figura 4.10 muestra para cada una de las tareas los
tiempos medios que tardaron los usuarios junto con el tiempo estimado. Dentro de esta
figura se pueden observar como los problemas detectados anteriormente (el cierre de los
grupos o el cambio de grupo de varios alumnos) tienen un tiempo de ejecuciń superior al
o
a

29

ETSI Inform´tica
a

´
IRICA
l´
ımite preestablecido. Para los perfiles de estudiante y profesor, los tiempos tambiń fueron
e
satisfactorios.

Figura 4.10: Tiempo empleado en la realizaciń de tareas de administraciń
o
o

A pesar de haber tenido en cuenta el campus al que pertenec´ el usuario para la
ıa
realizaciń de los cuestionarios, no se ha detectado ninguna variaciń importante entre los
o
o
resultados de los usuarios de un campus u otro.

Porcentaje de usuarios que califican el producto fćil de usar
a
Comprobando las respuestas obtenidas tal y como aparecen en la figura 4.11 se puede
concluir que el 95 % de los usuarios ha calificado al producto como fćil de usar.
a
a

30


´
CAP´

Figura 4.11: Muestra de las respuestas obtenidas en el cuestionario de usabilidad.
Mejoras
Una vez analizados los datos, podemos definir qu´ cambios son necesarios para satisfacer
e
las necesidades no contempladas anteriormente de los usuarios o corregir los posibles
errores. Los cambios pueden venir definidos por problemas en la usabilidad de la aplicaciń
o
o bien por problemas en las tareas que tienen que realizar. En el perfil estudiante no es
necesario realizar ningń tipo de cambio. En el perfil de profesor no se ha detectado ningń
u
u
error de usabilidad y todos los usuarios han sido capaces de realizar las tareas propuestas.
No obstante se ha detectado un posible cambio gracias a las observaciones de los profesores.
En la versiń que se utilizń en esta evaluaciń emp´
o
o
o
ırica s´lo se pod´ ver a los alumnos
o
ıan
que estuvieran matriculados en el aõ acad´mico actual. Sin embargo por la normativa que
n
e
a

31

ETSI Inform´tica
a

´
IRICA
exist´ en ese momento, pod´ darse el caso de que un alumno habiendo cursado un grupo
ıa
ıa
del curso 2010-11, no se presentase a una convocatoria hasta el 2011-12. Por lo que se ha
definido una nueva pantalla llamada “Alumnos sin calificar” en la que se engloban a todos
los alumnos de aõs anteriores al actual.
n
La parte en la que m´s problemas han surgido corresponde a la del perfil de
a
Administraciń. La diferencia entre este perfil y el resto es que este m´dulo es el que
o
o
tiene m´s peso en la aplicaciń y es en el que se realiza el 90 % de todas las funcionalidades
a
o
de toda la aplicaciń.
o
Dentro de los errores derivados de la usabilidad nos encontramos con una mala
visualizaciń de las convocatorias definidas. Hasta ahora se mostraban en un listado todas
o
las convocatorias que se hab´ generado hasta la fecha. El problema surge cuando tienes
ıan
muchas convocatorias a lo largo del tiempo, lo que hace que localizar una convocatoria
espec´
ıfica sea dif´
ıcil. Para resolver este problema se decidi´ permitir realizar un filtrado
o
por curso acad´mico y por semestre en el que se defini´ la convocatoria (váse la figura
e
o
e
4.12 donde en su parte superior se presentan estos filtros).

Figura 4.12: Filtros de las convocatorias en el m´dulo de administraciń
o
o
A parte de los problemas de visualizaciń o una correcta localizaciń de las
o
o
convocatorias, vemos que en general la forma de representar los datos, en concreto,
la imposibilidad de reordenar los campos de las diferentes tablas generadas con los
a

32


´
CAP´
datos obtenidos repercute negativamente en la utilizaciń de la herramienta. Por ello,
o
se ha decidido permitir que todos los listados que se obtengan puedan ser reordenados
posteriormente en funciń del campo que desee el usuario. Adem´s, a partir de ahora se
o
a
marcar´ de forma clara la fila en la que se encuentren los datos de un alumno de manera
a
que se diferencie respecto al resto de datos y mejore su lectura (váse la figura 4.13 donde
e
en la parte superior se pueden ver los controles que permiten reordenar los datos y marcar
claramente los datos de una fila concreta).

Figura 4.13: Ordenaciń y marcado de datos
o
Se ha detectado tambiń un error que podemos englobarlo dentro de usabilidad y en
e
las tareas a realizar. Dada la gran cantidad de alumnos que pueden estar matriculados a la
vez en un grupo, no se ha tenido en cuenta que se debe mostrar estos datos de forma clara
y que puede darse el caso de que sea necesario realizar una misma acciń para muchos
o
alumnos a la vez, cuando ahora s´lo se puede hacer de uno en uno. Este ultimo problema
o
´
puede ser realmente importante, pues el tiempo que se tarda en realizar una acciń tan
o
sencilla como cambiar alumnos de un grupo a otro puede incrementarse mucho de forma
innecesaria. Adicionalmente en el caso del m´dulo de administraciń se ha generado una
o
o
nueva pantalla para que el administrador pueda realizar la misma operaciń a todos los
o
alumnos a la vez. Estas nuevas pantallas son:
Unificar grupos: Permite juntar a todos los alumnos de un grupo con otro, eliminando
los grupos or´
ıgenes y creando uno nuevo con los alumnos de los grupos (váse la figura
e
4.14).
a

33

ETSI Inform´tica
a

´
IRICA
Cambiar varios alumnos de un grupo a otro: Permite cambiar a un n´mero
u
determinado de alumnos de un grupo a otro (váse la figura 4.15).
e
Realizar una b´squeda de un alumno: Permite obtener toda la informaciń relativa
u
o
de un alumno sin tener que acceder al grupo al que pertenece: grupos en los que se
ha inscrito, convocatorias a la que ha asistido y las calificaciones obtenidas (váse la
e
figura 4.16).

Figura 4.14: M´dulo de administraciń. Unificar varios grupos
o
o

a

34


´
CAP´

Figura 4.15: M´dulo de administraci´n. Cambiar alumnos de grupo
o
o

Figura 4.16: M´dulo de administraci´n. Buscador de alumnos
o
o

a

35

ETSI Inform´tica
a

´
IRICA
Otro comportamiento de la aplicaciń, que si bien no da error directamente, puede ser
o
peligroso, consiste en que cuando el usuario realiza la operaciń de “Cierre de grupos” el
o
usuario no pod´ ver previamente qu´ cambios iban a ocasionarse. De esta manera que el
ıa
e
administrador no pod´ realizar posibles cambios sobre los alumnos inscritos en los grupos
ıa
antes de dicha operaciń. Por tanto, ahora esta operaciń est´ dividida en dos fases, de
o
o
a
manera que inicialmente se realiza una previsualizaciń de los cambios que van a producirse.
o
En ese momento el usuario puede realizar las operaciones que considere pertinente antes
de realizar los cambios de forma definitiva (váse la figura 4.17).
e

Figura 4.17: M´dulo de administraciń. Cierre de grupos
o
o
Vistos los cambios que se ha decidido realizar bien para solucionar errores o
para aumentar la eficiencia de las tareas implementadas, se han aãdido dos nuevas
n
funcionalidades que surgen a partir del uso continuado de la herramienta y que han sido
recogidas mediante conversaciones con usuarios. La primera consiste en generar un listado
con los alumnos que tienen una calificaciń de No Apto (váse la figura 4.18). La segunda
o
e
es la generaciń de otro listado con los alumnos que no se han inscrito en una convocatoria
o
(váse la figura C.4).
e

a

36


´
CAP´

Figura 4.18: Listado de alumnos caliﬁcados como no aptos

a

37

ETSI Inform´tica
a

´
IRICA

Figura 4.19: Listado de alumnos sin inscripci´n de convocatorias
o

a

38


Cap´tulo
ı

5

Conclusiones
Cuando surgi´ la idea de informatizar toda el procedimiento manual de la asignatura
o
“Idioma Moderno”, se ten´ cierto temor sobre si esta aplicaciń iba a tener buena acogida
ıa
o
entre los alumnos, profesores y personal de administraciń de la universidad. Dado el gran
o
n´mero de usuarios y las diferencias entre las tareas que iban a realizar, era muy importante
u
enfocar el desarrollo de la aplicaciń en el usuario. Por ello se decidi´ utilizar un diseõ
o
o
n
centrado en el usuario, que permiti´ realizar una aproximaciń muy buena sobre lo que
o
o
exactamente iba a necesitar el usuario y c´mo iba a utilizar la herramienta.
o
Una vez realizado y finalizado el trabajo, podemos decir que gracias a los estudios de
usabilidad y las evaluaciones heur´
ıstica y emp´
ırica que se realizaron, hemos conseguido
una aplicaciń robusta que cumple los requisitos definidos previamente. Mediante la
o
evaluaciń heur´
o
ıstica se han corregido errores que en muchas ocasiones se pasan por alto,
pero son bastante importantes, como por ejemplo el perfecto funcionamiento en diferentes
navegadores Web.
Con las evaluaciones emp´
ıricas, hemos conseguido que una vez implantada la
herramienta, el n´mero de incidencias sea prćticamente inexistente. La informaciń
u
a
o
recogida en los cuestionarios y sobre todo las impresiones facilitadas por los usuarios, ya sea
tras observaciń escrita en dichos cuestionarios o con los comentarios facilitados durante
o
las sesiones, ha sido de una gran ayuda para conseguir que el usuario est´ completamente
e
satisfecho con el sistema e incluso se hayan detectado nuevas funcionalidades que
inicialmente no fueron pensadas.

39

Podemos concluir que los usuarios est´n muy satisfechos con el trabajo realizado, lo
a
cual permite que si en el futuro se decide informatizar otros procedimientos, est´n a favor
e
y contribuyan a ese nuevo desarrollo.

a

40


Bibliograf´
ıa

[1] Nielsen, J. Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability
Inspection Methods, John Wiley & Sons, New York, NY. - 1994
[2] Jakob Nielsen’s Alertbox, Why You Only Need to Test with 5 Users - 2000
[3] Referencia Web usabilidad: http://www.useit.com/
[4] ISO 13407 User centred desingns process for interactive systems - 1998

41

BIBLIOGRAF´
IA

a

42


´
Apendice

A

Contenido del CD-ROM
De forma adjunta a este documento se entrega un soporte digital en el que se encuentran
el ﬁchero correspondiente al presente documento (Memoria/memoria.pdf).

43

a

44


´
Apendice

B

Formulario de consentimiento
Investigador: Juan Carlos Hernńdez Guti´rrez
a
e
Antes de dar su aprobaciń para colaborar en este estudio, le sugerimos que se tome
o
unos minutos para leer detenidamente cada uno de los puntos que aqu´ se exponen.
ı
Objetivo del estudio
El objetivo de este estudio es evaluar las impresiones sobre la aplicaciń de Idioma
o
Moderno de la Universidad Rey Juan Carlos, que servir´ para un mejor funcionamiento en
a
dicha aplicaciń.
o
Procedimiento
La metodolog´ a seguir, consiste en lo siguiente: un cuestionario previo al estudio del
ıa
que se extraer´ el perfil del participante y las caracter´
a
ısticas relevantes que la aplicaciń
o
deber´ contemplar.
ıa
Sus datos serń guardados para la realizaciń de dicha aplicaciń y enseãr el prototipo
a
o
o
n
una vez realizado.
Confidencialidad
Acepto participar, bajo compromiso de que toda la informaciń que proporciono sea
o
confidencial. En ningń momento, se podr´ publicar informaciń capaz de identificarme,
u
a
o
incluidos informes o resultados finales. En caso de requerir publicar alguna informaciń
o
que a mi concierne, queda asumido que antes deber´ ser pedido mi consentimiento,
a
45

adem´s de otorgarme una trascripciń de lo que ser´ publicado. Finalmente, queda
a
o
a
estrictamente prohibido compartir mi informaciń personal con alguna otra organizaciń
o
o
o grupo de investigaciń diferente del que aqu´ suscribe. Una vez aclarado lo anterior,
o
ı
acepto proporcionar mi informaciń personal necesaria para participar en el estudio
o
desarrollado con el objetivo de mejorar el funcionamiento de dicha aplicaciń. Entiendo que
o
esta informaciń ser´ utilizada solamente para los prop´sitos establecidos en la presente
o
a
o
declaraciń y mi consentimiento est´ condicionado a que la Universidad Rey Juan Carlos
o
a
cumpla con sus deberes y obligaciones en virtud de la Ley de Protecciń de Datos de 1998.
o
Consentimiento
Estoy de acuerdo en colaborar con el estudio elaborado para la mejora del
funcionamiento de la aplicaciń de Idioma Moderno de la Universidad Rey Juan Carlos. He
o
tenido la oportunidad de discutir lo concerniente a este estudio, y mis preguntas han sido
contestadas a mi satisfacciń. Mi participaciń es voluntaria, y en caso de no convenir a
o
o
mis intereses, puedo retirarme y dar por terminada mi colaboraciń en el momento qu´ yo
o
e
as´ lo disponga. La realizaciń del cuestionario indica su conformidad con los datos arriba
ı
o
descritos

a

46


´
Apendice

C

Cuestionarios
El texto que aparece a continuaciń pertenece a las preguntas sobre usabilidad que
o
aparecen en los cuestionarios de los tres perfiles de usuario.
El objetivo de este cuestionario es realizar un an´lisis para el mejor funcionamiento de
a
la aplicaciń de Idioma Moderno, que se utiliza en la Universidad Rey Juan Carlos.
o
La informaciń que usted proporcione es completamente confidencial y no
o
se almacenar´ la informaciń en soportes inform´ticos que podrán identificarle
a
o
a
ı
posteriormente.
Usted no tiene la obligaciń de participar y puede retirarse libremente en cualquier
o
momento.

Antes de realizar este cuestionario le recomendamos que lea el siguiente

formulario de conformidad.
http://goo.gl/FE0wU

47

Figura C.1: Preguntas sobre las caracter´
ısticas de los usuarios
a

48


´
APENDICE C. CUESTIONARIOS

Figura C.2: Preguntas sobre la usabilidad de la aplicaci´n
o
a

49

ETSI Inform´tica
a

C.1. CUESTIONARIO DEL ESTUDIANTE

C.1.

Cuestionario del estudiante

Se puede acceder a este cuestionario desde el siguiente enlace: http://goo.gl/TmNN8

Figura C.3: Preguntas sobre la tareas que debe realizar el estudiante en la aplicaci´n
o

a

50


´
APENDICE C. CUESTIONARIOS

C.2.

Cuestionario del profesor

Se puede acceder a este cuestionario desde el siguiente enlace: http://goo.gl/728XX

Figura C.4: Preguntas sobre la tareas que debe realizar el profesor en la aplicaci´n
o

C.3.

Cuestionario del administrador

Se puede acceder a este cuestionario desde el siguiente enlace: http://goo.gl/Su0Nc
En la ﬁgura C.5 se muestran las tareas que debe realizar el administrador.

a

51

ETSI Inform´tica
a

C.3. CUESTIONARIO DEL ADMINISTRADOR

Figura C.5: Preguntas sobre la tareas que debe realizar el administrador en la aplicaci´n
o
a

52


Miim estudio usabilidad_idiomamoderno_juancarloshernandezgutierrez ok

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Miim estudio usabilidad_idiomamoderno_juancarloshernandezgutierrez ok

Similar a Miim estudio usabilidad_idiomamoderno_juancarloshernandezgutierrez ok (20)

Más de Universidad Tecnológica del Perú

Más de Universidad Tecnológica del Perú (20)

Último

Último (20)

Miim estudio usabilidad_idiomamoderno_juancarloshernandezgutierrez ok