ANLISIS, DISEO Y CONSTRUCCIN DE SOFTWARE EN LA WEB CON

UN-MTODO PARA UNA EXPERIENCIA DE USUARIO SATISFACTORIA.

DANIEL GONZLEZ BUSTAMANTE

Trabajo de grado para optar al ttulo de

Ingeniero de Sistemas e Informtica

Directora
Gloria Luca Giraldo Gmez
I.I, M.Sc, Ph.D

UNIVERSIDAD NACIONAL DE COLOMBIA

SEDE MEDELLN
FACULTAD DE MINAS
ESCUELA DE SISTEMAS
MEDELLN
2012

Anlisis, diseo y construccin de software en la web con UN-MTODO para una experiencia de usuario satisfactoria
by Daniel Gonzlez is licensed under a Creative Commons Reconocimiento 4.0 Internacional License.

ii

CONTENIDO
Pg.
LISTA DE TABLAS

LISTA DE ILUSTRACIONES

LISTA DE ANEXOS

GLOSARIO

RESUMEN

13

ABSTRACT

14

RESUMO

15

INTRODUCCIN

16

1.1 PLANTEAMIENTO DEL PROBLEMA

1.2 OBJETIVOS
1.2.1 Objetivo General
1.2.2 Objetivos Especficos
1.3 ORGANIZACIN DEL TRABAJO DE GRADO

18
18
18
19
20
21

MARCO TERICO
2.1 LA INTERACCIN HUMANO - COMPUTADOR
2.2 DISEO CENTRADO EN EL USUARIO - DISEO CENTRADO EN EL USO.
2.3 INGENIERA DE SOFTWARE
2.3.2 Diferencias entre la Ingeniera de Software y la Interaccin HumanoComputador.
2.4 CALIDAD DE SOFTWARE
2.5 CMO REALMENTE USAMOS LA WEB?
2.5.1 Diferencias entre los Sitios y las Aplicaciones Web
2.6 DEFINICIN: USABILIDAD.
2.7 DEFINICIN: EXPERIENCIA DE USUARIO (UX)
2.7.1 Elementos de la Experiencia de Usuario
2.8 DEFINICIN: SATISFACCIN DE USO.
2.8.1 Factores del diseo que Influyen en la Satisfaccin de Uso.
2.9 UTILIDAD
2.9.1 Relacin entre Utilidad e Ingeniera de Requisitos.
2.9.1 UN-Mtodo: Metodologa de la Universidad Nacional de Colombia, Sede
Medelln, para la Elicitacin de Requisitos de Software.
2.10 FUNCIONALIDAD
2.10.1 Funcionalidad y Usabilidad
2.10.2 Errores del Software y Mantenimiento.
2.12 DISEO DE INTERACCIN: CMO ENCONTRAR Y MANIPULAR LA
INFORMACIN?

21
22
25
26
28
30
32
33
36
39
41
42
43
44
47
49
50
51
54

2.12.1 Arquitectura de Informacin vs. Diseo de Interaccin.

2.12.2 Casos de Uso.
2.12.3 Fundamentos del Diseo de Interaccin.
2.12.3.1 Eficiencia y Ley de Fitts.
2.12.3.2 Productividad.
2.12.3.3 Autonoma.
2.12.3.4 La aplicacin debe anticiparse al usuario.
2.12.3.5 Consistencia.
2.12.3.6 Seguridad.
2.12.3.7 Capacidad de Aprendizaje.
2.12.3.8 Comprensin.

2.11 ACCESIBILIDAD
2.11.1 Pautas de Evaluacin de la Accesibilidad en la Web. (W3C)
2.11.1.1 Proporcionar alternativas para el contenido.
2.11.1.2 Contraste de Color.
2.11.1.3 Marcadores y Hojas de Estilo (CSS)
2.11.1.4 Preferencias de Idioma
2.11.1.5 Creacin de tablas que se transformen de acuerdo al contenido.
2.11.1.6 Manejo de JavaScript
2.11.1.7 El usuario tiene el control sobre los cambios de contenido.
2.11.1.8 Accesibilidad directa de las interfaces.
2.11.1.9 Diseo Independiente del Dispositivo.

2.13 ESTTICA Y COMPOSICIN VISUAL

2.13.2 Reglas Fundamentales del Diseo Visual.
2.13.3 Tipografa y Legibilidad
2.13.4 Esquemas de Color.
2.14 CREDIBILIDAD Y CONFIABILIDAD
2.15 USABILIDAD
2.15.1 Tcnicas de Evaluacin de la Usabilidad.
2.15.1.1
2.15.1.2
2.15.1.3
2.15.1.4

Evaluacin Heurstica
Paseo Cognitivo (Cognitive Walkthrough)
Inspeccin de Estndares.
Seguimiento Interdisciplinario.

54
55
56

56
58
59
59
59
60
60
61

62
63
64
65
65
65
66
66
66
67
67

68
70
73
74
76
77
78
78
80
81
81

81

2.15.2 Ingeniera de la Usabilidad

82

2.15.2.1 Metodologas

85

MODELO EVALUATIVO PROPUESTO

3.1 METODOLOGA
3.2.1 CUESTIONARIO

85
86

PROTOTIPO DE APLICACIN

91

4.1 ESQUEMA DE UML

4.1.1 DIAGRAMA DE CLASES
4.1.2 DIAGRAMA ENTIDAD-RELACIN
4.1.3 MODELO RELACIONAL

91
92
93
94
95

ANLISIS DE RESULTADOS

5.1 EVALUACIN DEL PROTOTIPO ANTIGUO

5.1.1 EVALUACIN HEURSTICA DE LA FUNCIONALIDAD
5.1.2 EVALUACIN POR ESTNDARES DE LA ACCESIBILIDAD
5.1.3 EVALUACIN GENERAL CON USUARIOS
5.2 NUEVO PROTOTIPO
5.2.1 EVALUACIN HEURSTICA DE LA FUNCIONALIDAD
5.2.2 EVALUACIN POR ESTNDARES DE LA ACCESIBILIDAD
5.2.3 EVALUACIN GENERAL CON USUARIOS
5.3 ANLISIS

95
96
96
98
102
103
103
105
108

CONCLUSIONES

110

BIBLIOGRAFA

112

ANEXOS

117

LISTA DE TABLAS
Pg.
TABLA 1: DIFERENCIAS ENTRE EL DISEO CENTRADO EN EL USUARIO, Y EL DISEO
CENTRADO EN EL USO.
24
TABLA 2: DIFERENCIAS ENTRE LA INGENIERA DE SOFTWARE Y LA INTERACCIN
HUMANO-COMPUTADOR
28
TABLA 3: TABLA COMPARATIVA ENTRE SITIO WEB Y APLICACIN WEB.
33
TABLA 4: CRITERIOS PARA LA CLASIFICACIN DE LOS FACTORES DE DISEO
42
TABLA 5: LEYES BSICAS DE LA COMPOSICIN POR GESTALT.
71
TABLA 6: EFECTOS CROMTICOS ASOCIADOS A LOS COLORES EN EL DISEO WEB. 75
TABLA 7: METODOLOGAS DE EVALUACIN DE LA USABILIDAD
84
TABLA 8: TEST PROPUESTO PARA LA MEDICIN DE LA EXPERIENCIA DE USUARIO 90
TABLA 9: PORCENTAJE DE CUMPLIMIENTO DE ACCESIBILIDAD POR CASO DE USO. 97
TABLA 10: TABLA RESUMEN DE LA EVALUACIN CON USUARIOS DEL PROTOTIPO
ANTIGUO.
99
TABLA 11: RESULTADOS DE LA EVALUACIN POR USUARIOS - PROTOTIPO ANTIGUO
101
TABLA 12: TABLA DEL CUMPLIMIENTO DE LOS ESTNDARES DE LA W3C PRIORIDAD A PROTOTIPO NUEVO
103
TABLA 13: TABLA DEL CUMPLIMIENTO DE LOS ESTNDARES DE LA W3C PRIORIDAD
AA - PROTOTIPO NUEVO
105
TABLA 14: TABLA RESUMEN DE LA EVALUACIN CON USUARIOS DEL PROTOTIPO
NUEVO.
105
TABLA 15: DIAGRAMAS Y RESULTADOS DE LA EVALUACIN CON USUARIOS DE
PROTOTIPO NUEVO
107
TABLA 16: RESUMEN DE LAS PAUTAS DE ACCESIBILIDAD ESTABLECIDAS POR LA W3C
DE PRIORIDAD 1 (A) (WCAG 1.0)
121
TABLA 17: RESUMEN DE LAS PAUTAS DE ACCESIBILIDAD ESTABLECIDAS POR LA W3C
DE PRIORIDAD 1 (AA) (WCAG 1.0)
124
TABLA 18: RESUMEN DE LAS PAUTAS DE ACCESIBILIDAD ESTABLECIDAS POR LA W3C
DE PRIORIDAD 1 (AAA) (WCAG 1.0)
125
TABLA 19: RELACIN ENTRE LOS FACTORES DE DISEO, Y LOS ROLES
PROFESIONALES
127

LISTA DE ILUSTRACIONES
Pg.
ILUSTRACIN 1: MBITOS DEL TRABAJO DE GRADO.
17
ILUSTRACIN 2: ACTIVIDADES DEL DISEO CENTRADO EN EL USUARIO (ISO-13407) 23
ILUSTRACIN 3: MODELO EN CASCADA DE LA INGENIERA DE SOFTWARE
25
ILUSTRACIN 4: CARACTERSTICAS DE LA CALIDAD DEL SOFTWARE SEGN EL
ESTNDAR ISO 9126
29
ILUSTRACIN 5: CARACTERSTICAS DE LA CALIDAD DE USO SEGN EL ESTNDAR ISO
9126
30
ILUSTRACIN 6: ASPECTOS Y SUBDIVISIONES DE LA EXPERIENCIA DE USUARIO
38
ILUSTRACIN 7: ELEMENTOS DE LA EXPERIENCIA DE USUARIO SEGN GARRETT. 40
ILUSTRACIN 8: FACTORES DE DISEO ORIENTADOS A LA SATISFACCIN DE USO 43
ILUSTRACIN 9: IMPACTO DE LAS MODIFICACIONES DEL PRODUCTO, DEPENDIENDO
DE LA ETAPA DE DESARROLLO.
47
ILUSTRACIN 10: PRINCIPALES CAUSAS DE LOS DEFECTOS DEL SOFTWARE
53
ILUSTRACIN 11: DIAGRAMA QUE ILUSTRA EL PRINCIPIO DE LA LEY DE FITTS.
57
ILUSTRACIN 12: GUA VISUAL A TRAVS DE UNA JERARQUA VISUAL.
72
ILUSTRACIN 13: DIAGRAMA DE CLASES (PROTOTIPO DIMA)
92
ILUSTRACIN 14: DIAGRAMA ENTIDAD- ASOCIACIN (PROTOTIPO DIMA)
93
ILUSTRACIN 15: MODELO RELACIONAL
94
ILUSTRACIN 16: CAPTURA DE PANTALLA DEL PROTOTIPO ANTIGUO
95
ILUSTRACIN 17: PORCENTAJE DE CUMPLIMIENTO DE LOS ESTNDARES DE
ACCESIBILIDAD - PRIORIDAD A
97
ILUSTRACIN 18: CUMPLIMIENTO DE LOS ESTNDARES DE ACCESIBILIDAD,
PRIORIDAD AA POR EL PROTOTIPO ANTIGUO.
98
ILUSTRACIN 19: CAPTURAS DE PANTALLA DEL PROTOTIPO PROPUESTO DESDE
VARIOS DISPOSITIVOS
102
ILUSTRACIN 20: GRFICO DEL PORCENTAJE DE CUMPLIMIENTO-INCUMPLIMIENTO
DE LOS ESTNDARES DE LA W3C. PROTOTIPO NUEVO.
104
ILUSTRACIN 21: GRFICO DEL PORCENTAJE DE CUMPLIMIENTO DE LOS
ESTNDARES DE ACCESIBILIDAD - PRIORIDAD AA - PROTOTIPO NUEVO
104
ILUSTRACIN 22: ELEMENTOS DE LA EXPERIENCIA DE USUARIO (GRFICO RESUMEN)
117
ILUSTRACIN 23: ESQUEMA GENERAL DE LA METODOLOGA UN-MTODO. TOMADO
DE: (ARANGO, F; ZAPATA, C, M; 2006)
118
ILUSTRACIN 24: DIAGRAMA DE CAUSA-EFECTO, CUYAS CAUSAS (EN ROJO) SE
SATISFACEN CON LA SOLUCIN PROPUESTA.
119
ILUSTRACIN 25: RESOLUCIN DE PANTALLA DE DISPOSITIVOS MS COMUNES. 126
ILUSTRACIN 26: CUADRO EXPLICATIVO DE LA LEGIBILIDAD DEL TEXTO SEGN SU
COLOR POR: EVA HELLER
127
ILUSTRACIN 27: MODELO DETALLADO DE LA METODOLOGA DE JAKOB NIELSEN 128
ILUSTRACIN 28: ESQUEMA DE LA METODOLOGA DUTCH - INGENIERA DE
USABILIDAD
130
ILUSTRACIN 29: CICLO DE VIDA DE LA INGENIERA DE USABILIDAD PROPUESTO POR
D.J. MAYHEW
131
ILUSTRACIN 30: MODELO POR FASES DEL MPIU+A
133

LISTA DE ANEXOS
Pg.
ANEXO A: ELEMENTOS DE LA EXPERIENCIA DE USUARIO
117
ANEXO B - ESQUEMA GENERAL DE LA METODOLOGA UN-MTODO
118
ANEXO C: PROPUESTA DE SOLUCIN CREATIVA CON UN-MTODO
119
ANEXO D EVALUACIN DE LAS PAUTAS DE ACCESIBILIDAD EN LA WEB, SEGN LA
WCAG VERSIN 1.0
120
ANEXO E - TAMAOS DE PANTALLA MS COMUNES
126
ANEXO F - LEGIBILIDAD DE LOS TEXTOS SEGN SU COLOR
127
ANEXO G - RELACIN FACTORES DE DISEO- ROLES PROFESIONALES
127
ANEXO H METODOLOGAS DE LA INGENIERA DE USABILIDAD
128
ANEXO I: CASOS DE USO ASOCIADOS AL PROTOTIPO
135

GLOSARIO

accesibilidad.
1. f. Cualidad de accesible.
aceptabilidad.
1. f. Cualidad de aceptable.
2. f. Ling. Conjunto de propiedades gramaticales y semnticas que un
enunciado debe reunir para que resulte comprensible por los hablantes de una
lengua dada.
cualitativo, va. (Del lat. qualitatvus).
1. adj. Que denota cualidad.
cuantificacin.
1. f. Accin y efecto de cuantificar.
2. f. Fil. Expresin de la cantidad (extensin y comprensin) en los enunciados
o juicios, o especialmente en el predicado.
cuantitativo, va. (Del lat. quanttas, -tis).
1. adj. Perteneciente o relativo a la cantidad.
emprico, ca. (Del lat. empircus, que se rige por la experiencia).
1. adj. Perteneciente o relativo a la experiencia.
2. adj. Fundado en ella.
ergonoma.
(Del gr. , obra, trabajo, y -noma).

1. f. Estudio de datos biolgicos y tecnolgicos aplicados a problemas de

mutua adaptacin entre el hombre y la mquina.
fiabilidad.
1. f. Cualidad de fiable.
2. f. Probabilidad de buen funcionamiento de algo.
flexible. (Del lat. flexiblis).
1. adj. Que tiene disposicin para doblarse fcilmente.
2. adj. Que en un enfrentamiento se pliega con facilidad a la opinin, a la
voluntad o a la actitud de otro o de otros. Carcter, persona flexible.
3. adj. Que no se sujeta a normas estrictas, a dogmas o a trabas. Ideologa,
legislacin flexible.
4. adj. Susceptible de cambios o variaciones segn las circunstancias o
necesidades. Horario, programa flexible.
5. m. Cable formado de hilos finos de cobre recubiertos de una capa aislante,
que se emplea como conductor elctrico.
funcional.
1. adj. Perteneciente o relativo a las funciones. Competencia, procedimiento
funcional. Dependencia o enlace funcional.
2. adj. Se dice de todo aquello en cuyo diseo u organizacin se ha atendido,
sobre todo, a la facilidad, utilidad y comodidad de su empleo.
3. adj. Dicho de una obra o de una tcnica: Eficazmente adecuada a sus fines.
4. adj. Perteneciente o relativo a las funciones biolgicas o psquicas.
Recuperacin funcional.
5. adj. Ling. Perteneciente o relativo al funcionalismo.
10

6. adj. Ling. Se dice de las unidades gramaticales de relacin, a diferencia de

las unidades con contenido lxico.
7. adj. Ling. Se dice de diversas escuelas lingsticas que estudian el lenguaje
atendiendo a la funcin que desempean los elementos idiomticos.
8. adj. Med. Se dice de los sntomas y trastornos en los cuales la alteracin
morbosa de los rganos no va acompaada de lesiones visibles y es, por tanto,
susceptible de desaparicin rpida y total.
heurstico, ca.
(Del gr. , hallar, inventar, y tico).
1. adj. Perteneciente o relativo a la heurstica.
2. f. Tcnica de la indagacin y del descubrimiento.
3. f. Busca o investigacin de documentos o fuentes histricas.
4. f. En algunas ciencias, manera de buscar la solucin de un problema
mediante mtodos no rigurosos, como por tanteo, reglas empricas, etc.
interdisciplinariedad.
1. f. Cualidad de interdisciplinario.
interdisciplinario, -ria.
1. adj. Dicho de un estudio o de otra actividad: Que se realiza con la
cooperacin de varias disciplinas.
interfaz. (Del ingl. interface, superficie de contacto).
1. f. Inform. Conexin fsica y funcional entre dos aparatos o sistemas
independientes.
psicologa. (De psico- y -loga).

11

1. f. Parte de la filosofa que trata del alma, sus facultades y operaciones.

2. f. Todo aquello que atae al espritu.
3. f. Ciencia que estudia los procesos mentales en personas y en animales.
4. f. Manera de sentir de una persona o de un pueblo.
5. f. Sntesis de los caracteres espirituales y morales de un pueblo o de una
nacin.
6. f. Todo aquello que se refiere a la conducta de los animales.

12

RESUMEN

El presente trabajo de grado, pretende indagar los factores que influyen

positivamente en la experiencia de usuario, con el fin de implementar estos
factores en la metodologa de anlisis, diseo y construccin de software en la
web. Por esta razn, se propuso realizar una investigacin en el campo de la
Interaccin Humano-Computador, para plantear una teora que rena las reglas
bsicas necesarias, para evaluar y lograr una experiencia de usuario
satisfactoria, que por lo general, estn ntimamente relacionadas con el ciclo
iterativo del desarrollo de software.
Partiendo de las definiciones formales, se ilustran aquellos elementos que
conforman la experiencia de usuario, de los cuales, se hace un especial nfasis
en siete factores de diseo, ligados implcitamente, que influyen positivamente
en la satisfaccin y no frustracin de uso; utilidad, funcionalidad, accesibilidad,
diseo de interaccin, esttica, credibilidad y usabilidad-; a partir de los cuales
se relacionan las fases de desarrollo de software, y se deducen las reglas que
evalan la satisfaccin de uso.
Finalmente, los conceptos analizados a partir del marco terico, se
implementan en un prototipo de aplicacin, cuya evaluacin fue comparada con
otros prototipos desarrollados anteriormente, para luego deducir los efectos de
stos, en la interaccin del usuario con la aplicacin.
Palabras clave: diseo web, interaccin Humano-Computador, experiencia de
Usuario, satisfaccin de uso, utilidad, usabilidad, funcionalidad, accesibilidad,
esttica, interaccin, credibilidad, evaluacin, prototipo.

13

ABSTRACT

This capstone project, aims to investigate the factors positively influencing in

the user experience, in order to implement these factors in the methodology of
analysis, design and construction of software on the web. Due to this reason, it
was suggested to make a research in the field of Human-Computer Interaction,
to pose a theory which satisfies the basic and necessary rules to evaluate and
make a satisfactory user experience, that generally, are intimately related with
the iterative cycle software development.
Starting from the formal definitions, it is possible to illustrate the elements that
form the user experience, of which, special emphasis is made in seven design
factors, linked implicitly, positively influencing the factor of satisfaction and
frustration of use; -utility, functionality, accessibility, interaction design,
aesthetics, reliability and usability-; from which relate the phases of software
development, and are deducted the rules that evaluate the satisfaction of use.
Finally,

the

concepts

analyzed

from

the

theoretical

framework,

are

implemented in a prototype application, which evaluation was compared with

other previously developed prototypes, and then it was deduced the effects of
these in the user interaction with the application.

Keywords: web design, Human-Computer interaction, user experience,

satisfaction of use, utility, usability, functionality, accessibility, aesthetics,
interaction, credibility, evaluation, prototype.

14

RESUMO

Esta monografia de graduao indaga os fatores que influem positivamente na

experincia do usurio, com o fim de program-los na metodologia da anlise,
desenho e construo do software na web. Por isso, prope-se realizar uma
investigao na rea da interao Humano-Computador e, assim, definir uma
teoria que rena as regras bsicas necessrias, que geralmente esto
relacionadas intimamente com o ciclo do desarrolho do software, para avaliar
uma experincia satisfatria do usurio.
Partindo das definies formais, ilustram-se aqueles elementos que conformam
a experincia do usurio, dando nfase em sete fatores do desenho, ligados
implicitamente, que influem positivamente na satisfao e no frustrao ao
uso utilidade, funcionalidade, acessibilidade, desenho da interao, esttica,
credibilidade e usabilidade - relacionando-os com as fases do desarrolho do
software e deduzindo as regras que avaliam a satisfao ao uso.
Finalmente, os conceitos analisados partindo do marco terico, programam-se
num prottipo, cuja evacuao foi comparada com outros desarrolhados
anteriormente, para logo deduzir seus efeitos, na interao do usurio e a
aplicao.

Palavras chaves: desenho web, interao Humano-Computador, experincia

de

Usurio,

satisfao

de

uso,

utilidade,

usabilidade,

funcionalidade,

acessibilidade, esttica, interao, credibilidade, evacuao, prottipo.

15

INTRODUCCIN

Una tarde de Noviembre de 2010, me encontraba presentando el ltimo

entregable de Diseo de Software, en el cual aplicaba todos los conceptos de
Ingeniera de Software en un prototipo funcional, alojado en la web, y que
cumpliera con todos los requisitos establecidos por el cliente.
Lamentablemente, esa lluviosa y desastrosa tarde, despus de obtener un
mediocre 2.9, surgieron demasiados interrogantes: qu factores influyeron
para obtener tan mala calificacin? Por qu no logramos satisfacer los
parmetros acordados? En qu fallamos?
As, como no logramos pasar la prueba, decid adentrarme en esta
investigacin, que busca principalmente, presentar los factores que influyen en
el concepto de satisfaccin, y aplicarlos en las aplicaciones web, construidas
mediante la metodologa UN-Mtodo.
Vale la pena considerar, que en un mundo cada vez ms conectado, los
productos de software pasaron a ser accedidos desde cualquier lugar y de
mltiples dispositivos. Con una cifra de 255 millones de sitios web registrados
hasta el ao 2011 (Netcraft, 2010), y un total de 2000 millones de usuarios que
la actualidad cuentan con acceso a la red (Internet World Stats, 2011), la
disponibilidad de cualquier aplicacin supone una necesidad de satisfacer a
una audiencia potencialmente enorme; adems, en internet, los usuarios
poseen una gran impaciencia por recibir satisfaccin inmediata. Si no se
imaginan cmo usar un sitio web en un minuto o quizs dos, terminan por
pensar que no merece la pena perder el tiempo, y se van; igual, internet les
ofrece un amplio abanico de posibilidades para elegir.
Generalmente, en el desarrollo tradicional de los productos fsicos, los usuarios
no pueden experimentar la usabilidad de ste hasta que lo adquiran y lo

16

pagaban; mientras que en el desarrollo de software y en la web, los usuarios

experimentan primero, y pagan despus.
Por esta razn, la usabilidad y la experiencia de usuario, han asumido una
parte mucho ms importante de la economa de Internet que en el pasado.
Siendo as, con la constante evolucin de las tecnologas de la informacin, es
de vital importancia, investigar los comportamientos de los usuarios en su
interaccin Humano-Computador, con el fin de lograr una alta satisfaccin en el
uso de las aplicaciones desarrolladas con estrictos mtodos de anlisis,
desarrollo y construccin de software, y as, aumentar significativamente su
intencin de uso, en un entorno donde la competencia se encuentra tan solo a
un clic; as que ante tal magnitud, no se pueden cometer aquellos errores que
frustraron el uso de nuestro prototipo final.
La investigacin que se desarrolla en el siguiente trabajo de grado, comprende
las siguientes reas del conocimiento: Ingeniera de software, las tecnologas
de Informacin, y la ergonoma. Principalmente se centra en el desarrollo de
requisitos, por medio de UN-Mtodo, y adicionndole los mbitos de usabilidad,
y tecnologas web como ejes centrales del trabajo de grado.

Ilustracin 1: mbitos del Trabajo de Grado.

17

1.1 PLANTEAMIENTO DEL PROBLEMA

Alguna vez, nos hemos preguntado por qu algunas aplicaciones web que
prestan el mismo servicio son tan visitadas y otras no? Esto se debe, a que el
usuario al fin de cuentas es el que califica y aprueba un sitio, y en caso de que
no logre conseguir sus objetivos o la aplicacin no logre satisfacer sus
necesidades, sencillamente la abandona en busca de otra alternativa; al fin al
cabo, en internet, la competencia slo cuestin de hacer clic aqu o all.
Por esa razn, es lgico que la satisfaccin del usuario final se convierta en el
primer condicionante del xito o fracaso de cualquier proyecto web. Un usuario
satisfecho podr pasar ms tiempo en el sitio web, volver a visitarlo o
recomendrselo a otros usuarios.
As, cuando hablamos de satisfaccin de uso, nos referimos a un concepto
complejo y difcil de delimitar; ya que puede llegar a ser demasiado subjetivo, y
cuyos parmetros y variables son difciles de cuantificar.
Como desarrolladores, es de vital importancia conocer qu factores de diseo
influyen en la satisfaccin de uso; como lo hacen y qu interrelaciones se
presentan entre ellos, para aplicar y evaluar estos conceptos en el desarrollo
de software, y as, construir sitios y aplicaciones web mucho ms competitivas
y que faciliten las interacciones entre el usuario y la aplicacin.

1.2 OBJETIVOS

1.2.1 Objetivo General

Indagar el fenmeno de uso la web desde la perspectiva de diseo en la
satisfaccin o frustracin del usuario final, que permitir presentar los criterios

18

que influyen positiva o negativamente en la intencin de uso de una aplicacin

web, y con base a stos, construir un prototipo funcional que integre las nuevas
tecnologas de informacin y los mtodos de anlisis, diseo y construccin de
software aplicado a la metodologa (UN-Mtodo).

1.2.2 Objetivos Especficos

Investigar los principales factores que influyen en la satisfaccin en el

uso de una aplicacin web, e identificndolos desde el punto de vista
higinico o motivador.

Destacar las tcnicas existentes que permiten aumentar el nivel de cada

uno de los factores que influyen en la satisfaccin de uso del usuario
final.

Analizar cada una de las tcnicas o mtodos que permiten la medicin y

estimacin de cada uno de los factores que influyen en la satisfaccin de
uso del usuario final en una aplicacin web.

Realizar las pruebas correspondientes con un prototipo final construido

bajo la metodologa UN-Mtodo, aplicando las tcnicas que permiten
aumentar la satisfaccin del usuario mientras utiliza la aplicacin.

Para cumplir estas metas, se propone la inclusin de nuevos mtodos al marco

terico de UN-Mtodo, que permitan la construccin de software, con una alta
usabilidad y satisfaccin para el usuario final, de modo que pueda plantearse
una nueva investigacin en este campo, y el desarrollo de futuros prototipos.
El planteamiento de la investigacin se define principalmente sobre dos puntos
de vista. El primero, compondr una aproximacin terica a la experiencia del
usuario, la usabilidad y satisfaccin de uso en la web, aportando modelo
explicativo de la perspectiva del impacto de los diferentes factores de diseo en
dicha satisfaccin. El segundo, consiste en ayudar a mejorar los modelos de

19

anlisis, diseo y construccin de software, definiendo criterios que permitan

evaluar la satisfaccin del usuario en las aplicaciones web.
As, los pasos a seguir en este trabajo investigativo son los siguientes:
1. Recopilacin de la informacin, anlisis, conceptos y criterios de
evaluacin de la usabilidad, experiencia de usuario y satisfaccin de uso
a partir de la literatura especializada.
2. Verificacin de los criterios seleccionados.
3. Integracin al prototipo de evaluacin propuesto, construido a partir de la
metodologa UN-Mtodo.
4. Evaluacin y pruebas del prototipo.

1.3 ORGANIZACIN DEL TRABAJO DE GRADO

El trabajo de grado, est compuesto por cinco captulos. La primera parte,
consta de la introduccin, el planteamiento del problema y los objetivos. El
segundo captulo, corresponde al marco terico, el cual estudia el
comportamiento de los usuarios de la web, profundizar en los conceptos de
usabilidad y satisfaccin de uso, analizando cul es la relacin real entre
ambos, y se definen siete factores de diseo que influyen directamente en la
medicin de la satisfaccin de uso de una aplicacin. El anlisis de cada uno
de los factores, se realiza detalladamente a partir de bibliografa especializada.
En el captulo tres, se presenta el modelo evaluativo que recoge toda la
diversos modelos para la realizar pruebas de usabilidad y satisfaccin de uso
de una aplicacin web, las cuales, finalmente sern aplicadas en un prototipo
final, planteado en el captulo cuatro, y desarrollado utilizando la metodologa
propuesta por los profesores de la Escuela de Sistemas de la Universidad
Nacional (UN-mtodo), que ha sido fundamental en el anlisis, desarrollo y
construccin de software.

20

MARCO TERICO
A diferencia de los productos tangibles, las aplica las aplicaciones de software
desarrolladas en la web, definen gran parte de su xito o fracaso a la
satisfaccin del usuario final. En caso de que ste no consiga sus objetivos o la
aplicacin no satisface sus necesidades, sencillamente abandonar el sitio, en
busca de otra alternativa. Por esta razn, es de vital importancia que en el
anlisis y construccin del software para la web, se tenga en cuenta el diseo
orientado al usuario para lograr una alta satisfaccin, y adems una mayor
probabilidad de que vuelva a visitar el sitio, o se fidelice con la aplicacin
fcilmente, ya que para el usuario de la web existe como regla principal "si algo
es complicado de utilizar, simplemente no lo uso demasiado". (Krug, 2006)

2.1 LA INTERACCIN HUMANO - COMPUTADOR

El creciente desarrollo cientfico, ha permitido automatizar las tareas que
antiguamente realizaba el hombre, al disear aparatos que cumplieran esas
funciones eficientemente, sin importar la dificultad en el manejo de stos, ya
que el experto conoca cada detalle de su funcionamiento.
Luego, al observar que era prcticamente imposible, enviar un cientfico por
cada sistema de defensa instalado en los aviones, se plantea la necesidad de
capacitar el personal para su uso, a pesar de la complejidad en el manejo de
estos aparatos, ya que al usarlo, se disminuan otras capacidades del usuario,
o se tomaba demasiado tiempo para realizar una accin. A partir de este
momento, se plantea la necesidad de mejorar la Interaccin HumanoComputador, (HCI) por sus siglas en ingls.
A partir de la invencin de los computadores, y la masificacin de esta
tecnologa, se genera un hito en el desarrollo de sistemas y productos, que
permitieron realizar tareas de forma sencilla y rpida, pero a pesar de las
capacidades de los computadores, fue complejo su entendimiento, haciendo

21

que el usuario promedio sintiera frustracin al usarlo. De ah, los sistemas

operativos, ms exitosos, implementaron la interfaz grfica como mtodo fcil y
sencillo de interaccin entre el usuario y la mquina.
Ahora, cada vez hay ms dispositivos conectados, interactuando entre si y que
convergen en internet, y como la red ms grande del mundo, es necesario
estudiar aquellos componentes de interaccin, entre humano-computador, que
mediante el desarrollo de software y productos para la web, permitan la
correcta visualizacin e interaccin con el producto, de tal manera que
promueva su uso, y fidelice al usuario a tal punto de convertirlo en parte de su
vida diaria.
2.2 DISEO CENTRADO EN EL USUARIO - DISEO CENTRADO EN EL
USO.
En el anlisis y desarrollo de sistemas interactivos, es necesario conocer las
particularidades de los usuarios, quienes al final, sern quienes determinen el
xito o el fracaso de las aplicaciones, en gran parte dependiendo de la
familiaridad que encuentren en ellas. Por lo general, se busca que la aplicacin
proporcione seguridad y confiabilidad mientras el usuario manipula el sistema.
Por esta razn, el equipo de desarrollo de software, debe tener una estrecha
comunicacin con los usuarios, ya que la interfaz se construye con una
excelente relacin de stos con los diseadores y programadores. A esta
interaccin se le conoce como Diseo Centrado en el Usuario, donde ste pasa
a ser el foco de atencin y la implementacin se lleva a cabo dependiendo de
las caractersticas de los mismos, sin excluir los rasgos diferenciales entre
ellos, pensando incluso en aquellos que tienen problemas de accesibilidad.
Los principios bsicos por los cuales se rige el diseo orientado al usuario,
establecidos por el Proyecto Europeo para la Usabilidad en la Red,
(UsabilityNet European Union Project, 2001-2003) son los siguientes:

Diseo para los usuarios y sus tareas.

22

 Consistencia.
Dilogo simple y natural.
Reduccin del esfuerzo mental del usuario.
Proporcionar realimentacin adecuada.
Proporcionar mecanismos de navegacin adecuados.
Dejar que el usuario dirija la navegacin.
Presentar informacin clara.
El sistema debe ser amigable.
Reducir el nmero de errores.
La ISO, a travs del estndar 13407, contribuye con los principios bsicos para
la elaboracin de sistemas interactivos, que incorporan el Diseo Centrado en
el Usuario, durante todo el desarrollo. (ISO, 2001). El estndar internacional,
describe cuatro actividades claves: Entender y especificar los contextos de uso,
especificar los requisitos de los usuarios, producir las soluciones de diseo, y
finalmente, evaluar los diseos confrontndolos con los requisitos. En la figura,
se observa el ciclo de desarrollo, basado en las cuatro actividades bsicas.

Ilustracin 2: Actividades del Diseo Centrado en el Usuario (ISO-13407)

Por otro lado, el Diseo centrado en el Uso es un concepto completamente

diferente al de Diseo centrado en el Usuario, ya que el foco de atencin de

23

esta tcnica, est principalmente en las tareas que el usuario desea realizar.
Fue planteado por (Constantine & Loockwood, 1999), como una aproximacin
al modelo para el diseo visual e interactivo de las interfaces de usuario,
basadas en la web.
Principalmente, el Diseo Centrado en el Uso, busca la construccin de
modelos precisos, en vez de la iteracin sobre ensayo y error que se observa
en el Diseo Centrado en el Usuario. Para resumir las diferencias entre los dos
trminos, es necesario citar la tabla del trabajo de (Granollers, 2004).

Enfoque
Principal
Dirigido por
Implicacin
del Usuario

Descripcin
Diseado
por
Proceso
Proviene de

Diseo Centrado en el
Diseo Centrado en el Uso.
Usuario
Los usuarios. (Su experiencia y El uso (Mejora de las
satisfaccin de uso)
herramientas para el
cumplimento de las tareas)
La entrada o Input del usuario
Modelos
Alta (Estudio de los Usuarios,
Selectiva (Modelado
Diseo participativo, feedback
Exploratorio, Validacin de
del usuario, usuarios en las
Modelos, Evaluacin de la
pruebas).
Usabilidad con Mtodos de
Inspeccin estructurada)
Usuarios y sus caractersticas
Modelos de relaciones entre
los usuarios y los sistemas.
Prototipo iterativo.
Modelado
Variado, a menudo informal
(bajo nivel de especificacin)
Una evolucin mediante
mtodos de ensayo-error.

Sistemtico y completamente
especificado.
Una derivacin de la
Ingeniera de Software.

Tabla 1: Diferencias entre el Diseo Centrado en el Usuario, y el Diseo Centrado en el Uso.

As, es necesario especificar y definir algunos conceptos que bsicamente

sustentan la construccin de software, a partir de una metodologa ordenada,
basada en la comunicacin entre el usuario y desarrollador, que permita la
construccin de aplicaciones diseadas y orientadas al usuario.

24

2.3 INGENIERA DE SOFTWARE

La ingeniera del software es el establecimiento y uso de principios robustos
de ingeniera con el fin de obtener econmicamente software que sea fiable y
que funcione eficientemente sobre mquinas reales. (Pressman R. , 2000), y
comprende los mtodos, procedimientos para llevar a cabo no solo el
desarrollo, sino tambin el mantenimiento, y la calidad del software.
El modelo propuesto para la elaboracin de software, conlleva cinco etapas en
las cuales hay constante retroalimentacin con las anteriores. Es de vital
importancia incluir este modelo en el trabajo, para entender posteriormente la
integracin propuesta por la Ingeniera de la Usabilidad, en el desarrollo de
aplicaciones usables y accesibles.

Ilustracin 3: Modelo en Cascada de la Ingeniera de Software

Principalmente las fases consisten en lo siguiente:

Anlisis: Se establecen los requerimientos que debe cumplir el

software, tanto en funcionamiento (interaccin con personas, hardware,
bases de datos, etc.). Tambin se debe comprender el dominio en el
cual funcionar el software, y la naturaleza de los programas a
construir. Por lo general, estos requerimientos se documentan y se
revisan constantemente con el cliente.

Diseo: Es un paso que se enfoca principalmente sobre tres atributos:

La estructura de los datos, la arquitectura del software y el detalle

25

procedimental. Igualmente que en el anlisis, el diseo se documenta

tericamente.

Codificacin o Implementacin: Consiste en la traduccin de los

atributos del diseo, al lenguaje de las mquinas. Como resultado, se
obtiene el cdigo fuente del programa.

Pruebas: Una vez se codifica, comienzan las pruebas del software. Se

enfoca principalmente en la lgica interna, para que los resultados que
se requieren, sean producidos correctamente por el software.

Mantenimiento: Los cambios que puede sufrir el software, se pueden

presentar debido a la existencia de errores, modificaciones del entorno,
aumentos funcionales o de rendimiento etc.

En la Universidad Nacional, Sede Medelln, existe una metodologa propia,

planteada por (Arango & Zapata, 2006), para el anlisis de requerimientos del
software,
2.9

la

cual

ser

profundizada

en

el

captulo

UTILIDAD como factor determinante que aumenta la utilidad e intencin

de uso de una aplicacin, al cumplir estrictamente con los requisitos del

usuario.

2.3.2 Diferencias entre la Ingeniera de Software y la Interaccin HumanoComputador.

Ante el inters generalizado durante los ltimos aos, al desarrollar sistemas
que interacten correctamente con los usuarios, se han dedicado esfuerzos a
cubrir la brecha entre la Ingeniera de Software y la Interaccin HumanoComputador. Esta brecha, se conoce como "HCI-SE Gap, y puede cerrarse
fcilmente, ya que ambas disciplinas comparten el mismo objetivo; desarrollar
sistemas interactivos que sern utilizados por personas. Por otro lado, una
disciplina necesita de la otra para poder conseguir ese objetivo comn, ya que
cada una por separado es incapaz de solucionar el problema, aunque la forma
de enfocar la consecucin de los objetivos, sea su separacin. La ingeniera de

26

software tiene un enfoque tecnolgico, influenciado principalmente por la

programacin, la Interaccin Humano-Computador se basa en los factores
humanos y la visin del usuario final, cuya prioridad queda relevada en
segundo plano en la Ingeniera de Software.
A manera resumida, y citando la tesis doctoral de (Granollers, 2004), las
principales diferencias entre la Ingeniera de Software y la Interaccin HumanoComputador, son las siguientes:
Atributo

Ingeniera de Software

Recursos

Predominan los
especialistas de la
computacin y el desarrollo
de software.

Humanos

Tareas

Enfocadas por el cdigo.

Dirigidas por la
funcionalidad.
Casos de Uso Se obtienen a partir del
Anlisis de Tareas.

Inter. Humano-Computador
Por lo general, se compone de
profesionales
interdisciplinarios provenientes
de campos del conocimiento
alejados de la ciencia de los
computadores.
Enfocadas por la evaluacin.
Dirigidas por el uso.

Se obtienen a partir del trabajo

contextual con los usuarios.
Se describen a partir del
Son descritos con
lenguaje natural y tcnicas
notaciones formales
alternativas de bajo nivel
(bsicamente UML).
tcnico.
Actores
Red, bases de datos...
Personas.
Diseo
Elaborado por tecnlogos, Realizado por profesionales
sin contar con el punto de de cada rea contando
vista de los usuarios.
siempre con la participacin
activa de usuarios.
Dirigido por atributos
Defienden la idea que "el
tcnicos y de proceso
diseo est dnde se produce
la accin".
Emprico:
Paradigma de Pragmtico:
Investigacin Prctica teora - prctica.
Teora - prctica - teora.
Unidades de
Anlisis

Aspectos sociales
relacionados con los factores

La tecnologa.

27

humanos.
Modelos de
proceso

Prototipos

Evaluaciones

Modelos de datos, objetos,

funciones y estados del
sistema.
Dirigidos por el proceso.
Software vertical (con
funcionalidades).
Funcionales, de sistema y
de integracin.

Modelos de Diseo Centrado

en el Usuario.
Dirigidos por la interfaz.
Evolutivos desde prototipos de
baja fidelidad a prototipos
software.
De usabilidad.

Tabla 2: Diferencias entre la Ingeniera de Software y la Interaccin Humano-Computador

Por esta razn, y desde la Ingeniera, se busca la unin de las dos disciplinas,
por medio de una metodologa que permita la evaluacin y medicin de los
aspectos que determinan el uso de las aplicaciones interactivas. De esto, se
profundizar en el captulo de Ingeniera de Usabilidad, y el anexo A.

2.4

CALIDAD DE SOFTWARE

El software se ha convertido en una herramienta fundamental en el mbito de

vida de las personas, y de su correcto funcionamiento, depende su
comunicacin, seguridad, etc. Por esta razn, es de gran importancia
desarrollar software de alto nivel cualitativo, que cumpla con las expectativas y
funcionalidades que requieren los usuarios.
En 1991, la ISO defini el estndar ISO 9126, que establece los factores que
debe cumplir el software, para cumplir con ciertos parmetros de calidad, y el
estndar ISO 14598 , donde se observa el proceso de evaluacin de stos. En
el mismo estndar, se define el concepto de calidad de software como El
conjunto total de caractersticas de una entidad (producto, proceso o servicio)

28

que le confieren la capacidad de satisfacer las necesidades establecidas y las

necesidades implcitas. (ISO, 1991).
Entre las caractersticas definidas en la norma ISO 9126, se observan los
requerimientos funcionales y no funcionales del software, determinadas como
atributos de la calidad interna y externa, desde el punto de vista del cliente y
del usuario. El concepto de calidad externa del software, se basa en su
correcto funcionamiento y hace lo que se supone que debe hacer, es eficiente,
e incluso, estticamente bonito, mientras que la calidad interna se define
como la capacidad que tiene el software de cambiar, adaptarse a requisitos
nuevos o desconocidos, y detectar errores en fases tempranas del desarrollo.
El estndar ISO 9126, establece la funcionalidad, fiabilidad, y la usabilidad,
como atributos de calidad externa, mientras que la eficiencia, mantenimiento y
portabilidad hacen parte de la calidad interna.

Ilustracin 4: Caractersticas de la calidad del software segn el estndar ISO 9126

Por otro lado, el estndar tambin establece ciertos estndares que influyen
en la calidad de uso, principalmente basadas en las caractersticas de
efectividad, productividad seguridad y satisfaccin.

29

Ilustracin 5: Caractersticas de la calidad de uso segn el estndar ISO 9126

Como se puede observar, los atributos que componen el estndar de calidad,

son subjetivos y difciles de medir. Ms adelante, en el captulo 2.6, se
introducir el concepto de usabilidad, y qu tan ligado est con la satisfaccin
del usuario, como dos componentes bsicos de la calidad del software,
especialmente en la web.

2.5 CMO REALMENTE USAMOS LA WEB?

Antes de profundizar en los conceptos, y conocer qu factores influyen en la
satisfaccin del usuario final cuando utiliza una pgina o aplicacin alojada en
internet, es necesario indagar y observar los patrones psicolgicos que se
observan mientras navegamos por la web. En el proceso de anlisis, diseo y
construccin

de

software,

es

de

vital

importancia

comprender

el

comportamiento del usuario, ya que en parte, de ste depender la satisfaccin

o frustracin de uso de la aplicacin. Generalmente, como desarrolladores
asumimos errneamente que todos los usuarios usan la web del mismo modo
que nosotros lo hacemos, e inclinndonos a pensar que nuestro propio
comportamiento en internet es mucho ms metdico, ordenado y sensato.
As, como la web, reinvent la manera de buscar informacin, el usuario
promedio sigue un patrn de bsqueda rpida, que segn Krug, generalmente,
consiste en echar un vistazo a cada nueva pgina, leer rpidamente parte del
30

texto y hacer clic en el primer vnculo que resulte interesante o se parezca,

vagamente a lo que se est buscando, por lo que normalmente hay partes
extensas de la pgina que ni siquiera se miran. (Krug, 2006).
Por esta razn, Krug propone tres factores a tener en cuenta sobre cmo
realmente se utiliza la web:
No se leen las pginas; se hojean: El usuario promedio de internet, lee por
encima el contenido, en busca de palabras o frases que capten la atencin a la
vista. (Krug, 2006).

No se toman decisiones ptimas, simplemente es suficiente: Por lo

general, el usuario hojea una pgina, considera las opciones disponibles y elige
la mejor. Para Krug, la mayor parte de las veces, no se selecciona la mejor
opcin, ya que la primera ms razonable cumple con las expectativas del
usuario. Esta tcnica se conoce como satisficing1. Normalmente, en la web, el
usuario tiene prisa, por lo que optimizar es difcil y toma bastante tiempo. La
estrategia de satisficing, es mucho ms efectiva y las consecuencias por
cometer algn error, no son realmente importantes, ya que se solucionan con
solo presionar el botn atrs del navegador (Krug, 2006).

No se averigua acerca del comportamiento de las cosas: Cuando se

realizan pruebas de usabilidad con los usuarios, stos desconocen
completamente el funcionamiento de los productos. Realmente, son muy pocos
que dedican un tiempo a leer las instrucciones, por lo que comnmente se
observan usuarios que utilizan el software de forma eficiente, pero muy alejada
de las intenciones verdaderas de los desarrolladores y diseadores. Por lo
general, esto sucede porque al usuario promedio, no le importa entender el

Herbert Simon utiliz el trmino, a partir de un cruce entre satisfactorio y suficiente.

31

funcionamiento de las cosas (como un programador o diseador) en tanto

cumplan con su objetivo. Esto se debe ms que todo, por la escasez de
cuidado y atencin. Adems, si el usuario encuentra una forma de que el
software funcione (sin importar que sea la forma correcta o no), contina
utilizndola frecuentemente. Muy raramente busca otra manera de realizar la
tarea, por lo que si encuentra otra, ser por casualidad. . (Krug, 2006).

Siendo

as,

surge

la

necesidad

de

comprender

estos

patrones

de

comportamiento, para desarrollar sitios y aplicaciones en la web que sean

fciles de usar, que cumplan con las expectativas del usuario final, y por ende
generen una alta satisfaccin de uso. Por esta razn, el siguiente captulo
consta de las definiciones conceptuales, las cuales de descomponen en
factores que, segn los comportamientos de los usuarios en la web, pueden
suponer el xito o el fracaso de la aplicacin.

2.5.1 Diferencias entre los Sitios y las Aplicaciones Web

Al comienzo, la web posea un carcter puramente informativo, que permita
crear documentos que enlazaran a otros documentos, y publicarlos con un
alcance global. Por esta razn, se convirti en uno de los principales medios de
publicacin, a tal punto de evolucionar tecnolgicamente, y convertirse en una
plataforma de distribucin, interaccin y manipulacin de informacin, muy
similar a las aplicaciones de escritorio, pero con la gran ventaja de acceso
desde cualquier lugar del planeta.
A pesar de que comparten la misma plataforma, son muchas las diferencias
que se pueden identificar entre una aplicacin y un sitio web. Por lo general, los
sitios web se destacan por su carcter informativo, mientras que las
aplicaciones se centran por la consecucin de objetivos. La siguiente tabla, que
se deduce a partir de los elementos planteados por Garrett, que influyen en la

32

experiencia de usuario (Garrett, 2011), ilustra detalladamente los aspectos ms

relevantes que diferencian las aplicaciones de los sitios web:

Sitio Web

Aplicacin Web

Encontrar Informacin

Completar una tarea

Casual

Lineal

Contenidos y mens

Formularios

Espacios de Informacin

Flujo y manejo de Informacin

Arquitectura de Informacin

Diseo de Interaccin

Objetivo
Navegacin
Interfaces
Preocupacin
Tcnicas

Tabla 3: Tabla comparativa entre Sitio Web y Aplicacin Web.

A partir de diferencias, el ciclo de desarrollo de sitios y aplicaciones web, vara

radicalmente, como puede observarse claramente en el captulo Experiencia
de Usuario, (Ver captulo 2.7.1 Elementos de la Experiencia de Usuario) en el
cual se profundizar en este concepto, que influye directamente en la
satisfaccin de uso.
Adems, cabe aclarar que en el mbito investigativo de este trabajo de grado,
ser objeto de profundizacin nicamente la fase de desarrollo de aplicaciones,
la cual hace parte del anlisis y desarrollo de software.

2.6 DEFINICIN: USABILIDAD2.

La satisfaccin del uso es un concepto complejo y difcil de delimitar, pero entre
las variables que la condicionan, se destaca el diseo, que finalmente

Vale la pena aclarar que el trmino Usabilidad, no se encuentra en el diccionario de la Real

Academia Espaola, ya que se traduce directamente dela palabra inglesa Usability, que se
define como la capacidad que tiene un objeto, para ser utilizado por humanos de una manera
fcil y efectiva.

33

posibilita o impide la consecucin de sus objetivos (Hassan Y. , 2006), y por

esta razn, se plantea una relacin ntima entre los conceptos de usabilidad y
satisfaccin de uso. (Folmer & Bosch, 2004). Por lo tanto, es supremamente
importante definir el concepto de usabilidad, para luego deducir su
importancia en el diseo web, y el aporte que genera a la satisfaccin del
usuario final.
El primero en utilizar el concepto de usabilidad, fue (Bennett, 1979), quien la
defini como un factor determinante en el desempeo humano. Luego,
(Shackel, 1991) defina el trmino de Usabilidad como la capacidad que tiene
un objeto, para ser utilizado por humanos de una manera fcil y efectiva,
donde, en dnde el trmino fcil corresponde a un nivel especfico de
satisfaccin subjetiva, y efectivo a un nivel de desempeo humano.
Quizs una de las definiciones ms prcticas de usabilidad, proviene de Krug,
para quien Despus de todo, la Usabilidad realmente significa estar seguro
de que algo funciona bien: que una persona con habilidades promedio (e
incluso por debajo del promedio) pueda utilizar una cosa ya sea una
aplicacin web, un jet de combate, o una puerta rotatoria para su
intencionado

sin

terminar

enormemente

frustrado.

(Krug,

2006).

A travs de las definiciones anteriores, se puede inferir, que la palabra

usabilidad, proviene del trmino user friendly (fcil de usar), cuyo concepto
puede tener connotaciones vagas y subjetivas. (Bevan, Kirakowski, & Maissel,
1991), ya que las definiciones propuestas por diferentes autores, se centran en
clasificar sus atributos (que ms adelante sern expuestos), o los factores
cuantificables que la componen, por lo que finalmente cada autor la define
segn el contexto y el enfoque para medirla.
La usabilidad no es una simple propiedad unidimensional de las interfaces de
usuario, ya que tiene mltiples componentes y es tradicionalmente asociado a
cinco atributos, entre los que se encuentran la capacidad de aprendizaje, la

34

eficiencia, la capacidad de memorizar, el nmero de errores y la satisfaccin.

(Nielsen J. , Usability Engineering, 1993). La usabilidad encapsula en un
concepto, todos los atributos necesarios para que el usuario alcance
cmodamente su objetivo, a diferencia de la experiencia de usuario, que se
preocupa por la sensacin que el usuario experiment mientras cumpla su
objetivo. Por eso, a partir de estos atributos, se busca definir el concepto
abstracto de Usabilidad, en trminos de componentes precisos que puedan
ser medibles desde la perspectiva de la ingeniera. Por eso, (Folmer & Bosch,
2004), proponen una divisin orientada al comportamiento del usuario, cuyos
componentes pueden clasificarse dos clases principales que componen el
concepto de usabilidad: atributos objetivos, como facilidad de aprendizaje,
facilidad de memorizacin, eficacia o nmero de errores cometidos, eficiencia o
tiempo empleado para completar una tarea, operatividad, y facilidad de
comprensin; y atributos subjetivos como satisfaccin de uso o atractivo
esttico.
Por otro lado, es necesario citar el estndar internacional, que en la norma
9241, la ISO la define, como la eficacia, eficiencia y satisfaccin con la que
usuarios especficos pueden lograr objetivos especficos. (ISO, 1998) Como
puede observarse, en la definicin se identifican tres variables que componen
el concepto de usabilidad: eficacia, eficiencia y satisfaccin.
As, se puede apreciar una clara divisin objetiva y subjetiva del concepto de
usabilidad. La eficiencia y la eficacia, pueden ser medidas o evaluadas
objetivamente, a partir de la observacin del usuario mientras interacta con el
sistema, mientras que la satisfaccin es el resultado subjetivo de preguntarle al
usuario una vez terminadas las tareas, qu tan fcil le ha parecido la
aplicacin, y qu tan satisfecho se encuentra con la misma. (Fu & Salvendy,
2002).
Partiendo del hecho que las tres variables eficacia, eficiencia y satisfaccin
son completamente independientes, se observa una alta correlacin entre

35

ambas, ya que cada una de las variables aporta informacin no contenida en el

resto, (Sauro & Kindlund, 2005) por lo que se evidencia y complicando la
medicin de estos atributos, teniendo en cuenta que tambin se sugieren que
la usabilidad percibida, presenta una estrecha relacin con otros atributos del
diseo, ajenos a al usabilidad objetiva, como lo es la esttica o apariencia
visual. (Hassan Y. , 2006). Esto fue corroborado anteriormente por (Lingaard &
Dudek, 2003), afirmando que una web estticamente agradable, ser percibido
al mismo tiempo como ms fcil de usar.
La compleja interrelacin entre los aspectos subjetivos que componen el
concepto de usabilidad, sera explicada en gran parte por la hiptesis de
Bengts, el cual demuestra que la satisfaccin de uso no puede ser analizada
como un atributo de la usabilidad, sino que, por el contrario, la usabilidad debe
ser entendida como un factor ms en el camino para asegurar una experiencia
de usuario satisfactoria (Bengts, 2004).

2.7 DEFINICIN: EXPERIENCIA DE USUARIO (UX)3

La experiencia de usuario, puede definirse fcilmente, citando una analoga
presentada en el curso de Usabilidad de la Universidad de Catalua.
(Catalua, 2011) Cuando vamos a un restaurante elegante, no queremos
solamente comer bien. Deseamos saborear cada plato, su presentacin,
disfrutar de la compaa, de la atencin del servicio, de la msica, del ambiente
en general y mantener ese momento como algo especial, memorable.
En este caso, nuestro objetivo principal consiste en alimentarnos, pero los
factores adicionales que influyen en ste, provocan una sensacin satisfactoria
o frustrante. Por lo general, el restaurante ms usable o accesible ser
aquel ms cercano, pero no necesariamente ser el que asegure la mejor
experiencia al cenar.
3

Acrnimo de la expresin inglesa User eXperience.

36

Por esto, comnmente se confunden conceptualmente la usabilidad y la

experiencia de usuario, a tal punto de estar proporcionalmente ligadas, pero
como lo afirma (Norman D. , Emotional Design, 2004),

las buenas

experiencias no siempre cuentan con una buena usabilidad pero esta ltima se
convierte en una buena consejera para lograr experiencias positivas. A partir
de la analoga, podemos deducir la gran diferencia que se observa entre la
Usabilidad y la Experiencia del Usuario. Segn la ISO, y como se cit
anteriormente, la Usabilidad se mide segn la eficiencia, eficacia y satisfaccin,
mientras que la experiencia de usuario, segn la ISO 9241, son todos los
aspectos que el usuario siente, por medio de la interaccin con un producto o
servicio. (Standardisation, 2001) Por otro lado, los conceptos de usabilidad, y
experiencia de usuario, se pueden diferenciar segn los objetivos que cumple
cada una en la web. La primera, busca la comodidad del usuario en la
consecucin de sus objetivos, mientras que la segunda busca la felicidad del
usuario antes, durante y despus de utilizar la aplicacin. Adems, la primera
se cuestiona Pudo el usuario cumplir con su objetivo? Mientras que la
segunda se pregunta Tuvo el usuario la mejor experiencia posible?
De lo anterior, y Partiendo de la Interaccin Humano-Computador, es necesario
citar a (D'Hertefelt, 2000), quien afirma que la Experiencia de Usuario,
representa un cambio sustancial del propio concepto de usabilidad, donde el
objetivo no se limita a mejorar el rendimiento del usuario en la interaccin
eficacia, eficiencia y facilidad de aprendizaje, sino que se intenta resolver el
problema estratgico de la utilidad del producto (que el producto sea til y
usable), y el problema psicolgico del placer y diversin de su uso, (que el
producto sea aceptado por el usuario). Con la experiencia de usuario entran
en juego ms factores (como la aceptacin, la credibilidad, la confianza, la
emocin o el placer), pero todos ellos comienzan a mantener una relacin tan
estrecha que el fallo de uno de ellos afecta con determinacin al resto, lo que
eleva el concepto de usabilidad hacia la experiencia de usuario.

37

La UX, basa sus principios en la utilidad del producto, y en el cumplimiento y

satisfaccin de las necesidades del usuario. A partir de sta, la funcionalidad es
un factor clave, ya que el usuario debe ser capaz de usar el producto, y
adems sentirse satisfecho con su Look and Feel. Por ltimo, estos aspectos
contribuyen a la creacin de una imagen de marca, que asocia los sentimientos
del producto, a una determinada compaa. En el siguiente grfico, se pueden
observar perfectamente las subdivisiones de la Experiencia de Usuario
anteriormente citadas:

Ilustracin 6: Aspectos y subdivisiones de la Experiencia de Usuario

Como se puede apreciar, la experiencia resultante en el uso de un producto

pertenece exclusivamente al usuario, y el desarrollador est nicamente en
condiciones de ofrecer un producto cercano, en continuo cambio, utilizando las
tcnicas y conceptos de diseo centrado en el usuario, lo que permite una alta
adaptabilidad, y as acercarse a las necesidades reales y deseos del usuario,
con alta probabilidad de obtener resultados satisfactorios, ya que el xito o el
fracaso de la aplicacin dependen en gran parte de la satisfaccin de uso.
38

2.7.1 Elementos de la Experiencia de Usuario

As como se profundiz en el captulo correspondiente, la web fue
originalmente concebida como un espacio de informacin hipertextual; y ha
evolucionado a tal punto de convertirse en una interfaz remota de software.
(Ver captulo 2.5.1 Diferencias entre los Sitios y las Aplicaciones Web).
Por esta razn, (Garrett, 2011) en su libro, define los elementos y
consideraciones clave que forman el desarrollo de la experiencia de usuario en
la Web, dependiendo de su objetivo principal: La web como interfaz de software
o como sistema de hipertexto. Adems, clasifica estos elementos segn su
nivel de abstraccin, y deja abierta la discusin, al plantear el proceso de
desarrollo desde su concepcin a la culminacin. Los elementos que
conforman la experiencia del usuario, se muestran en la siguiente figura:
(Resumidamente en ANEXO A: ELEMENTOS DE LA EXPERIENCIA DE
USUARIO)

39

Ilustracin 7: Elementos de la Experiencia de Usuario segn Garrett.

Como un sistema de hipertexto, la web posee un alto flujo de contenidos,

donde se observa principalmente, la importancia de mostrar la informacin que
es estrictamente relevante, sin saturar la vista del usuario. Al profundizar en
cada uno de los aspectos anteriores, tenemos que las necesidades del usuario,
se identifican a partir de los objetivos del sitio, a travs de una investigacin
etnogrfica, tecnolgica y psicolgica, por lo que estos objetivos se basan
principalmente en satisfacer una demanda puramente informativa.
As, en la siguiente fase, es necesaria la filtracin y redaccin de los contenidos
que satisfacen las necesidades informativas de los usuarios, evitando la
informacin que puede llegar a ser irrelevante. Por lo general, el usuario de la
web lee poco, por lo que al redactar los contenidos, es clave ser conciso y
claro. Todos estos aspectos estn definidos en la fase de los requerimientos de
contenido. Por otro lado, para llegar fcilmente al contenido, es fundamental el
diseo estructural del espacio de informacin, para que el usuario acceda
intuitivamente a la informacin que busca. La fase encargada de esta tarea, se
le conoce como la Arquitectura de la Informacin.
Para facilitar el movimiento a travs de la estructura establecida, es necesario
el diseo intuitivo de la navegacin, principalmente en la interaccin con los
elementos de la interfaz, y teniendo en cuenta en el diseo de informacin, la
presentacin es la herramienta fundamental para facilitar el entendimiento.
(Tufte). Finalmente, la ltima fase de corresponde al diseo visual de los
componentes, grficos, elementos de texto y los componentes de navegacin,
teniendo en cuenta los aspectos esenciales estticos para una mejor
apreciacin del usuario.
En el mbito de este trabajo de grado, el desarrollo de aplicaciones orientada a
tareas y funciones, la experiencia de usuario comprende el diseo de objetivos

40

o requerimientos, la especificacin funcional, el diseo de interaccin, el diseo

de la interfaz y la informacin, y por ltimo el diseo visual. Para profundizar en
este campo, es necesario definir el concepto de satisfaccin, y as, definir los
aspectos que influyen en la percepcin positiva del usuario, para luego
relacionarlos con cada una de las etapas del desarrollo de software, y los
elementos que componen la experiencia del usuario.

2.8 DEFINICIN: SATISFACCIN DE USO.

Desde el desarrollo de software, y el concepto de usabilidad definido
anteriormente por la ISO, se observa claramente que basan sus definiciones en
el concepto de satisfaccin, el cual se convierte en el objetivo principal de los
diseadores de Experiencias de Usuario.
La satisfaccin es un concepto complejo. Principalmente se define como la
actitud afectiva (Bengts, 2004), aunque la ISO, la define en trminos de
confortabilidad y actitud positiva en el uso del sistema. (ISO, 1998).
Segn Norman, se pueden delimitar los factores que condicionan la
satisfaccin de uso, en un mbito cognitivo y otro afectivo. La experiencia de
uso, es influenciada tanto por el comportamiento racional o cognitivo del
usuario, como por su comportamiento emocional o afectivo que, aunque
interrelacionados, influirn de diferente modo en la satisfaccin del usuario.
(Norman D. , 2002), lo que divide los atributos que intervienen en el
comportamiento cognitivo del usuario como eficacia y eficiencia, de esta forma
podemos diferenciar entre atributos del diseo que intervienen principalmente
en el comportamiento cognitivo del usuario durante la interaccin, como
eficacia y eficiencia, y los atributos que intervienen en su comportamiento
afectivo o emocional, como la esttica.

41

As, para diferenciar cules atributos y comportamientos influyen en la

satisfaccin del usuario, el estudio de (Zhang & Dran, 2000) y citado por
(Hassan Y. , 2006),

se diferencian estos factores entre insatisfaccin

(frustracin) y satisfaccin como dos dimensiones independientes una de la

otra, y no como dos valores de una misma dimensin, es decir, que una
aplicacin web al no ser frustrante, no implica necesariamente que al usarla, le
produzca satisfaccin al usuario. Adems, se clasifican aquellos factores que
impiden la insatisfaccin de uso y cules producen satisfaccin de uso,
denominndolos factores higinicos y motivadores respectivamente. Los
factores higinicos hacen que la aplicacin sea funcional y servicial, mientras
que los motivadores animan a usarla y provocan intencin de uso. (Hassan Y.
, 2006)
As, se puede observar que los factores higinicos, al evitar la frustracin, son
imperceptibles al usuario final, y solo sern visibles cuando una aplicacin no
cumpla con alguno de ellos. Por el contrario, los factores motivadores, sern
directamente percibidos por el usuario ya que influyen directamente en el
aumento o la disminucin de la satisfaccin de uso.

2.8.1 Factores del diseo que Influyen en la Satisfaccin de Uso.

A partir del trabajo de Hassan, se identifican siete principales factores que
influyen en la satisfaccin y no frustracin de uso, cuyos criterios de
clasificacin (en higinicos y motivadores) se resumen en la siguiente tabla:
Criterio / Tipo de Factor
Carcter Perceptible
Impacto en la intencin de uso.
Impacto en la satisfaccin

Higinico

Motivador

Carcter desapercibido

Carcter apercibido

Impiden la desmotivacin

Provocan intencin de uso

Impiden la frustracin

Provocan satisfaccin

Tabla 4: Criterios para la clasificacin de los factores de diseo

Partiendo de estos criterios, y del trabajo previo de (Zhang & Dran, 2000),
42

Hassan define como factores higinicos, la accesibilidad, funcionalidad y

findability4, mientras que por el otro lado, los motivadores son la utilidad, la
esttica y la credibilidad. Adems, como sptimo factor, Hassan clasifica la
usabilidad, cuya dimensin objetiva y subjetiva, la caracteriza como factor
higinico y motivador al mismo tiempo.

Ilustracin 8: Factores de diseo orientados a la satisfaccin de uso

A partir de la clasificacin anterior, y de los elementos que componen la

experiencia de usuario, se definen cada uno de los factores que influyen en la
satisfaccin de uso, su relacin con el concepto de usabilidad, las tcnicas de
desarrollo de software que lo determinan, y se estudiarn las tcnicas para su
cuantificacin y medicin, para finalmente aplicarlas a un prototipo desarrollado
con la metodologa de anlisis y desarrollo de software UN-Mtodo.

2.9

UTILIDAD

Traducindolo psimamente en encontrabilidad o buscabilidad, y definindolo como la

capacidad que tiene un objeto para ser encontrado.

43

Partiendo del esquema de la Experiencia de Usuario, la utilidad es la

propiedad que debe poseer el software para cumplir estrictamente con las
necesidades del usuario. Por lo general, las aplicaciones son producto del
anlisis, diseo y construccin de software, basado principalmente en el
cumplimiento de una necesidad y/u objetivo.
Para (Hassan Y. , 2006), la utilidad de una aplicacin, hace parte de la actitud
o relacin afectiva que el usuario posee hacia ella, la cual es completamente
subjetiva, y est estrictamente ligada al concepto de usabilidad, ya que si la
aplicacin no es til para el usuario y no cumple con los requerimientos para
los que fue construida, su intencin de uso es baja, y si no es fcil de usar no
se aprovechar su utilidad, (Dillon & Morris, 1999) midiendo la usabilidad
como el grado en que el usuario puede explotar la utilidad de la web, por lo
que es clasificado como un factor puramente motivador desde la experiencia de
usuario, ya que por lo general, es de los aspectos que provocan una mayor
intencin de uso. (Hassan Y. , 2006).

2.9.1 Relacin entre Utilidad e Ingeniera de Requisitos.

Por esta estrecha relacin entre utilidad y usabilidad, desde la Ingeniera de
Software se establece una metodologa conocida como Ingeniera de
Requisitos, que permite relacionar los requerimientos de los usuarios de las
aplicaciones,

con

aquellos

desarrolladores,

diseadores

ingenieros

encargados de construirlas, lo que se transforma en un problema de

comunicacin, que principalmente se orienta a ser un diseo orientado al uso.
(Ver captulo 2.2

DISEO CENTRADO EN EL USUARIO -

DISEO

CENTRADO EN EL USO.).
Formalmente, los requisitos de una aplicacin, se definen como las
descripciones de cmo el sistema debe comportarse, la informacin acerca del
dominio de aplicacin, las restricciones operativas del sistema y las

44

especificaciones de las propiedades o atributos del sistema. (Kotonya &

Sommerville, 1997), haciendo sta, una de las fases ms importantes, ya que
como afirman (Bailey, Molich, Dumas, & Spool, 2002) si se hace un buen
trabajo, repercutir directamente a disminuir el nmero de iteraciones
necesarias para conseguir el proceso global, lo que permite ahorrar recursos
en el desarrollo de software.
Por esta razn, y segn (Gomaa, 2011), para una buena elaboracin de los
requisitos de software se deben tener en cuenta los siguientes aspectos:

Correcta: Cada requerimiento debe interpretar correctamente las

necesidades del usuario, por lo que ste debe hacer parte del desarrollo
en todo momento.

Completa: La elaboracin debe especificar cada requerimiento, por

insignificante que sea, a tal punto de definir si son correctas o no las
entradas y salidas de informacin del sistema.

Sin ambigedades: Cada requerimiento debe tener una nica

especificacin, por lo que los conceptos ambiguos deben ser
remplazados.

Consistente: Se deben evitar los conflictos tanto en la terminologa

utilizada y como entre requerimientos.

Verificable: Para Gomma, la especificacin de requisitos es un contrato

entre el desarrollador y la organizacin, por lo que si es necesario, cada
requerimiento debe ser evaluado las veces que sea necesario, para
determinar si el sistema cumple con los objetivos planteados.

Entendible: La elaboracin de requisitos debe ser fcil y entendible por

los usuarios, que no necesariamente son expertos en el rea de
computacin.

Modificable: El proceso de anlisis es iterativo, por lo que si es

necesario replantear y corregir los requisitos, la estructura del
documento debe ser completamente modificable.

45

Detectable: La especificacin de requisitos, debe permitir detectar

posibles errores, y dado el caso de presentar incoherencias, stas
deben ser fciles de encontrar y modificar.

Por lo general, el cumplimiento de estos aspectos, provee al desarrollador, las

herramientas necesarias para plasmar las necesidades del cliente, y plantear
las soluciones adecuadas para cada tipo de problema. Una mala estrategia en
esta fase, puede conducir a crear falsas expectativas en el cliente, acerca del
producto final, lo que conduce a la insatisfaccin y frustracin hacia la solucin
desarrollada por el equipo de software.
Los problemas ms comunes entre clientes y desarrolladores en el proceso de
anlisis de requisitos, los expone (Pressman R. S., 1998). Por lo general, los
clientes consideran que una declaracin general de los objetivos, es suficiente
para comenzar a escribir el programa y que ms adelante puedo dar ms
detalles, lo que conduce a una mala definicin inicial, y a la definicin de
requerimientos incompletos.

Adems, desde la perspectiva del cliente, se

puede llegar a pensar que los requisitos del proyecto cambian continuamente,
y que estos cambios pueden acomodarse fcilmente, ya que el software es
muy flexible, sin saber el impacto de estos cambios a medida que el ciclo de
desarrollo del producto avanza. La siguiente figura, tomada de la tesis doctoral
de (Granollers, 2004), ilustra ese impacto:

46

Ilustracin 9: Impacto de las modificaciones del producto, dependiendo de la etapa de desarrollo.

Entre estos, y otros problemas en el anlisis de requisitos, es absolutamente

necesario el uso de una metodologa que facilite esta tarea, ya que la utilidad
de la aplicacin es uno de los factores que ms influyen y provocan el uso de
las aplicaciones, por lo que un buen anlisis de requisitos permite cumplir con
los requerimientos del usuario, lo que finalmente le provoca una mayor
satisfaccin. As, el modelo planteado por docentes de la Universidad Nacional
de Colombia, es el marco conceptual utilizado en este trabajo de grado para el
anlisis de requisitos del prototipo final.

2.9.1 UN-Mtodo: Metodologa de la Universidad Nacional de Colombia,

Sede Medelln, para la Elicitacin5 de Requisitos de Software.
Esta metodologa, surge a partir del Grupo de Investigacin UN-INFO, que de
la Escuela de Sistemas, que pertenece a la Facultad de Minas de la
Universidad Nacional de Colombia, como una solucin que incluye los aspectos
positivos de las metodologas existentes, para una correcta elaboracin de los
5

La palabra Elicitacin no existe en el diccionario de la Real Academia de la Lengua, por lo que

se deduce a partir de la traduccin de la expresin Elicitation.

47

requisitos de software. Esta metodologa se ha impartido en las asignaturas

que pertenecen a la lnea de profundizacin de Ingeniera de Software, y se ha
caracterizado por ser el estndar en el anlisis de requisitos de la Escuela de
Sistemas. Segn, sus creadores, (Arango & Zapata, 2006), las caractersticas
ms destacables de UN-MTODO son las siguientes: (Para profundizar, ver
ANEXO B - ESQUEMA GENERAL DE LA METODOLOGA UN-MTODO).

Documenta de forma amplia la informacin del contexto en el que

trabajar del software, para modelarlo desde la concepcin hasta la
solucin. Esta documentacin no es tan extensa como en otros mtodos
como CDM6 o RUP7.

Es una metodologa reiterativa, ya que los diagramas que se desarrollan

en las fases iniciales se modifican recurrentemente a medida que se va
adquiriendo un conocimiento mayor de la organizacin, el problema y su
solucin.

No se aparta del estndar de modelamiento sugerido en la actualidad, e

incluye un conjunto de diagramas pertenecientes a UML, y otros
diagramas pertenecientes a otros mtodos (Diagrama de procesos de
CDM modificado, diagrama de objetivos y el diagrama causa-efecto) y
uno particular desarrollado por el grupo (el esquema preconceptual).

UN-Mtodo se enfoca en primero conocer la organizacin, sus

problemas y objetivos. Luego, procede a definir un conjunto de
soluciones posibles, y selecciona la mejor dependiendo del costo.

Conserva la figura de entregables, que corresponden a cuatro fases

del proceso: El problema, la solucin y el esquema conceptual de la

CDM son las siglas de Common Diagnostic Model, que en espaol "Modelo de Diagnstico

Comn".
7

Siglas de Rational Unified Process, la metodologa estndar para el anlisis de Software

48

solucin.

Comparando

con

la

metodologa

CDM,

UN-Mtodo

corresponde a las fases de Definicin, Anlisis y el inicio de Diseo.

A partir del trabajo realizado en las asignaturas que pertenecen a la lnea de

profundizacin de Ingeniera de Software, se realiza un estudio completo de la
organizacin en la cual se implementar el prototipo planteado en este trabajo
de grado, como la mejor una propuesta de solucin informtica que cumple
cabalmente, el 77% de los objetivos de la organizacin, (Ver ANEXO C:
PROPUESTA DE SOLUCIN CREATIVA CON UN-MTODO .
Por esta razn, vale la pena considerar que es alta la utilidad de la aplicacin
desarrollada, ya que cumple con los requisitos establecidos por la organizacin,
y soluciona los problemas que fueron planteados en el modelo.
2.10 FUNCIONALIDAD
La funcionalidad, puede definirse como el correcto funcionamiento tcnico de la
aplicacin, y la capacidad de la sta para soportar las tareas que el usuario
desea realizar (Dillon & Morris, 1999) ya que por parte del usuario, De qu
servira una aplicacin accesible y usable, si realmente no cumple con su
objetivo principal? Podemos clasificar la funcionalidad como un factor higinico
y determinante en la experiencia del usuario, ya que corresponde exactamente
a las especificaciones funcionales, que debe incluir la aplicacin para satisfacer
las necesidades del usuario.
A partir de la norma ISO 9126, que define el modelo de evaluacin de la
calidad del software, (Ver Cap.
2.4

CALIDAD DE SOFTWARE) asocia el concepto de funcionalidad a los

siguientes trminos, cuyos atributos posibilitan el correcto funcionamiento del

software:

49

Es ajustable: Son aquellos atributos del software que soportan la

presencia y propiedad de un conjunto de funciones para tareas
especficas.

Precisin: Son aquellos atributos del software que soportan la provisin

de resultados o efectos correctos o acordados.

Interoperabilidad: Son los atributos del software que soportan su

habilidad para interactuar con otros sistemas especficos.

Conformidad: Son los atributos del software que hacen que el mismo
se adhiera a los estndares o convenciones relativas a la aplicacin o a
regulaciones de tipo legal y prescripciones similares.

Seguridad: Son los atributos del software que soportan su habilidad

para prevenir acceso no autorizado, ya sea accidental o deliberado, a los
programas o datos. (ISO, 1991)

2.10.1 Funcionalidad y Usabilidad

La interrelacin entre la funcionalidad de una aplicacin y su usabilidad, es
compleja. Generalmente, muchos errores o fallos de funcionalidad, son
considerados al tiempo errores de usabilidad, debido a los fallos que provocan
en el usuario durante la interaccin, y a su vez, muchos errores de usabilidad
pueden ser percibidos como fallos de funcionalidad, cuando realmente no lo
son. En el caso de la web, se aprecian mltiples errores funcionales que
afectan la usabilidad, como los enlaces rotos (Nielsen J. , 2001), mientras
que por el otro lado, existen problemas de usabilidad que parecen errores
funcionales, como la visibilidad del estado del sistema (Nielsen J. , Enhancing
the explanatory power of usability heuristics, 1994) ya que el sistema no
informa al usuario de lo que est ocurriendo, y supondr que sta ha dejado de
funcionar.

50

Para ampliar un poco, acerca de la estrecha relacin entre la usabilidad y

funcionalidad, es necesario citar la analoga del iceberg de la usabilidad. Segn
Berry, anteriormente, se propona separar la interfaz del resto de la aplicacin,
para mejorar las condiciones de usabilidad, y as, modificar la capa de
presentacin, hasta que de forma iterativa se superen todos los test de
usabilidad, por lo que la funcionalidad no quedara afectada. (Ver captulo
2.15.1 Tcnicas de Evaluacin de la Usabilidad.). Pero los constantes fallos en
este modelo, implicaban cambios constantes a la funcionalidad de la aplicacin
despus de detectar fallos en la usabilidad del producto. Por esta razn, la
analoga propuesta por (Berry, 2000 ), explica que los aspectos relacionados
con la presentacin, o Look and Feel de una aplicacin, solo afectan en un
40% la medicin de la usabilidad, mientras que el 60% restante est
influenciado por el modelo de usuario, constituido principalmente por los
objetivos que el usuario quiere alcanzar con sus tareas, lo que determina que la
funcionalidad de la aplicacin es un factor de influencia determinante, ya que
segn Ceaparu, los errores son la mayor causa de frustracin del usuario
(Ceaparu, 2004).

2.10.2 Errores del Software y Mantenimiento.

Para cumplir los requerimientos mnimos de funcionalidad de una aplicacin,
esta debe presentar una muy baja tasa de errores. Por lo general, un fallo
ocurre cuando el comportamiento de un sistema es diferente del establecido en
la especificacin. Un error o defecto en el software, puede definirse como
resultado de un fallo o deficiencia durante el proceso de creacin de
programas de ordenador o computador. (Zapata, 2011) Desde otra
perspectiva, estos defectos se pueden definir, como una accin llevada a cabo
por el sistema, que no cumple el objetivo propuesto por el usuario. (Nielsen J. ,
Usability Engineering, 1993).

51

Por esta razn, los errores deben ser invisibles a los usuarios, mientras hacen
uso la aplicacin, y en caso de que ocurran, la sta debe recuperarse
fcilmente. Generalmente, en una aplicacin bien desarrollada, aquellos
errores catastrficos no ocurren. (Nielsen J. , Usability Engineering, 1993).
Generalmente, los fallos ms comunes se presentan en alguna de los
siguientes aspectos:

Procesamiento, por ejemplo, salidas incorrectas de un programa.

Rendimiento, por ejemplo, tiempo de respuesta demasiado alto en una

bsqueda de informacin (Errores de eficiencia).

Programacin, por ejemplo, inconsistencias en el diseo de un

programa.

Documentacin, por ejemplo, inconsistencias entre la funcionalidad de

un programa y el manual de usuario.

Por esta razn, la ISO, afirma en el estndar de Calidad de Software, que la

capacidad de localizar y corregir las fallas por medio del mantenimiento como
una caracterstica vital para asegurar su funcionamiento, y depender de la
facilidad de comprender, corregir, adaptar y mejorar el software.
Para (Ghezzi, 1991), existen tres tipos de mantenimiento: El correctivo, busca
principalmente corregir los errores, el adaptivo, modificar el software
dependiendo el entorno, y el perfectivo, que consiste en cambiar el producto
pensando en mejoras futuras.
Para realizar una

evaluacin efectiva de la funcionalidad de la aplicacin,

principalmente se realizan pruebas de usuario, en las cuales se interacta con

la aplicacin en desarrollo, en busca de posibles errores de funcionamiento
(Por medio del Paseo Cognitivo Ver captulo 2.15.1.2

Paseo Cognitivo

(Cognitive Walkthrough)). A partir de estos errores, el equipo de desarrollo

52

determina la gravedad del fallo, y procede a solucionarlo. En la figura, se

observan las principales causas de los defectos del software, los cuales, segn
(Grady, 1994), el 37,4% de los defectos se origina en la fase de especificacin
de requisitos, el 25,5% en la fase de diseo y el 36,3% en la fase de
codificacin.

11,0%

Interfaz/Hardware

7,8%
6,0%

Interfaz/Software

11,7%
20,2%

Lgica
Manejo de datos

25,7%
10,6%
7,0%

Estndares

Ilustracin 10: Principales Causas de los defectos del Software

A partir de los resultados, el equipo de desarrollo recurrir a tres herramientas

que facilitan la correccin de los fallos. En el caso de que el error se encuentre
en las especificaciones de requisitos, los casos de uso permiten la
identificacin de las interacciones, y plantea las herramientas necesarias para
corregirlos. Si el fallo se encuentra en la fase de diseo, los diagramas de
Jacobson y los contratos permiten observar la funcionalidad del software a
partir de las operaciones que lo componen, y si el error finalmente se encuentra
en la codificacin, la inspeccin de cdigo es la mejor manera de corregirlo.
Cabe aclarar, que la inspeccin del software en todas las fases del desarrollo
es vital en el mantenimiento, ya que a medida que se avanza en el proceso, es
mucho ms compleja y costosa la correccin de errores. (Ver Captulo. 2.9.1
Relacin entre Utilidad e Ingeniera de Requisitos.)

53

En el desarrollo del prototipo, la principal estrategia utilizada para la ubicacin y

correccin de errores, consiste en la revisin detallada de los contratos
construidos en diseo de software, los cuales proveen informacin detallada
acerca de las funciones e interacciones entre las clases, que componen la
estrategia de Modelo-Vista-Controlador. Dado el caso, si se producen errores
inesperados, se procede a la inspeccin de cdigo.

2.12 DISEO DE INTERACCIN: CMO ENCONTRAR Y MANIPULAR LA

INFORMACIN?
2.12.1 Arquitectura de Informacin vs. Diseo de Interaccin.
Luego de analizar detalladamente los atributos anteriores y su relacin con el
diseo de software, partiendo de los factores que influyen en la satisfaccin y
no frustracin de uso, (Ver captulo 2.8.1 Factores del diseo que Influyen en
la Satisfaccin de Uso., en su trabajo, Hassan define la Findability como un
factor higinico, cuya misin consiste en facilitar la bsqueda y recuperacin de
datos, y su principal herramienta se conoce como Arquitectura de la
Informacin.
La arquitectura de Informacin, es principalmente utilizada en los sitios web, y
est ligada al diseo de contenido de una organizacin, utilizando la web como
un sistema de hipertexto con un carcter puramente informativo. Desde el
enfoque investigativo de este trabajo de grado, orientado principalmente al
diseo de aplicaciones web, se considera omitir y profundizar acerca de la
arquitectura de informacin, ya que corresponde ms a la terminologa del
diseo de sitios web, que al desarrollo de aplicaciones web. (Ver captulo 2.5.1
Diferencias entre los Sitios y las Aplicaciones Web).
Por otro lado, y a partir del grfico, que resume los elementos de la experiencia
de usuario propuesto por Garrett, el diseo de interaccin, est orientado
principalmente al diseo de la informacin de las aplicaciones web, y consiste

54

en unir la funcionalidad con las interacciones del usuario. Segn Reimann, el

diseo de interaccin combina el diseo del tiempo, ms el diseo de espacio,
ms el diseo de las opciones a elegir por el usuario, y las respuestas de la
aplicacin (Reimann).
Desde el anlisis de requisitos, existe una herramienta que permite el estudio
de la interaccin entre el usuario y la aplicacin, desde las fases tempranas del
diseo, conocidos como Casos de Uso.

2.12.2 Casos de Uso.

Desde la Ingeniera de Software, se plantea principalmente, una herramienta
conocida como casos de uso, que definen las secuencias de interacciones
entre uno, o ms usuarios (tambin llamados actores) del sistema, desde la
fase de anlisis, lo que permite la visualizacin completa del funcionamiento del
sistema, desde el diseo de interfaces como respuestas del sistema.
Para determinar los casos de uso del sistema, es til comenzar por considerar
los actores, y las interacciones que realizan con el sistema. Cada caso de uso,
describe una secuencia de interacciones entre ambos. Por esta razn, los
requisitos funcionales del sistema, son descritos en trminos de los casos de
uso, lo que constituye no solo la especificacin funcional del sistema, sino
tambin las bases del diseo de interaccin. (Ver ANEXO I: CASOS DE USO
ASOCIADOS AL PROTOTIPO.
Esta fase es determinante en el desarrollo de software, ya que establece la
conexin entre los requisitos y la implementacin, por lo que el resultado se
deriva la interfaz con la que el usuario interactuar; y es compleja, ya que solo
puede llegar a ser exitosa, si el equipo de desarrollo utiliza los mecanismos y
metodologas de Diseo Centrado en el Usuario (DCU) con los de la Ingeniera
de Software.

55

Por lo general, existen dos maneras de disear la interaccin de un usuario con

el sistema. Por un lado, se puede realizar mediante una aproximacin emprica,
donde el diseo se basa en la propia experiencia del desarrollador, utilizando
recomendaciones ms o menos relevantes para la construccin de la interfaz,
evaluada por el usuario, mediante algn test de Usabilidad. (Ver captulo
2.15.1
consiste

Tcnicas de Evaluacin de la Usabilidad.). La otra metodologa,

en

una

aproximacin

terica,

basada

en

los

fundamentos

metodolgicos, y en la aplicacin de una serie de pasos para la realizacin del

diseo de la interfaz.

2.12.3 Fundamentos del Diseo de Interaccin.

Los principios sobre los que se basa el diseo de interaccin, estn
relacionados profundamente con el concepto de usabilidad, y buscan
principalmente aumentar la facilidad en el uso de las aplicaciones, aplicando
modelos y leyes fundamentales del movimiento. (Tognazzini, 1998), fundador
del Human Interface Group, plante una lista de ocho (8) principios para una
efectivo diseo de interaccin:
2.12.3.1 Eficiencia y Ley de Fitts.
En 1954, Paul Fitts desarroll un modelo matemtico para predecir el tiempo
requerido para mover el puntero hasta un espacio o rea demarcada, en este
caso, el tiempo que tarda el puntero del mouse en llegar a un elemento de la
interfaz web. Matemticamente, el modelo confirma que el tiempo que toma
para mover el cursor a cierta rea, es proporcional a su distancia desde la
posicin y el tamao del rea en sobre el eje de movimiento.
+
! = # + % log ) ( + 1)
,
Se tiene que:

56

T: Es el tiempo necesario para completar el movimiento.

a: Representa el tiempo de inicio / parada en segundos para un

dispositivo determinado.

b: Mide la velocidad inherente del dispositivo. Es una constante emprica

D: Distancia desde el punto inicial hasta el centro del objetivo.

S: Es la anchura del objetivo, medido sobre el eje de movimiento.

Ilustracin 11: Diagrama que ilustra el principio de la Ley de Fitts.

El diagrama anterior, muestra que el puntero se encuentra equidistante del

Botn A y el B, y segn la Ley de Fitts, es ms fcil llegar con el cursor al botn
A, ya que tiene una mayor superficie en el eje de movimiento. Por otro lado, el
botn B y C, poseen el mismo tamao, pero el botn B, es ms sencillo de
alcanzar con el cursor, ya que est mucho ms cerca que el botn C.
En la prctica, la Ley de Fitts plantea el diseo de botones grandes, para las
opciones ms comnmente utilizadas por el usuario, ya que en los botones
ms pequeos es ms difcil hacer clic. Adems, la ley presenta un caso
especial en las pantallas de computador, ya que si se mueve el cursor a una de
las esquinas, se detiene automticamente dentro del espacio del monitor as
siga moviendo el mouse. Estas esquinas son efectivas y fciles de llegar, ya

57

que el tamao de stas en el Ley de Fitts, es infinito. Por esta razn, las
esquinas son puntos fciles dnde llegar, por lo que comnmente en los
sistemas operativos se les asignan tareas comunes.
A pesar de ser excelentes reas, en el diseo de pginas web, slo sera
efectivo dado el caso que la navegacin se realice en modo pantalla
completa, ya que las aplicaciones web se ejecutan sobre los navegadores, que
poseen interfaz propia, pero es un factor clave del diseo de interaccin.

2.12.3.2 Productividad.
Para (Tognazzini, 1998), las personas son costosas y los computadores
baratos, por lo que es necesario darle prioridad a la productividad del usuario,
sobre la mquina. Por esta razn, propone cuatro tcnicas que ayudan a
mejorar la productividad del usuario, mientras utiliza una aplicacin web:

Utilizar etiquetas eficientes: En la interaccin, las etiquetas de men,

deben ser breves y claras, lo ms evidente posible. As, se promueve en
la aplicacin una de las principales reglas de la usabilidad de Krug,
evitar que el usuario piense demasiado en algo innecesario, y que por
lo general es gracias a la utilizacin de etiquetas con nombres bonitos,
ingeniosos o nombres tcnicos que no son familiares. (Krug, 2006).

Disminuir el tiempo de espera: La aplicacin debe permitir realizar

acciones en forma paralela, de tal modo que mientras una accin
termina, el usuario puede realizar otra, lo que evita tiempos prolongados
de espera. El ejemplo que propone (Tognazzini, 1998), consiste en que
mientras el servidor se encuentra subiendo una imagen del usuario, ste
est concentrado ingresando su descripcin.

No malgastar el tiempo del usuario: Dado el caso que una accin

tarde ms de un par de segundos, la aplicacin debe anunciarle al
usuario, y notificar su progreso. En el caso de acciones que impliquen

58

demasiado tiempo, (Tognazzini, 1998) propone que la tarea se lleve a

cabo en el servidor, y anunciarle al usuario cuando sta culmine, por
medio de un correo electrnico.

Utilizar controles eficientes: En el uso de formularios extensos, la

aplicacin debe facilitar el ingreso de los datos al usuario, ya que es
mucho ms sencillo utilizar un calendario, por ejemplo, que ingresar las
fechas manualmente. Para (Tognazzini, 1998), no solamente evita la
insercin de datos errneos, tambin permite facilitar la interaccin entre
el usuario y la aplicacin. Entre estas herramientas, se cuentan las
listas seleccionables, y los campos de formulario que permiten
autocompletarse.

2.12.3.3 Autonoma.
El usuario es el controla la interfaz, por lo que se le debe brindar la posibilidad
de trabajar confortable y confidencialmente (Tognazzini, 1998). En algunas
ocasiones, y por privacidad, algunos controles en las interfaces prohben el
acceso a ciertos usuarios, lo que impide explorar ciertas opciones, por lo que
se deben evitar aquellos enlaces que no estn permitidos dependiendo del rol
de usuario, y as evitar la frustracin del usuario ante la imposibilidad de
navegar por toda la aplicacin.

2.12.3.4 La aplicacin debe anticiparse al usuario.

(Tognazzini, 1998) define este principio, que principalmente consiste en evitar
que el usuario realice el trabajo que no es necesario, es decir, la aplicacin
debe iniciar las herramientas que el usuario necesita inmediatamente cuando
las necesita, evitando que el ste comience a buscarlas por toda la interfaz.

2.12.3.5 Consistencia.
Para (Tognazzini, 1998), la expectativa que tienen los usuarios acerca del
59

funcionamiento de la aplicacin, es proporcional a la apariencia de sta y a la

experiencia que le ofrece. Por esta razn, los conos, cursores, botones y otros
componentes del lenguaje visual, son convenciones que con el tiempo se van
estandarizando. Un ejemplo caracterstico de estas convenciones, planteado
por (Nielsen J. , 2001), es el tpico carrito de compras que se observa en los
sitios que venden mercanca por internet. Su uso ya es tan comn, que resulta
ser un estndar, por lo que modificarlos acarrea inconsistencias en la
interaccin, ya que el usuario se cuestiona acerca de su funcionalidad y
objetivo, o a tal punto de confundirlo con otras convenciones establecidas.

2.12.3.6 Seguridad.
En la lista planteada por (Tognazzini, 1998), este mbito resume cuatro
principios bsicos: La capacidad de exploracin de la interfaz, el seguimiento
del estado de la aplicacin, la proteccin del trabajo del usuario y la
navegacin. Principalmente, se busca que la interfaz sea un entorno para que
el usuario minimice la posibilidad de cometer errores por lo que todas las
acciones del usuario deben ser reversibles (por razones como stas, (Nielsen
J. , 2001) asegura que el botn atrs es el ms utilizado en los navegadores
web), y que el trabajo del usuario sea constantemente guardado, para evitar
prdidas de datos ante los fallos en la conexin, errores crticos en el
navegador, etc.
Este aspecto, quizs est ligado a la funcionalidad de la aplicacin, y debe ser
estrictamente implementada desde la interfaz, para evitar frustracin en el
usuario ante una eventual falla en el sistema.

2.12.3.7 Capacidad de Aprendizaje.

Por lo general, las aplicaciones web ms simples, son aquellas ms fciles de
aprender a usar. Esta capacidad es una de las metodologas propuestas por la

60

Ingeniera de la Usabilidad, para facilitar y simplificar el uso del software. La

idea, es que un nuevo usuario sin experiencia, pueda comprender y entender
cada una de las acciones de la aplicacin. Esto implica que la interfaz incluya
mtodos que permitan predecir el comportamiento del usuario, consistencia, y
familiaridad, an en la realizacin de tareas complejas.

2.12.3.8 Comprensin.
El usuario debe ser capaz de comprender completamente la interfaz de la
aplicacin. El texto debe tener un contraste alto con el fondo, y el tamao de
fuente debe ser claramente legible. Si la aplicacin ser utilizada por personas
con problemas de visin, se debe disear el texto adecuadamente, segn los
parmetros de accesibilidad de la W3C, que sern vistos en el captulo 2.11.1
Pautas de Evaluacin de la Accesibilidad en la Web. (W3C).

Estos principios aplicados en el diseo, aseguran una experiencia de usuario

satisfactoria, desde el punto interactivo, y estn incluidos e interrelacionados
con otros mbitos que influyen en la satisfaccin de uso, por lo que sern
expuestos ms adelante con mayor profundidad.
Adems, en el diseo de interaccin, la principal herramienta utilizada para
recibir y procesar la informacin por parte del usuario en la web, son los
formularios, por lo que se deben tener algunas consideraciones para su diseo,
no solo para evitar la introduccin de informacin errnea, si no para cumplir
con la ley fundamental de la usabilidad segn (Krug, 2006): Soy el usuario y
no me hagas pensar. Por lo tanto, en la metodologa de evaluacin propuesta
(Ver
MODELO EVALUATIVO PROPUESTOpropuesto) y siguiendo los principios
bsicos de interaccin se presentarn las reglas, que personalmente considero
de obligatorio cumplimiento, para el diseo de formularios de la aplicacin web,
61

partiendo de los prototipos establecidos en los casos de uso. Adems, se

implementar la estrategia A/B Test, que permite evaluar las posibles opciones
que tendr la interfaz, y por medio de un Paseo Cognitivo con los usuarios,
establecer cual cumple mejor con los objetivos de la aplicacin.

2.11 ACCESIBILIDAD
Uno de los factores que se encuentra ntimamente ligado al concepto de
usabilidad, es el de accesibilidad, ya que encierra en s, la posibilidad de
acceder a la informacin sin excluir a aquellos usuarios con limitaciones
individuales - discapacidades, dominio del idioma... - o limitaciones derivadas
del contexto de acceso - software y hardware empleado para acceder, ancho
de banda de la conexin empleada, etc. (Hassan & Martn, 2003)
Normalmente, en el desarrollo de aplicaciones, utilizando UN-Mtodo, se
disean las interfaces para el usuario final, cuyas necesidades especficas se
hacen presentes en el proceso de anlisis y desarrollo. Pero cuando se
desarrollan aplicaciones para una audiencia mayor (aplicaciones web), se
presentan necesidades de acceso muy diferentes, las cuales se deben tener en
cuenta. De hecho, es uno de los factores que claramente se puede clasificar
como higinico en el modelo de Hassan, ya que refiere a la posibilidad de
acceder a la aplicacin, y si un usuario no puede hacerlo, o no puede usarlo,
sentir frustracin. En cambio, si una aplicacin es accesible, y por lo tanto no
causa frustracin, este factor ser desapercibido por usuario, ya que solo ser
notado en la ausencia de ste.
Por lo general, la accesibilidad es concebida por todos los desarrolladores,
como realmente necesaria, pero muy pocas veces se lleva a la prctica,
nicamente cuando las empresas, observan en ellas una gran posibilidad de
llegar a ciertos clientes potenciales.

62

Desarrollar para la web, como la gran plataforma de convergencia tecnolgica,

debe suponer un alto cumplimiento de los estndares, para posibilitar el acceso
desde mltiples dispositivos, usuarios y regiones. Estas pautas han sido
desarrolladas por la W3C para permitir y asegurar la accesibilidad, por medio
de la WAI. (Web Accessibility Initiative). Por lo tanto, las tcnicas establecidas
por la Iniciativa de Accesibilidad Web (WAI) son consideradas como estndares
internacionales, y proporcionan soluciones accesibles para el software Web y
para los desarrolladores Web.

2.11.1 Pautas de Evaluacin de la Accesibilidad en la Web. (W3C)

La WAI, propone catorce (14) 8 pautas que buscan mejorar y aumentar la
accesibilidad en la web. En general, estas pautas buscan cumplir, dos objetivos
principales: asegurar una transformacin correcta de la web, y hacer el
contenido comprensible y navegable. La primera, como su nombre lo indica,
busca que los desarrolladores creen pginas que se transformen de manera
correcta, para que puedan ser accesibles para todos los usuarios, sin importar
las barreras tecnolgicas, dispositivos, o las discapacidades del usuario,
mientras que la segunda, proporciona los mecanismos comprensibles para
navegar entre pginas, ya que segn la WAI, el cumplimiento de este objetivo,
principalmente maximiza la accesibilidad y la utilidad de la aplicacin.
Cada pauta tiene uno o ms puntos de verificacin, correspondiente a la
explicacin de aplicacin en determinadas reas. A cada punto de verificacin
se le asigna una prioridad, escalonada de la siguiente manera:

Se incluyen 9 puntos de verificacin, ya que dems, estn clasificados como "provisionales",

lo que implica que eran vlidos y necesarios para la accesibilidad en el momento de la

publicacin del documento de la W3C. Sin embargo, actualmente estos puntos de verificacin
no son necesarios, ya que las tecnologas de la Web han incorporado esas caractersticas,
especialmente con el estndar HTML5.

63

Prioridad 1: (A) El desarrollador tiene que satisfacer este punto de

revisin. De otra forma, uno o ms grupos de usuarios encontrarn
imposible acceder a la informacin del documento.

Prioridad 2: (AA) El desarrollador debe satisfacer este punto de

revisin. De otra forma, uno o ms grupos encontrarn dificultades en el
acceso a la informacin del documento.

Prioridad 3: (AAA) El desarrollador puede satisfacer este punto de

revisin. De otra forma, uno o ms grupos de usuarios encontrarn
alguna dificultad para acceder a la informacin del documento. (W3C WCAG 1.0 )

En cada punto de verificacin, hay un enlace que conduce a las tcnicas que
permiten superar las dificultades de accesibilidad, acordes a cada pauta. Estas
tcnicas proporcionan estrategias, ejemplos y explicaciones utilizando el
lenguaje HTML y CSS. Por conocimiento general, aqu se nombran y se
describen superficialmente, las pautas establecidas por la WAI en su versin
1.09. Si se desea profundizar en esta rea de conocimiento, se recomienda la
lectura de los documentos publicados por el consorcio, disponibles en la web
de la W3C. (Ver BIBLIOGRAFA).

2.11.1.1 Proporcionar alternativas para el contenido.

Consiste en proporcionar una alternativa al contenido visual y auditivo, y que
cumpla con la misma funcin. Por lo general, por una discapacidad temporal
(problemas de acceso desde algn dispositivo) o fsica (limitaciones fsicas),
algunas personas no pueden utilizar imgenes, pelculas, sonidos, o scripts,

Vale la pena aclarar, que en el mbito del trabajo de grado, la metodologa vigente para la

evaluacin de la Accesibilidad en la Web, se encontraba en la Versin 1.0. A partir de Enero 4

de 2012, la herramienta evolucionar a la versin 2.0, lo que modificara el estndar de
medicin.

64

directamente, pero s pueden utilizar pginas que incluyen informacin

equivalente a los contenidos.
El ejemplo ms caracterstico, es la prohibicin de ejecutar scripts construidos
en flash, en la mayora de dispositivos mviles, por lo que es necesaria la
adecuacin de la informacin para estos dispositivos, o por defecto, una
advertencia que anuncie al usuario la incompatibilidad.

2.11.1.2 Contraste de Color.

Los textos y grficos deben ser comprensibles cuando se ven sin color. En
algunos casos, el contraste entre la fuente y el fondo es muy dbil, por lo que
no pueden ser ledos ni observados claramente.

2.11.1.3 Marcadores y Hojas de Estilo (CSS)

El uso errneo de marcadores establecidos por la W3C en HTML, dificulta la
accesibilidad de la aplicacin. Uno de los tpicos ejemplos, es utilizar una tabla
para maquetar (disear la pgina), con el fin de garantizar el formato de la
informacin en los navegadores antiguos. Como consecuencia, se dificulta la
interpretacin de la pgina correspondiente por medio de otros dispositivos e
implica considerar si el formato es tan importante como para hacer que la
aplicacin sea inaccesible para algunos usuarios.

2.11.1.4 Preferencias de Idioma

El idioma, suele llegar a ser uno de los principales factores que influyen en la
frustracin de un usuario. Por lo general, una aplicacin web construida para un
uso masivo, y global, debe considerar la opcin de modificar el idioma.
Adems, la identificacin del idioma permite a los motores de bsqueda
localizar las palabras claves e identificar los documentos en el idioma deseado,
65

por lo que los marcadores de idioma mejoran tambin la legibilidad de la Web

para todo el mundo.

2.11.1.5 Creacin de tablas que se transformen de acuerdo al contenido.

Normalmente, las tablas deberan utilizarse solamente para marcar la
informacin tabular, por medio de las tablas de datos, por lo que se deben
evitar para maquetar y disear las pginas, ya que el uso de stas, para otra
finalidad, genera dificultades para algunos usuarios, como los acceden a la web
por medios auditivos (por ejemplo un lector de pantalla), o a aquellos que slo
visualicen una parte de la pgina (usuarios de dispositivos con pantallas
pequeas).

2.11.1.6 Manejo de JavaScript

Principalmente, esta pauta busca que las pginas son accesibles incluso
cuando no se soportan las tecnologas ms modernas (como Javascript, AJAX,
etc.) o stas estn desconectadas, por lo que reta al desarrollador a
programarlas de tal forma, que funcionen con los navegadores ms antiguos, y
para los usuarios que desconecten esas caractersticas.

2.11.1.7 El usuario tiene el control sobre los cambios de contenido.

Hasta que las aplicaciones de usuario lo permitan, debe asegurarse que los
objetos o pginas que se mueven, parpadean, se desplazan o se actualizan
automticamente, tengan la opcin de detenerse, ya que algunas personas con
discapacidades visuales, son incapaces de leer textos que se mueven con la
suficiente rapidez. Adems, el movimiento puede tambin distraer de tal
manera que el resto de la pgina se vuelve ilegible.

66

2.11.1.8 Accesibilidad directa de las interfaces.

La interfaz de usuario debe seguir los principios de un diseo accesible:
funcionalidad de acceso independiente del dispositivo, teclado operable, etc.
Cuando un objeto incrustado tiene su propia interfaz, como flash, por ejemplo,
sta debe ser accesible. Dado el caso de que no puede hacerse accesible, lo
ideal sera proporcionar una solucin alternativa accesible.

2.11.1.9

Diseo Independiente del Dispositivo.

Para la W3C, el acceso independiente del dispositivo significa que el usuario

puede interactuar con la aplicacin o el documento con un dispositivo de
entrada (o salida) preferido - ratn, teclado, voz, pantalla tctil, puntero de
cabeza u otro. En la actualidad, mltiples dispositivos convergen en internet, y
permiten el acceso desde una amplia diversidad de plataformas e interfaces.
Por esta razn es de vital importancia que el dispositivo no se adapte a la web,
sino la web se adapte al dispositivo. Por esta razn, nace el concepto de
Diseo Web Sensible.
Esta convergencia de dispositivos, est impulsada principalmente por el
aumento de la movilidad. Los usuarios tienen objetivos diferentes segn el
dispositivo, como lo afirma (Margotte, 2011). Por lo general, los usuarios de
mviles buscan algo diferente que los usuarios de los computadores de
escritorio. Por ejemplo, si usted tiene un restaurante, los usuarios de
computadores de escritorio buscarn fotos del lugar, el men, etc., mientras
que los usuarios de dispositivos mviles probablemente querrn encontrar la
direccin y el horario de servicio. Por esta razn es vital que la web se
transforme dependiendo del dispositivo y las capacidades de ste, para que el
usuario sienta que ha sido diseada especialmente para l.

67

Dado que no existe la forma de saber con exactitud el tamao de las pantallas
de los dispositivos de los usuarios (Ver ANEXO E - TAMAOS DE PANTALLA
MS COMUNES), (Nielsen J. , 2001) plantea la posibilidad de disear para
todos los tamaos de pantalla. El principio bsico, consiste en evitar el uso de
valores en pixeles fijos para los elementos del diseo. (Nielsen J. , 2001).
Por otro lado, otros criterios que pueden ser evaluados en esta pauta, se
encuentran los mapas de imagen controlados por el servidor, diseo de interfaz
independiente del dispositivo de acceso, crear un orden lgico para la
navegacin por tabulacin, entre otros.
La evaluacin detallada por prioridades, y la metodologa propuesta por la W3C
para la evaluacin de la accesibilidad, se encuentran en el ANEXO D

EVALUACIN DE LAS PAUTAS DE ACCESIBILIDAD EN LA WEB, SEGN

LA WCAG VERSIN 1.0, en la tabla de mediciones, la cual sirve de modelo
para la propuesta evaluativa de este trabajo de grado.

2.13 ESTTICA Y COMPOSICIN VISUAL

La esttica, como mxima cualidad del diseo visual, integra los conceptos
para lograr una apariencia bella, placentera y atractiva. Para (Laviea &
Tractinsky, 2004), un diseo esttico es aquel que resulta ser agradable, para
los sentidos, para la imaginacin o para nuestro entendimiento.
Por lo general, al diseo esttico se le atribuyen cualidades altamente
motivadoras, a tal punto de mejorar la percepcin de usabilidad del sistema.
Uno de los estudios que lo demuestran, planteado inicialmente por (Kurosu &
Kashimura, 1995), y partiendo de la instalacin de dos cajeros electrnicos,
uno problemas evidentes de usabilidad, pero con un alto componente esttico y
el otro con mejor usabilidad, pero con una interfaz estticamente mala,
demuestran que el primero, era valorado como ms usable, a pesar de que ese

68

dato no era cierto. Esta conclusin fue comprobada posteriormente por

(Tractinsky , 1997), corroborando tambin, que la mayor percepcin de
usabilidad no depende de factores culturales. A partir de su libro, Donald
Norman explica este fenmeno de la siguiente forma: "las cosas atractivas
hacen que las personas nos sintamos mejor, lo que nos lleva a pensar de
forma ms creativa. Cmo se traduce eso en mejor usabilidad? Muy simple,
haciendo que las personas puedan encontrar soluciones a sus problemas ms
fcilmente". (Norman D. , Emotional Design, Why we love (or hate) everyday
things?, 2004).
Por eso, la relacin entre la esttica y la usabilidad tambin puede producirse
en sentido contrario, tal como lo plantea (Manchn, 2002); al afirmar que
algunos recursos, tales como las armonas, simetras, los colores suaves, los
bordes con transiciones suaves y los degradados, a pesar de ser agradables
visualmente, dificultan la usabilidad en la web. Y es que la interrelacin entre
esttica y usabilidad, es ms compleja de lo que se puede llegar a imaginar, ya
que puede influenciar o afectar otros factores positiva o negativamente. Se
puede llegar a suponer que la accesibilidad es influenciada negativamente por
la esttica, pero segn (Hassan Y. , 2006), no necesariamente esta influencia
debe ser negativa, al afirmar que los diseos visualmente sofisticados y
estticamente

agradables,

pueden

ser

compatibles

con

una

buena

accesibilidad. Por otro lado, otro de los factores que pueden afectarse, es la
utilidad percibida por el usuario, ya que segn (Heijden, 2003), es influenciada
positivamente, provocando una mayor intencin de uso.
En el contexto de uso en la web, se generaliza el uso repetido de las
aplicaciones, con tal de cumplir una tarea u ofrecer un servicio. As, segn
(Manchn, 2002), lo determinante para que el usuario vuelva a utilizar la
aplicacin, ser una experiencia de uso satisfactoria y para ello se han de
generar emociones positivas a travs de la experiencia de uso real, es decir, la
fidelizacin de usuarios, a diferencia de la compra y venta de productos, se
basa en la experiencia de stos, no en su apariencia. As, Manchn determina

69

que la experiencia de uso es determinada en gran parte por los procesos

cognitivos de anlisis de la informacin. Estos procesos son "ms racionales y
analticos" y no es tan fuerte la influencia de procesos "bsicos" donde suele
atacar la publicidad del mundo fsico, por lo que plantea considerar que en la
mayora de aplicaciones, es mucho ms efectivo mejorar la usabilidad que la
esttica.
Pero, al ser la capa de interaccin desde el modelo de la experiencia de
usuario, la esttica y el diseo visual es uno de los factores que ms provoca
motivacin, y cuyo peso es mayormente percibido por el usuario, a tal punto de
persuadir, o permitir el uso de la aplicacin, desde la misma la impresin inicial
de la interfaz.
Por eso, en el siguiente captulo se presentan los factores de diseo esttico,
que ms influyen en la percepcin de la usabilidad,

y la manera de

implementarlos en el diseo de aplicaciones de software.

2.13.2 Reglas Fundamentales del Diseo Visual.
El diseo visual, comienza con un espacio en blanco, en el cual, las formas y
figuras sern posicionadas. El desarrollador tiene el control para manejar el
espacio, para llamar la atencin del usuario, utilizando los tres elementos
bsicos de una composicin: Tamao, posicin, y la relacin espacial entre los
elementos. Partiendo de la teora de Gestalt, que explican los principios en los
que se basan las reglas fundamentales de la composicin. (Percepcin).
Ley de la Proximidad
Cuando

los

elementos

Ley de la Similitud
estn Se perciben como grupo, aquellos

agrupados, por lo general se perciben elementos

como un nico objeto.

cuya

caractersticas

forma,

visuales

posee
similares,

como la forma, el tamao, color, etc.

70

Ley de la Continuidad

Ley del Cierre

El ojo humano, continuar en la

direccin que est observando, por lo La mente siempre completar las
que naturalmente sigue una lnea o la partes o puntos que faltan de una
curva hasta encontrarse con otro figura conocida.
objeto.

Tabla 5: Leyes bsicas de la Composicin por Gestalt.

Por lo general, el diseo web utiliza los principios de proximidad y similitud,

para identificar los mens, y los botones y acciones con diferentes usos,
utilizando especialmente los balances de composicin, y la jerarqua visual.
A travs del tamao y la posicin de los elementos, se establece un balance en
la composicin. Por lo general, los diseos no-balanceados, generan tensin,
por lo que este aspecto visual, es importante en el diseo de aplicaciones.
Principalmente, consiste en ubicar en el espacio, un objeto oscuro y claro, con
uno oscuro y pequeo. Este principio permite ubicar visualmente los objetos,
para darles jerarqua y orden en la composicin, lo que permite guiar la visin
en busca de objetos importantes.

(Zambonini, 2011). Del mismo libro, se

extrae un ejemplo de la gua que sigue la vista, a travs de una jerarqua.

71

Ilustracin 12: Gua visual a travs de una jerarqua visual.

Por esta razn, y teniendo en cuenta la Ley de Fitts, (Ver captulo 2.12.3.1
Eficiencia y Ley de Fitts.), la vista se centra en la accin que debe realizar, a
partir de una visualizacin rpida, ya que es mucho ms lenta el movimiento
del dispositivo para conocer la accin. En aplicaciones sin jerarqua visual, el
usuario comenzar a buscar en el contenido, acciones similares o botones que
lo dirijan a lo que debe hacer, por lo que tarda ms tiempo de lo normal,
impidiendo una experiencia satisfactoria.
Entre otros elementos a tener en cuenta, se pueden observar las proporciones,
el nmero de oro, la regla de los tercios, etc. Adems vale la pena tener en
cuenta, que junto con los esquemas de colores, la ley de proximidad y la
temperatura del color, generan la sensacin de profundidad de los elementos
que componen el diseo web, lo que permite, a partir de un diseo en dos
dimensiones, establecer elementos que se encuentran mas lejanos que otros.

Despus de presentar resumidamente aquellos aspectos tcnicos del diseo

web, y tomando como referencia la bibliografa especializada y los aspectos
anteriores, se considera que la legibilidad en la tipografa, y el esquema de

72

colores son los dos aspectos estticos que ms influyen en la accesibilidad y

en la usabilidad de la aplicacin, y por ende, mejoran la experiencia de usuario.

2.13.3 Tipografa y Legibilidad

Para Jakob Nielsen todo lo dems falla (diseo, velocidad y contenido) falla,
cuando los usuarios no pueden leer el texto, por lo que plantea unas reglas
bsicas que se deben tener en cuenta para garantizar la legibilidad del texto.
(Nielsen J. , 2001).
Primero, recomienda utilizar colores que tengan mucho contraste entre el texto
y el fondo, lo que igualmente se establece en las pautas de la W3I para
facilitar la accesibilidad en la web. Y es que, segn la figura, tomada del libro
de Eva Heller, (Ver ANEXO F - LEGIBILIDAD DE LOS TEXTOS SEGN SU
COLOR) la mxima legibilidad del texto se obtiene en texto positivo (blanco
sobre fondo negro). Al invertir la combinacin, es decir, texto blanco sobre
fondo negro, ralentiza la lectura, ya que parecen ser poco importantes. Esta
combinacin, puede ser utilizada cuando los textos no poseen mayor
relevancia ya que otro elemento de la pgina atrae toda la atencin (por
ejemplo una aplicacin de video).
Las otras reglas bsicas planteadas por Nielsen, corresponden al uso de
fuentes grandes y legibles, y evitar el movimiento del texto. Estas fueron
presentadas previamente en el captulo de accesibilidad, cuyo cumplimiento es
obligatorio.
Por ltimo, Nielsen aconseja evitar el uso de maysculas sostenidas en los
prrafos, ya que los usuarios leen ese tipo de texto un 10% ms despacio, ya
que es mucho ms difcil reconocer para la vista, reconocer la forma de las
palabras con una apariencia uniforme.
As, la legibilidad del texto se convierte en un factor determinante, no slo para
asegurar la accesibilidad, si no, como un factor que influye negativamente si n

73

ose tiene en cuenta en la eficiencia del usuario. Entre otros factores a

considerar, vale la pena profundizar en los esquemas de colores, como una
herramienta que transmite las emociones a travs del diseo.

2.13.4 Esquemas de Color.

Uno de los aspectos que visualmente estn ms relacionados con el diseo
emocional, y la percepcin de la usabilidad, es el uso correcto de las paletas de
colores; y no es para ms, ya que segn (Heller, 2005), en su libro Psicologa
del Color, afirma que los colores y los sentimientos no se combinan de forma
accidental, y que sus asociaciones no son cuestin de gusto, si no producto de
experiencias universales enraizadas desde la infancia en el lenguaje y el
pensamiento, por lo que, el uso del color desde el diseo web, provee una
poderosa herramienta para generar emociones asociadas, que permiten
mejorar o empeorar la experiencia del usuario.
Por eso, es fundamental el uso de una correcta paleta de colores, que influya
positivamente en la percepcin de ste. Por esta razn, partiendo del estudio
de Eva Heller, y de manera muy resumida, a continuacin se exponen los
principales efectos cromticos, y el uso de stos en la web.
Color

Descripcin
El rojo, es uno de los colores que ms llama la atencin, y
evoca sentimientos de peligro, pasin, amor, y energa.
Comnmente, es utilizado para connotar errores en las
aplicaciones, o en botones cuyas acciones denoten urgencia
o excitacin.
El amarillo, es un color estimulante, que evoca la memoria y
la retencin de datos, pero puede ser irritante por su
exagerada exposicin. Est asociado a la cobarda, o a la
felicidad. En el diseo web, est asociado principalmente a la

74

informacin temporal, las advertencias, notificaciones etc.

El verde es el color asociado al medio ambiente, la

naturaleza, el crecimiento y la salud. Es el color de la
seguridad, por lo que en las aplicaciones web se utiliza
especialmente

en

acciones

que

se

llevan

cabo

satisfactoriamente. Generalmente se le asocian valores

positivos, mientras que el rojo asimila valores negativos. (En
oriente lejano es el efecto contrario).
El azul es masculino, asociado con la inteligencia y los
negocios. Genera una sensacin de calma. Por lo general es
utilizado en los hipervnculos, as que debe ser utilizado con
cuidado. Tambin es un color frio, lo que produce una
sensacin de profundidad cuando se usa en el fondo.
El gris es sofisticado, y simboliza la autoridad y la
experiencia. Tiene connotaciones negativas, tales como
aburrimiento, vejez y seriedad. Usualmente, es utilizado para
mostrar elementos que no estn disponibles para el usuario o
campos de formulario que no se pueden completar.

El negro es el color dominante y fuerte. Est relacionado con

la elegancia, pero tambin con la muerte.

El blanco es puro, limpio, pero tambin vaco. Lujurioso,

sofisticado y mundialmente reconocido como el color de la
verdad.

Tabla 6: Efectos cromticos asociados a los colores en el diseo web.

75

2.14 CREDIBILIDAD Y CONFIABILIDAD

La credibilidad y confiabilidad de una aplicacin, puede definirse como su
funcionalidad subjetiva, es decir, qu nivel de confianza percibe el usuario, de
tal modo que el software cumpla con su tarea.
En el marco de la experiencia del usuario, la confiabilidad se genera en la
ltima fase, cuando se asocia un producto a una marca. Por lo general, estos
factores estn determinados por la calidad del mismo. As, los atributos del
software que influyen en la calidad del software, segn (Bass, Clements, &
Kazman, 2003), son los requerimientos no funcionales que influyen
directamente en la fiabilidad del producto, los cuales, son los siguientes: La
capacidad de modificar y adaptar el software (modifiability), la facilidad en el
mantenimiento (maintainability), la capacidad de evaluarlo constantemente
(testability), la capacidad de volver a las fases anteriores (traceability), la
capacidad de llevarlo a otras plataformas (scalability), la capacidad de reusarse
(reusability) y su rendimiento (performance).
En el mbito de este trabajo de grado, vale la pena considerar otros aspectos
que influyen en la confiabilidad del usuario, entre ellos la privacidad y la
seguridad.
De hecho, la seguridad es una de las principales consideraciones en el
desarrollo de sistemas interactivos,

ya que mltiples infecciones pueden

afectar la estabilidad y disponibilidad del software, y ms an en la web. Para

(Gomaa, 2011), entre las principales infecciones que pueden afectar la
seguridad y la privacidad de la informacin en un sistema, se encuentran:

Filtracin o penetracin en el sistema: Una persona no autorizada

ingresa a la aplicacin, y ejecuta acciones que no tiene permiso.

76

Violacin de la Autorizacin: Una persona autorizada para usar la

aplicacin, utiliza el rol de otro usuario para ejecutar acciones que segn
su perfil, no tiene permitidas.

Filtracin de Informacin: La informacin personal de los usuarios, son

accedidos por una persona no autorizada.

Denegacin de Servicio: El acceso a la aplicacin se encuentra

restringido, por el alto trfico de datos, o bloqueos intencionales en el
servicio.

Integridad de la Informacin: Una persona no autorizada, modifica los

datos de la aplicacin o su comunicacin con la base de datos.

Vale la pena considerar, que mediante el trabajo investigativo, la confiabilidad,

puede asumirse como un factor integrador, que incluye los componentes
anteriormente vistos en los dems aspectos, con la nica diferencia que en el
ciclo de desarrollo de software, es la fase encargada de velar por la calidad del
producto, para lograr una experiencia de marca satisfactoria en el usuario, el
cual, finalmente recomienda el uso de la aplicacin, y de todas las aplicaciones
desarrolladas por el equipo de desarrollo.
Por eso, este factor, est ntimamente relacionado con la usabilidad que
percibe el usuario, como con la esttica de la aplicacin (Hassan Y. , 2006), a
la vez que busca la perfecta funcionalidad, y accesibilidad, y a pesar de que
difcilmente es percibido por el usuario, motiva el uso de la aplicacin.
2.15 USABILIDAD
A partir de las definiciones enumeradas en el comienzo de este trabajo, que se
basan principalmente en la enumeracin de los diferentes atributos que la
componen, y a travs de los cuales puede ser evaluada, el concepto de
usabilidad integra los aspectos anteriores que influyen en la satisfaccin de
uso, siendo ste un factor al mismo tiempo higinico y motivador, ya que si se
evalan desde la facilidad de aprendizaje, memorizacin, eficacia, eficiencia
77

comprensin,

evitar

la

desmotivacin

de

uso,

adems

depender

principalmente de que funcione correctamente y que sea accesible. Mientras

que si se evala en el mbito del diseo, el atractivo esttico, su confiabilidad,
la facilidad de uso, y su utilidad, se determina la capacidad de la aplicacin de
provocar satisfaccin y motivar su uso.
Por esta razn, es necesario profundizar en aquellas metodologas y tcnicas
de evaluacin que promueve la Ingeniera de la Usabilidad, para poder
cuantificar y medir el grado de satisfaccin del usuario con la aplicacin.

2.15.1 Tcnicas de Evaluacin de la Usabilidad.

La principal actividad en el proceso de usabilidad es la evaluacin, (Ferr,
Juristo, Windl, & Constantine, 2001) y consiste en medir, o identificar
problemas potenciales que afectan algunos atributos de utilidad de un sistema
o dispositivo con respecto a usuarios particulares, desempeando tareas
particulares, en contextos particulares. (Hilbert & Redmiles, 1999)
Por lo general, esta medicin se destaca por cumplir un conjunto de reglas
basadas en el juicio de un experto en usabilidad, quien juzga los aspectos
relacionados con la interfaz de usuario. En la literatura especializada, se
encuentra un amplio abanico de propuestas metodolgicas que buscan
detectar problemas de usabilidad en la web. Las ms comunes, son nombradas
por (Mack & Nielsen, 1994), y complementadas por (Mayhew, 1999):
2.15.1.1

Evaluacin Heurstica

Esta tcnica puede aplicarse en cualquier fase de desarrollo del software, y

consiste en que un experto verifica si el diseo (estructuracin, color, etc.)
cumple con los principios de usabilidad, basndose en conocimientos de
cognicin humana y las reglas que se basan en estos principios, conocidas
como heursticas. En la literatura, se pueden encontrar autores que desarrollan
investigaciones a profundidad, acerca de la evaluacin heurstica, entre ellos,

78

Jakob Nielsen; quien propone un conjunto de diez (10) principios para evaluar
la usabilidad: (Nielsen J, 1994).

Visibilidad del estado: El sistema siempre debe informar al usuario

acerca de lo que est sucediendo. Cuando el usuario ignora
completamente el estado de la aplicacin, tiende a pensar que se ha
producido un fallo crtico, y que sta ha dejado de funcionar, lo que
produce frustracin de uso. (Ver Captulo 2.10 FUNCIONALIDAD).

Lenguaje comn entre sistema y usuario: El lenguaje entre el sistema

y el usuario debe ser el mismo, para evitar confusiones. Generalmente,
se evita el uso de trminos tcnicos e incomprensibles.

Consistencia y estndares: La consistencia en la aplicacin, es la

clave para evitar confusiones y saltos entre la misma aplicacin. Adems
se deben seguir ciertos estndares o convenciones de diseo
ampliamente aceptados. (Ver Captulo 2.12

) Cuanto ms se parezca

un diseo y su funcionamiento al resto de la aplicacin, ms familiar y

fcil de usar resultar para el usuario.

Prevencin de errores: Los errores son la mayor frustracin del

usuario. Se recomienda ampliamente, que en vez de disear buenos
mensajes de error, se prevenga que ocurra el error. (Ver Captulo 2.10.2
Errores del Software y Mantenimiento.).

Es mejor reconocer que recordar: Este principio se basa en las

tcnicas de bsqueda de informacin, y busca la visibilidad de las
diferentes opciones, enlaces y objetos de la aplicacin. Para (Hassan,
Martin, & Iazza, 2004), el usuario no tiene por qu recordar dnde se
encontraba cierta informacin, o cmo se llegaba a determinada pgina.

79

Flexibilidad y eficiencia de uso: La eficiencia, es uno de los atributos

que compone el concepto de usabilidad, por lo que es primordial que la
aplicacin, le permita al usuario novato, aprender a utilizarla fcilmente,
pero tambin proporcione atajos o tcnicas rpidas para los usuarios
avanzados.

Diseo minimalista: La esttica juega un papel importante en la

percepcin de usabilidad. (Ver Captulo 2.13 ESTTICA), pero a la vez,
Nielsen afirma que la informacin que no sea relevante para el usuario y
que sobrecargue la interfaz debe ser eliminada.

Permitir al usuario solucionar el error: Si se producen errores por

causa del comportamiento del usuario, el sistema debe informarle o
sugerirle posibles acciones que puedan solucionar el problema.

Ayuda y Documentacin: Existe la posibilidad de que una aplicacin se

pueda utilizar sin necesidad de ayuda o documentacin, pero siempre
debe tenerse en cuenta, y ms an en las aplicaciones web con
procesos de interaccin complejos (como el rellenado de un formulario,
generacin de diagramas, informes, etc.), donde se debe proporcionar
informacin de ayuda para que el usuario no cometa errores.

2.15.1.2

Paseo Cognitivo (Cognitive Walkthrough)

Se conoce como una tcnica de revisin previa, donde se construyen las

interfaces y escenarios para las tareas, a partir de las especificaciones de la
fase de anlisis de requisitos.
En la Ingeniera de Software, se aplica comnmente, en el planteamiento y
desarrollo de los casos de uso (Ver Captulo 2.10 FUNCIONALIDAD). Por lo
general, se evala cada uno de los posibles escenarios de interaccin entre el

80

usuario y la aplicacin (casos de uso), lo que facilita la identificacin de los

objetivos.
Esta tcnica se utiliza principalmente en etapas tempranas del desarrollo dado
que solo puede ser aplicada en el anlisis de requisitos, tomando los casos de
uso como punto de partida para el diseo y evaluacin de las interfaces.
(Rowley & Rhoades, 1992)

2.15.1.3

Inspeccin de Estndares.

El cumplimiento de los estndares, aseguran que los principios de usabilidad

sean considerados en un diseo. Esta tcnica consiste en que un experto de
interfaces, analiza si la aplicacin cumple con los patrones establecidos en el
estndar. Por lo general, se busca que la aplicacin web, cumpla con los
parmetros de accesibilidad, basados en HTML y CSS. Para profundizar ms
acerca de estos estndares, en el captulo de Accesibilidad, se estudiarn las
pautas de cumplimiento establecidas por la W3C.

2.15.1.4

Seguimiento Interdisciplinario.

Este mtodo busca que los actores implicados en la construccin y desarrollo

del

software

(usuarios,

desarrolladores,

psiclogos,

etc.)

trabajen

conjuntamente en el diseo, a medida que aparecen problemas de usabilidad.

Esta tcnica es la base fundamental de la metodologa MPIU+a, que busca
fusionar la Ingeniera de Software, con la Interaccin Humano-Computador,
propuesta en la tesis doctoral de Toni Granollers, que se profundizar en las
metodologas utilizadas en el rea de la ingeniera de la usabilidad.
2.15.2 Ingeniera de la Usabilidad
El concepto de Ingeniera de la Usabilidad (IU por sus iniciales en ingls) se
introdujo inicialmente por el equipo multidisciplinar de la (Digital Equipment

81

Corporation, 1986), refirindose a las principales tcnicas para planificar,

conseguir y medir los objetivos de la usabilidad.

Por lo tanto, la Ingeniera de Usabilidad es una disciplina que plantea una

metodologa estructurada e iterativa, cuyo fin es el mejoramiento del diseo de
las interfaces de usuario, y el anlisis de las actividades del usuario, durante el
desarrollo de software, por medio de unos objetivos medibles, que deben ser
definidos al comienzo del proceso, para evaluarlos repetidamente durante todo
el desarrollo, para verificar su cumplimiento.

2.15.2.1 Metodologas
En

la

literatura,

abundan

los

modelos

propuestos

para

facilitar

la

implementacin y construccin de proyectos de software, donde la usabilidad

es la meta principal, y buscan integrar la Ingeniera de Software con la
Interaccin Humano-Computador. A continuacin, y de manera explicativa, se
presentan aquellas metodologas ms destacadas. (Para profundizar, puede
consultar el Anexo A Metodologas de la Ingeniera de Usabilidad)

MODELO

CARACTERSTICA
Jakob Nielsen es considerado el padre de la Usabilidad, ya
que introdujo el concepto en el desarrollo de aplicaciones.
Por lo tanto, su metodologa fue la primera hacer aparicin,
y enumera las actividades necesarias para desarrollar

Nielsen

aplicaciones usables, colocando la interaccin del usuario

con el sistema, en el centro del problema. Este modelo se
basa principalmente en la evaluacin heurstica, donde un
experto cognitivo, interacta con la aplicacin y saca sus
propias

conclusiones.

(Nielsen

J.

Enhancing

explanatory power of usability heuristics, 1994)

82

the

Liderada por Gerrit Van Der Veer, y desarrollada por el

grupo de investigacin en Ingeniera de Software, de la
Universidad

de

Vrije

[Amsterdam

Holanda].

Principalmente es un mtodo de diseo, que se basa en el

desarrollo de prototipos por ciclos, que finalmente
Designing for
Users and
Tasks from
Concepts to
Handles
(DUTCH)

conducen a la implementacin del sistema final. Por lo

general, comienza con un anlisis exhaustivo de los
usuarios, y los objetivos que deben cumplir en determinada
situacin.

Adems,

esta

metodologa

plantea

la

importancia del trabajo en equipos multidisciplinares,

especialmente compuestos de personas expertas en las
reas de psicologa, ingeniera y diseo grfico. Por esta
razn, esta tcnica puede considerarse como un hbrido
entre las tcnicas de paseo cognitivo, y seguimiento
interdisciplinario. (Veer, Lenting, & Bergevoet, 1996)
Este mtodo plantea tres fases de desarrollo: Anlisis de
Requisitos, la fase de diseo, prueba y desarrollo, y la fase
de instalacin. La fase de diseo, est a su vez dividida en

Ciclo de vida
de la Ingeniera
de la
Usabilidad.

tres niveles: El diseo del modelo conceptual, el diseo de

la pantalla y el diseo detallado de la interfaz de usuario.
Todas las fases incluyen actividades de evaluacin final,
para analizar el cumplimiento o no de los objetivos
propuestos. Solo est permitido avanzar a la siguiente
fase,

si

los

objetivos

de

la

fase

se

cumplen

satisfactoriamente. Fue planteado por (Mayhew, 1999).

Planteada como tesis doctoral (Granollers, 2004). La
Modelo de
Proceso de la
Ingeniera de la
"Usabilidad" y
de la
Accesibilidad
(MPIU+A)

metodologa incorpora a un ciclo de Ingeniera de Software

(Anlisis

de

Lanzamiento)

Requisitos,
algunas

Humano-Computador,

83

Diseo,

actividades
que

Implementacin
de

permiten

la
unir

Interaccin
las

dos

disciplinas, por medio de una serie de fases, que

repetitivamente se realizarn durante el desarrollo del
software.
Tabla 7: Metodologas de Evaluacin de la Usabilidad

84

MODELO EVALUATIVO PROPUESTO

3.1 METODOLOGA
A partir de las tcnicas que promueve la ingeniera de la usabilidad, en el
presente trabajo de grado, se proponen dos tipos de mediciones, para los
aspectos que componen la experiencia de usuario.
Primero, se realizar una inspeccin de estndares, que permita medir los
aspectos incluidos en la WCAG Versin 1.0, en cada uno de los prototipos que
se presentarn a continuacin. Dependiendo de esta validacin, se determinar
el grado de accesibilidad que posee cada una de las aplicaciones, con el fin de
observar posibles falencias en este aspecto.
Luego, y partiendo de una evaluacin heurstica, se proceder a evaluar la
funcionalidad y usabilidad de la aplicacin, para establecer el porcentaje de
errores, las fallas en determinados casos de uso, para que el equipo de
desarrollo de software las corrija en el menor tiempo posible. Adems, si se
observa algn problema de usabilidad, que incumpla uno de los factores
establecidos por Nielsen, el grupo tambin proceder a replantearlo y
solucionarlo.
Por ltimo, se realizar un cuestionario para los usuarios, los cuales explorarn
la aplicacin por medio de un paseo cognitivo, y respondern las preguntas
planteadas a continuacin. Finalmente, medirn su nivel de satisfaccin en el
manejo de la aplicacin, para luego establecer las posibles mejoras y falencias
que posea el prototipo.

85

3.2.1 CUESTIONARIO
Accesibilidad

SI

Considera que el contraste (La diferencia entre el color del fondo y el texto) es correcto, y que la
informacin detallada por la aplicacin puede leerse fcilmente?
Se permite modificar el idioma del texto?
La aplicacin provoca destellos en la pantalla?
El tamao de la letra permite la correcta lectura de la informacin?
Se permite aumentar o disminuir el tamao de la letra?
Las imgenes utilizadas se encuentran borrosas?
Si hay animaciones, considera que stas lo distraen del objetivo principal?
La aplicacin tiene un dominio (www.ejemplo.com) fcil de pronunciar y recordar?
Ha notado si las imgenes o elementos de la aplicacin tardan mucho en cargar?
El sitio funciona con cualquier navegador? Incluso en Internet Explorer?
Usuario Experto
Las imgenes muestran informacin adicional en los thumnails?
Dado el caso que el men utilice imgenes, se proporcionan textos alternativos para navegar?
Aparecen todas las imgenes y grficos de la aplicacin?
El diseo de interfaz, se adapta fcilmente a las diferentes resoluciones de pantalla?
Es necesaria la instalacin de un Plug-in para utilizar la aplicacin?

86

NO

N/A

Funcionalidad

SI

NO

N/A

SI

NO

N/A

Ha detectado enlaces rotos? Hay enlaces que no llevan a ninguna parte?

Suele encontrarse con errores de funcionamiento?
Los resultados de las operaciones son correctos?
Las acciones principales, tienen un espacio en el men principal?
Los mensajes de error son expresados claramente, indicando el problema y una solucin?
Diseo de Interaccin
A primera vista, Existe algn enlace o cono del cual que no sepa cul es su accin?
Algn botn no posee una descripcin clara de las acciones que realiza?
Las etiquetas del formulario son claras y precisas? Ha dudado del significado, o la finalidad de
la informacin en alguno de los campos?
Mientras realiza acciones que toman bastante tiempo, mientras tanto, la aplicacin le permite
hacer alguna otra tarea?
La aplicacin anuncia si la tarea que va a desarrollar tarda ms de lo normal?
La aplicacin incluye controles adicionales que permiten facilitar las tareas? (Por ejemplo, un
calendario para elegir los formatos tipo fecha, autocompletar, etc.)
La aplicacin incluye convenciones establecidas, y sabe cul es su funcin? (Por ejemplo, para
buscar, el cono de la lupa, o para comprar artculos, un carrito de supermercado, etc.)
Los conos o smbolos, representan conceptos o ideas?

87

La aplicacin posee opciones para corregir errores?, es decir, volver atrs dado el caso de
equivocarse en las opciones, o borrar el formulario en caso de equivocarse, etc.)
La aplicacin proporciona un punto claro de salida, en caso de volver atrs o cerrar la sesin?
Considera que la aplicacin le ayuda para no cometer errores?
Existen campos de formulario que realmente le parecen intiles?
En caso de formularios extensos y encuestas, La aplicacin le permite saber cunto falta para
culminar la tarea, y en qu fase del proceso se encuentra?
Considera que hay demasiados distractores en la pgina que le impiden concentrarse en su
tarea?
Despus de completar la accin, la aplicacin anuncia si la operacin fue realizada
exitosamente, o si se produjo algn fallo?
Diferencia claramente dnde puede hacer clic, y dnde no? Los enlaces son claros y se
diferencian del resto del contenido?
Usuario Experto

SI

El formulario valida los datos en el cliente?

El formulario utiliza tamaos adecuados de textbox y sugerencias en los label, acerca de la
informacin que el usuario debe introducir?
Los enlaces abren nuevas ventanas del navegador?
Para poder observar la aplicacin, considera que El uso de scroll es excesivo?

88

NO

N/A

Existe una barra o men de navegacin global?

Esttica

SI

NO

N/A

SI

NO

N/A

SI

NO

N/A

Considera que la combinacin de colores utilizada, es atractiva visualmente?

El color de la letra permite una lectura fcil y descansada?
El tamao de la letra es muy pequeo y dificulta su lectura?
La forma, y tipo de letra permite una lectura fcil?
Considera que es excesiva la cantidad de elementos que contiene la aplicacin?
Hay prrafos escritos en maysculas?
El fondo es claro y sutil?
En el caso de que el fondo del sitio sea oscuro, y la letra clara, Hay demasiado texto?
Credibilidad y Confiabilidad
El logotipo es claro y visible en todas las pginas de la aplicacin?
Dado el caso que necesite leer la ayuda y/o documentacin, sabe dnde encontrarla dentro de la
aplicacin?
La aplicacin cuenta con documentacin y ayuda tcnica?
Existe una consistencia tanto en el funcionamiento, como en la apariencia de la aplicacin?
Usuario Experto
Dado el caso de ser una aplicacin de comercio electrnico, transferencias bancarias, etc.
Poseen certificados de seguridad vlidos?

89

Usabilidad

SI

Los grficos utilizados son indispensables para el funcionamiento de la aplicacin?

Confa en el reconocimiento, y no en la memoria para realizar un correcto uso de la aplicacin?
Es necesaria la asesora de un experto para poder manejar correctamente la aplicacin?
Se proporcionan las instrucciones correspondientes para realizar las tareas?
La aplicacin anuncia en todo momento, qu est haciendo o cul es su estado?
Considera que la aplicacin hace ms fcil su trabajo?
Recomendara el uso de esta aplicacin a otra persona?
Tabla 8: Test propuesto para la medicin de la Experiencia de Usuario

90

NO

N/A

PROTOTIPO DE APLICACIN
El problema abordado desde Ingeniera de Requisitos, consiste en solucionar
los inconvenientes que posee la DIMA (Direccin de Investigacin de la Sede
Manizales, de la Universidad Nacional de Colombia), en la gestin de los
proyectos y grupos de investigacin.
Partiendo del anlisis de la organizacin, se procede a realizar la especificacin
de requisitos, utilizando la metodologa UN-Mtodo, de la Escuela de Sistemas
de la Universidad Nacional, por medio del cual se obtiene una solucin
informtica creativa que soluciona los inconvenientes en un 77%. (Ver ANEXO
C: PROPUESTA DE SOLUCIN CREATIVA CON UN-MTODO.
Luego, a partir de la solucin, se plantean los respectivos casos de uso (Ver
ANEXO I: CASOS DE USO ASOCIADOS AL PROTOTIPO), teniendo en
cuenta la interaccin y las acciones del usuario y la aplicacin, para luego, en
diseo y construccin de productos de software, realizar la correspondiente
divisin de capas, utilizando el Modelo-Vista-Controlador, los contratos, y
finalmente la implementacin.

4.1 ESQUEMA DE UML

Para facilitar la comprensin y estudio del prototipo, a continuacin se adjuntan
el diagrama de clases, el diagrama entidad-relacin y el modelo relacional. Las
capturas correspondientes del prototipo, y el anlisis evaluativo planteado en
este trabajo de grado, pueden encontrarse fcilmente en el captulo siguiente.

91

4.1.1 DIAGRAMA DE CLASES

Ilustracin 13: Diagrama de Clases (Prototipo DIMA)

92

4.1.2 DIAGRAMA ENTIDAD-RELACIN

Ilustracin 14: Diagrama Entidad- Asociacin (Prototipo DIMA)

93

4.1.3 MODELO RELACIONAL

Ilustracin 15: Modelo Relacional

94

ANLISIS DE RESULTADOS

5.1 EVALUACIN DEL PROTOTIPO ANTIGUO

Desarrollado a finales del ao 2010, por Len Jaramillo, Cristian Vlez, Grissa
Maturana, Faider Flrez y el autor de este trabajo de grado, fue presentado
como trabajo final de la asignatura diseo y construccin de productos de
software, ejecutando JSP desde el servidor, Javascript desde el cliente y
HTML + CSS en la capa visual. Este prototipo buscaba solucionar los
inconvenientes presentados por la DIMA en la gestin de proyectos de
investigacin, aplicando los conceptos vistos en toda la lnea de profundizacin
de Ingeniera de Software. En la siguiente figura, se puede observar una
captura de pantalla del prototipo en funcionamiento:

Ilustracin 16: Captura de Pantalla del Prototipo Antiguo

A continuacin, se presentarn los resultados de la evaluacin propuesta en

este trabajo de grado, implementada sobre este prototipo, para luego comprar
los resultados y sacar las respectivas conclusiones.

95

5.1.1 EVALUACIN HEURSTICA DE LA FUNCIONALIDAD

De los once (11) elementos de men, los cuales, cada uno corresponde a un
caso de uso, solo uno funciona correctamente. El resto de casos no fueron
implementados, por lo que el prototipo posee funcionalidad mnima.
El enlace de Programar reuniones, despliega un formulario para el ingreso de
la informacin. El botn de Adicionar Investigador no funciona, por lo que
debe ingresarse un investigador por reunin (algo ilgico, ya que es una
reunin de investigadores).
La ayuda es funcional, y explica textualmente cada uno de los campos del
formulario. Al llenar los campos, y hacer clic en el botn enviar, procede a
enviar la informacin satisfactoriamente, almacenndola en la base de datos (al
menos eso anuncia), ya que es imposible observarlo, pues es el nico caso de
uso que funciona.
Evaluando la funcionalidad del prototipo, es el factor por el cual la aplicacin,
(si se puede llamar aplicacin), genera una alta frustracin de uso, ya que no
cumple con los objetivos del usuario.

5.1.2 EVALUACIN POR ESTNDARES DE LA ACCESIBILIDAD

A pesar de su funcionamiento, la aplicacin contaba con una pgina HTML por
cada caso de uso, a la cual, se le realiz la prueba de accesibilidad, a partir de
los estndares establecidos por la W3C. Cada una de las pautas evaluables,
tanto de prioridad A, como de prioridad AA, estn especficamente detalladas
en los anexos. (Ver ANEXO D

EVALUACIN DE LAS PAUTAS DE

ACCESIBILIDAD EN LA WEB, SEGN LA WCAG VERSIN 1.0

Dependiendo de cada una de las pautas, y por cada caso de uso, se clasifican
tres posibles valores: Cumple con la pauta, no cumple, o la pauta, en ese caso

96

especfico, no aplica. La siguiente, es la tabla de resultados para las pautas de

prioridad A.
Caso de Uso
CU1
CU2
CU3.
CU4.
CU5.
CU6.
CU7.
CU8.
CU9.
CU10
CU11

Cumple

% cumple

No cumple

% no cumple

No aplica

% no aplica

6
6
6
6
6
6
6
6
6
6
6

31,58
31,58
31,58
31,58
31,58
31,58
31,58
31,58
31,58
31,58
31,58

8
13
9
9
9
9
9
9
9
9
9

42,11
68,42
47,37
47,37
47,37
47,37
47,37
47,37
47,37
47,37
47,37

5
0
4
4
4
4
4
4
4
4
4

26,32
0,00
21,05
21,05
21,05
21,05
21,05
21,05
21,05
21,05
21,05

Tabla 9: Porcentaje de cumplimiento de Accesibilidad por Caso de Uso.

Como se puede observar, que el caso de uso 2, correspondiente a la

implementacin del diagrama de Gantt para la gestin de proyectos, es aquel
con ms pautas sin cumplir, y que posee grandes problemas de accesibilidad
ya que impide la visualizacin en otros dispositivos.
Adems, por lo que se puede observar en la tabla, es generalizado el
incumplimiento de seis pautas, que fallan en todos los casos de uso. Si desea
detallar cada uno de los aspectos por caso de uso, se adjunta la hoja de
clculo correspondiente al modelo evaluativo.

57,96

% cumplimiento A

42,04

% incumplimiento A

Ilustracin 17: Porcentaje de cumplimiento de los estndares de Accesibilidad - Prioridad A

97

Como se puede observar en la ilustracin, luego de realizar la tabulacin y

clculo de los datos, se obtiene que el prototipo incumple con un 58% de las
pautas de accesibilidad establecidas por la W3C, las cuales se consideran
prioritarias. nicamente el 42.04% de las pautas, cumplieron la norma
satisfactoriamente.
En el caso de la prioridad AA, se tiene que el prototipo cumple con el 48,22%
de las pautas establecidas, mientras que incumple en un 51, 78%.

51,78

48,22

% cumplimiento AA
% incumplimiento AA

Ilustracin 18: Cumplimiento de los estndares de accesibilidad, Prioridad AA por el prototipo

antiguo.

Si se tienen en cuenta tanto las pautas de prioridad A, como las AA, se observa
que el prototipo cumple con el 45,85% de ellas, mientras incumple con el 51%.
Tambin se puede observar que el caso de uso que presenta mayores
dificultades de accesibilidad, corresponde al Diagrama de Gantt, ya que al ser
generado por medio de plug-ins externos, los convierte en un objeto poco
personalizable y accesible al usuario.

5.1.3 EVALUACIN GENERAL CON USUARIOS

La evaluacin se realiza por medio de un paseo cognitivo con usuarios, los
cuales evalan por medio de un test, el desempeo de la aplicacin, lo que

98

permite conocer ms de cerca, la experiencia que obtuvieron con su uso. Para

esta prueba, se cont con cuatro participantes, los cuales interactuaron con la
aplicacin durante un tiempo, y reflejaron sus opiniones, en cada uno de los
aspectos que componen la experiencia de usuario.
En la siguiente tabla, se resumen los resultados de la evaluacin para el
prototipo antiguo:
TOTAL
PAUTAS CUMPLE

NO
CUMPLE

NO
APLICA

%
% NO
CUMPLE CUMPLE

% NO
APLICA

Accesibilidad

50

31

16

62,0

32,0

6,0

Funcionalidad
Diseo
Interaccin

20

18

10,0

90,0

0,0

74

26

44

35,1

59,5

5,4

Esttica

32

29

90,6

0,0

9,4

Credibilidad

16

11

31,3

68,8

0,0

Usabilidad

28

12

14

42,9

50,0

7,1

Tabla 10: Tabla resumen de la evaluacin con usuarios del prototipo antiguo.

Como se puede apreciar fcilmente, los factores de diseo con mayor

relevancia en la aplicacin, en orden ascendente: La esttica, la accesibilidad,
la usabilidad, el diseo de interaccin, la credibilidad, y por ltimo su
funcionalidad.
As, partiendo de la evaluacin heurstica, los usuarios tambin aseguran que
la funcionalidad de la aplicacin es psima, principalmente por la existencia de
enlaces que no funcionan, y casos de uso que no cumplen los objetivos.
Adems, la aplicacin no posee una herramienta que gestione los errores, por
lo que los usuarios no saben si las acciones se ejecutaron satisfactoriamente.
As, de las 5 pautas funcionales, los usuarios deducen que aproximadamente
no cumple un 90%, lo que genera una frustracin de uso que, en la evaluacin
de la experiencia, opaca a los dems aspectos por la falta de funcionalidad.
Pero no todo es malo. Segn las consideraciones de los usuarios, la aplicacin
es estticamente agradable, por lo que de treinta y dos (32) pautas, cumple

99

exitosamente con veintinueve (29). Los aspectos ms destacados son

respectivamente la correcta la combinacin de colores, la buena distribucin y
cantidad de elementos de la interfaz, y la fcil lectura de la informacin, por lo
que en un 90% de las pautas de medicin, vale la pena destacar que los
usuarios, se sienten satisfechos visualmente.
Por otro lado, la accesibilidad percibida por los usuarios, es mayor a la
accesibilidad objetiva, obtenida a travs de las pruebas de la W3C. Segn la
evaluacin, las pautas de accesibilidad que percibida, cumplen con las
expectativas de los usuarios en un 62%, principalmente basados en el
contraste de la fuente y el fondo, la legibilidad, la ausencia de animaciones que
distraigan del objetivo principal, y la carga rpida y eficiente del diseo. El otro
32%, es por la ausencia de herramientas que permitan aumentar el tamao del
texto.
Accesibilidad

Funcionalidad
0,010,0

6,0
32,0
62,0

90,0
% CUMPLE

% NO CUMPLE

% NO APLICA

% CUMPLE

Diseo Interaccin

% NO CUMPLE

% NO APLICA

Esttica

5,4

9,4
0,0
35,1

59,5
90,6
% CUMPLE

% NO CUMPLE

% NO APLICA

100

% CUMPLE

% NO CUMPLE

% NO APLICA

Usabilidad

Credibilidad
0,0

7,1
31,3

42,9
50,0

68,8

% CUMPLE

% NO CUMPLE

% NO APLICA

% CUMPLE

% NO CUMPLE

% NO APLICA

Tabla 11: Resultados de la evaluacin por usuarios - Prototipo Antiguo

La usabilidad percibida por el usuario es el tercer factor que se observa en el

prototipo. Los usuarios, incluso los ms novatos, consideran que la aplicacin
es fcil de manejar, pero critican la falta de instrucciones en los formularios, lo
que dificulta realizar el trabajo.
Por otro lado, la aplicacin falla en su diseo de interaccin, principalmente por
la omisin de herramientas que permitan predecir el comportamiento del
usuario, aumentando la probabilidad de que ste cometa errores. A pesar que
la aplicacin cuenta con una clara navegacin a travs del men principal, los
usuarios consideraron que hay elementos que confunden, y no comprenden su
funcionamiento. Tal es el caso del botn Actualizar sistemas, que en un par
de ocasiones, fue confundido con el botn de actualizar la pgina en el
navegador.
Finalmente, como la credibilidad est fuertemente influenciada por los actores
estticos y funcionales, la mayora de usuarios consideraron que se producen
inconsistencias entre el funcionamiento y la apariencia, por lo que finalmente
resultan desconfiando de la aplicacin, a tal punto de calificar su experiencia de
uso con un valor de 2, en una escala de 1 a 10, y afirmar que no
recomendaran el uso de la aplicacin a otra persona.

101

5.2 NUEVO PROTOTIPO

Este prototipo, surge como mtodo prctico, al aplicar todos los conceptos y
teoras de este trabajo de grado, en la implementacin de software.
Desarrollado a partir de PHP, Javascript y HTML+CSS, cumple con las pautas
de accesibilidad, y de diseo orientado al usuario.
Cabe la pena aclarar, que aplica el concepto de diseo web sensible lo que
permite transformarse dependiendo del dispositivo de acceso. En la figura, se
observan algunas capturas de pantalla, que varan dependiendo del dispositivo
(computador de escritorio (PC), Tablet, o telfono mvil).

Ilustracin 19: Capturas de Pantalla del Prototipo propuesto desde varios dispositivos

A comparacin del prototipo anterior, se desarrollaron nicamente dos casos

de uso, considerados los ms importantes de la aplicacin. A continuacin, se
detalla la evaluacin realizada para este modelo, para luego comparar con el
prototipo anterior, y sacar las propias conclusiones.

102

5.2.1 EVALUACIN HEURSTICA DE LA FUNCIONALIDAD

A comparacin del prototipo anterior, este cumple con todas las expectativas
funcionales, establecidas en los casos de uso, a pesar de solamente
implementar dos de ellos. De los siete (7) elementos de men, se encuentran
inhabilitados

tres,

los

cuales

corresponden

futuras

mejoras

implementaciones. A comparacin del prototipo antiguo, este visualmente le

anuncia al usuario, cuales opciones funcionan, y cuales no, por lo que evita la
frustracin de observar fallas. Partiendo del men, el enlace Nuevo Proyecto,
despliega el formulario para el ingreso de la informacin y las instrucciones de
uso. Cada uno de los label del formulario, est relacionado a una pregunta
concreta, cuya respuesta se ingresa en el campo del formulario, evitando las
ambigedades en la terminologa. Luego de aadir un nuevo proyecto, se
observa el diagrama de Gantt correspondiente, y disponible para ingresar o
modificar las actividades. A comparacin del otro, este prototipo, deja una
buena sensacin al usarlo, a pesar de implementar pocos casos de uso.

5.2.2 EVALUACIN POR ESTNDARES DE LA ACCESIBILIDAD

Igualmente, que en la evaluacin del prototipo antiguo, se evalan cada una de
las pautas establecidas en el modelo de la W3C, (ampliamente detallado en los
anexos) y por cada caso de uso, se clasifican tres posibles valores: Cumple
con la pauta, no cumple, o la pauta, en ese caso especfico, no aplica. En este
caso, al ser tan solo dos casos de uso, la prueba result siendo mucho ms
corta y fcil. La siguiente, es la tabla de resultados que arroj la evaluacin de
las pautas de prioridad A:

CU2. Crea el Proyecto

CU3. Diagrama Gantt

Cumple
14
13

Porcentaje
No
Porcentaje
No
Porcentaje
cumple
cumple no cumple aplica no aplica
73,68
0
0,00
5
26,32
73,68
1
5,26
4
21,05

Tabla 12: Tabla del cumplimiento de los estndares de la W3C Prioridad A - Prototipo Nuevo

103

Como se puede observar en la tabla, el caso de uso 2, correspondiente a la

creacin del proyecto, cumple con todas las pautas de la W3C, en el nivel A de
prioridad. Por otro lado, el caso de uso 3, cuya funcin es mostrar el diagrama
de Gantt, cumple con todos, menos con proporcionar un texto equivalente para
todo elemento no textual. Dados estos resultados, se ha de suponer un
aumento significativo en el cumplimiento de las pautas, como lo demuestra la
figura siguiente:

3,45
% cumplimiento A
% incumplimiento A
96,55

Ilustracin 20: Grfico del porcentaje de cumplimiento-incumplimiento de los estndares de la

W3C. Prototipo nuevo.

El nuevo prototipo, cumple con el 96% de las pautas establecidas en el nivel de

prioridad A, lo que implica que la mayora de usuarios con discapacidades
fsicas o temporales, por lo general, no tendrn inconvenientes para acceder a
la aplicacin. Adems, por otro lado, se tiene que el prototipo cumple con un
95% de las especificaciones AA, y solamente ignora un 4.76% de las pautas.

4,76

95,24
% cumplimiento AA

% incumplimiento AA

Ilustracin 21: Grfico del porcentaje de cumplimiento de los estndares de accesibilidad Prioridad AA - Prototipo Nuevo

104

Adems y como se logra observar en la tabla a continuacin, nicamente no

cumple con un estndar, que corresponde a la omisin de los metadatos de los
documentos web, para dar informacin semntica a la aplicacin.
Porcentaje
cumple

Cumple

CU2. Crea el Proyecto

CU3. Generacin del
Diagrama de Gantt

No cumple

% no
cumple

% no se
aplica

No aplica

19

61,29

3,23

11

35,48

21

67,74

3,23

29,03

Tabla 13: Tabla del cumplimiento de los estndares de la W3C Prioridad AA - Prototipo Nuevo

Respecto a las comparaciones entre ambos prototipos, de estos resultados, se

profundizarn con mayor exactitud en el captulo de anlisis.

5.2.3 EVALUACIN GENERAL CON USUARIOS

Igualmente, la evaluacin consiste en el paseo cognitivo con usuarios, sin
mayores variaciones del anterior. Igualmente, para esta prueba, se prob el
desempeo del prototipo con cuatro participantes. En la siguiente tabla, se
resumen los resultados de la evaluacin para el nuevo prototipo:
TOTAL
PAUTAS

Accesibilidad

NO
NO
CUMPLE CUMPLE APLICA

%
% NO
CUMPLE CUMPLE

% NO
APLICA

Funcionalidad

50
20

39
17

6
3

5
0

78,0
85,0

12,0
15,0

10,0
0,0

Diseo
Interaccin
Esttica
Credibilidad
Usabilidad

73
32
16
28

55
28
15
23

13
0
1
4

5
4
0
1

75,3
87,5
93,8
82,1

17,8
0,0
6,3
14,3

6,8
12,5
0,0
3,6

Tabla 14: Tabla resumen de la Evaluacin con usuarios del Prototipo nuevo.

En este caso, se observan cuatro factores de diseo, que tienen una mayor
relevancia en este prototipo: La credibilidad, la esttica, la funcionalidad, y la

105

usabilidad. Muy de cerca, se tiene la accesibilidad, y por ltimo, el diseo de

interaccin.
La confiabilidad se observa de primer lugar, ya que depende directamente de la
funcionalidad y la esttica. Estos dos factores, se puede decir, son claves, ya
que este prototipo busca corregir los errores de funcionalidad, con una
excelente presentacin, implementando pocos casos de uso, pero totalmente
funcionales. Similarmente, y como en el prototipo antiguo, la esttica se
destaca por la correcta combinacin de colores, y la legibilidad del texto.
La usabilidad percibida por el usuario es el cuarto factor dominante en el
prototipo. De nuevo, los usuarios, incluso los ms novatos, consideran que la
aplicacin es fcil de manejar, gracias a su diseo esttico y funcional, pero
an piensan que la aplicacin no agiliza el duro trabajo de gestionar proyectos
de investigacin.
Lastimosamente, no todo es bueno. El prototipo presenta una accesibilidad
percibida mucho menor que la objetiva, medida por los estndares de la W3C.
Esto corresponde a la ausencia de otros idiomas en la interfaz, que puede
dificultar el acceso a la audiencia extranjera, aunque en el mbito del trabajo de
grado, y el modelo propuesto, se considera que no es una prioridad.
A pesar de los grandes avances en el mbito, el diseo de interaccin, por la
ausencia de conos claros que deduzcan las acciones del usuario, el uso de
convenciones establecidas (como el botn cerrar sesin, etc.) a pesar de la
inclusin herramientas que permiten la prediccin del comportamiento del
usuario, completando su trabajo, y disminuyendo la probabilidad de cometer
errores.
Finalmente, comentan que es una gran mejora, pero por lo general, se observa
un trabajo incompleto, an sin todas las funcionalidades planteadas en el
anlisis de requisitos, por lo que la utilidad de la aplicacin, por ahora es bajo.
Por eso califican su experiencia de uso con un valor de 8, en una escala de 10,
y afirman que tal vez recomendaran el uso de la aplicacin a otra persona.
106

A continuacin se ilustran las medidas correspondientes de cumplimiento de

este prototipo, para cada uno de los aspectos evaluados en este trabajo de
grado:
Accesibilidad

Funcionalidad
15,0 0,0

10,0
12,0

78,0

% CUMPLE

% NO CUMPLE

85,0
% NO APLICA

% CUMPLE

Diseo Interaccin

% NO CUMPLE

Esttica

6,8

12,5
0,0

17,8

75,3

% CUMPLE

% NO CUMPLE

87,5
% NO APLICA

% CUMPLE

Credibilidad

14,3

% NO APLICA

3,6

82,1

93,8
% NO CUMPLE

% NO CUMPLE

Usabilidad

6,30,0

% CUMPLE

% NO APLICA

% NO APLICA

% CUMPLE

% NO CUMPLE

% NO APLICA

Tabla 15: Diagramas y Resultados de la Evaluacin con Usuarios de prototipo nuevo

107

5.3 ANLISIS
Los resultados en la evaluacin de la satisfaccin del usuario final, demuestran
que los factores higinicos son los que ms influencian la experiencia del
usuario. Solo basta observar los resultados del prototipo desarrollado como
trabajo de la asignatura Diseo y Construccin de Software, que a pesar de
cumplir con las pautas estticas establecidas, su psima funcionalidad
provocaba un declive en la percepcin del usuario, a tal punto de calificar su
experiencia con el software negativamente.
En el prototipo propuesto en la realizacin de este trabajo de grado, se observa
un amplio margen de mejora, al implementar los conceptos y estrategias clave
que incrementan la percepcin de cada aspecto. Por ejemplo, funcionalmente,
desde el desarrollo de software, se evitaron los enlaces rotos, y se evaluaron
las respuestas del sistema ante cada accin planteada en los casos de uso,
para lograr aumentar los factores percibidos por el usuario respecto al
funcionamiento, del 10 al 85 por ciento.
Por otro lado, se obtienen mejoras significativas en la accesibilidad percibida,
que pas del 62 al 78 por ciento, a pesar de ser menor que la accesibilidad
objetiva, medida a travs de los estndares de la W3C.
Quizs el diseo de la interaccin, fue el rea en la que se generaron ms
cambios en comparacin al prototipo inicial. Se implement un sistema de
errores para informar posibles fallas, se corrigieron los nombres de men, se
describen claramente cada uno de los campos de formulario, y se
implementaron herramientas para predecir el comportamiento del usuario, para
disminuir la probabilidad de cometer errores, a tal punto de mejorar la
satisfaccin en la experiencia de usuario en este aspecto, de un 35 a un 75 por
ciento.
El nico aspecto que disminuy, respecto al prototipo inicial, fue el diseo
visual y esttico, que pas del 90 al 87 por ciento. La causa principal de este

108

descenso, es el aumento significativo de la accesibilidad u la usabilidad de la

aplicacin, lo que

disminuye notablemente las formas estticas, los

redondeados, las sombras y degradados que tanto influyen en la percepcin de

una aplicacin.

109

CONCLUSIONES
A partir de un extenso anlisis bibliogrfico, desde la Interaccin HumanoComputador, se establecen siete aspectos que influyen en el diseo de las
aplicaciones web, para asegurar una buena experiencia de usuario utilidad,
funcionalidad, accesibilidad, diseo de interaccin, confiabilidad, el diseo
visual, y la usabilidad-. Estos principios, estn ntimamente relacionados, e
incluyen componentes ntimamente emocionales y subjetivos, los cuales fueron
definidos, estudiados, y aplicados a la metodologa de anlisis, diseo, y
construccin de productos de software, por medio de la implementacin de un
prototipo que maximice la probabilidad de que el usuario posea una experiencia
satisfactoria.
Por eso, el modelo de evaluacin propuesto, basado en el mbito de este
trabajo de grado, con base a la investigacin y la bibliografa, definen ciertas
reglas que mejoraran la experiencia de usuario en las aplicaciones
desarrolladas para la web. Partiendo de las reglas, y los estndares
establecidos en algunos mbitos, (como la accesibilidad), se observa un
incremento en la satisfaccin de uso del prototipo propuesto, con respecto al
prototipo realizado en la asignatura de Diseo de Software.
As,

se

deduce

fundamentalmente

que

al

acceder

evaluar
a

la

una

aplicacin,

aplicacin

web,

el

usuario,

luego

busca

explorar

su

funcionalidad e interaccin que le ofrece, motivado inicialmente por un buen

diseo esttico, para despus experimentar su facilidad-dificultad de uso, lo
que finalmente genera credibilidad-frustracin en el software.
Finalmente, se demuestra que la aplicacin de estos aspectos desde la
experiencia de usuario, mejoran la percepcin de la aplicacin, representada
subjetivamente en la credibilidad y confiabilidad, ya que, al fin y al cabo, este es
el objetivo principal de la calidad, desde el anlisis, desarrollo y construccin de
software.

110

Y ste, es solo el comienzo

Algunos aspectos a tener en cuenta para la continuacin y mejoramiento de
esta investigacin, son:
El estndar de medicin de la accesibilidad de los sitios web, fue modificado
recientemente en su versin 2.0, lo que implica una nueva metodologa de
evaluacin de este aspecto, por lo que sera conveniente actualizar tambin las
mediciones de este trabajo de grado.
Adems, tambin, se podra realizar un manejo estadstico de los datos
obtenidos con las evaluaciones y as, poder manejar las desviaciones
significativas de los datos.

Tambin, se puede unir metodolgicamente el desarrollo de software, con el

rea de Interaccin Humano-Computador, de tal forma que tenga en cuenta los
aspectos ms destacados, presentados en este trabajo de grado, desde la
misma experiencia de usuario, aplicados a la Ingeniera de Software, lo que
implicara la cuantificacin y medicin de los factores de diseo, cuya relacin
es compleja y algunos son puramente subjetivos, teniendo en cuenta la
conformacin de equipos interdisciplinarios que permitan desarrollar productos
ms satisfactorios.
Considero que esta rama del conocimiento, posee diversas aplicaciones, y esta
investigacin apenas es la punta del iceberg (si, as como el iceberg de la
usabilidad) de innumerables estudios.

111

BIBLIOGRAFA

Arango, F., & Zapata, C. (2006). UN-Mtodo para la Elicitacin de Requisitos

de Software. Medelln: Escuela de Sistemas de la Universidad Nacional
de Colombia.
Bailey, R., Molich, R., Dumas, J., & Spool, J. M. (2002). Usability in Practice:
Formative Usability Evaluations. CHI2002.
Bass, L., Clements, P., & Kazman, R. (2003). Software Architecture in Practice.
Boston : Addison-Wesley.
Bengts, M. (2004). Usability as a constituent of end-user satisfaction. Masters
thesis in Information.
Bennett, J. L. (1979). The comercial impact of usability in interactive systems.
Infotech.
Berry, D. (01 de Octubre de 2000 ). The user experience: The iceberg analogy
of usability. Recuperado el 17 de Octubre de 2011, de IBM
Developerworks: http://www.ibm.com/developerworks/library/w-berry/
Bevan, N., Kirakowski, J., & Maissel, J. (Septiembre de 1991). What is
Usability? Recuperado el Octubre de 2011, de
www.nigelbevan.com/papers/whatis92.pdf
Catalua, U. d. (2011). Introduccin a la Usabilidad y su Evaluacin. Catalua:
Universidad de Catalua.
Ceaparu, e. a. (2004). Determining Causes and Severity of End-User
Frustration. International Journal of Human-Computer Interaction, 333356.
Constantine, L., & Loockwood, L. (1999). Software for Use: A Practical guide to
the Models and Methods of Usage-Centered Design. Addison - Wesley.
D'Hertefelt, S. (02 de Febrero de 2000). Emerging and future usability
challenges: designing user experiences and user communities.
Recuperado el 23 de Enero de 2012, de Interaction Architect:
http://www.interactionarchitect.com/future/vision20000202shd.htm

112

Digital Equipment Corporation. (1986). User-derived impact analysis as a tool

for usability engineering. Proceedings of Human Factors in Computing
Systems. Nueva York: ACM.
Dillon, A., & Morris, M. (1999). Power, Perception and Performance: From
Usability Engineering to Technology Acceptance with the P3 Model of
User Response. Human Factors and Ergonomics Society 43rd Annual
Meeting. Houston, TX.
Ferr, X., Juristo, N., Windl, H., & Constantine, L. (2001). Usability basics for
software developers. IEEE Software, 22-29.
Folmer, E., & Bosch, J. (2004). Architecting for Usability. Journal of Systems
and Software, 6178.
Fu, L., & Salvendy, G. (2002). The contribution of apparent and inherent
usability to user's satisfaction in a search and browsing task on the web.
Ergonomics, 415-424.
Garrett, J. J. (2011). The Elements of User Experience: User-Centered Design
for the Web ans Beyond. Berkeley, California, USA: New Riders.
Ghezzi, C. (1991). Fundamentals of Software Engineering. Prentice-Hall.
Gomaa, H. (2011). Software Modeling & Design. Cambridge.
Grady, R. (1994). Succesfully Applying Software Metrics. Computer Vol.27, 1825.
Granollers, T. (2004). Tesis Doctoral: Una Metodologa que Integra la
Ingeniera del Software, la Interaccin Persona-Ordenador y la
Accesibilidad en el Contexto de Equipos de Desarrollo Multidisciplinares
MPIu+a. Lleida: Universitat de Lleida.
Hassan, Y. (2006). Factores del diseo web orientado a la satisfaccin y nofrustracin de uso. Revista Espaola de Documentacin Cientfica, 239257.
Hassan, Y., & Martn, F. J. (2003). Que es la Accesibilidad Web. Recuperado el
3 de Septiembre de 2010, de No solo usabilidad:
http://www.nosolousabilidad.com/articulos/accesibilidad.htm
Hassan, Y., Martin, F., & Iazza, G. (2004). Diseo Web Centrado en el Usuario:
Usabilidad y Arquitectura de la Informacin.

113

Heijden, H. V. (2003). Factors Influencing the Usage of Websites. Information

and Management, 541-549.
Heller, E. (2005). Psicologa del Color. Munich: Droemer Verlag.
Hilbert, D., & Redmiles, D. (1999). Extracting Usability Information from User
Interface Events. Department of Information and Computer Science,
University of California, 399.
Internet World Stats. (11 de Octubre de 2011). World Internet Usage Stadistics.
Recuperado el 17 de Octubre de 2011, de
http://internetworldstats.com/stats.htm
ISO. (1991). Software engineering - Product quality.
ISO. (1998). 9241 - Ergonomic Requirements for Office Work with Visual
Display Terminals.
ISO. (2001). ISO 13407 - Human Centered Design Processes for Interactive
Systems.
Kotonya, G., & Sommerville, I. (1997). Requirements Engineering. Processes
and Techniques. JohnWiley.
Krug, S. (2006). No me hagas pensar: Una aproximacin a la Usabilidad en la
Web. Prentice Hall.
Kurosu, M., & Kashimura, K. (1995). Apparent Usability vs. Inherent Usability
Experimental analysis on the determinants of the apparent usability.
Recuperado el 8 de Enero de 2012, de CHI '95 Proceedings Short
Papers: http://www.sigchi.org/chi95/proceedings/shortppr/mk_bdy.htm
Laviea, T., & Tractinsky, N. (2004). Assesing Dimensions of Perceived Visual
Aesthetics of Web Sites. Internationa Journal of Human Computer
Studies, 269-298.
Lingaard, G., & Dudek, C. (2003). What is this evasive beast we call user
satisfaction? Interacting with Computers, 429-452.
Mack, R., & Nielsen, J. (1994). Usability Inspection Methods. Nueva York:
Wiley.
Manchn, E. (17 de Junio de 2002). Esttica, usabilidad y emocin en el
diseo. Recuperado el 14 de Diciembre de 2011, de Alzado.org:
http://www.alzado.org/articulo.php?id_art=60

114

Margotte, E. (2011). Responsive Web Design. New York: A Book Apart.

Mayhew, D. (1999). The Usability Engineering Lifecycle. San Francisco:
Kaufmann.
Netcraft. (1 de Diciembre de 2010). December 2010 Web Server Survey.
Recuperado el 10 de Septiembre de 2011, de
http://news.netcraft.com/archives/2010/12/01/december-2010-webserver-survey.html
Nielsen J. (1994). Ten Usability Heuristics. Recuperado el 02 de Septiembre de
2011, de Useit.com:
http://www.useit.com/papers/heuristic/heuristic_list.html
Nielsen, J. (1993). Usability Engineering. Academic Press.
Nielsen, J. (1994). Enhancing the explanatory power of usability heuristics.
SIGCHI conference on Human factors in computing systems.
Nielsen, J. (2001). Usabilidad: Diseo de Sitios Web. Pearson Education.
Norman, D. (1988). La psicologia de los objetos cotidianos. Nerea.
Norman, D. (2002). Emotion and Design: Attractive things work better.
Interactions, 36-42.
Norman, D. (2004). Emotional Design. Nueva York: Basic Books.
Norman, D. (2004). Emotional Design, Why we love (or hate) everyday things?
Nueva York: Basic Books.
Percepcin. (s.f.). Recuperado el 24 de Enero de 2012, de Estudio del
psicoanlisis y psicologa: http://psicopsi.com/PERCEPCION-1
Pressman, R. (2000). Ingeniera de Software . McGraw-Hill.
Pressman, R. S. (1998). Software Engineering. McGraw-Hill.
Rankin, I. (04 de Septiembre de 2005). Introduction to Software Testing. QES
Inc.
Reimann, R. (s.f.). Recuperado el 24 de Enero de 2012, de
http://www.ixda.org/node/23600
Rowley, D., & Rhoades, D. (1992). The Cognitive Jogthrough: A Fast-Paced
User Interface Evaluation Procedure. CHI, (pgs. 389-395).

115

Sauro, J., & Kindlund, E. (2005). A Method to Standardize Usability Metrics Into
a Single Score. CHI 2005, (pgs. 401-409). Portland.
Shackel, B. (1991). Usability context, framework, definition, design and
evaluation. Cambridge University Press.
Standardisation, I. O. (2001). ISO 9241 Ergonomic, Part 11: Guidance on
usability. Ginebra.
Tognazzini, B. (1998). First Principles of Interaction Design. Recuperado el 31
de Enero de 2012, de Bruce Tognazzini:
http://www.asktog.com/basics/firstPrinciples.html
Tractinsky , N. (1997). Aesthetics and Apparent Usability: Empirically Assessing
Cultural and Methodological Issues. Recuperado el 10 de Enero de
2012, de CHI 97 Electronic Publications: Papers:
http://www.sigchi.org/chi97/proceedings/paper/nt.htm
Tufte, E. (s.f.). Presenting Data and Information. Recuperado el 6 de Enero de
2012, de Edward Tufte Web Page.:
http://www.edwardtufte.com/tufte/courses
UsabilityNet European Union Project. (2001-2003). UsabilityNet European
Union Project. Recuperado el 4 de Agosto de 2011, de
www.usabilitynet.org
Veer, G., Lenting, B., & Bergevoet, B. (1996). GTA: Groupware Task Analysis Modeling Complexity. Acta Psychologica, 297-322.
W3C - WCAG 1.0 . (s.f.). Pautas de Accesibilidad al Contenido en la Web Versin 1.0. Recuperado el 14 de Octubre de 2011, de
http://www.w3.org/WAI/: http://www.w3.org/WAI/
Zambonini, D. (2011). A Practical Guide to Web App Success. Londres: Five
Simple Steps.
Zapata, C. M. (2011). Introduccin a la calidad de software. Presentaciones de
clase - Calidad de Software. Medelln: Universidad Nacional de
Colombia.
Zhang, P., & Dran, G. (2000). Satisfiers and Dissatisfiers: A Two-Factor Model
forWebsite Design and Evaluation. Journal of the American Society for
Information, 1253-1268.

116

ANEXOS
ANEXO A: ELEMENTOS DE LA EXPERIENCIA DE USUARIO

Ilustracin 22: Elementos de la Experiencia de Usuario (Grfico Resumen)

117

ANEXO B - ESQUEMA GENERAL DE LA METODOLOGA UN-MTODO

Ilustracin 23: Esquema General de la Metodologa UN-Mtodo. Tomado de: (Arango, F; Zapata, C, M; 2006)

118

ANEXO C: PROPUESTA DE SOLUCIN CREATIVA CON UN-MTODO

Ilustracin 24: Diagrama de Causa-Efecto, cuyas causas (en rojo) se satisfacen con la solucin propuesta.

119

ANEXO D EVALUACIN DE LAS PAUTAS DE ACCESIBILIDAD EN LA WEB, SEGN LA WCAG VERSIN 1.0
Puntos de Verificacin Prioridad 1 - A
Punto de Verificacin
1.1 La aplicacin proporciona un texto equivalente para todo elemento no textual? (por
ejemplo, a travs de "alt", "longdesc" o en el contenido del elemento). Esto incluye:
imgenes, representaciones grficas del texto, mapas de imagen, animaciones (por
ejemplo, GIFs animados), "applets" y objetos programados, "ascii art", marcos, scripts,
imgenes usadas como vietas en las listas, espaciadores, botones grficos, sonidos
(ejecutados con o sin interaccin del usuario), archivos exclusivamente auditivos, banda
sonora del vdeo y vdeos
2.1 La informacin transmitida a travs de los colores tambin est disponible sin color, por
ejemplo mediante el contexto o por marcadores.
4.1 La aplicacin o el sitio permiten cambios en el idioma del texto del documento y en
cualquier texto equivalente (Por ejemplo, leyendas).
6.1 El documento puede ser ledo sin hoja de estilo CSS? Por ejemplo, cuando un
documento HTML es interpretado sin asociarlo a una hoja de estilo, tiene que ser posible
leerlo.
6.2 Los contenidos dinmicos son actualizados cuando cambia el contenido dinmico.
7.1 La aplicacin provoca destellos en la pantalla?
14.1 Se utiliza un lenguaje claro ms claro y simple para el contenido?
Si se utilizan imgenes y mapas de imagen (Prioridad 1)
1.2 La aplicacin proporciona vnculos redundantes en formato texto para cada zona
activa de un mapa de imagen del servidor?
9.1 Se proporcionan los correspondientes mapas de imagen, controlados por el cliente en
lugar de por el servidor, excepto donde las zonas sensibles no puedan ser definidas con
una forma geomtrica?
Y si utiliza tablas (Prioridad 1)
5.1 En las tablas de datos, identifique los encabezamientos de fila y columna.
120

SI

NO

N/A

SI

NO

N/A

SI

NO

N/A

Y si utiliza marcos ("frames") (Prioridad 1)

5.2 Para las tablas de datos que tienen dos o ms niveles lgicos de encabezamientos de
fila o columna, utilice marcadores para asociar las celdas de encabezamiento y las celdas
de datos.
12.1 Titule cada marco para facilitar su identificacin y navegacin de los mismos.
Y si utiliza "applets" y "scripts" (Prioridad 1)
6.3 Asegrese de que las pginas sigan siendo utilizables cuando se desconecten o no se
soporten los scripts, applets u otros objetos programados. Si esto no es posible,
proporcione informacin equivalente en una pgina alternativa accesible.
Y si utiliza multimedia (Prioridad 1)
1.3 Hasta que las aplicaciones de usuario puedan leer automticamente el texto
equivalente de la banda visual, proporcione una descripcin auditiva de la informacin
importante de la banda visual de una presentacin multimedia.
1.4 Para toda presentacin multimedia tempo-dependiente (por ejemplo, una pelcula o
animacin) sincronice alternativas equivalentes (por ejemplo, subttulos o descripciones de
la banda de visual) con la presentacin.
Y si todo lo dems falla (Prioridad 1)
11.4 Si, despus de los mayores esfuerzos, no puede crear una pgina accesible,
proporcione un vnculo a una pgina alternativa que use tecnologas W3C, sea accesible,
tenga informacin (o funcionalidad) equivalente y sea actualizada tan a menudo como la
pgina (original) inaccesible.

SI

NO

N/A

SI

NO

N/A

SI

NO

N/A

SI

NO

N/A

NO

N/A

Tabla 16: Resumen de las Pautas de Accesibilidad establecidas por la W3C de prioridad 1 (A) (WCAG 1.0)

Puntos de Verificacin Prioridad 2 - AA

Punto de Verificacin
2.2 Asegrese de que las combinaciones de los colores de fondo y primer plano tengan
suficiente contraste para que sean percibidas por personas con deficiencias de percepcin
de color o en pantallas en blanco y negro.

121

SI

3.1 Cuando exista un marcador apropiado, use marcadores en vez de imgenes para
transmitir la informacin.
3.2 Cree documentos que estn validados por las gramticas formales publicadas.
3.3 Utilice hojas de estilo para controlar la maquetacin y la presentacin.
3.4 Utilice unidades relativas en lugar de absolutas al especificar los valores en los atributos
de los marcadores de lenguaje y en los valores de las propiedades de las hojas de estilo.
3.5 Utilice elementos de encabezado para transmitir la estructura lgica y utilcelos de
acuerdo con la especificacin.
3.6 Marque correctamente las listas y los tems de las listas.
3.7 Marque las citas. No utilice el marcador de citas para efectos de formato como sangras.
6.5 Asegrese de que los contenidos dinmicos son accesibles o proporcione una pgina o
presentacin alternativa.
3.6 Marque correctamente las listas y los tems de las listas.
3.7 Marque las citas. No utilice el marcador de citas para efectos de formato tales como
sangras.
6.5 Asegrese de que los contenidos dinmicos son accesibles o proporcione una pgina o
presentacin alternativa.
2.2 Asegrese de que las combinaciones de los colores de fondo y primer plano tengan
suficiente contraste
7.2 Hasta que las aplicaciones de usuario permitan controlarlo, evite el parpadeo del
contenido (por ejemplo, cambio de presentacin en periodos regulares, as como el
encendido y apagado).
7.4 Hasta que las aplicaciones de usuario proporcionen la posibilidad de detener las
actualizaciones, no cree pginas que se actualicen automticamente de forma peridica.
7.5 Hasta que las aplicaciones de usuario proporcionen la posibilidad de detener el
redireccionamiento automtico, no utilice marcadores para redirigir las pginas
automticamente. En su lugar, configure el servidor para que ejecute esta posibilidad.
10.1 Hasta que las aplicaciones de usuario permitan desconectar la apertura de nuevas
ventanas, no provoque apariciones repentinas de nuevas ventanas y no cambie la ventana

122

actual sin informar al usuario.

11.1 Utilice tecnologas W3C cuando estn disponibles y sean apropiadas para la tarea y
use las ltimas versiones que sean soportadas.
11.2 Evite caractersticas desaconsejadas por las tecnologas W3C.
12.3 Divida los bloques largos de informacin en grupos ms manejables cuando sea
natural y apropiado.
13.1 Identifique claramente el objetivo de cada vnculo.
13.2 Proporcione metadatos para aadir informacin semntica a las pginas y sitios.
13.3 Proporcione informacin sobre la maquetacin general de un sitio (por ejemplo, mapa
del sitio o tabla de contenidos).
13.4 Utilice los mecanismos de navegacin de forma coherente.
Y si utiliza tablas (Prioridad 2)
5.3 No utilice tablas para maquetar, a menos que la tabla tenga sentido cuando se
transcriba lnea a lnea. Por otro lado, si la tabla no tiene sentido, proporcione una
alternativa equivalente (la cual debe ser una versin linearizada).
5.4 Si se utiliza una tabla para maquetar, no utilice marcadores estructurales para realizar
un efecto visual.
Y si utiliza marcos ("frames") (Prioridad 2)
12.2 Describa el propsito de los marcos y como stos se relacionan entre s, si no resulta
obvio solamente con el ttulo del marco.
Y si utiliza formularios (Prioridad 2)
10.2 Hasta que las aplicaciones de usuario soporten explcitamente la asociacin entre
control de formulario y etiqueta, para todos los controles de formularios con etiquetas
asociadas implcitamente, asegrese de que la etiqueta est colocada adecuadamente.
12.4 Asocie explcitamente las etiquetas con sus controles.
Y si utiliza Applets o Scripts (Prioridad 2)
6.4 Para los scripts y applets, asegrese de que los manejadores de evento sean
independientes del dispositivo de entrada.
7.3 Hasta que las aplicaciones de usuario permitan congelar el movimiento de los
123

SI

NO

N/A

SI

NO

N/A

SI

NO

N/A

SI

NO

N/A

contenidos, evite los movimientos en las pginas.

8.1 Haga los elementos de programacin, tales como scripts y applets, directamente
accesibles o compatibles con las ayudas tcnicas. [Prioridad 1 si la funcionalidad es
importante y no se presenta en otro lugar; de otra manera, Prioridad 2].
9.2 Asegrese de que cualquier elemento que tiene su propia interfaz pueda manejarse de
forma independiente del dispositivo.
Tabla 17: Resumen de las Pautas de Accesibilidad establecidas por la W3C de prioridad 1 (AA) (WCAG 1.0)

Puntos de Verificacin Prioridad 3 - AAA

Punto de Verificacin
4.2 Especifique la expansin de cada abreviatura o acrnimo cuando aparezcan por
primera vez en el documento.
4.3 Identifique el idioma principal de un documento.
9.4 Cree un orden lgico para navegar con el tabulador a travs de vnculos, controles de
formulario y objetos.
9.5 Proporcione atajos de teclado para los vnculos ms importantes (incluidos los de los
mapas de imagen de cliente), los controles de formulario y los grupos de controles de
formulario.
10.5 Hasta que las aplicaciones de usuario (incluidas las ayudas tcnicas) interpreten
claramente los vnculos contiguos, incluya caracteres imprimibles (rodeados de espacios),
que no sirvan como vnculo, entre los vnculos contiguos.
11.3 Proporcione la informacin de modo que los usuarios puedan recibir los documentos
segn sus preferencias (Por ejemplo, idioma, tipo de contenido, etc.)
13.5 Proporcione barras de navegacin para destacar y dar acceso al mecanismo de
navegacin.
13.6 Agrupe los vnculos relacionados, identifique el grupo (para las aplicaciones de

124

SI

NO

N/A

usuario) y, hasta que las aplicaciones de usuario lo hagan, proporcione una manera de
evitar el grupo.
13.7 Si proporciona funciones de bsqueda, permita diferentes tipos de bsquedas para
diversos niveles de habilidad y preferencias.
13.8 Localice al principio de los encabezamientos, prrafos, listas, etc, la informacin que
los diferencie.
13.9 Proporcione informacin sobre las colecciones de documentos (por ejemplo, los
documentos que comprendan mltiples pginas).
13.10 Proporcione un medio para saltar sobre un dibujo ASCII art de varias lneas.
14.2 Complemente el texto con presentaciones grficas o auditivas cuando ello facilite la
comprensin de la pgina.
14.3 Cree un estilo de presentacin que sea coherente en todas las pginas.
Y si utiliza imgenes o mapas de imagen (Prioridad 3)
1.5 Hasta que las aplicaciones de usuario interpreten el texto equivalente para los vnculos
de los mapas de imagen de cliente, proporcione vnculos en formato texto redundantes para
cada zona activa del mapa de imagen de cliente.
Y si utiliza tablas (Prioridad 3)
5.5 Proporcione resmenes de las tablas.
5.6 Proporcione abreviaturas para las etiquetas de encabezamiento.
10.3 Hasta que las aplicaciones de usuario (incluidas las ayudas tcnicas) interpreten
correctamente los textos contiguos, proporcione un texto lineal alternativo (en la pgina
actual o en alguna otra) para todas las tablas que maquetan texto en paralelo, columnas
envoltorio de palabras.
Y si utiliza formularios (Prioridad 3)

SI

NO

N/A

SI

NO

N/A

SI

NO

N/A

10.4 Hasta que las aplicaciones de usuario manejen correctamente los controles vacos,
incluya caracteres por defecto en los cuadros de edicin y reas de texto.
Tabla 18: Resumen de las Pautas de Accesibilidad establecidas por la W3C de prioridad 1 (AAA) (WCAG 1.0)

125

ANEXO E - TAMAOS DE PANTALLA MS COMUNES

Ilustracin 25: Resolucin de Pantalla de Dispositivos ms comunes.

126

ANEXO F - LEGIBILIDAD DE LOS TEXTOS SEGN SU COLOR

Ilustracin 26: Cuadro explicativo de la Legibilidad del Texto segn su color Por: Eva Heller

ANEXO G - RELACIN FACTORES DE DISEO- ROLES PROFESIONALES

Factor
Funcionalidad
Accesibilidad
Diseo de Interaccin
Utilidad
Esttica
Credibilidad
Usabilidad

Responsable profesional
Programador o desarrollador web
Experto - Auditor de Accesibilidad
Diseador de Interaccin
Equipo de desarrollo
Diseador visual o grfico
Todo el equipo de desarrollo
Experto Diseador de Interaccin

Tabla 19: Relacin entre los factores de diseo, y los roles profesionales

127

ANEXO H METODOLOGAS DE LA INGENIERA DE USABILIDAD

Para complementar la informacin depositada en la tabla que describe las

diferentes metodologas utilizadas por la Ingeniera de la Usabilidad, este
anexo presenta de manera ms detallada, cada uno de los aspectos
destacados de cada mtodo

MODELO PROPUESTO POR JAKOB NIELSEN

Jakob Nielsen fue quien introdujo el trmino de la Usabilidad (o como mnimo
fue quien lo difundi masivamente y supo comercializarlo mejor) al mundo de
las aplicaciones interactivas, y como era de esperar fue el primero en proponer
una metodologa para el desarrollo de aplicaciones usables. En la siguiente
figura, podemos observar el ciclo de vida de la Ingeniera de la Usabilidad que
propone:

Ilustracin 27: Modelo detallado de la metodologa de Jakob Nielsen

El modelo definido por Nielsen, ms que una metodologa supone la primera

enumeracin de las actividades necesarias para ser capaces de desarrollar

128

sistemas interactivos con la componente Usabilidad (y consecuentemente los

usuarios) en el centro del problema. La parte de la evaluacin del sistema
recoge una gran diversidad de mtodos, pero se fundamenta especialmente
con el mtodo conocido como evaluacin heurstica.

METODOLOGA DUTCH
El mtodo o modelo DUTCH, Designig far Users and Tasks fram Cancepts ta
Handles, fue desarrollado por el grupo de investigadores de la seccin de
Cestin de la Informacin e Ingeniera del Software de la Universidad de Vrije
(Amsterdam), liderada por el Dr. Cerrit van der Veer.
Sus autores lo definen como un mtodo de diseo de sistemas interactivos,
cuya base es el desarrollo de prototipos incrementales que conducen
gradualmente a la implementacin del sistema final; el prototipo realizado en
un ciclo es considerado como una nueva visin del sistema y, tras su
evaluacin, se convierte en el punto de partida del siguiente ciclo. Este modelo
da mucha importancia a disponer en los equipos de desarrollo de personas
provenientes de las disciplinas provenientes del campo de las humanidades,
de varias ingenieras y del diseo grfico.
El mtodo comienza analizando a los usuarios y las tareas que stos realizan
en una situacin actual (si sta existe), analizando futuros usos y usuarios,
involucrando a estos usuarios, a los implicados en el sistema a disear, as
como a los clientes receptores de dicho diseo. Intenta modelar entornos
complejos donde personas diversas interactan con sistemas interactivos,
considerando necesarios tres puntos de vista para modelar el marco de trabajo
de cualquier aplicacin: Las personas (usuarios y grupos de usuarios), el
trabajo y la situacin. Las actividades de estos tres puntos de vista se
estructuran en dos categoras de modelos: El Modelo de Tareas 1 (MT1) y el
Modelo de Tareas 2 (MT2). El MT1 representa el modelado de las tareas de la
129

"situacin actual" (entendiendo que la situacin actual es distinta para cada

nuevo ciclo) y engloba la estructura organizativa actual, incluyendo los objetos
y las tecnologas utilizadas y disponibles. Por su parte, el MT2 modela el
dominio de tareas correspondiente a una "situacin futura" en la que se
incluyen los cambios en la organizacin de estructura personal y los nuevos
procedimientos a seguir para el sistema a desarrollar. La relacin entre el MT1
y el MT2 refleja "el cambio" que supone implementar el nuevo sistema. En la
ilustracin se pueden observar las relaciones anteriormente nombradas:

Ilustracin 28: Esquema de la metodologa DUTCH - Ingeniera de Usabilidad

EL CICLO DE VIDA DE LA INGENIERA DE LA USABILIDAD

Este marco de trabajo distingue tres fases de desarrollo principales que son: la
fase del anlisis de requisitos, la fase del diseo, prueba y desarrollo y la fase
de la instalacin.
130

La segunda fase est a su vez dividida en tres subfases o niveles, que son el
diseo del modelo conceptual, el diseo de la pantalla y el diseo detallado de
la interfaz de usuario, teniendo las tcnicas de prototipado y de evaluacin
"integradas" dentro de cada una de ellas.
Todas las fases, excepto el anlisis de requisitos, incluyen actividades de
valoracin final que formalizan la iteracin al modelo. Una vez se alcanza el
final de cada fase (o subfase), se formula una pregunta para analizar la
consecucin o no del objetivo propuesto en la correspondiente fase y slo est
permitido pasar a la prxima fase si la respuesta a dicha pregunta es
verdadera.

Ilustracin 29: Ciclo de Vida de la Ingeniera de Usabilidad propuesto por D.J. Mayhew

Las tres columnas centrales, correspondientes a las fases o niveles del diseo
(diseo del modelo conceptual, diseo de la pantalla y el diseo detallado de la
131

interfaz del usuario), incluyen adems una valoracin combinada acerca de la

consecucin o no de la funcionalidad del sistema. Si esta valoracin no se
satisface el proceso retorna a la fase de anlisis de requisitos.
Cada una de las etapas tiene una serie de "salidas" en forma de documentos
que aglutinan el resultado final de la fase. As, del anlisis de requisitos se
obtiene una lista con los objetivos de la usabilidad aplicados al sistema a
desarrollar y la primera versin de la gua del estilo a seguir, gua de estilo que
ser modificada o ampliada al final de los niveles 1 y 2 de la parte de diseo,
prueba y desarrollo.
La filosofa general del ciclo de vida, segn la propia autora, se sostiene sobre
los siguientes principios:

El diseo de la interfaz del usuario es un punto clave.

La integracin de la Ingeniera del Software con la de la Usabilidad debe
ser adaptada ("hecha a medida").

El esfuerzo realizado durante el anlisis de requisitos es enteramente

compensado en el producto final.

El diseo puede conseguirse siguiendo un proceso de arriba hacia abajo

(top-down) estructurado.

El diseo, la prueba y el desarrollo deben realizarse iterativamente.

El ciclo de vida completo puede conseguirse a travs de subconjuntos de
funcionalidades.

Existe una amplia variedad de tcnicas para llevar a cabo cada tarea del
ciclo de vida.

El uso de tcnicas alternativas hacen el ciclo de vida flexible y adaptable.

La implementacin ptima del ciclo de vida requiere la completa
participacin de equipos multifuncionales (interdisciplinarios).

132

MODELO MPIU+a
El esquema est organizado en una serie de fases cada nodo del esquema
corresponde a una de estas fases que repetitivamente irn realizndose
durante el desarrollo de un determinado sistema interactivo. Veremos a
continuacin el objetivo de cada una de estas fases y las actividades que en
cada una de ellas pueden o deben ejecutarse. El criterio seguido para explicar
cada una de las fases es el siguiente: Primero se explican las columnas de fase
nica concernientes al prototipo y a la evaluacin para posteriormente entrar en
el detalle de las fases de la primera columna (que como se ha mencionado
corresponde a un ciclo de vida de la IS). La razn de esta decisin se debe a
que tanto el prototipo como la evaluacin son aspectos primordiales en todo
diseo de sistemas centrado en el usuario e inevitablemente se hace
continuada referencia al explicar el resto de fases y sus actividades
relacionadas.

Ilustracin 30: Modelo por fases del MPIU+a

Desde que se empieza el desarrollo de un sistema interactivo necesitamos

probar

partes

del

mismo

con

multitud

133

de

objetivos

para:

Verificar

funcionalidades, averiguar aspectos relacionados con la interfaz del sistema

(posicin de controles, textos, colores), validar la navegacin, probar nuevas
posibilidades tcnicas, etc.
Es impensable llegar al final del desarrollo sin haber realizado comprobaciones
a lo largo del camino. Los prototipos son precisamente el mecanismo que
permite realizar estas comprobaciones. Los prototipos, que son documentos,
diseos o sistemas que simulan o tienen implementadas partes del sistema
final, constituyen una herramienta muy til para, como es nuestra intencin,
hacer participar al usuario en el desarrollo y poder evaluar el producto desde
las primeras fases del desarrollo.
El MPIu+a no marca ninguna pauta para indicar a los diseadores en qu
situaciones debern recurrir al uso de una determinada o determinadas
tcnicas para simular el funcionamiento. Tampoco los limita a poder realizar un
primer prototipo en una fase muy inicial del proyecto. El modelo intenta
garantizar que se cumplan los pasos necesarios para disponer de un producto
altamente usable y accesible a la vez que concede un alto grado de libertad
para que el equipo de desarrollo libremente decida cundo y cmo deber
aplicar las diferentes tcnicas.
En las aproximaciones del Diseo Centrado en el Usuario (DCU), los prototipos
constituyen mucho ms que simples demostraciones del producto; se utilizan
para recoger las impresiones del usuario para repercutirlas en el diseo de la
interfaz.

134

ANEXO I: CASOS DE USO ASOCIADOS AL PROTOTIPO

Caso de Uso

CU1. Programar reuniones de supervisin

Versin

Autor

Grupo6

Fecha

Fuente
Propsito

Seguimiento a los proyectos

Objetivo

Se resuelven:

Resumen

Actores
Precondicin
Secuencia de
interacciones

C4. Falta de asesora a los investigadores en la ejecucin de los proyectos

El comit de supervisin, revisa el informes de avance y presupuesto,
y de acuerdo a estos solicita al sistema que programe una reunin de
acuerdo a la disponibilidad del grupo de investigacin y del comit de
supervisin
Investigador y el comit de supervisin
P17. Generacin de alerta por incumplimiento de plazo anomalas en P20.
Revisin de informes avance y presupuesto
Grupo de investigacin

Consulta en la base datos tiempo

disponible, tanto para el investigador
como para el comit de supervisin.

Programa reuniones

4
5

Sistema

Enva al
Correo del grupo de
investigacin, una notificacin de
fechas tentativas listas.
Ingresa al sistema, a la seccin
reuniones.
Acepta fechas

El sistema enva notificacin de

reunin al comit de supervisin y al
grupo de investigacin

Secuencia alternativa

5
Demora

Rechaza fechas

Propone Nuevas fechas

El tiempo ptimo, consiste en que el sistema obtenga las fechas optimas de

acuerdo a la disponibilidad registradas en el sistema.

135

Frecuencia
Tipo

La frecuencia de este caso de uso depende, de la calidad del trabajo de los

grupos de investigacin.
Primario.

Postcondicione Reunin concertada entre el grupo de investigacin y el comit de

s
supervisin
Grfico

Interaccin

Programar reuniones de supervisin

Actores

Comit supervisor

Resumen

El sistema programa las reuniones de supervisin, para esto toma en

cuenta la disponibilidad de tiempo de los investigadores.

Secuencia de
interacciones

Secuencia Normal
1. Sistema -> Enva al
Correo del grupo de investigacin, una
notificacin de fechas tentativas listas.
2. Grupo de investigacin-> Ingresa al sistema, a la seccin reuniones.
3. Sistema -> Muestra horario tentativo de reunin
4. Grupo de investigacin -> Aprueba o rechaza el horario
5. Sistema -> Si el horario es aprobado, el sistema programa al reunin
y enva notificaciones.
Secuencia alternativa
1. Sistema -> Muestra otro horario tentativo de reunin (Paso 1
Secuencia normal)

136

Pantalla

Caso de Uso

CU2. Crea el proyecto.

Versin

Autor

Grupo6

Fecha

Fuente
Propsito

Registrar propuesta del proyecto

Objetivo

Se resuelven:

Resumen
Actores

C2 Ausencia de procedimientos y recursos

El investigador, crea propuesta del proyecto, la registra en el sistema,
para que de esta forma el director solo tenga que consultarla en el
sistema, sin tener que recibirla fsicamente.
El investigador y el director

Precondicin
Secuencia de
interacciones

Investigador

Sistema

137

Ingresa proyecto

Demora

Inmediato: la demora depende del tiempo de digitacin

Frecuencia

Cada que se crea un proyecto

Tipo

Secundario

Registra proyecto.

Postcondicione Se crea proyecto en el sistema

s
Grfico

Interaccin

Crea el proyecto

Actores

Investigador

Resumen

El investigador crea el proyecto en el sistema ingresando los distintos

datos necesarios para su descripcin y registro.

Secuencia de
interacciones

1. Investigador -> Ingresa Nombre de Proyecto

2. Investigador -> Ingresa Integrante
3. Investigador -> Ingresa datos de actividad
4. Investigador -> Ingresa datos de otra actividad (si es necesario)
5. Investigador -> Registra fecha de inicio
6. Investigador -> Ingresa plazo
7. Investigador -> Hace clic en Ingresar
8. Sistema -> Guarda los datos ingresados, si esto es exitoso muestra
mensaje respectivo

138

Pantalla

Caso de Uso

CU3. Generacin Diagrama de Gantt

Versin

Autor

Grupo6

Fecha

Fuente
Propsito

Creacin de un diagrama de Gantt para el seguimiento de las actividades del

proyecto

139

Objetivo

Resumen
Actores

Se resuelven:
C3. No hay seguimiento a la ejecucin de los proyectos
C5. No hay sistema que administre la ejecucin del proyecto
Despus de que el proyecto es aprobado, el sistema genera un
diagrama de Gantt, en base a la informacin del mismo, para servir
como apoyo al seguimiento de los proyectos.
El investigador

Precondicin
Secuencia de
interacciones

Investigador

Sistema

Consulta

Genera diagrama de Gantt

Demora

Inmediato.

Frecuencia

Cada que se aprueba un proyecto

Tipo

Secundario

Postcondicione Se crea diagrama de Gantt

s
Grfico

Interaccin

Generacin del diagrama de Gantt

Actores

Investigador

Resumen

El sistema genera el diagrama de Gantt teniendo en cuenta las

fechas y actividades propias del proyecto.

Secuencia de
interacciones

1. Sistema -> Muestra diagrama de Gantt

140

Pantalla

Caso de Uso

CU4. Generacin de informes de presupuesto

Versin

Autor

Grupo6

Fecha

Fuente
Propsito

Generar informes de los gastos del presupuesto hechos por el investigador

Objetivo

Se resuelven:

Resumen

C7. No hay sistema que garantice el seguimiento a la distribucin del

presupuesto
Los investigadores ingresan, los campos correspondientes al informe
del presupuesto, y el sistema lo enva a la DIMA para ser revisado.

Actores

DIMA e investigador.

Precondicin

El proyecto ha sido aprobado

Secuencia de
interacciones

investigador

Sistema

Ingresa los datos, relacionado al Almacena el informe

informe de presupuesto

Demora

Enva informe a la DIMA.

Inmediato.la demora depender de la digitacin del informe..

141

Frecuencia

Cada mes

Tipo

Secundario

Postcondicione Se crea diagrama de Gantt

s
Grfico

Interaccin

Generacin de informes de presupuesto

Actores

Investigador

Resumen

Teniendo en cuenta el presupuesto asignado por la DIMA al proyecto

y su utilizacin, los investigadores generan informes en los que se
plasme la utilizacin del mismo.

Secuencia de
interacciones

1. Investigador ->Ingresa nombre del proyecto

2. Investigador -> Ingresa monto gastado del presupuesto
3. Investigador -> Ingresa descripcin de movimiento en el presupuesto
4. Investigador -> Ingresa fecha
5. Investigador -> Ingresa otro monto gastado del presupuesto (esto
mientras sea necesario)
6. Investigador -> Ingresa otra descripcin de movimiento en el
presupuesto (esto mientras sea necesario)
7. Investigador -> Ingresa otra fecha (esto mientras sea necesario)
8. Investigador -> Hace clic en Registrar
9. Sistema -> Muestra si el registro de la informacin y el envo de esta
fueron exitosos

142

Pantalla

Caso de Uso

CU5. Revisin y envo de informes de presupuesto

Versin

Autor

Grupo6

Fecha

Fuente
Propsito
Objetivo

Resumen

Analizar informes de los gastos del presupuesto hechos por el investigador y

hacerlos llegar a la entidad cofinanciadora
Se resuelven:
C9 No hay supervisin adecuada
al presupuesto en la ejecucin del proyecto
C7 No hay sistema que garantice el seguimiento
a la distribucin del presupuesto.
La DIMA toma el informe ingresado por el usuario lo revisa y enva a
la entidad cofinanciadora.

Actores

DIMA.

Precondicin

El informe ha sido diligenciado por el investigador

143

Secuencia de
interacciones

DIMA

Consulta informe

Analiza Informe

Demora

Solicita
envi
cofinanciadora

Sistema

la

entidad Enva
informe
cofinanciadora.

la

entidad

En el anlisis de acuerdo a la disponibilidad de la DIMA (los informes se

realizaran cada mes)

Frecuencia

Cada que se aprueba un proyecto

Tipo

Secundario

Postcondicione Revisin de informe de presupuesto por parte de la entidad

s
cofinanciadora
Grfico

Interaccin

Revisin y envo de informes de presupuesto

Actores

DIMA

Resumen

Un funcionario de la DIMA revisa el informe enviado por parte de los

investigadores, una vez hecho esto envan dicho informe a la entidad
cofinanciadora.

Secuencia de
interacciones

1. DIMA -> Hace clic en Mostrar Informe Presupuesto

2. Sistema -> Muestra informe presupuestal anteriormente generado
3. DIMA -> Revisa el informe
4. DIMA -> Hace clic en Enviar

144

5. Sistema -> Si el envo del informe a la entidad cofinanciadora fue

exitoso, muestra el mensaje respectivo

Pantalla

Caso de Uso

CU6. Actualiza sistemas

Versin

1.2

Autor

Grupo6

Propsito
Objetivo
Resumen

Fecha

Actualizar los diferentes sistemas que manejan las convocatorias sin

necesidad, de reprocesos.
Se resuelven:
C16 Reingreso de informacin en CVLac, GrpLac y Hermes
El director actualiza el nuevo sistema y este automticamente
actualiza e Cvlac GrupLac y Hermes.

Actores

Director

Precondicin

El proyecto a sido aceptado

Secuencia de
interacciones

Director

Sistema

Actualiza datos en el nuevo sistema.

Actualiza Hermes,

Actualiza Cvlac

Actualiza GrupLac

Demora

Inmediato, tiempo en el ingreso de los datos correspondientes

145

Frecuencia

Cada que se acepta o se aprueba un proyecto

Tipo

Primario

Postcondicione Se actualizan todos los sistemas referentes al proyecto.

s
Grfico

Caso de Uso

CU7. Distribucin del presupuesto

Versin

Autor

Grupo6

Fecha

Fuente
Propsito
Objetivo

Resumen

Que la DIMA distribuya el presupuesto de forma efectiva y organizada para

facilitar su seguimiento.
Se resuelven:
C7 No hay sistema que garantice el seguimiento a la 146 distribucin del
presupuesto.
C6 El sistema Hermes solo administra las convocatorias.
El personal de la DIMA, presumiblemente su director, se ayuda de la
herramienta informtica para administrar el presupuesto asignado a
cada grupo de investigacin.

Actores

DIMA

Precondicin

El presupuesto ha sido entregado por la entidad cofinanciadora

Secuencia de
interacciones

DIMA

Sistema

146

El operario
verifica
asignado
por
la
cofinanciadora

el

monto El sistema devuelve informacin

entidad registrada de los montos asignados
por entidades cofinanciadoras

Se asigna el monto al proyecto

Se registra en el sistema el monto

que se distribuye al proyecto en
cuestin

Demora

Inmediato, tiempo en el ingreso de los datos correspondientes

Frecuencia

Cada que se asigna presupuesto a un proyecto

Tipo

Secundario

Postcondicione Se determina el tiempo asignado a los investigadores.

s
Grfico

Interaccin

Distribucin de presupuesto

Actores

DIMA

Resumen

Un funcionario de la DIMA lleva a cabo la distribucin de

presupuesto, esto es, asignando ordenadamente al proyecto en
cuestin, el monto dado por la entidad cofinanciadora.

Secuencia de
interacciones

1. DIMA -> Consulta el monto asignado por una entidad cofinanciadora

a un proyecto determinado
2. Sistema -> Muestra la informacin del presupuesto determinado entre
una entidad y un proyecto
3. DIMA -> Ingresa el monto asignado de este, por parte de la DIMA al
proyecto en cuestin

147

4. Sistema -> Registra el monto, si la operacin fue exitosa, muestra el

mensaje respectivo

Pantalla

Caso de Uso

CU8. Revisin de informes de avance y presupuesto

Versin

Autor

Grupo6

Fecha

Fuente
Propsito
Objetivo

Resumen

Que el comit supervisor tenga una visin del estado de los proyectos y
pueda actuar en consecuencia.
Se resuelven:
C4. Falta de asesora a los investigadores en la ejecucin de los proyectos
C5. No hay sistema que administre la ejecucin del proyecto
C7. No hay sistema que garantice el seguimiento a la distribucin del
presupuesto
C9. No hay supervisin adecuada al presupuesto en la ejecucin del
proyecto
El comit asesor revisa el avance del proyectoen caso de que haya
retraso, adems de la utilizacin del presupuesto.

Actores

Comit supervisor

Precondicin

Se genera una alerta por incumplimiento de plazo

148

Secuencia de
interacciones

1
2

Demora
Frecuencia
Tipo

Comit supervisor

Sistema

Consulta el diagrama de Gantt

Genera el diagrama de Gantt del

proyecto

Consulta
los
presupuesto

informes

de Muestra los informes de presupuesto

del proyecto revisado

Inmediato, tiempo en que se hace la consulta

Cada que hay un retraso u otro tipo de anomala en el progreso de un
proyecto
Primario

Postcondicione Se programan reuniones con los investigadores del proyecto.

s
Grfico

Interaccin

Revisin de informes y avance de presupuesto

Actores

Comit supervisor

Resumen

El comit supervisor hace esto entrando a la interfaz respectiva del

aplicativo, que muestra la informacin respectiva de los informes,
tanto de retraso como de presupuesto del proyecto.

Secuencia de
interacciones

1. Comit supervisor -> Selecciona grupo

2. Comit supervisor -> Selecciona proyecto
3. Comit supervisor -> Consulta informes
4. Sistema -> Muestra diagrama de Gantt
5. Sistema ->
seleccionado

Muestra

149

informes

presupuestales

del

proyecto

Pantalla

Caso de Uso

CU9. Generacin de alerta por incumplimiento de plazo

Versin

1.2

Autor

Grupo6

Fecha

Fuente
Propsito
Objetivo
Resumen

Que haya una forma de regular y controlar los incumplimientos de plazos en

proyectos.
Se resuelve:
C3. No hay seguimiento a la ejecucin de los proyectos
Cuando hay incumplimiento en el plazo de actividades, se genera
una alerta.

Actores

Investigador comit de supervisin

Precondicin

Se incumple el plazo de una actividad

Secuencia de
interacciones

Investigador o comit Supervisin

1
2

Sistema

Enva una alerta de incumplimiento

de plazo, al correo
Recibe correo con alerta de
incumplimiento de plazo, al correo

150

Demora

Inmediato

Frecuencia

Cada que hay incumplimiento en el plazo de una actividad en un proyecto

Tipo

Primario

Postcondicione El comit supervisor y el grupo de investigacin son alertados, por

s
incumplimiento en el proyecto.
Grfico

Pantalla

Este caso de uso es una Funcin Interna del sistema por lo cual no
tiene interfaz

Caso de Uso

CU10. Entrega de presupuesto

Versin

Autor

Grupo6

Fecha

Fuente
Propsito

Que la entidad cofinanciadora registre la entrega del presupuesto de una

forma estandarizada.

Objetivo
Resumen

La entidad cofinanciadora ingresa en el sistema el monto a asignar a

un proyecto determinado.

Actores

Entidad cofinanciadora

Precondicin

El proyecto ha sido aprobado

Secuencia de

Entidad cofinanciadora

151

Sistema

interacciones

La entidad cofinanciadora asigna un Se registra en el sistema el monto

monto al proyecto para que este sea
distribuido por la DIMA

2
3

Demora

Inmediato, tiempo en el ingreso de los datos correspondientes

Frecuencia

Cada que un proyecto es aprobado

Tipo

Secundario

Postcondicione Se distribuye el presupuesto.

s
Grfico

Interaccin

Entrega de presupuesto

Actores

Entidad cofinanciadora

Resumen

Un funcionario de la entidad cofinanciadora ingresa el monto del

proyectoque le asigna a los proyectos.

Secuencia de
interacciones

1. Entidad cofinanciadora -> Selecciona el grupo de investigacin

2. Entidad cofinanciadora -> Selecciona el proyecto
3. Entidad cofinanciadora ->Ingresa el monto a asignar al proyecto
4. Entidad cofinanciadora ->Hace clic en Asignar
5. Sistema -> Si la operacin es exitosa, muestra el mensaje respectivo

152

Pantalla

Caso de Uso

CU11. Ingresar disponibilidad de tiempo.

Versin

Autor

Grupo6

Fecha

Fuente
Propsito

Ingresar disponibilidad de tiempo.

Objetivo

Se resuelven:

Resumen
Actores
Precondicin
Secuencia de
interacciones
1

C4. Falta de asesora a los investigadores en la ejecucin de los proyectos

El comit de supervisin o el grupo de investigacin, ingresa la
disponibilidad de tiempo para programacin de reuniones
El comit de supervisin o el grupo de investigacin.
P17. Generacin de alerta por incumplimiento de plazo anomalas en P20.
Revisin de informes avance y presupuesto
Comit de supervisin o grupo de Sistema
investigacion
Ingresa informacin referente a la Comprueba informacin.
disponibilidad de tiempo

Almacena la informacin referente a

la disponibilidad de tiempo

Secuencia alternativa

Informacin incorrecta o
incompleta.

153

Solicitud ingreso completo y

correcto de la informacin.

Grfico

Interaccin

Ingresar disponibilidad de tiempo.

Actores

Comit supervisor o grupo de investigacin.

Resumen

El comit ingresa fechas de disponibilidad para reuniones.

Secuencia de
interacciones

Secuencia Normal
6. Comit de supervisin -> ingresa horario para programacin de
reuniones
7. Sistema -> almacena informacin si esta es correcta?
Secuencia alternativa
2. Sistema -> El sistema solicita correccin de informacin incorrecta.

Pantalla

154