Pontificia Universidad Católica de Valparaíso

Facultad de Ingeniería

Escuela de Ingeniería Informática

Ingeniería Civil en Informática

EL ENFOQUE DEL DISEÑO CENTRADO EN USUARIO

EN EL DESARROLLO DE SITIOS WEB
TRANSACCIONALES

Informe final del Proyecto para optar al Título profesional de

Ingeniero Civil en Informática
Autor:
Carmen Gloria Benavides Allendes
Profesor Guía:
Cristian Alexandru Rusu
Profesor Co-referente:
Silvana Roncagliolo de la Horra
Agosto, 2008
 A mis padres, familiares y amigos, por creer en todo momento en mí.

Agradecimientos

A mis Padres y profesor guía, por todo el apoyo brindado,

A Dios por darme la fortaleza necesaria para terminar este largo camino y

A mi madre por su dedicación y esfuerzo,

Pues sin ella no habría sido posible llegar a estas instancias. Gracias.

Lista de Abreviaturas

DCU: Diseño Centrado en Usuario.

DCS: Diseño Centrado en Sistemas.

DHC: Diseño Centrado en el Humano.

HCI: Human Computer Interaction.

IU: Ingeniería de la Usabilidad.

IS: Ingeniería de Software.

ISO: Internacional Organization for Standarization.

IPO: Interacción Persona Ordenador.

IMM: Ingresos Mínimos Mensuales.

PUCV: Pontificia Universidad Católica de Valparaíso.

Resumen

Gran parte de los usuarios culpa a los desarrolladores por la poca operatividad y
funcionalidad de sus sistemas, lo que con frecuencia se traduce en una deficiente
representación de sus necesidades, una de las causas de este problema es la omisión o una
mala aplicación de la usabilidad en el proceso de desarrollo. Además, los desarrolladores
poseen un enfoque erróneo de ésta, contemplándola solo desde las fases finales,
centrándose en la apariencia estética de la interfaz de usuario. A consecuencia, nace el
Diseño Centrado en Usuario quién proporciona un enfoque que incluye la usabilidad y al
usuario en todo el ciclo de vida del software. Para asegurar la usabilidad, este enfoque
utiliza técnicas de usabilidad, mediante las cuales se incluye al usuario en todo el proceso
de desarrollo. En esta memoria se presentan los fundamentos del enfoque del Diseño
Centrado en el Usuario, a través de un extenso análisis del modelo centrado en usuario y
sus componentes, en la generación de una pauta constituida por técnicas de usabilidad, con
el fin de medir el impacto en la usabilidad percibida por los usuarios y en los
desarrolladores, a través de su implementación en un caso de estudio práctico y la
comparación con un sistema desarrollado con el enfoque tradicional.

Palabras claves: Usabilidad, Diseño Centrado en Usuario, Técnicas de Usabilidad.

Abstract

Most of users blame to developers for the little bit operability and functionality of his
systems, this often is translated in a poor representation of his needs, one of the causes of
this problem is the omission or an incorrect applicability of the usability in the development
process. Also, the developers have a wrong approach of this one, looking it just in the final
phases, and focus in the interface esthetic appearance of user. As a consequence, the user-
centered Design was created, who provides an approach that, includes the usability and user
in all life cycle software. To ensure the usability, this approach uses usability techniques,
by which includes the user in all develop process. This report beginnings of the user focus
design, by an extensive analysis of the user focus design and his components, in the
creation of a guide made of usability techniques, with the objective of measure the impact
in the usability perceived for the user and developers, through his implementation in a
practice case study and comparison with a system developed with the traditional approach.
Capítulo 1
Introducción

Habitualmente los desarrolladores, en la actualidad poseen un enfoque erróneo respecto a la

usabilidad, ya que se contempla desde la perspectiva a que ésta solo involucra la apariencia
de la interfaz de usuario, llegando a considerar la gestión de la usabilidad como análoga y
relativa a otras acciones del control de calidad del software propiamente tal. En este marco,
los Procesos de Desarrollo de Software habituales de la Ingeniería de Software (IS), no
aplican regularmente las prácticas de usabilidad en todo el proceso de desarrollo,
dejándolas para las fases finales de este mismo proceso, desaprovechando con esto las
grandes ventajas que poseen su utilización, entre las cuales se destaca la disminución de los
costos del proceso que sin duda no deja de ser un factor peyorativo. Es por ello que en este
último tiempo, considerando la demanda actual que existe por los sistemas de información
y la meta de producir sistemas en los cuales los costos sean menores, este nuevo enfoque
juega un papel fundamental, ya que las industrias de software han contemplado los
beneficios que conlleva la usabilidad, y por ende se ha producido un aumento en la
utilización de estas prácticas en el Proceso de Desarrollo de Software.

Desde el punto de vista del usuario, éstos esperan un sistema que cumpla con sus
necesidades, además de simplificar sus tareas de la manera más simple posible. En la
mayoría de los casos, los software proporcionados a los usuarios o no son utilizados en su
totalidad o simplemente no cumplen sus necesidades, cayendo en consideración los motivos
del porqué los usuario no saben cómo utilizar los sistemas, ya sea en su completitud y/o
ciertas módulos del software y en el peor de los casos, su complejidad no los deja
interactuar. Estas desventajas alejan a los usuarios y crean una imagen de incertidumbre
para con los proveedores de software culpándolos de no entender las necesidades del
cliente y entregar productos inutilizables o utilizables en un menor porcentaje. A
consecuencia de esta problemática, los desarrolladores de software han considerado que
para no construir aplicaciones que no representen las necesidades de los usuarios, se hace
necesario incluirlo de una forma más participativa en el desarrollo para asegurar un
producto final utilizable y representativo.

Ante la necesidad de incluir al usuario en todas las fases de desarrollo como un participante
activo del proceso completo y lograr la usabilidad en un sistema software, nace el enfoque
del Diseño Centrado en Usuario (DCU). El Modelo de Proceso de este enfoque se basa en
el estándar internacional ISO 13407 [ISO, 99], que establece un marco de referencia
normativo, que sirve de guía para garantizar la usabilidad en el desarrollo de sistemas
interactivos. Se incorpora el DCU durante el ciclo de vida del desarrollo, sin considerar el
modelo que se utilice, proporcionando un complemento a cualquier método de diseño y
estableciendo una perspectiva general centrada en el usuario que puede integrarse en
diferentes procesos de desarrollo. Para la integración de la usabilidad en el proceso de
desarrollo de Software es necesario que sea aplicado sobre un desarrollo iterativo, con el fin
de medir y asegurar la usabilidad en las iteraciones según las especificaciones de usabilidad
y requerimientos del cliente, mediante las técnicas de evaluación de usabilidad, además de
las utilizadas por los procesos habituales de la Ingeniería de Software en el ciclo completo
de desarrollo.

En la primera etapa de este estudio, se profundizó en el enfoque DCU, el cual se basa

principalmente en cómo el usuario será parte del proceso de desarrollo, incluyéndolo desde
las fases más tempranas hasta las finales, considerando su entorno organizacional y social,
entre otros aspectos significativos para el usuario y que los procesos de desarrollo
habituales dejan fuera, pero si son tomados en cuenta en el enfoque DCU. Se incluye al
usuario a través de cada una de las técnicas de usabilidad utilizadas en las distintas fases de
desarrollo, donde se validan cada una de las especificaciones propuestas por éste. Sin
embargo, el enfoque DCU no precisa específicamente qué técnicas de usabilidad utilizar y
en qué etapa del proceso de desarrollo aplicarlas, sólo propone los requisitos, características
y directrices para planificar el proceso completo. Es por esto, que mediante la aplicación de
este enfoque se pretende elaborar una pauta compuesta por un conjunto de técnicas de
usabilidad según el contexto y entorno en particular del proyecto (caso de estudio) y que
beneficien a los Ingenieros de Software en el proceso de desarrollo, con el fin de medir el
impacto de la aplicación de este enfoque. Esta pauta se encuentra formada por un conjunto
de técnicas de usabilidad, las cuales conllevan un previo análisis y posterior elección, sobre
la base de la naturaleza de cada una de ellas y del contexto propuesto por el enfoque DCU.

Este enfoque, por cuestiones de tiempo, se aplicó solo a un caso de estudio y se comparó
con otro sin este enfoque. El fin fue establecer diferencias entre las aplicaciones centradas
en el usuario y las desarrolladas con los enfoques habituales de la Ingeniería de Software
(Diseño Centrado en Sistemas). El primer caso de estudio corresponde a un Sitio Web para
el Control de Remuneraciones para un estudio contable y tributario, desarrollado por
alumnos de Ingeniería Ejecución en Informática de la PUCV, y el segundo un Sitio Web
para el Control de Inventarios desarrollado por alumnos del ramo de Ingeniería de Software
de la PUCV, el cual conforma la contraparte de similares características que fue comparada
con el primer caso de estudio.

En la siguiente etapa de este proyecto, se llevó a cabo el refinamiento de la propuesta

preliminar (definición de la pauta preliminar) obtenida desde la primera etapa del proyecto,
para su posterior aplicación en el caso de estudio elegido. Después de obtener la propuesta
definitiva (pauta preliminar refinada) se definió en qué parte del proceso de desarrollo
(análisis, diseño y/o evaluación) se incluirían cada una de las técnicas de Usabilidad,
dependiendo del Modelo de diseño de desarrollo del caso de estudio. Cabe destacar que
para efectos de análisis y comparación, ambos casos de estudio se desarrollaron con
procesos de desarrollo iterativos, donde su impacto se evaluará en cuanto a la aceptación de
las mejoras al aplicar el enfoque DCU por parte de los desarrolladores y respectivamente
del usuario. Tal aceptación se medirá en base, a opiniones, entrevistas, encuestas y
cuestionarios. En cuanto a su comparación, se utilizaron técnicas de usabilidad como
encuestas, cuestionarios, test de usabilidad, entre otras.

Por otra parte, en la actualidad existe una variada gama de documentos que explican
claramente el concepto de usabilidad y sus métodos de evaluación, en su mayoría abocada
al desarrollo Web. Respecto a documentos que ayudan a comprender el enfoque DCU,
existe una gran variedad, pero abocados en su mayoría al estudio e investigación de la
integración de las practicas de usabilidad en el proceso de Desarrollo de Software, donde el
enfoque como tal es un elemento clave para los efectos de estudio. Como ejemplo de esto,
existen publicaciones de tesis doctórales y papers disponibles en la Word Wide Web, como
en el caso de Xavier Ferré Grau con su tesis doctoral “Marco de Integración de la
usabilidad en el proceso de desarrollo de Software” quién ilustra material de interés
respecto a las características de los Procesos Centrados en el Usuario y se centra
básicamente en lo que es la investigación de la integración de la usabilidad en el desarrollo
mismo. A su vez, en cuanto a las publicaciones (papers), existen en particular publicaciones
de revistas como por ejemplo RPM (Revista de Procesos y Métricas de las Tecnologías de
la Información), Revista Española de Documentación Científica, entre otras, las cuales
entregan una amplia visión del enfoque DCU, sus actividades y técnicas de usabilidad
aplicables a él. Los papers más utilizados en esta investigación son los de autores como:
Xavier Ferré, Nuria Hurtado, Mercedes Ruiz, Yusef Hassan Montero, entre otros.

1.1. Definición de Objetivos

1.1.1. Objetivo General

El objetivo general de esta memoria es:

Evaluar el impacto del enfoque del Diseño Centrado en el Usuario en el desarrollo de

Sitios Web Transaccionales.

La evaluación del impacto consiste en implementar este enfoque mediante casos de estudio,
para luego comparar los resultados obtenidos, a través de un conjunto de técnicas de
usabilidad.

1.1.2. Objetivos Específicos

Comprender las actividades del enfoque del Diseño Centrado en el Usuario.

Investigar las técnicas de usabilidad aplicables en los Procesos de Desarrollo

Centrado en el Usuario

Crear una pauta de técnicas de usabilidad que permitan llevar a la práctica el enfoque
del Diseño Centrado en el Usuario.

Validar la pauta a través de casos de estudio.

 Comparar el Diseño Centrado en el Usuario con el Diseño Centrado en Sistemas a
través de casos de estudio.

1.2. Metodología
El Proyecto contempla las siguientes metodologías para alcanzar los objetivos:

Estudio Teórico.

Estudio Exploratorio, descriptivo y Explicativo.

1. El estudio teórico se realizó para tener un marco teórico de referencia y se enfocó

respecto a:

Estudio del concepto de usabilidad, sus atributos, principios y reglas.

Estudio de los conceptos relativos al enfoque del Diseño Centrado en Usuario:

Especificaciones del contexto de uso, Análisis de tareas y Análisis de usuarios,
Especificaciones de Usabilidad, Evaluaciones de Usabilidad, entre otros.

Estudio e investigación del modelo de procesos del Diseño Centrado en Usuario.

Estudio de las actividades y técnicas de usabilidad utilizadas en el Diseño Centrado

en Usuario según los distintos autores.

2. La metodología de investigación que se eligió, fue la propuesta por R. Hernández, donde

los pasos a seguir serán los siguientes:

1) Concebir la idea a investigar.

2) Planteamiento del proyecto a desarrollar:

a. Establecer Objetivo General.

b. Establecer Objetivos Específicos.

3) Definición del alcance de la investigación a realizar, utilizado alguna metodología.

4) Formulación del problema.

5) Selección del diseño de investigación apropiada.

6) Recolección de datos.

7) Análisis de los datos.

8) Elaboración del reporte de los resultados.

Según [Hernández, 98], los tipos de investigación son cuatro: Exploratorio, Descriptivo,
Correlacional y Explicativo. La metodología exploratoria es la investigación que pretende
darnos una visión general y sólo aproximada de los objetos de estudio. Este tipo de
investigación se realiza especialmente cuando el tema elegido ha sido poco explorado,
cuando no hay suficientes estudios previos y cuando aún, sobre él, es difícil formular
hipótesis precisas o de cierta generalidad. Para la metodología Descriptiva, su preocupación
primordial radica en describir situaciones y eventos, utilizando criterios sistemáticos que
permiten poner de manifiesto la estructura o el comportamiento de los fenómenos en
estudio, proporcionando de ese modo información comparable con la de otras fuentes. La
metodología Correlacional mide dos o más variables, en las cuales se pretende ver si están
o no relacionadas en los mismos sujetos y después se analiza la correlación. La utilidad y
propósito son saber cómo se puede comportar un concepto o variable conociendo el
comportamiento de otras variables relacionadas. Y Finalmente, la metodología Explicativa,
es aquella en donde la preocupación se centra en determinar los orígenes o las causas de un
determinado conjunto de fenómenos. Su objetivo, por lo tanto, es conocer por qué suceden
ciertos hechos, analizando las relaciones causales existentes o, al menos, las condiciones en
que ellos se producen.

1.3. Estructuración
En el capitulo dos se describirán los conceptos de Usabilidad y Diseño Centrado en
Usuario, donde se describe la usabilidad como concepto base, con sus atributos, principios
y paradigma, y Los Procesos Centrados en Usuario con las distintas actividades y técnicas
de Usabilidad utilizadas en este enfoque, finalizando con la comparación de los procesos de
diseño tradicionales y los centrados en usuario.
En el Capitulo tres se describirán los casos de estudio que conforman la implementación
practica del enfoque Centrado en el Usuario.

El Capitulo cuatro refiere a la elaboración de la propuesta de usabilidad, donde se describe

cómo se conforma la pauta de usabilidad con las distintas técnicas de usabilidad del área
para implementar en los distintos casos de estudio.

El Capitulo cinco refiere a la implementación del Enfoque del Diseño Centrado en Usuario,
y la aplicación de la pauta de usabilidad, definida en el capitulo anterior, en el caso de
estudio. También se describen los resultados obtenidos de la implementación a través de la
medición del impacto en la usabilidad percibida del producto y la comparación entre un
sistema Centrado en Usuario y un Sistema Centrado en el Desarrollo de Sistemas Clásico.

El Capitulo seis está dedicado a las conclusiones del estudio realizado.

Capítulo 2
La Usabilidad y El Diseño Centrado en Usuario

2.1. Usabilidad
El término usabilidad se define en la norma ISO 9241-11[ISO, 98] como “el grado en el
que un producto puede ser utilizado por usuarios especificados para conseguir objetivos
concretos con efectividad, eficiencia y satisfacción, en un determinado contexto de uso”. La
norma ISO 9241-11 explica que los beneficios de la usabilidad de los sistemas se miden
fundamentalmente por el grado de consecución de los objetivos previstos en cuanto a
utilización (efectividad), por los recursos empleados para alcanzar esos objetivos
(eficiencia) y por el grado de aceptación del producto por parte del usuario (satisfacción).

En el siguiente apartado presentaremos brevemente los atributos, reglas y principios de

usabilidad según Nielsen [Nielsen, 92].

2.1.1. Atributos de la Usabilidad

x Aprendizaje (Learnability): Que sea fácil de aprender para inexpertos. Este atributo se
puede medir eligiendo usuarios inexpertos para ciertas tareas del sistema, midiendo el
tiempo necesario que toman en llevarlas a cabo.

x Eficiencia (Efficiency): Que sea eficiente para expertos. Se mide a través de la

definición o decisión de cuáles son los usuarios expertos (tarea difícil), midiendo el
tiempo en que toman en llevar a cabo tareas típicas del sistema.

x Memorización (Memorability): Fácil de acordar para usuarios ocasionales. Medido a

través del tiempo necesario para cumplir tareas por usuarios que no han utilizado
últimamente el sistema.
x Errores (Errors): Frecuencia de errores menores y graves. Medición mediante el
conteo del número de errores para tareas típicas.

x Satisfacción subjetiva (Subjective Satisfaction): Que el sistema sea agradable es para

usar. Medición mediante cuestionarios.

2.1.2. Paradigma y Principios de Usabilidad

El objetivo del diseño es maximizar los niveles de usabilidad del sistema, por ende es de
vital importancia entender el sentido de la usabilidad, no basta con tener en mente los
atributos mencionados, sino que a demás se debe tener en cuenta paradigmas y principios
que nos ayuden a comprender en su mayor totalidad la usabilidad y tener éxito en el diseño.

a) Reglas de usabilidad

x Acceso: El sistema debe ser usable, sin ayuda o capacitación, para personas con
experiencia en el área de aplicación, pero no en el sistema.

x Eficaz: El sistema no debe impedir el trabajo eficiente para personas con experiencia en
el sistema.

x Ascenso: El sistema debe apoyar el avance continuo en conocimientos y habilidades,

debe acomodarse al cambio progresivo, mientras que los usuarios acumulan
experiencia.

x Soporte: El sistema debe apoyar las tareas concretas del usuario, haciendo las cosas
más fáciles, simples, rápidas, divertidas, o incluso permitiendo nuevas cosas.
x Contexto: El sistema debe estar adaptado a las condiciones de uso reales, en el entorno
en el cual se va a utilizar.

b) Principios de usabilidad

x Estructura: Organizar la interfaz con ciertos objetivos, con sentido, de manera útil,
basada en modelos claros, consistente, fácil de reconocer para los usuarios, agrupando
cosas relacionadas, y separando cosas no relacionadas, mostrando de la misma manera
las cosas similares, y de manera distinta las cosas distintas. Las metáforas complicadas
hacen las cosas más difíciles de entender, así como a su vez las simulaciones simplistas
hacen las cosas difíciles de utilizar.

x Simplicidad: Simplificar la ejecución de tareas comunes, comunicar las cosas de

manera simple y clara, en el lenguaje del usuario, ofrecer accesos directos fáciles de
entender para procedimientos largos. No todo se puede hacer de manera simple y las
tareas simples en la percepción del usuario deben quedar simples en la interfaz.

x Visibilidad: Guardar las alternativas y herramientas para una cierta tarea visibles, sin
distraer al usuario con información extraña y/o redundante. No sobrecargar el usuario
con demasiadas alternativas y no confundir el usuario con información no necesaria.

x Feedback: Mantener al usuario informado sobre las acciones, cambios de estado,

errores y excepciones, en un lenguaje claro y conciso, no ambiguo, familiar al usuario.
Un buen feedback no necesita muchas palabras.

x Tolerancia: Flexibilidad y tolerancia, bajar el costo de las acciones erróneas,

ofreciendo posibilidades de deshacer y rehacer, interpretar de manera razonables las
acciones razonables. Un buen software es en el mismo tiempo flexible y tolerante, y no
debe hacer acciones inadecuadas cuando recibe entradas o acciones inesperadas.
x Reusabilidad: Reutilizar componentes y comportamientos internos y externos,
manteniendo consistencia con los propósitos, reducir la necesidad de repensar y
memorizar. Las interfaces inconsistentes son más difíciles de utilizar y requieren más
programación.

Como podemos apreciar el concepto de usabilidad es de carácter peyorativo en el desarrollo

de software. Como atributo de calidad hace determinante que se considere en un enfoque
para poder así considerarlo desde los comienzos del desarrollo, es por esto, que a
continuación presentaremos el enfoque del Diseño Centrado en Usuario.

2.2. El Diseño Centrado en Usuario

El Diseño Centrado en el Usuario (sus siglas en ingles UCD, User Centred Design) es un
enfoque para el diseño de sistemas interactivos que trata específicamente de lograr que los
sistemas sean más usables a través de la incorporación del usuario en el proceso de
desarrollo.

1. El Propósitos del DCU

El Diseño Centrado en el Usuario es una nueva aproximación metodológica de la disciplina

del diseño, cuyo objetivo es crear productos adaptados a las necesidades reales de los
usuarios, que en muchos casos aún no han sido identificadas y, en consecuencia, pueden
suponer una importante e innovadora oportunidad para las empresas.

2. Principios del DCU

Los principios del DCU no son más que una reformulación de los principios más
elementales de la Ergonomía Clásica y de aquellos se derivan, en general, las guías de
accesibilidad. Solo nombraremos estos principios y nos basaremos en los de mayor interés:

El control de la situación debe estar en manos del usuario.

Es preciso un planteamiento directo.

La consistencia es parte indispensable en el diseño.

 Hay que posibilitar la recuperación de los errores.

Retroalimentación apropiada por el sistema.

No se puede descuidar la estética.

El diseño debe caracterizarse por su simplicidad.

Es fundamental seguir una rigurosa metodología de diseño.

El equipo de diseño debe ser equilibrado.

Se distinguen cuatro partes en el proceso de diseño.

Son indispensables las consideraciones de usabilidad en el proceso de diseño.

Hay que entender al usuario.

Hay que realizar renuncias en el diseño.

Por lo tanto, los tres principios de básicos de este enfoque:

Un enfoque desde el inicio hacia los usuarios y las tareas que han de realizar con el
producto, recopilando datos de manera estructurada, sistemática y objetiva.

Medición empírica de la utilización real. El énfasis se centra en la realización de Test

de facilidad de uso desde el inicio del diseño basado en prototipos tempranos del
producto.

Diseño iterativo mediante la repetición cíclica de las fases de diseño, modificación de

parámetros y Test de usabilidad del producto, desde el primer momento, realizando
ciclos hasta que el resultado sea completamente satisfactorio.

Entre los beneficios de la aplicación de Procesos de DCU se pueden incluir:

Reducción de los costes de producción. Los costes y el tiempo de desarrollo se

pueden reducir evitando el sobrediseño y reduciendo el número de cambios
posteriores sobre el producto.

Incremento de la productividad de los usuarios y de la eficiencia operativa de las

organizaciones.
 Mejora de la calidad del producto y su atractivo para los usuarios dando lugar a una
ventaja competitiva.

Se realizan sistemas más fáciles de usar y de aprender lo cual reduce los costes de
asistencia técnica, formación y mantenimiento.

Aumenta la satisfacción del usuario reduciendo las molestias y el estrés.

Entre los problemas que podemos encontrar al aplicar este enfoque DCU encontramos:

Desconocimiento y carencias de comprensión del enfoque por parte de los

desarrolladores.

Es preciso realizar un estudio de cómo acomodar el enfoque centrado en el usuario en

el proceso de desarrollo general.

La integración de los métodos o técnicas de usabilidad resulta extremadamente

compleja, puesto que se debe acomodar todo el proceso que propone la IS a las
condicionantes de los dichos métodos, lo que puede producir que otros atributos de
calidad que no sean de usabilidad queden desatendidos.

Los métodos de la comunidad HCI (Human Computer Interaction), se encuentran

descritos de forma mayoritaria para su aplicación como un proceso paralelo al de la
IS. Encontrándose reducidos a momentos puntuales del ciclo de vida del desarrollo de
software (considerados en la mayoría de los casos sólo para la evaluación de
interfaces).

Existe una importante diferencia en la terminología utilizada por la IS y la comunidad

HCI.

Por parte de los usuarios, no es posible definir exactamente sus necesidades al inicio
del proceso, ya que por una parte, el diseñador no tiene una clara idea de lo que el
usuario pueda querer, y por la otra, el usuario no tiene una idea clara de lo que la
tecnología pueda hacer.

Existen diferentes propuestas de procesos de DCU, pero podemos considerar que la

incorporación de un enfoque DCU se caracteriza por [ISO, 99]:
 La participación activa de los usuarios así como una comprensión clara de los
requisitos del usuario y de la tarea.

Una asignación clara de funciones entre los usuarios y la tecnología.

La iteración de las soluciones de diseño.

Un equipo de diseño multidisciplinar.

De estas características se desprenden las condiciones de un proceso (DCU) para integrar la

usabilidad. Por esto podemos representar cómo y porqué se cumplen estas características,
con lo siguiente:

x Implicancia o participación activa de los usuarios: Es esencial involucrar al usuario

para poder entender y definir el contexto de uso, las tareas y la forma en que van a
trabajar los usuarios en el futuro con el producto o sistema. Es importante destacar que
la participación de los usuarios en el desarrollo supone un cambio importante en la
mentalidad de los desarrolladores y en su forma de abordar los problemas. Por ejemplo,
los usuarios no deberían requerir un conocimiento técnico profundo en el desarrollo de
sistemas, de manera que éste pueda realizar aportaciones al diseño, lo cual es
proporcionado por ciertas técnicas de usabilidad del campo HCI.

En cuanto a la comprensión del usuario visto como parte de un contexto más amplio que
solo para el tema de los requisitos por parte de la IS es clave para la usabilidad del
producto final, ya que se trata de abordar la comprensión del problema con una perspectiva
mucho más amplia que la de los meros requisitos funcionales por parte de la IS, abordando
las necesidades ultimas de los usuarios.

Por parte de las tareas, la comprensión de éstas proporciona una base para diseñar tareas
que encajen con la forma habitual en que el usuario las lleva a cabo. Es aquí su importancia
y mediante la adición de técnicas de usabilidad en las actividades de requisitos contribuyen
a la adecuada comprensión de éste y sus tareas.

x Asignación clara de las funciones de los usuarios y la tecnología: El objetivo de la

tecnología es asistir al usuario a desarrollar las tareas seleccionadas, por lo que el
diseño debe identificar todas las tareas, la forma en que serán desarrolladas y como
 serán repartidas entre el usuario y la tecnología, decisión que no puede basarse
únicamente en las capacidades de la tecnología y dejar las demás tareas al ser humano.

x La iteración de las soluciones de diseño: La situación actual de trabajo es sólo el punto

de inicio para el diseño, por lo que el nuevo sistema puede cambiar el contexto de uso,
los requerimientos tecnológicos y del usuario. El proceso de diseño debe “soportar”
estas iteraciones visualizando y evaluando las nuevas situaciones, con lo que el diseño
puede ser refinado.

x Un equipo de diseño multidisciplinar: Es necesario tomar en consideración

conocimientos de diversas disciplinas, para comprender al usuario adecuadamente en su
contexto de trabajo y organizacional, y para proveerle de una interacción adecuada a sus
características y limitaciones. El equipo multidisciplinario puede incluir usuarios
finales, miembros de la gerencia, expertos en la aplicación, diseñadores del sistema,
expertos en mercadotecnia, diseñadores gráficos, especialistas en factores humanos y
personal de capacitación. Las técnicas de usabilidad están inversas en este contexto
multidisciplinar por el hecho de pertenecer al campo HCI y con estas se suple este
requisito.

Cabe de importancia destacar, que el Diseño Centrado en el Usuario (DCU) es también

conocido como el Diseño Centrado en el Humano (DCH), donde la ISO a preferido utilizar
DCH en vez de la denominación tradicional del campo HCI, DCU. Para efectos de estudio,
se utilizara el término DCU en vez de DCH para efectos de no confundir al lector.

2.2.1. Ciclo de vida del Diseño Centrado en el Usuario

Ciclo de vida en Ingeniería de la Usabilidad (IU) [Rusu, 07]:

1. Conocer al usuario.

2. Análisis de competencia.

3. Establecer metas.
4. Diseño de interacción orientado a objetivos.

5. Diseño iterativo:

Prototipos.

Evaluación de la usabilidad (Inspecciones y pruebas).

6. Estudios posteriores.

1. Conocer al usuario

x Observar el usuario en su ambiente de trabajo: La usabilidad se centra en el usuario

final. Para lograr conocer al usuario final se comienza concertando Visitas en su
entorno de trabajo y se observa sin interrumpir.

x Características individuales del usuario: Permite clasificar a los usuarios según

experiencia, según nivel educacional, edad, capacitación previa etc.

x Análisis de tareas: Análisis de los objetivos del usuario, enfoque actual, modelo de
tareas, prerrequisitos, excepciones del entorno de trabajo.

x Análisis funcional: Se busca responder la siguiente pregunta: ¿Que es realmente

necesario hacer (tareas)?

Las técnicas para obtener este tipo de información son principalmente: encuestas,
entrevistas y estudios de campo (métodos de indagación).

a) Métodos de Indagación

Estos métodos tienen como objetivo obtener información acerca de los gustos, necesidades,
desagrados, etc. del usuario. Son muy apropiados para obtener información acerca de la
usabilidad de un producto que aún no se ha empezado a fabricar pero también para obtener
información una vez fabricado. Estos métodos son aplicados en etapas tempranas del
proceso de desarrollo para así lograr comprender lo que el usuario desea de un sistema de
software.

Dentro de estos métodos podemos encontrar:

x Observación de campo: Consiste en visitar el lugar de trabajo donde se estén

realizando las actividades objeto de nuestro estudio y donde encontraremos usuarios
representativos. El objetivo principal consistirá en observarlos para entender cómo
realizan sus tareas y qué clase de modelo mental tienen sobre ellas. Se pueden hacer
preguntas para completar esta información. Este método se puede utilizar en las etapas
de prueba y del despliegue del desarrollo del producto.

x Cuestionarios: Se establecen una lista con preguntas necesarias para indagar acerca de
aspectos relevantes en el uso de un sistema determinado. Esta lista debe ser respondida
por los usuarios del sistema. Estos cuestionarios pueden ayudar a conocer mejor los
perfiles de usuario y el contexto de uso de este con el sistema.

Tipos de pregunta:

a) General: Ayuda a determinar los perfiles de usuario obteniendo datos como edad, sexo,
ocupación.

b) Abierta: Se obtiene información general y subjetiva, sugerencias de los participantes,

entre otros. etc.

c) Escalar: El participante asigna un valor, basada en una escala numérica, a un aspecto

especifico del sistema.

d) Opción múltiple: Serie de respuestas u opciones, donde el usuario debe marcar una o
varias de estas opciones en base, a la pregunta realizada.

e) Ordenadas: Serie de opciones o afirmaciones, y el participante las debe ordenar de

acuerdo a algún criterio.
x Entrevistas: Forma directa y estructurada de recoger información. Las entrevistas
pueden ser efectivas para una evaluación de alto nivel, particularmente para extraer
información sobre las preferencias del usuario, impresiones y actitudes. Así como
también, pueden ayudar a encontrar problemas no previstos en el diseño.

La entrevista debe ser preparada con antelación para que sea efectiva. El revisor puede
adaptar la entrevista al entrevistado para obtener el máximo beneficio.

1. Modelo mental del usuario

Existe mucha más información que puede ser de interés del usuario, aparte de la que
podamos obtener con las anteriores técnicas. Un ejemplo es la obtenida a través de técnicas
como Card Sorting (ordenación de conceptos) o Free-Listing (listado libre).

x Card Sorting: es una técnica que consiste en observar como el usuario ordena y agrupa
por similaridad un conjunto de tarjetas previamente etiquetadas con los nombres de las
categorías a clasificar. De esta forma podremos organizar las categorías según el
modelo mental del usuario, asegurando el éxito y usabilidad de la estructuración final.

x Free-Listing: nos permite determinar el contenido de un dominio según el modelo

mental del usuario. La técnica consiste en preguntar a un conjunto de usuarios acerca de
todos los objetos o subcategorías que conozcan de una categoría o clase determinada

2. Evaluación de lo diseñado

x análisis de los ficheros log, a través del registro que realiza el servidor de la navegación
de los usuarios pueden detectar patrones de navegación, errores de usabilidad,
problemas de findability, etc.

Todas estas etapas nos permiten categorizar al usuario según su experiencia con
computadores, el entendimiento de este en su área y que tan experto es en el uso del sistema
especifico.
Fig. 3. Categoría de los Usuarios con relación a la experiencia y el conocimiento del área.

2. Análisis Competitivo

En esta etapa se busca realizar un análisis competitivo de los sistemas similares mediante a
un análisis empírico o heurístico, o tan solo sacar ideas de otros sistemas (préstamo
inteligente).

3. Establecer Metas de Usabilidad

En esta etapa se definen y establecen las métricas de usabilidad que se utilizaran, además de
definir cuáles son las metas de usabilidad que se desean lograr para validar el nivel deseado
de usabilidad del sistema (Especificaciones de Usabilidad). Es aconsejable realizar un
análisis del impacto financiero, costo versus esfuerzo.

4. Diseño de Interacción Orientado a Objetivos

Esta etapa se basa en tener presente los objetivos o metas que desea realizar el usuario final,
durante todo el diseño del sistema. Se deben tener en cuenta las tareas relacionadas que se
necesitan para lograr dichos objetivos, sin debe dejar de lado las necesidades del usuario
final.

5. Diseño Iterativo
En esta etapa el enfoque se basa en iterar hasta que el sistema cumpla las metas de
usabilidad, a través de la idea de diseñar, evaluar, rediseñar. Se construye y evalúa un
prototipo del sistema, luego se identifican y corrigen los problemas según su severidad
respecto los problemas de usabilidad encontrado. Luego se crea una nueva versión del
prototipo, documentando los cambios y el porqué de ellos. Este proceso se repite hasta
cuando se satisfagan los objetivos o metas de usabilidad y la factibilidad del presupuesto.

a) Proceso Iterativo

Cualquier proceso iterativo se divide en etapas y, a pesar de que no todos los procesos
iterativos son iguales, siguen normalmente un patrón similar, como se muestra en la Fig. 3.
A continuación, en cada ciclo iterativo, distinguimos los momentos centrales, los
momentos finales y finalmente los ciclos de Evolución.

Fig. 4. Etapas de un Proceso Iterativo.

x Elaboración (ciclos iniciales): Antes de los ciclos iterativos hay una etapa previa de
exploración.

x Ciclos centrales: se definen como aquellos que se llevan a cabo entre los ciclos
iniciales y los de evolución. En estos ciclos se trabaja ya con un concepto del producto
compartido por todos los integrantes del equipo de desarrollo. Estaos ciclos suelen
formar el grueso del desarrollo [Ferré, 05].

x Ciclos de evolución: son aquellos que se llevan a cabo una vez que se tiene una parte
del software instalada en el entorno de uso previsto.
6. Estudios Complementarios

Esta etapa es necesaria en futuras versiones, donde se puede obtener información de

usabilidad a través estudios de campos específicos (entrevistas, cuestionarios,
observaciones, etc.), estudios de mercado, informes de errores, entre otros.

2.2.2. Modelo de Proceso Centrado en el Usuario

Existen diferentes propuestas metodológicas, provenientes de distintas disciplinas (IU e IS)
para el desarrollo de sistemas interactivos basadas en el enfoque Centrado en el Usuario
(DCU). Todas estas propuestas tratan de guiar a los desarrolladores en la manera de
proceder organizadamente para lograr la usabilidad de un sistema interactivo durante el
desarrollo del mismo. El modelo de proceso desarrollado se basa en el estándar
internacional ISO 13407 [ISO, 99] por ser considerado el marco de referencia básico en el
desarrollo de Procesos Centrados en el Usuario por parte de la comunidad HCI. No
obstante, el DCU no está ligado a ningún método existente, proporciona un complemento a
cualquier método de diseño y establece una perspectiva general centrada en el usuario que
puede integrarse en diferentes procesos de desarrollo, de acuerdo con cada contexto en
particular. Todas las actividades de diseño que plantea son aplicables, en mayor o menor
medida, a cada una de las etapas del desarrollo de un sistema, aunque previamente a su
aplicación debe establecerse la planificación del proceso centrado en el usuario. En dicha
planificación debe indicarse, el procedimiento para la integración de estas actividades en el
resto de las actividades de desarrollo del sistema (por ejemplo análisis, diseño y
evaluación), procedimiento que dependerá en cada caso del proyecto en cuestión pero que
debe permitir siempre la iteración. No obstante, el estándar no especifica cómo debe ser
dicha integración.
Fig. 5. Interdependencia de las actividades de Diseño Centradas en Usuario [ISO, 99].
En la fig. 5 se pueden observar las diferentes actividades del proceso DCU y la
interdependencia entre ellas. El proceso describe cuatro actividades principales de diseño
centradas en el usuario: comprender y especificar el contexto de uso, especificar los
requisitos del usuario y de la organización, producir soluciones de diseño y evaluar los
diseños respecto a los requisitos. El proceso implica la iteración de estas actividades hasta
que el sistema satisfaga los requisitos especificados. Los métodos y técnicas a emplear en
cada actividad así como la inversión a realizar en cada una de ellas dependerán del tamaño
y tipo de producto que se pretenda desarrollar. A continuación se comentan brevemente
cada una de las actividades de DCU que contempla el proceso y que posteriormente se
profundizarán en el Estándar ISO 13407 (Anexo A):

x Comprensión y especificación del contexto de uso: Se deben identificar las

características de los usuarios potenciales, las tareas que estos van a desarrollar así
como el entorno en el cual el sistema se va a utilizar.

x Especificación de los requisitos del usuario y de la organización respecto a la

descripción del contexto de uso: Se deben fijar los objetivos identificando los
compromisos y prioridades entre los diferentes requisitos.
x Producción de soluciones de diseño: A partir de los conocimientos existentes
procedentes de equipos multidisciplinares, se deben llevar a cabo las soluciones de
diseño concretas utilizando algún tipo de prototipado. Estos prototipos se presentan a
los usuarios y se recoge la información de retorno a partir de la cual se realiza la
modificación del diseño. Este proceso se repite hasta alcanzar los objetivos
especificados.

x Evaluación de los diseños respecto a los requisitos: La evaluación debe estar presente
durante todo el ciclo de vida con la intención de proporcionar un retorno de información
que contribuya a mejorar el diseño, también determinará si se han alcanzado los
objetivos especificados y verificará el uso a largo plazo del producto.

A continuación, el análisis de las literaturas más relevantes de autores de la comunidad

HCI, los cuales definen el enfoque de forma explícita o implícita, como en el caso de
Nielsen, para así poder entender y conocer las distintas definiciones del Diseño Centrado en
Usuario.

Existen normas ISO que tratan este enfoque, especialmente ISO 13407, Human-Centred
Design Processes for Interactive Systems (Anexo), ISO TR 16982, Usability methods
supporting human centred design, e ISO TR 18529, Ergonomics of human-system
interaction - Human-centred lifecycle process descriptions, los cuales no se abordaran a
excepción del estándar ISO 13407, por no ser objeto de investigación en este documento.

Por otra parte, la propuesta de Hix y Hartson [Hix, 93] se define sobre la base de los
siguientes principios:

El desarrollo debería incluir pruebas empíricas desde fases tempranas y de forma

continua, centradas en usuarios apropiados realizando tareas representativas.

Según avanza el desarrollo, debería incorporar procedimientos de refinamiento

iterativo y análisis costo / beneficio para determinar los cambios más efectivos a
realizar en el diseño de la interacción con el usuario.
 El proceso de gestión debería verificar y controlar el ciclo de vida general del
desarrollo y asignar responsabilidades para cada paso.

Esta propuesta describe el Diseño Centrado en Usuario de una manera poco precisa. Se
enfoca básicamente, en la descripción de la interacción del usuario, dejando de lado la del
sistema. Lo cual implica que esta propuesta es una aproximación al enfoque, respecto a la
integración de la usabilidad en el proceso de desarrollo de la IS.

A continuación Preece el al. [Preece, 94] se refiere al Diseño Centrado en Usuario con lo
siguiente:

Se debe implicar a los usuarios lo máximo posible de forma que se pueda influir en el
diseño,

Integrar el conocimiento y la experiencia de las distintas disciplinas que contribuyen

al diseño HCI,

Y ser altamente iterativo de forma que se puedan realizar pruebas para comprobar que
el diseño verdaderamente cumple los requisitos del usuario.

En esta propuesta se logra un avance y un acercamiento al enfoque, de manera que se toma

en cuenta al usuario en el proceso completo, además de incluir los conceptos:
multidisciplinario y la iteratividad del diseño. Por consiguiente, se integran ambos campos
(HCI e IS) pero no es suficiente.

Nielsen [Nielsen, 93] no utiliza el término Diseño Centrado en Usuario, pero si plantea
como una de las practicas bases de su enfoque el diseño iterativo. El autor realizó un
estudio mediante una encuesta realizada entre especialistas en Ingeniería de la Usabilidad
[Nielsen, 92] donde se llega a un consenso por medio de una opinión mayoritaria acerca del
diseño iterativo y el análisis de las tareas que el usuario realiza actualmente, como las dos
practicas de usabilidad más importantes.

Mayhew [Mayhew, 99] representa el ciclo de vida de la Ingeniería de Usabilidad en los

siguientes puntos:

El diseño de la interfaz de usuario es clave.

 La integración de la Ingeniería de usabilidad con la IS debe ser particularizada.

El análisis de requisitos vale la pena.

El diseño puede aproximarse en un proceso estructurado de descomposición (top-

down).

El diseño, las pruebas y el desarrollo deberían ser iterativos.

El ciclo de vida completo puede ser estratificado en subconjuntos de funcionalidad.

Hay una variedad de técnicas para llevar a cabo cada tarea del ciclo de vida.

Las técnicas alternativas hacen que el ciclo de vida sea flexible y adaptable.

Una implementación óptima del ciclo de vida requiere participación completa de

equipos multidisciplinares.

Esta propuesta no se aleja de las anteriores, pero si denota un gran cambio, como ya
mencionamos, además de los conceptos de iteratividad, multidisciplinario y el incluir al
usuario como un agente activo del proceso, se toma en cuenta una descripción más cercana
y detallada a lo que hoy en día se conoce como DCU, incluyendo en este detalle un factor
determinante para DCU, las técnicas que pueden ser aplicadas en el ciclo de vida completo
de desarrollo.

Un modelo más clásico, en cuanto responde a las premisas de la IS, es el propuesto por J.
Lorés [Lorés, 01], el denominado Modelo de Proceso de la Ingeniería de la Usabilidad y la
Accesibilidad. Este modelo incorpora tres núcleos principales de actividad,
correspondientes a:

El Ciclo de vida del software, con las fases clásicas de análisis de requisitos, diseño,
implementación y lanzamiento.

El Prototipado, mediante el cual, en relación con las fases de análisis de requisitos y

diseño, se preparan propuestas de interfaz de la aplicación, y se evaluación para
proceder a su aceptación, mejora o rechazo.

La Evaluación, en el que se llevan a cabo actividades para asegurar la usabilidad y la

accesibilidad del producto, desde la perspectiva del usuario final.
Fig. 6. Modelo de Proceso de la Ingeniería de la Usabilidad y la Accesibilidad.
En la Fig. 6 se puede apreciar el esquema de funcionamiento del modelo, y la iteración
existente entre los tres elementos componentes del modelo. En primera instancia, la fase de
análisis de requerimientos, en esta fase se realizaría un estudio del contexto social del
usuario en su organización, de sus objetivos, de las tareas que debe desarrollar, etc., hasta
obtener un perfil detallado del mismo. Por consiguiente, la fase de diseño, donde se
analizarían las tareas, para proponer su mejora, mediante la definición de una interfaz dada,
con un estilo propio y ajustado al perfil de usuario. Se obtendría un modelo conceptual de
la interfaz, que pasaría a ser objeto del prototipado. En esta fase obtendríamos una visión
previa de la interfaz, que sería analizada mediante la evaluación, la cual, a su vez, puede
utilizar técnicas de inspección, de indagación y de Test. Este sería el momento en el cual se
aplicarían, en toda su amplitud y potencial, las técnicas de análisis de usabilidad y de
accesibilidad.
Finalmente, una vez que el prototipo haya sido estudiado y afinado, hasta ajustarse a las
necesidades de los usuarios, y a los estándares establecidos de usabilidad y accesibilidad, se
pasaría las fases de implementación y lanzamiento.

Esta propuesta incluye el ciclo de desarrollo de la IS, tomando en cuenta las evaluaciones
de usabilidad en el desarrollo. Respecto a las propuestas anteriores, podemos concluir, que
este modelo es el más cercano al DCU, pero aun se encuentra lejos de lo que se propone en
el DCU, pero sirve como complemento a la hora de comenzar su aplicación.

2.2.3. Actividades y Técnicas de Usabilidad en el Diseño Centrado en

Usuario

2.2.3.1. Actividades del Diseño Centrado en Usuario

Según los principios en los que se caracteriza el DCU, se ve reflejada en una estructura de
fases o etapas, en una secuencia cíclica, que tenga la iteración como uno de sus hilos
conductores, los que se reflejan en actividades de diseño.

Se destaca que la usabilidad depende estrechamente del contexto de uso, es decir, del
entorno de trabajo y usuarios concretos y que por tanto no es una cualidad inherente al
software. Es por esto, que podemos deducir que es preciso aplicar un Proceso DCU, que
permita incluir al usuario desde las etapas tempranas de desarrollo y con esto conocer
ampliamente el contexto de uso.

A continuación, una descripción más detallada de las Especificaciones del contexto de uso
y en breve algunas de las actividades que comprende este enfoque.

1. Especificaciones del contexto de uso

Tiene como objetivo comprender y registrar las características del contexto previsto de uso,
es decir el entorno de trabajo, estas especificaciones implícitamente se pernean en el
Software final, ya que tienen un carácter relevante para la usabilidad y por ende, para el
producto final ya que se deben considerar en las tareas de diseño.
El contexto de uso se define en el estándar ISO 13407 [ISO, 99] el cual consta de los
siguientes componentes:

Las características de los usuarios a los que está dirigido el Software. La

identificación de estas características se conoce como Análisis de Usuarios.

Las tareas que los usuarios van a realizar. El Análisis de Tareas se ocupa de este
asunto.

El entorno en que los usuarios van a utilizar el sistema, incluyendo el Hardware,

Software y materiales que se van a utilizar.

En los siguientes apartados, se describirá en mayor profundidad y especificidad las

subactividades de Análisis de los Usuarios y Análisis de las Tareas.

1.1. Análisis de los Usuarios

El Análisis de los Usuarios identifica sus conocimientos, necesidades y características

relevantes en su interacción con el sistema. Es importante identificar la destreza,
experiencia, formación, conocimiento del dominio, características físicas, preferencias,
actitudes, entre otras. De manera, que el sistema se adapte a sus usuarios.

Otro de los factores relevantes, es el tipo de Hardware y Software a utilizar, además de la

experiencia que estos tengan con sistemas similares, con el fin de cumplir a cabalidad las
expectativas de los usuarios que utilizaran el sistema.

También el entorno físico es importante, a pesar de no ser una característica directa del
usuario, pero se enfoca a consideraciones de elementos como por ejemplo: niveles
excesivos de ruido, luminosidad, entre otros, básicamente lo relacionado con las
herramientas que utilizan los usuarios para llevar a cabo sus tareas.

El entorno laboral-social, es importante en caso de restricciones por parte de la

organización, básicamente esto refiere a problemas causados por el tipo de trabajo que se
efectúa, así como también las relaciones entre usuarios, interrupciones constantes entre
usuarios, etc. Básicamente todo lo relevante y que pueda ser considerado y de importancia
para el sistema futuro.
El Análisis de usuario trae consigo una clasificación de éstos, trayendo consigo la
definición de tipos de usuarios, conformado por grupos de usuarios relevantes que calzan
en un perfil dado. En algunos casos, donde se considera una estratificación de una serie de
grupos de relevantes, trae consigo molestias, dependiendo del número de usuarios objetivo,
por el hecho de tener que realizar un estudio de sí mismos, además de tener que aplicar un
Análisis de Usuario sobre cada grupo.

1.2. Análisis de las tareas

Este tipo de Análisis tiene como fin el obtener una descripción de lo que los usuarios hacen
para llevar a cabo sus tareas. Según Preece [Preece, 94] “obtener descripciones de lo que
las personas hacen, representar estas descripciones, predecir dificultades y evaluar los
sistemas contra requisitos de usabilidad o funcionales”.

El Análisis de Tareas se encuentra relacionado con la Especificación de Requisitos y la

Educción, pero tiene la característica clave de centrar este tipo de actividades en los
objetivos últimos del uso del sistema por parte del usuario. Por esto es importante destacar
que la funcionalidad no tiene la misma finalidad que una tarea., ya que la funcionalidad
tiene sentido en el usuario mismo y la tarea en el sistema.

La descripción de las tareas debe incluir el rol que el usuario desempeña en la ejecución
global de la tarea, no en términos de las funcionalidades provistas por un producto o
sistema. Este puede considerarse como orientado a las funcionalidades. En resumen, el
Análisis de las tareas debe estar siempre enfocado a los objetivos de los usuarios.

2. Especificaciones de Usabilidad

Las Especificaciones de Usabilidad son objetivos de usabilidad cuantitativos,

transformándose en una guía para poder determinar cuándo un sistema alcanza los niveles
de usabilidad adecuado. Pueden ser consideradas un subconjunto de los requisitos no
funcionales de un sistema.

Sus componentes son por un lado la eficiencia del usuario y por otro su satisfacción. En el
caso de la eficiencia, esta es interpretada como el nivel de eficiencia deseado del sistema,
en conjunto con el usuario del cual tienen como propósito llevar a cabo los objetivos del
usuario mismo. Por el lado de la satisfacción hace alusión al cumplimiento que se espera de
la funcionalidad del sistema Software.

Las Especificaciones de Usabilidad se definen sobre tareas específicas definidas a partir de

las descripciones de tareas generales obtenidas en las actividades de Especificación del
Contexto de Uso. De manera que dicho contenido sirve como base para esta actividad. En
otras palabras, se definen según las características de la población de usuarios obtenidos en
el Análisis de Usuarios, y según los objetivos y tareas identificadas en el Análisis de
Tareas.

El conjunto de Especificaciones de Usabilidad representan el criterio de aceptación del

sistema desde el punto de vista de su usabilidad. Son evaluadas al final de cada ciclo del
desarrollo, estableciéndose cuanto progreso se ha hecho hacia el objetivo marcado
usabilidad. De esta forma, sirven como criterio para determinar cuándo se deja de iterar.

Cabe destacar que los atributos de usabilidad no son directamente medibles, a diferencia de
las Especificaciones de Usabilidad, por lo tanto estos atributos de usabilidad se
descomponen en subatributos y se particularizan por tareas específicas, basándose en los
resultados de la Especificación del Contexto de Uso. Con esto, se pueden medir
indirectamente los valores de los atributos de usabilidad. Cada Especificación de
Usabilidad está ligada a un atributo de usabilidad concreto pero referido a un aspecto
particular del atributo en cuestión.

3. Prototipado

En el estándar ISO 13407 [ISO, 99] se define un prototipo como “una representación de
todo o parte de un producto o sistema que, aunque limitado de algún modo, puede utilizarse
con fines de evaluación”. Los prototipos permiten a los diseñadores comunicarse de una
manera más efectiva con los usuarios, reduciendo la necesidad y el costo que conlleva
rehacer un sistema ya implementado, en caso que se identifiquen problemas.

El prototipado se encuentra íntimamente ligado con el desarrollo iterativo. Es por esto que
el enfoque de Prototipado en el desarrollo de sistemas interactivos implica, al menos, una
versión inicial del sistema que representa las características principales del futuro sistema.
Es más, un objetivo importante de las actividades de Especificación del Contexto de Uso,
es asegurar que el sistema propuesto tenga toda la funcionalidad necesaria para llevar a
cabo las tareas que el usuario quiere realizar. El prototipado ofrece un medio para asegurar
este objetivo, ya que puede servir para deducir información sobre [Preece, 94]:

Las funcionalidades necesarias del sistema.

Secuencias de operaciones de soporte al usuario.

Representaciones necesarias.

Aspecto y sensación (look and feel) de la Ingeniería de la Usabilidad.

4. Evaluación de la usabilidad

La usabilidad es un concepto complejo, debido a la naturaleza compleja de los seres

humanos. Sin llevar a cabo algún tipo de evaluación es imposible saber si el sistema
satisface las necesidades de los usuarios y si encaja adecuadamente en el contexto físico,
social y organizacional en la que va a ser usado [Preece, 94]. Sin importar el énfasis que se
le dé a las actividades de Usabilidad en el proceso de desarrollo, no se puede predecir con
exactitud el nivel de usabilidad del sistema por adelantado. Es por esto, que es necesario
realizar actividades de Evaluación de Usabilidad a lo largo de todo el desarrollo,
especialmente al final de cada ciclo iterativo, para conocer qué nivel de usabilidad ha
alcanzado el producto, y cuánta mejora será necesaria para cumplir los objetivos de
usabilidad establecidos.

Es necesario realizar Evaluaciones de usabilidad en todas las etapas del desarrollo, cada una
con una distinta formalidad.

Para tener una apreciación más completa presentaremos la Rauch, Soderston y Hil [Rauch,
96]:
Actividad Contenido

Identificar las necesidades de los Identificar los grupos de usuarios, las

usuarios y su contexto necesidades de los mismos, y la
formación y capacitación que tienen
sobre la cuestión. Conocer su
experiencia y sus preferencias.

Analizar las tareas de los usuarios Observar y estudiar las tareas que llevan
a cabo los usuarios, en su propio
contexto. Debe contemplar los objetivos
de los usuarios, y el flujo de tareas, y sus
secuencias, que desarrollan los usuarios
para cumplir sus objetivos.

Establecer objetivos mensurables Fijar parámetros mensurables, que

puedan aplicarse como criterios de
calidad en el cumplimiento de los
objetivos y de las tareas, y en la
satisfacción de los usuarios.

Crear prototipos de la interfaz de usuario Desarrollar prototipos del sistema, tanto

en papel, como interactivos. Permite
probar varias propuestas.
 Probar y testear la propuesta Desarrollo de tareas reales, con objetivos
reales, sobre interfaces plenamente
operativos, y con grupos de usuarios
reales.

Redefinir, mejorar y probar la nueva Redefinir el prototipo con los resultados

propuesta. obtenidos en la actividad anterior. Los
cambios pueden producir consecuencias
inesperadas, por lo que es necesario
volver a repetir la prueba y test, en ciclo
iterativo.

Tabla 1: Actividades clave en el diseño centrado en el usuario.

Esta propuesta es sólo una de la gran cantidad de propuestas existentes, la cual refleja las
principales etapas del DCU. Cabe destacar que estas actividades se encuentran íntimamente
ligadas con las técnicas de evaluación de usabilidad, donde según autores como Xavier
Ferré [Ferré, 05] proponen distintas clasificaciones para evaluar la usabilidad de un sistema
software. Es por esto, que este autor ofrece una búsqueda mediante vistas para elegir las
técnicas de usabilidad más adecuadas y apropiadas para el proceso de desarrollo y la
organización, un ejemplo de esto es la búsqueda por Actividades, donde notamos el
acoplamiento entre las actividades y técnicas respectivamente.

2.2.3.2. Técnicas de Usabilidad

La evaluación de la usabilidad constituye la etapa más importante en el proceso de DCU, se
puede realizar a través de varios métodos o técnicas y sobre diferentes representaciones del
sistema (prototipos en papel, prototipos software, etc.).

Uno de los principales factores es el usuario, es muy importante que al momento de realizar
estas experiencias, no se encuentre presente nadie que no esté directamente vinculado con
la evaluación, puesto que puede cambiar la actitud del usuario.
Como mencionamos con anterioridad, existe una amplia gama de técnicas de evaluación de
usabilidad que pueden ser aplicadas al DCU. Es por esto, que solo ilustraremos algunas de
estas técnicas, considerando solo aquellas que sean más reconocidas y de mayor utilidad.
Es importante aclarar la diferencia entre métodos y técnicas. Los métodos están enfocados a
evaluar uno o más aspectos (eficiencia, eficacia, facilidad de uso, etc.) de la usabilidad y las
técnicas son utilizados por los métodos para lograr estos objetivos. Cabe destacar que estos
métodos no son exclusivos entre sí. Se pueden unir, complementar o simplemente tener en
cuenta mientras se aplican otros, dependiendo de la experiencia de los examinadores, los
diseñadores, desarrolladores y el tiempo disponible para realizar las evaluaciones, entre
otros.

3 tipos de métodos de evaluación de usabilidad: Métodos de inspección, indagación y Test,

los cuales se describen en mayor detalle a continuación:

1. Métodos de Inspección: Conjunto de métodos o técnicas donde grupo de expertos en

usabilidad se dedica a la revisión y análisis del Sistema Software o prototipos que se
encuentren disponibles al momento de la evaluación.

Dentro de estos métodos se encuentran:

a) Evaluación Heurística: Los especialistas en usabilidad, basándose en su propia

experiencia y guiándose por un conjunto de heurísticas establecidas, juzgan si cada
elemento de la interfaz de usuario sigue los principios de usabilidad establecidos
identificando errores y ventajas del sistema. La evaluación heurística puede ser utilizada en,
prácticamente, cualquier momento del ciclo de desarrollo, aunque probablemente se adapta
mejor en etapas tempranas, cuando no hay material lo suficientemente firme para efectuar
alguna prueba. Su gran ventaja es la facilidad y rapidez con la que se puede llevar a cabo.

Consiste en lo siguiente:

Cada evaluador realiza individualmente una revisión de la interfaz.

Al terminar las evaluaciones se permite a los evaluadores comunicar los resultados y

sintetizarlos.
 Este procedimiento es importante para asegurar evaluaciones independientes e
imparciales de cada evaluador.

Los resultados de la evaluación se pueden registrar con informes escritos de cada

evaluador o haciendo que los evaluadores comuniquen verbalmente sus comentarios a
un observador mientras realizan la evaluación.

b) Recorrido Cognitivo: Técnica de revisión donde los evaluadores expertos construyen

escenarios para las tareas a partir de una especificación o de un prototipo temprano para
desempeñar después el papel del usuario trabajando con la interfaz en cuestión (navegación
a través de la interfaz). Actúan como si la interfaz estuviera completamente construida y
asumen el papel del usuario tipo como si estuvieran trabajando a través de las tareas que
estos realizan comúnmente. Teniendo como objetivo encontrar los principales
impedimentos que no permitan realizar el trabajo que el usuario quiera llevar a cabo.

La entrada a una sesión de recorrido cognitivo consiste en:

Un diseño detallado de la interfaz (prototipo).

Un escenario de la tarea o tareas.

Suposiciones explícitas acerca de la población de usuarios y el contexto de uso.

Secuencia de acciones que el usuario tiene que realizar satisfactoriamente para

completar la tarea designada.

Para cada acción el analista explicará la interacción que el usuario puede realizar
típicamente con la interfaz, que va a intentar realizar y que acciones están
disponibles.

Si el diseño de la interfaz es bueno, las intenciones del usuario provocarán que se

seleccione la acción apropiada.

c) Inspecciones formales: Las inspecciones formales de usabilidad toman la metodología

de inspección del software (inspecciones de código) y la adaptan a la evaluación de
usabilidad. Los inspectores recorren meticulosamente las tareas con los propósitos y
objetivos de los usuarios en mente, donde el énfasis radica en el hallazgo de errores. Esta
técnica puede ocupar características de otros métodos para complementar los resultados y
puede ser ocupada en todo el ciclo de desarrollo del sistema.

Consiste en lo siguiente:

Constitución del equipo de trabajo: grupo de personas (diseñadores, ingenieros, etc.)

que aportan su perspectiva para descubrir defectos de usabilidad.

Asignación de funciones: Cada miembro del equipo debe adoptar una función durante
la evaluación y las reuniones de equipo que se hagan. Algunas de estas funciones son:
Moderador, Propietario, Encargado de registro, Inspector.

Distribución de documentación: Es la documentación necesaria para realizar las

evaluaciones (prototipos en papel, perfil de los usuarios, contextos de uso,
heurísticas, etc.)

Inspección: Cada evaluador realiza su trabajo en forma individual asumiendo la

función que se le fue asignada y de acuerdo a los documentos de evaluación. El
evaluador debe registrar todos los defectos encontrados en un formulario entregado al
comienzo de la evaluación.

Reunión Formal: Se realiza una reunión final donde el moderador conduce al grupo a
través de cada escenario y sus respectivas tareas y los evaluadores informan de los
defectos encontrados en los escenarios.

Asignación de prioridades: Se les asigna prioridad a los defectos encontrados y

pasan a ser de responsabilidad del equipo pertinente.

d) Inspección de consistencia: Técnica que verificar la consistencia entre un grupo de

interfaces procedentes del mismo tipo de sistema en terminología, colores, esquemas,
entradas, manuales de usuario, sistema de ayuda, etc.

Este análisis se utiliza para decidir la forma de realización de una determinada función de
los sistemas. Se utiliza en etapas previas de desarrollo, donde el sistema no se haya
comenzado a desarrollar, debido a que así si se requieran grandes cambios con respecto a
consistencia no tengan que ser modificados en su totalidad.
Consiste en lo siguiente:

Se empieza constituyendo un equipo de inspección, disponiendo miembros de cada

equipo de desarrollo para todos los productos cubiertos por la inspección.

Estos miembros habrán de tener la autoridad para negociar a favor o en contra de los
diferentes elementos de diseño, así como el poder de introducir cambios en su diseño
del producto en una posterior reunión de revisión.

Cada producto será analizado por un profesional de la usabilidad, al igual que la

respectiva interfaz de usuario. Este documento inicial servirá de base para las
discusiones del equipo durante una reunión posterior.

Durante dicha reunión se habrá de llegar a un acuerdo para cada elemento acerca de
su apariencia y modo de trabajo en todos los productos. Dicho acuerdo habrá de ser
unánime y de forma previa a la reunión se habrá procurado su aceptación por parte de
los equipos de desarrollo de los productos.

2. Métodos de Indagación: Descritos con anterioridad en el apartado del ciclo de vida del
DCU conocer al usuario.

3. Métodos de Pruebas (Test): En estas técnicas se emplean a usuarios representativos

que trabajan en tareas utilizando el sistema y los evaluadores utilizan los resultados para ver
como la interfaz soporta a los usuarios con sus tareas. Por otra parte, debido a su gran coste
es recomendable realizarlo siempre después de otro método de evaluación.

Entre estos métodos podemos encontrar:

a) Pensamiento en voz alta: Se pide a los usuarios que expresen en voz alta sus
pensamientos, sentimientos y opiniones mientras que interaccionan con el sistema. Esta
técnica puede ser utilizada en cualquier etapa del ciclo de vida de desarrollo del producto.

Para su realización, es necesario reclutar de 3 a 5 usuarios por cada perfil para así obtener
diferentes puntos de vista, también preparar el material y establecer el escenario para la
prueba. Al llevar a cabo la evaluación es necesario registrar todo lo que el usuario va
comentando durante la ejecución de las tareas y al finalizar, se recomienda solicitar al
usuario que responda un cuestionario completo con respecto a la experiencia realizada
detallando los defectos y hallazgos encontrados. Permite a los probadores comprender
como el usuario se aproxima a la interfaz y que consideraciones tiene en la mente cuando lo
usa. Además de permitir conocer mejor el modelo mental del usuario también permite
conocer la terminología que el usuario utiliza para expresar una idea o función que debería
ir incorporada en el diseño del producto.

b) Interacción constructiva: También conocido como aprendizaje por codescubrimiento.

Es una derivación del “pensando en voz alta”, es necesario reclutar a 2 usuarios que hagan
el Test del sistema conjuntamente. La principal ventaja es que la situación del Test es más
natural que el anterior ya que las personas normalmente verbalizan cuando tratan de
resolver un problema conjuntamente y además hacen muchos más comentarios. Uno de los
inconvenientes es que los usuarios pueden tener diferentes estrategias de aprendizaje y
además requiere el doble de usuarios que el “pensando en voz alta”.

c) Técnica de interrogación: Es una técnica en la que el usuario es interrogado

directamente sobre el sistema utilizado. Esta técnica es generalmente aplicada después de
algún otro método de prueba, como por ejemplo, pensamiento en voz alta. Con ella es fácil
detectar que partes del sistema resultan obvias y cuales son más difíciles de manejar. Es una
técnica que, en comparación con otras, va más allá debido a que al usuario se le interroga
directamente sobre el sistema utilizado. Esta técnica puede ser utilizada en cualquier parte
del ciclo de desarrollo.

• Análisis comparativo de los métodos de evaluación de usabilidad

En la presente tabla ilustramos un análisis comparativo de los métodos o técnicas de

evaluación de usabilidad descrito en el apartado anterior:

Posibles
Método Clasificación etapas de Ventajas Desventajas
aplicación
Evaluación Método de Todo el ciclo -Bajo costo en -Puede obviar
heurística inspección de desarrollo comparación con problemas del
otras técnicas. dominio específico.

-Utilizable en -Si aumentan los

etapas tempranas evaluadores, más
del ciclo. errores se
encontrarán, pero
-Encuentra muchos
los costos se
problemas tipo.
dispararán.

Recorrido Método de Todo el ciclo -Utilizable en -El tiempo

cognitivo inspección de desarrollo etapas tempranas. consumido en la
evaluación.
-Hallazgos en
relación a las tareas -Solo mejora
necesarias para un problemas de
usuario. aprendizaje.

-Identificar más -El proceso puede

claramente las pasar por alto
necesidades de los muchos tipos de
usuarios. problemas.

Inspección Método de Todo el ciclo -Se encuentran una -Dificultad para

formal inspección de desarrollo gran cantidad de conseguir el equipo
problemas tipo. de colaboración.

-Aplicable desde
etapas tempranas
de desarrollo.

Inspección Método de Etapas -Se consigue -La dificultad para

de previas de información para llegar a un acuerdo
consistencia inspección desarrollo. lograr que unánime entre los
productos similares integrantes del
se comporten de grupo.
forma similar.
-Necesidad de
-Se puede utilizar grupo grande de
en etapas previas. inspectores.

-Se centra más en

la forma de
utilización del
producto que en las
posibles mejoras.

Observació Método de Todo el ciclo -Se obtienen datos -Cada usuario

n de campo indagación de desarrollo más claro y puede tener formas
precisos debido a distintas de
que se aplica en el aprendizaje.
entorno de trabajo.

-Puede ser aplicada

desde etapas
tempranas.

Cuestionari Método de Todo el ciclo -Puede llegar a un -Menos flexible

os indagación de desarrollo grupo numeroso. que otros métodos.

-Se obtiene -Si no se cuenta

información con tecnología
requerida. necesaria para
tabular las
respuestas, el
análisis puede
 resultar incómodo.

-Puede pasarse por

alto algunos
aspectos.

Entrevistas Método de Todo el ciclo -Se obtiene -Alto costo de

indagación de desarrollo información de preparación.
manera directa.
-Un alto nivel en su
-Puede ayudar a estructura puede no
encontrar ser adecuado para
problemas no los entrevistados,
previstos en el pudiendo reducir
diseño. la obtención de
información.

Pensamient Método de Todo el ciclo -Se encuentra una -Puede tornarse un

o en voz prueba (Test) de desarrollo gran cantidad de poco lenta debido a
alta problemas de su forma de
usabilidad. ejecución

-Se puede -Los diferentes

determinar el usuarios pueden
porqué de los tener diferentes
problemas formas de
encontrados aprendizaje.

-La terminología
puede ser utilizada
en el diseño y
documentación

-Fácil y económico
 en su aplicación.

Interacción Método de Todo el ciclo -Puede revelar más -Puede tornarse un

constructiva prueba de desarrollo información con poco lenta debido a
respecto a la su forma de
técnica de ejecución.
pensamiento en voz
-Los diferentes
alta.
usuarios pueden
-Se encuentra una tener diferentes
gran cantidad de formas de
problemas de aprendizaje.
usabilidad.

Tabla 2: Tabla comparativa de los Métodos de evaluación de usabilidad.

Este es el primer alcance de la amplia gama de técnicas de usabilidad existentes. En los

apartados posteriores, se presentará un estudio y análisis más detallado de las técnicas más
características.

2.2.3.3. Técnicas de Validación para la Satisfacción del Usuario

Este apartado no está enfocado desde la perspectiva de la usabilidad. Por tanto, se entrará
en detalles en las dos técnicas más conocidas para validar la satisfacción de los usuarios:
cuestionarios y encuestas.

1. Cuestionarios

Los cuestionarios en el proceso de validación para la satisfacción de los usuarios, son una
práctica común socorrida por los desarrolladores, así como para un investigador con su
respectiva investigación.

Se deben tener en cuenta los siguientes aspectos a la hora de diseñarlos:

a) Confiabilidad: Una pregunta es confiable si significa lo mismo para todos los que la van
a responder. Se puede confiar en una escala cuando produce constantemente los mismos
resultados al aplicarla a sujetos similares. La confiabilidad implica consistencia. El
investigador debe asegurarse que el tipo de persona a quien se le van a hacer las preguntas
tenga la información necesaria para poder responder. El asegurar la respuesta de los que se
les aplique el cuestionario redundará en resultados confiables. Para la confiabilidad de los
resultados hay que determinar por qué no todos respondieron el cuestionario. Es necesario
investigar con los no respondientes para conocer las razones. Un cuestionario largo es
demasiado cansado y las preguntas finales se responden sin entusiasmo, lo cual le resta
confiabilidad.

b) Validez: Una pregunta es válida si estimula información exacta y relevante. La

selección y la redacción influyen en la validez de la pregunta. Algunas preguntas que son
válidas para un grupo de personas, pueden no serlo para otro grupo. Entre menos tenga que
reflexionar el sujeto, más válida será la respuesta.

La validez implica congruencia en la manera de plantear las preguntas. Puede ser:

1. De contenido.

2. De criterio.

3. De constructo.

Para decir que un instrumento tiene validez de contenido el diseñador del cuestionario debe
asegurarse que la medición representa el concepto medido. Por ejemplo, si el instrumento
es para medir actitudes de las personas, debe medir eso y no sus emociones. En cuanto a la
validez de criterio, el diseñador del cuestionario la puede establecer comparando la
medición del instrumento con un criterio externo. Entre más se relacionen los resultados de
la investigación con el criterio, mayor será a validez del instrumento. La validez del
constructo indica cómo una medición se relaciona con otras de acuerdo con la teoría o
hipótesis que concierne a los conceptos que se están midiendo. De ahí que sea importante
que el investigador tome en cuenta dichos conceptos para correlacionarlos posteriormente.
x Cuatro preguntas clave:

1. ¿De cuánto tiempo disponen quienes responderán para contestar el cuestionario?

2. ¿Cuánto tiempo tiene el investigador para editarlo, presentarlo, aplicarlo, codificarlo,

procesarlo y analizarlo?

3. ¿Qué tan dispuestos están para responder quienes van a contestar?

4. ¿Cuánto costará su aplicación?

x Antes de diseñar el cuestionario: Es necesario determinar si el cuestionario tendrá

preguntas abiertas o hacer las preguntas abiertas con una muestra de la población. Con
estas respuestas, se pueden diseñar las preguntas cerradas. Es necesario estar seguros de
que los encuestados respondan. Por eso es importante conocer las opiniones de los
posibles sujetos acerca del tema a investigar, antes de diseñarlo. El contacto inicial es
fundamental para lograr que los encuestados respondan. Hay que preparar una
explicación para los encuestados sobre la importancia de su participación y lo que se
hará con los resultados de la investigación. En esta explicación se les debe asegurar el
anonimato de su participación y ofrecerles una copia del resumen del trabajo cuando
esté terminado (habrá que cumplir esta promesa) cerradas. Para el análisis de las
preguntas es mejor que éstas sean cerradas. Para cerrarlas, primero se deben No es
conveniente mencionar que se está llevando a cabo este trabajo para cubrir un requisito
de graduación (tesis), sino la importancia real del estudio. Todo cuestionario debe
hacerse con ese propósito en mente. El investigador tiene que pensar en cómo va a
presentar los resultados antes de elaborar el cuestionario. Hay que involucrar a alguien
que sea responsable de capturar la información de los cuestionarios así como a una
persona que haga el procesamiento de los datos en la computadora. Ellos pueden ayudar
a determinar la mejor presentación de cada una de las preguntas. Eso no lo va a hacer
un asesor de tesis; es indispensable la ayuda profesional de un experto en cómputo y en
estadística.
x Diseño del cuestionario: El título del trabajo debe estar al inicio del cuestionario. Hay
que incluir instrucciones breves, pero incluirlas. Es conveniente usar una tipografía
diferente a la de las preguntas. Al inicio deben colocarse preguntas interesantes, no
amenazantes. Los puntos importantes deben ir cercanos al inicio del cuestionario,
después de las preguntas interesantes. Hay que numerar las preguntas. Es importante
agrupar las preguntas en secciones lógicas. Debe haber una categoría para cada posible
respuesta, pues si se omite una opción, se forzará al que responde a contestar de una
manera que no refleje su respuesta. Por eso en ocasiones se necesita abrir una opción de
"otros" con un renglón amplio para dejar esa parte de la pregunta abierta. También, a
veces, es necesario incluir una opción de "no sé", pues si no existe ésta, el sujeto puede
seleccionar cualquier respuesta simplemente para no dejarla en blanco.

Se debe asegurar que cada opción que se presente sea excluyente cuatro puertas. Hay que
balancear las escalas utilizadas en las opciones de respuesta, incluyendo el mismo número
de opciones de cada lado.

2. Encuestas

En la encuesta se procede a la reunión de datos individuales para obtener durante la

evaluación datos agregados. El objeto de la evaluación no es sólo la descripción sino
también el descubrimiento o la comparación de relaciones. Cabe hacer una distinción entre
preguntas de hechos y preguntas de opinión. Las primeras se refieren a hechos
comparables, pudiendo relacionarse con el encuestado mismo, por ejemplo su edad. En las
preguntas de opinión se exige una toma de posición subjetiva. A esta categoría pertenecen
las preguntas de opiniones y apreciaciones de hechos objetivos, actitudes, deseos,
sentimientos, motivos y normas de comportamiento individual.

Por encuesta se comprenden procedimientos particulares muy diversos, que se pueden

clasificar según cuatro criterios:

Según el grado de estandarización se diferencian:

x Entrevistas no dirigidas: Con finalidad explorativa, se indica un tema sobre el que se
conversa libremente. Entrevista intensiva: Se dispone de un esquema fijo, pero las
preguntas aún no están estandarizadas.

x Encuesta estandarizada: Por medio de cuestionario, la formulación y el orden de

preguntas están dadas al entrevistador. El encuestado tiene un menor grado de
espontaneidad. Garantiza la integridad y comparabilidad de las respuestas y tiene un
mayor grado de fiabilidad.

Una encuesta puede ser realizada de palabra o por escrito:

x En la encuesta oral: El entrevistador realiza preguntas y apunta las respuestas.

x En la encuesta escrita: El encuestador rellena el cuestionario previamente preparado.

Este tipo de encuesta es menos costoso económicamente.

Las entrevistas pueden ser realizadas con individuos o con grupos: Dentro de las de grupo
pueden ser por escrito, oral o discusión de grupo.

Finalmente pueden distinguirse la encuesta cínica que representa un corte trasversal

temporal con respecto a la encuesta de panel.

Plan de desarrollo de una encuesta:

La secuencia de las tareas a cumplir en la realización de una encuesta desde las primeras
etapas del planeamiento hasta la preparación del informe final.

x Objetivos generales: Se establecen los problemas que hacen necesaria una encuesta, así
como sus objetivos generales. Esta enunciación habitualmente se expresa en términos
amplios y sólo define el área general y el alcance del proyecto.
x Objetivos específicos: Aunque los objetivos generales, habitualmente pocos en número,
se formulan sin considerar los requerimientos de la técnica de la encuesta, éstos deben
tomarse en cuenta cuando los objetivos generales se dividen en objetivos específicos,
casi siempre numerosos. En esta etapa se especifican todos los datos que deben reunirse
y las hipótesis que deben verificarse a través de la encuesta.

x Muestra: En relación con la muestra deben adoptarse dos decisiones:

Cuál será el universo de la encuesta.

El tamaño y el diseño de la muestra que debe extraerse.

Tras adoptar estas decisiones, se cumple el proceso real de obtener las unidades de la
muestra y la preparación de mapas delimitados, listas de unidades, etc.

x Cuestionario: Se determina el método mediante el cual se tomará contacto con la

muestra (entrevista personal, por teléfono o correo) y se prepara un cuestionario. La
confección de un cuestionario no consiste simplemente traducir a un lenguaje
comprensible para los entrevistados los objetivos específicos; debe construírselo
cuidadosamente, considerando el tipo de preguntas, el grado de exploración, la
secuencia y el establecimiento del rapport. El proyecto del cuestionario se prueba en el
campo antes de su uso real.

x Trabajo de campo: Cuando es necesario realizar entrevistas personales, es preciso

instruir a los entrevistadores tanto en los procedimientos generales de la entrevista,
como sobre los problemas específicos de una encuesta determinada. Debe
proporcionárseles un manual de instrucciones que explique los objetivos del estudio y el
significado de cada pregunta. Se tomarán medidas para lograr una cuidadosa
supervisión de las entrevistas.
x Análisis de contenido: Los datos obtenidos en una encuesta deben ser tan simples como
para transcribirlos fácil y directamente en tablas (o en las tarjetas perforadas mediante
las cuales se hacen las tabulaciones). Pero incluso las encuestas de tipo de los censos
requieren una cuidadosa transcripción, y las de actitudes y opinión exigen análisis de
contenido. Ello se logra mediante la elaboración de un código, lista enumerada de los
principales temas que abarquen todas las repuestas recibidas para cada pregunta.

x Plan de análisis: El cuestionario de una encuesta en una gran escala puede contener 50,
100 o más preguntas. Sería ineficaz tabular la relación entre las respuestas recibidas
para cada pregunta. El plan de análisis íque cuando se usan equipos de tabulación
mecánica supone copiar el programa de la máquinaí contiene los recorridos de la
maquina que son necesarios para verificar las hipótesis enumeradas en el paso 2
(objetivos específicos). Este plan se hallaba implícito en la mente de quién realizaba la
encuesta desde el momento en que comenzó el estudio. Su anticipación del material de
tabulación necesario para lograr los objetivos de la encuesta fue la base de la
preparación del cuestionario y de la determinación del análisis del contenido.

x Tabulaciones mecánicas: Se utilizan los resultados del proceso de codificación para

preparar las tarjetas perforadas y se efectúan las tabulaciones previstas en el paso 7
(plan de análisis).

2.3. Comparación entre el Enfoque del Diseño Centrado en

Usuario y el Clásico
En lo ámbito de la Ingeniería de Software (enfoque clásico IS) el Proceso de Software
establece un marco común del proceso definiendo un pequeño número de actividades del
marco de trabajo, que son aplicables a todos los proyectos del software, con independencia
de su tamaño o complejidad. Por ende, podemos decir que el Proceso de desarrollo es un
mapa, del cual se siguen determinadas actividades para el desarrollo de un sistema
Software.
La IS se caracteriza por aplicar un enfoque sistemático, disciplinado y cuantificable al
desarrollo de Software. El proceso de desarrollo se puede definir a distintos niveles,
existiendo una gran diversidad de procesos de desarrollo definidos en la literatura para la
construcción de sistemas Software. Dentro de esta variedad se pueden identificar elementos
comunes, en un proceso definido típicamente, se incluye al menos la descripción de las
actividades que hay que llevar a cabo, junto con las técnicas que se aplican en cada
actividad. Además, cada proceso tiene una terminología propia para cada actividad, la cual
depende del nivel al que esté definido y de las condicionantes del desarrollo en los que se
basa. A pesar de la diferencia de terminología, sin embargo, las actividades de un proceso
pueden típicamente enmarcarse en tipos genéricos de actividades como son: Actividades de
análisis, de diseño, y de evaluación. Un Ingeniero Software puede acomodar las actividades
que formen parte del proceso de desarrollo definido en su organización a tipos genéricos de
actividades de este tipo, puesto que forman parte del cuerpo de conocimiento de las IS.

Por otro parte, los procesos que incluyen las actividades y técnicas de usabilidad tienen un
enfoque distinto a las utilizadas normalmente en la IS, este tipo de proceso de desarrollo se
enmarca en el área de Human Computer Interaction (HCI) donde, la usabilidad es una de
las máximas preocupaciones y su principal objetivo es diseñar Sistemas Informáticos que
den soporte a personas de tal forma que éstas puedan llevar a cabo sus actividades
productivamente y con seguridad personal. El área HCI es de carácter multidisciplinario,
donde se proporcionan todos los puntos de vista que se requieren para el desarrollo de
Sistemas Informáticos. HCI comprende distintos campos del saber, entre ellos, la
Informática, la Psicología, la Sociología o el Diseño Industrial y la Ergonomía. De manera
que con esto, se provee un soporte adecuado a las personas según las condicionantes
involucradas entre sus objetivos.

La visión de HCI respecto al desarrollo de Software, limitándose al Proceso Centrado en el

Usuario, es más amplia que el enfoque habitual de la IS, ya que, por parte de la IS, la
atención se centra en gran medida en el sistema en ejecución, sin considerar las
implicaciones sociales y organizacionales respecto a una tarea del sistema en general, así
como también las limitaciones del ser humano en el procesamiento de la información,
además de los problemas en cuanto a comunicación se refiere. Es por esto, que los Procesos
Centrados en el Usuario tienen una mayor amplitud respecto a los temas abarcados, pero es
menos especifico respecto a la construcción del software en sí, denotando una gran
diferencia con respecto a la visión de la IS quien profundiza en mayores detalles, por tanto,
una de las diferencias más relevantes entre estos procesos, es que no poseen el mismo nivel
de detalle en sus actividades y procesos. Es por esto, que los Procesos de Centrados en el
Usuario no poseen un consenso respecto a sus actividades y técnicas, por lo que existe una
gran variedad de éstas que se aplican en cada actividad entre los distintos autores del campo
HCI.

Por otro parte, los Procesos Centrados en el Usuario no son procesos completos, en el
sentido que estos se ocupen de todos los aspectos del desarrollo. Puesto que, en algunos
casos, los autores tienden a tomar una perspectiva donde el trato con los usuarios solo se
realiza en las actividades HCI dejando así lo demás (lo abarcable) por parte de los procesos
de desarrollo de la IS, además de realizar un diseño que se acomode a las especificaciones
de las actividades HCI.

Cabe destacar que por objeto de estudio, no profundizará en la temática de la integración y

consenso de estas técnicas sino más bien en la metodología misma del DCU que
analizaremos más adelante.
Capítulo 3
Casos de Estudio

El impacto del enfoque del Diseño Centrado en el Usuario y la comparación con el enfoque
clásico se mide sobre casos de estudio específicos, es por esto, que es necesario tener al
menos un par de opciones tentativas para su elección.

A continuación, en el apartado posterior se presentan cuatro casos de estudio tentativos.

3.1. Sitio Web para el Control de Remuneraciones

Multiempresas
En organizaciones de este tipo se realizan procesos del ámbito contable, legal y tributario,
donde las remuneraciones son realizadas mensualmente, dependiendo de la cantidad de
clientes que posean, ejemplo de esto son: las liquidaciones de sueldo, planillas de pago, etc.

El proceso de remuneraciones es abordado ya sea tanto por organizaciones de mayor

envergadura así como también para pequeñas y medianas empresas (Pymes).

Este caso de estudio es llevado a cabo por un estudio contable y tributario se basa en Pymes
del sector privado.

La posible elección de este sistema se basa en darle una solución a la problemática más
frecuente en el mercado del software existente en la actualidad, “el producto final sea el que
realmente quiere el usuario”. Esta se ve con mayor frecuencia en este tipo de sistemas,
donde en muchas ocasiones parte de sus módulos no son ocupados o los módulos ofrecidos
no cumplen con las necesidades reales de los usuarios que trabajan en ellos. Es por esto,
que un enfoque DCU provocaría un incremento en la usabilidad en este tipo de sistemas.
3.2. Sistema Web en e-commerce
El comercio Electrónico (e-commerce) consiste principalmente en la “distribución, compra,
venta, mercadotecnia y suministro de información complementaria” para productos o
servicios impulsada por la interacción de agentes económicos a través de redes informáticas
privadas o públicas.

Este caso de estudio es llevado a cabo por un alumno de la carrera el cual desarrollará un
sitio Web basado en e-commerce.

La posible elección de este sistema como caso de estudio es la creciente necesidad de los
usuarios por la utilización de sitios Web que cumplan y satisfagan sus necesidades. Es más,
es de vital importancia en los sitios donde se promueve el comercio electrónico cumplan
con los atributos de calidad y por ende proporcionen toda la información solicitada por los
usuarios. Además de tener una mayor accesibilidad por distintos tipos de usuarios.

3.3. Sitio Web para una Empresa Privada

La Empresa Privada de carácter confidencial se dedicada a Servicios Integrales, Tecnología
Servicios Integrales, Tecnología de Optimización de Procesos y Confiabilidad en los
Activos, Equipos de Planta para el Área de la Minería.

En este caso de estudio se requiere la creación de un Sitio Web para el área de Servicio,
para la Intranet Pública de la empresa.

La posible elección de este caso de estudio se basa en la necesidad que tiene el usuario de
un portal que represente el servicio y permita la interacción entre usuarios por medio de
este. Para organización, la información proporcionada por este portal es de gran
importancia, ya que permitiría la accesibilidad e intercambio de opiniones entre los
usuarios, además de exponer esta área de la empresa.

3.4. Sitio Web para el Control de Inventario

Este sistema fue creado para el curso de Ingeniería de Software de la Escuela de
Informática de la Pontificia Universidad Católica de Valparaíso, el cual controla los típicos
procesos de inventario, desde la rotación de artículos hasta el registro de los movimientos
trasladados a bodega.

La posible elección de este caso de estudio se basa en la necesidad de poder comparar un

sistema ya creado, centrado en el Diseño Centrado en Sistemas (DCS) con un enfoque
centrado en el usuario, permitiendo analizar las diferencias respecto a la usabilidad de
ambos sistemas.

3.5. Elección del Caso de Estudio

El caso de estudio elegido para la aplicación del enfoque DCU representa a un Sistema de
Control de Remuneraciones Multiempresas para un estudio contable. En la actualidad el
estudio tributario contable, posee un sistema de remuneraciones comprado a una empresa
desarrolladora de Software, el cual hace un par de meses dejó de funcionar correctamente,
quedando obsoleto. Dicha empresa no presta mantención ni actualización al sistema,
obligando al estudio a adquirir sus nuevos productos, con los cuales no se puede contar por
motivos financieros. Como solución a esta problemática, en acuerdo con el cliente se ha
decidido desarrollar un Sistema de Remuneraciones Multiempresas basado principalmente
en atender a la automatización de la información que este estudio posee, para así poder
cumplir con las disposiciones que las distintas instituciones previsionales exigen a sus
empleadores.

En base, a un estudio realizado por los gestores del caso de estudio, se decidió utilizar el
Paradigma de Proceso Unificado de Desarrollo como modelo de diseño, utilizando UML
(Lenguaje Unificado de Modelado) como herramienta de modelado, y para su construcción
el Lenguaje de programación PHP y PostgresSQL como motor de Base de datos.

Para la comparación del enfoque DCU y el enfoque clásico el caso de estudio elegido es el
Sistema de Control de Inventario. El cual fue construido utilizando como lenguaje de
programación PHP y PostgresSQL como motor de Base de datos.
Capítulo 4
Pautas de Usabilidad

4.1. Elaboración de la Propuesta: Pautas de Usabilidad

La propuesta de este proyecto consiste en la elaboración de pautas de usabilidad, las cuales
se componen por un conjunto de técnicas de usabilidad aplicadas a casos de estudio. Dicho
conjunto de técnicas, en particular necesita un análisis previo tanto por parte de la
integración de éstas al proceso de desarrollo y el área específica de cada caso de estudio,
con el fin de poder elegir y definir esta propuesta.

La integración de las técnicas de usabilidad en las etapas de desarrollo es un factor

importante que afecta de manera directa la aplicación del DCU, pero no es objeto de
nuestro estudio. Por tanto, es necesario tener un alcance respecto a cómo integrar estas
técnicas, de manera que en nuestro estudio, después de hacer una revisión de un gran
número de propuestas, hemos elegido dos de las propuestas más características en esta área:
la propuesta realizada por Xavier Ferré [Ferré, 05] para un desarrollo de software genérico,
y la propuesta realizada por Jesús Tramullas [Tramullas, 92] para sedes Web.

A continuación, se presentará la propuesta del “Marco de Integración de Técnicas de

Usabilidad en el Desarrollo de Software” de Xavier Ferré y posteriormente la propuesta de
Jesús Tramullas, “El Diseño Centrado en el Usuario para la Creación de Productos y
Servicios de Información Digital”.

4.1.1. Propuesta de Xavier Ferré

1. Criterios de Caracterización de las Técnicas de Usabilidad según la Propuesta de
Xavier Ferré

La propuesta de Xavier Ferré clasifica según criterios de caracterización para valorizar las
técnicas de usabilidad definidas en ella. Esta valorización se define de la siguiente forma:
• Participación de los usuarios (PU): Nos referimos básicamente a la implicancia
(participación) activa o pasiva de los usuarios respecto a las técnicas de usabilidad. Medida
con un SI o NO.

• Necesidad de Formación (Estudios y conocimientos del desarrollador): Este criterio

hace referencia a cuánta información necesita un ingeniero de software medio para poder
aplicar la técnica con mínimas garantías de éxito. Medida con los valores:

x Muy alto: Indica que se necesita una experiencia en usabilidad extensa para poder
aplicarse, de manera q se requiere personal experto en la materia para su aplicación.

x Alto: El ingeniero de software requeriría una formación extensa en usabilidad para

poder aplicar la técnica.

x Medio: Indica que se requiere una formación de cierta importancia ante la técnica pero
aun así puede ser aplicada por ingenieros de software medios.

x Bajo: Indica que únicamente es necesaria una formación básica respecto a la técnica
para poder ser aplicada por ingenieros de software medios.

• Aplicabilidad: Este criterio refleja la generalidad de la técnica, esto es, cuánto de

aplicable es un abanico de tipos de proyectos de desarrollo de software. Los valores que
puede tomar son los siguientes:

x Alto: indica que su uso puede resultar de utilidad prácticamente en todo tipo de
proyectos.

x Medio: indica que la técnica es aplicable en ciertos tipos de proyectos, pero en otros
tipos no.
x Bajo: indica que únicamente ciertos tipos de proyectos (porcentaje escaso) son
adecuados para su aplicación.

• Cercanía a la IS: Este criterio refleja si las actividades en los que se basa la técnica
coinciden con los enfoques habituales de la IS. Se mide mediante los siguientes valores:

x Alto: Indica que la técnica puede ser aplicada por los ingenieros de software, puesto
que se basa en habilidades y enfoques típicos de la IS.

x Medio: Indica que, si bien la técnica se basa en actividades que no pertenecen a la IS,
no está tan alejada de la misma como para considerarla ajena al campo.

x Bajo: Indica que la técnica requiere un enfoque de desarrollo y unas habilidades que
son ajenas a los que suelen tener una persona con formación en IS.

• Aportación / Esfuerzo: Este criterio se refiere a la mejora que contribuye en la

usabilidad del producto final aplicar el uso de esta técnica. Los valores para medir este
criterio son alto, medio y bajo.

• Representatividad (Rep.): este criterio refleja cuán comúnmente se aplica la técnica en

el campo HCI. Como indicador de este criterio se ha utilizado él numero de autores del
estudio que aconsejan la aplicación de la técnica, por tanto el valor de este atributo en
numérico y está en el rango 1-6.

• Valoración Total: este criterio recoge un valor agregado de los criterios anteriores, y
refleja el grado de utilidad que la técnica puede aportar al objetivo de la integración de
técnicas y actividades de usabilidad en el proceso de desarrollo, en el caso de una
organización con un enfoque de IS. Puede tomar los valores: muy útil y útil.
• Tipo de actividad: este criterio se refiere al tipo de actividad (definidas en apartado
siguiente) del desarrollo es los que la aplicación de la técnica resulte de mayor utilidad para
el objetivo de mejorar la usabilidad del producto software.

• Etapas de aplicación en un proceso Iterativo (momentos de aplicación): corresponde

al criterio que indica el grado de adecuación a cada uno de las etapas del desarrollo:
momentos iniciales, momentos centrales y momentos de evolución.

Medida desde la perspectiva:

x Especialmente apropiada: implica que dicha técnica puede resultar de máxima

utilidad cuando se aplica en esta etapa del desarrollo.

x Neutra: implica que la técnica puede aplicarse en dicha etapa sin destacar la etapa en
específico como la más apropiada frente a otros momentos de aplicación.

x No es Habitual: implica que la etapa de desarrollo no es la más apropiada donde

aplicar esta técnica.

• Referencia Básica: para cada técnica se proporciona una referencia básica de la

literatura HCI. Está destinada a servir de punto de partida para conocer los puntos básicos
de la técnica y su modo de aplicación (descritas en el Anexo).

Cabe señalar, que los valores por los cuales se miden estos criterios se verán ilustrados en
una tabla resumen en los apartados posteriores.

2. Consideración para la Elección de las Técnicas de Usabilidad en la Propuesta de

Xavier Ferré

Dentro de la propuesta de Xavier Ferré, se estructura la organización de las técnicas de

Usabilidad mediante vistas: por técnicas, por actividades de desarrollo y por momentos de
desarrollo. Una consideración para la elección de las técnicas de usabilidad en este estudio,
es que la organización de estas técnicas será en base, a la vista por actividades de
desarrollo, las cuales proporcionan una mayor visibilidad y ubicación del lugar de
aplicación de estas técnicas para los desarrolladores. Cabe destacar, que solo se consideran
las actividades afectadas por la usabilidad, dentro de las cuales se encuentran las
actividades típicas de un proceso de desarrollo de software habitual (IS) y también las
actividades necesarias para incorporar la usabilidad al mismo (HCI).

a) Actividades de desarrollo

En las distintas organizaciones existe una serie de actividades básicas que aparecen en
todos los procesos de desarrollo, independientes de las distintas terminologías propuestas
por las distintas áreas de la Ingeniería (IS y HCI). Entre las actividades comúnmente
aceptadas (por la IS) las actividades en un nivel más macro son: Análisis o Ingeniería de
Requisitos, diseño y evaluación.

1. Actividades de Análisis o Ingeniería de Requisitos

• Educción de Requisitos: En la Educción de Requisitos se identifican y capturan las

fuentes de requisitos.

• Análisis de Requisitos: El análisis de requisitos, se ocupa de detectar y resolver posibles

conflictos entre requisitos, definir los límites del sistema y cómo debe interactuar con su
entorno, elaborar el paso de requisitos del sistema a requisitos software. Dentro de este tipo
de actividades, se incluyen como subactividades, las actividades de Desarrollo del concepto
del producto, el modelado de las Especificaciones del contexto de uso: actividades de
Análisis de Usuario, Análisis de Tareas, y prototipado como actividades para incorporar la
usabilidad y ofrecer una visión estructurada de la organización de las técnicas de usabilidad
en esta actividad.

x Análisis de Usuarios: Se ocupa de identificar cuáles son los usuarios previstos del
sistema, y para ellos recoger toda la información sobre sus conocimientos, necesidades
y características que sean relevantes en su interacción con el sistema.
x Desarrollo del concepto del producto: En esta actividad se considera la lógica que
seguirá el funcionamiento del sistema, sus espacios de interacción principales y cómo
se trabajará con el mismo. Con el fin de ayudar a que el concepto del producto se
trasmita de forma adecuada al usuario, de manera que se pueda desarrollar un correcto
modelo mental del sistema.

x Análisis de Tareas: Tiene como finalidad obtener descripciones de lo que las personas
hacen para llevar a cabo los asuntos de los cuales se ocupan.

x Prototipado: Esta actividad tiene como objetivo lograr una mejor comprensión de las
necesidades del usuario mediante el uso de prototipos que permitan avanzar hacia una
comprensión común del problema que sé este abordando.

• Especificación de Requisitos: Consiste en la elaboración de un documento que refleja

los requisitos que el sistema debe cumplir, y en particular la estructura, calidad y
verificabilidad de dicho documento.

• Validación de Requisitos: Conjunto de actividades que tienen como finalidad examinar

los requisitos para asegurarse que el sistema es el adecuado o lo que el usuario espera.

El siguiente esquema lo ilustra de forma gráfica:

Fig. 1. Actividad de Análisis o Ingeniería de Requisitos.

2. Actividades de Diseño

x Diseño de la Interacción: Esta actividad se encarga de la definición de los entornos de

interacción y su comportamiento. Al incluir el comportamiento implica coordinar la
interacción entre el usuario y el sistema. También incluye el diseño de los elementos
visuales que forman la interfaz grafica de usuario, cuando la interfaz es de dicho estilo.
Se trata de una actividad relativamente independiente del resto de actividades de diseño,
por lo que tiene un espacio propio dentro de las actividades de este tipo.

El siguiente esquema lo ilustra de forma gráfica:

Fig. 2. Actividad de Diseño.

3. Actividades de Evaluación
• Evaluación de Usabilidad: Se incluyen todas las actividades relacionadas con la
evaluación de la usabilidad del producto software en construcción. Se dividen en 3
actividades:

x Evaluación por expertos: Este tipo de evaluación no requiere la participación de

usuarios representativos utilizando el sistema, y complementa al resto de actividades de
evaluación de la usabilidad que se planteen en un proyecto.

x Test de usabilidad: Incluye todas las variantes de Test de usabilidad con usuarios
representativos. Se trata de la evaluación de usabilidad más característica, necesaria en
cualquier proyecto de desarrollo software que tenga como objetivo un buen nivel de
usabilidad, porque permite probar el software que se va desarrollando en condiciones
similares a las de su uso previsto.

x Estudio de Seguimiento de Sistemas Instalados: Estas evaluaciones se aplican sobre

sistemas o prototipos software ya instalados en el entorno previsto de uso. Permite
recoger datos fidedignos sobre el uso real del software y las dificultades que plantea.

El siguiente esquema lo ilustra de forma gráfica:

Fig. 3. Actividad de Evaluación.

En resumen se presenta un esquema gráfico donde se muestra el conjunto de actividades

por etapas de desarrollo:
Fig. 4. Actividades de desarrollo afectadas por la Usabilidad [Ferré, 05].
En la Fig. 10 se destacan las actividades de Usabilidad que son necesarias introducir en el
proceso de desarrollo por un color blanco y las actividades del desarrollo que son precisas
replantear para considerar la usabilidad en un color plomo claro.

3. Tabla resumen de las Técnicas de Usabilidad por actividades de desarrollo

Tabla 1: Resumen de las técnicas de usabilidad ordenadas por actividad de desarrollo y
Valoración total. [Ferré, 05].
*No se trata de tipos de actividades IS, sino actividades HCI incluidas para ofrecer al
desarrollador una visión estructurada de las 15 técnicas HCI que pueden aplicarse en
actividades de Educción y Análisis de Requisitos.
Tabla 2: Resumen de las técnicas de usabilidad ordenadas por actividad de desarrollo y
Valoración total (Continuación).

4.1.2. Propuesta de Jesús Tramullas

El ciclo de vida que se utiliza para el desarrollo de sedes Web debe combinar aspectos del
proceso de desarrollo de software, y del proceso de publicación. Las características del
hipertexto establecen particularidades que obligan a tener en cuenta ambos esquemas al
estudiar la usabilidad Web. Las grandes fases en que pueden dividirse serían las
correspondientes a Análisis, Diseño, Desarrollo y Mantenimiento.

A continuación se definen las técnicas que se utilizan en cada una de las fases del proceso
sobre la base de la propuesta de J. Tramullas [Tramullas, 92]:
Fase Tareas Técnicas de usabilidad

Análisis de Definición de objetivos Generación de ideas

requerimientos de la sede. (escenarios y
Storyboards, y escenarios
Creación de modelo de
de tareas).
negocio.
Grupos de enfoque
Definición de audiencias
(Focus Group).
y usuarios.
Entrevistas.
Análisis de necesidades
de usuarios. Cuestionarios.

Observaciones de campo
o etnográficas.

Estudios previos.

Normas y estándares

Diseño Análisis de tareas de Análisis de tareas.

conceptual y usuario. Test de prototipos
prototipado
Definición de flujos de (prototipado horizontal,
trabajo. vertical, alta fidelidad,
baja fidelidad, papel).
Definición de arquitectura
de la información. Recorridos cognitivos.

Definiciones de la gestión Desarrollo de escenarios.

de contenidos. Listas de control o
Diseño y prototipado de comprobación.
interfaces de usuario. Evaluación heurística de
Documentación de expertos.
procesos y manuales. Test de usuarios.

Observación.
 Compilación de
manuales y normas
internas.

Desarrollo Creación de interfaces de Evaluación heurística de

usuario. expertos.

Desarrollo de los Inspección (normas,

componentes de diseño características y
gráfico. consistencia).

Desarrollo de contenidos Listas de control o

informativos. comprobación.

Desarrollo de
aplicaciones para
interacción.

Mantenimiento Producción de Control de Logs.

contenidos.
Evaluación heurística por
Revisiones. expertos.

Recorridos cognitivos.

Test de usuarios.

Procesos de Proceso iterativo Proceso iterativo

rediseño de
sede
Tabla 3: Propuesta de integración de evaluación de usabilidad en el proceso de diseño y
creación de sedes Web (tomada de [Tramullas, 02] y modificada por el autor).
La tabla 5 muestra que el esquema propuesto resulta ser una aproximación genérica, lo que
obliga a contextualizar el mismo en cada proyecto en el que se aplique, atendiendo a sus
características.

En esta propuesta los métodos de usabilidad alcanzan su mayor importancia para el

desarrollo en las dos primeras fases, las cuales establecen los objetivos y el diseño
conceptual de la sede Web. Las técnicas seleccionadas para ambas fases permiten el diseño
participativo en colaboración de los usuarios, atendiendo a las características del producto,
limitando la participación de grupos de expertos, intentando contrarrestar una tendencia
común en la actualidad, motivada por cuestiones económicas. Debe destacarse el interés,
además de crear normas y manuales internos para asegurar la usabilidad de la sede, con la
metáfora de los libros o guías de estilo, pero aplicados a la interacción del usuario y a la
usabilidad.

Cabe destacar, que la Tabla 5, fue modificada por el autor del estudio, con el fin de señalar
algunas similitudes, en cuanto a terminología, de algunas técnicas respecto de la propuesta
de Xavier Ferré.

4.1.3. Margen Comparativo entre la Propuesta de Xavier Ferré y Jesús

Tramullas
Después de revisar y comparar ambas propuestas encontramos una serie de diferencias, que
hace necesario realizar un ajuste para poder tener una misma definición o margen entre los
conceptos que se utilizarán en el posterior análisis de la propuesta de este proyecto. Una de
las más importantes, son las actividades de desarrollo. Para este caso, este ajuste es respecto
a la Propuesta de Xavier Ferré, ya que se considera más adecuada su clasificación y
definición por lo amplio de su concepto. En la propuesta de Xavier Ferré las actividades
son las actividades de Análisis, diseño y evaluación, las que se establecen para este estudio
y posterior análisis, por tener una representación más genérica y ser mayormente utilizadas
en la IS, en cambio, la propuesta de Jesús Tramullas, estas actividades difieren en los
límites de cada una de ellas (respecto a las actividades de la propuesta que se establece para
el análisis posterior), donde las actividades de desarrollo son las siguientes: actividades de
análisis, diseño, desarrollo y Mantenimiento. Por tanto, comprendiendo el concepto que
estas actividades son similares y la definición de cada una en particular son semejantes,
hace posible su reagrupación, lo que hace factible establecer una misma definición para
ambas propuestas. De donde se desprende, que para el caso de la propuesta de Jesús
Tramullas las actividades de desarrollo se consideran de la siguiente manera:

x Análisis: Corresponden a las actividades de análisis de requisitos y diseño conceptual y

prototipado.

x Diseño: Corresponden al diseño conceptual y prototipado, y a las actividades de

desarrollo.

x Evaluación: Corresponden a las actividades de mantención.

Por lo tanto las técnicas quedan de la siguiente manera:

1. Análisis

Generación de ideas (Escenarios y Storyboards).

Grupos de enfoque (Focus Group).

Entrevistas.

Cuestionarios.

Observaciones de campo o etnográficas.

Estudios previos.

Normas y estándares.

Análisis de tareas.

Test de prototipos (prototipado horizontal, vertical, alta fidelidad, baja fidelidad,

papel).
 Desarrollo de escenarios (Escenarios de tareas).

Recorridos cognitivos.

Listas de control o comprobación.

Evaluación heurística de expertos.

Test de usuarios.

Observación.

Compilación de manuales y normas internas.

2. Diseño

Evaluación heurística de expertos.

Inspección (normas, características y consistencia).

Listas de control o comprobación.

3. Evaluación

Evaluación heurística de expertos.

Control de Logs.

Recorridos cognitivos.

Test de usuarios.

Por otro lado, otra de las diferencias importantes que se presentan entre ambas propuestas,
se refleja en los criterios de caracterización de las técnicas de usabilidad, respecto a los
momentos de aplicación en el desarrollo de cada una de ellas, por lo que se hace necesario
que para el caso de la propuesta de Jesús Tramullas se clasifique de la misma forma que la
propuesta de Xavier Ferré.

Para tener un margen respecto a esta clasificación y solo clasificar lo que es de interés para
el posterior análisis, solo para efectos de estudio se consideran los criterios de
caracterización por momentos de aplicación (especialmente apropiada, neutra y no es
habitual) y la valorización total (muy útil y útil). Cabe de destacar, que solo por efectos de
acotar de antemano la población de técnicas de usabilidad entre las propuestas, que solo se
consideró para el caso de los momentos de aplicación las caracterizaciones más
funcionales, es decir, las caracterizaciones de especialmente apropiada y neutra, dejando
fuera la caracterización de no es habitual. Por tanto, las técnicas en la propuesta de Xavier
Ferré se caracterizan de la siguiente forma:

Análisis: Para la actividad de análisis se consideran solo los momentos de aplicación

iniciales.

Educción y análisis de Requisitos:

Técnicas Momento inicial Valorización total

Card Sorting Neutra Muy útil

Análisis Competitivo Especialmente apropiada útil

Diagramas de Afinidad Especialmente apropiada útil

Investigación Contextual Especialmente apropiada útil

Observación Etnográfica Especialmente apropiada útil

Tabla 4: Actividades iniciales para la Educción y Análisis de Requisitos.

Análisis de Usuarios:

Técnicas Momento inicial Valorización total

Personas Especialmente apropiada Muy útil

Mapa de Roles de Usuario Especialmente apropiada útil

 Perfiles de Usuario Especialmente apropiada útil

Tabla 5: Actividades iniciales para el Análisis de Usuarios.

Análisis de Tareas:

Técnicas Momento inicial Valorización total

Escenarios y Storyboards Especialmente apropiada Muy útil

Tormenta de Ideas visual Especialmente apropiada útil

Tabla 6: Actividades iniciales para Análisis de Tareas.

Prototipado:

Técnicas Momento inicial Valorización total

Prototipos de papel Especialmente apropiada Muy útil

Tabla 7: Actividades iniciales para el Prototipado.

Especificación de Requisitos:

Técnicas Momento inicial Valorización total

Especificaciones de Neutra Muy útil

Usabilidad

Tabla 8: Actividades iniciales para la Especificación de Requisitos.

Validación de Requisitos:
 Técnicas Momento inicial Valorización total

Inspecciones Neutra Muy útil

Inspecciones Colaborativas Especialmente apropiada útil

Recorrido Pluralístico Especialmente apropiada útil

Tabla 9: Actividades iniciales para la Validación de Requisitos.

Diseño: Para la actividad de análisis se consideran solo los momentos de aplicación
centrales.

Diseño de la interacción:

Técnicas Momento central Valorización total

Árboles de menús Neutra Muy útil

Mapa de navegación Especialmente apropiada útil

Modelo de contenido de la Especialmente apropiada útil

interfaz

Tabla 10: Actividades centrales para el Diseño de la Interacción.

Evaluación: Para la actividad de análisis se consideran solo los momentos de aplicación
evolución.

Evaluación por expertos:

Técnicas Momento evolución Valorización total

Inspecciones Neutra Muy útil

Tabla 11: Actividades de evolución para la Evaluación por Expertos.

Test de usabilidad:

Técnicas Momento evolución Valorización total

Pensar en voz alta Neutra Muy útil

Tabla 12: Actividades de evolución para los Test de Usabilidad.

Estudios de seguimiento de sistemas instalados:

Técnicas Momento evolución Valorización total

Retroalimentación con el Neutra Muy útil

usuario

Cuestionarios, entrevistas Especialmente apropiada útil

y encuestas

Registros del uso Especialmente apropiada útil

Tabla 13: Actividades de evolución para los Estudios de seguimiento de sistemas

instalados.
Para el caso de las técnicas de usabilidad de la propuesta de Jesús Tramullas la clasificación
es de la siguiente forma:

Análisis: Para la actividad de análisis se consideran solo los momentos de aplicación

inicial.

x Generación de Ideas: Cuando se está intentando transmitir a todas las partes

implicadas qué tipo de sistema se quiere construir, los Escenarios y Storyboards ayudan
a centrar la narración de cómo va a ser el sistema en usuarios concretos que realizan
tareas especificas. La finalidad de estas técnicas es hacer pensar al equipo de desarrollo
en el contexto de uso, en temas tangenciales a la pura funcionalidad que va a tener que
 usar el usuario, los cuales van más allá de los requisitos clásicos. Es por esto, que su
uso es especialmente indicado en etapas tempranas y de mucha utilidad, porque sirven
para no perder de vista el contexto de uso previsto en todo trabajo de diseño posterior.

x Grupos de enfoque (Focus Group): La finalidad de esta técnica es que permite

preguntar a los usuarios de sus experiencias y preferencias de un producto. Por tanto,
esta técnica puede ser utilizada en cualquier etapa de desarrollo (Neutra) y útil a su vez
dependiendo del propósito con el cual se aplica, donde comúnmente se utilizan una vez
que el producto ha sido lanzado con el objetivo de mejorar la satisfacción del cliente, en
cuanto al producto mismo, el que desea como finalidad a medida que evoluciona a lo
largo del desarrollo.

x Entrevistas y cuestionarios: Estas técnicas se utilizan para conocer el entorno de

trabajo del usuario y en qué forma afecta a la utilización del sistema. Además de ser una
herramienta fundamental para poder medir la satisfacción del usuario respecto del
producto final. Es por esto, que se considera una técnica útil y especialmente apropiada
para los ciclos iniciales o etapas tempranas, las etapas de evolución para poder medir la
satisfacción del usuario.

x Observación Etnográfica o de campo: Esta técnica se encuentra estrechamente

relacionada con la Educción de Requisitos respecto al estudio de los usuarios y de las
tareas que realizan habitualmente. Esta técnica es especialmente útil cuando se quiere
adecuar el sistema software a desarrollar a la cultura de la organización, en la cual se
encuentra inmerso el usuario. Por tanto, sé considera una técnica especialmente
apropiada y útil para ciclos tempranos de desarrollo.

x Análisis de tareas: Según la propuesta de Xavier Ferré, esta técnica se considera parte
de la especificación del contexto de uso en la actividad de análisis, además de dar una
 descripción de lo que los usuarios hacen para llevar a cabo sus tareas habituales en su
entorno de trabajo. Por tanto, se considera, una técnica especialmente apropiada y muy
útil para la actividad de análisis.

x Test de prototipos (Prototipos de Papel): Frente a los prototipos software

tradicionalmente usados en la IS, los cuales tienen un coste relativamente alto, los
prototipos de papel tienen un coste muy bajo, y por esta razón están especialmente
indicados en los momentos muy tempranos del desarrollo, en los que se tienen ideas de
diseño no elaboradas que se quieren contrastar con el usuario.

x Desarrollo de escenarios (Escenarios de tareas): Esta técnica por dedicarse al estudio

de las tareas que el usuario realiza con el sistema, no se encuentra especialmente
apropiada para alguna actividad o etapa de desarrollo especifica. Por tanto, se considera
una técnica Neutra y útil.

x Recorridos cognitivos: Estas técnicas son aplicables en todo el desarrollo, por lo que
se consideran neutras y útiles.

x Listas de control o comprobación: Las guías y las listas de comprobación ayudan a

asegurar que los principios de usabilidad sean considerados en un diseño. Es por esto,
que se consideran técnicas neutras respecto a los momentos de aplicación y útiles para
cualquier etapa.

x Evaluación heurística de expertos: Al igual que las técnicas anteriores estas se pueden
aplicar en cualquier etapa de desarrollo.
x Test de usuarios: Esta prueba se basa en la observación y análisis de cómo un grupo de
usuarios reales utiliza un sistema software, registrando los problemas de uso con los que
se encuentran para poder solucionarlos posteriormente. Es una prueba complementara a
la evaluación heurística, pero más costosa por lo que se recomienda utilizarla después
de ésta. Es por esto, que se considera una técnica neutra y útil, ya que puede aplicarse a
todo el desarrollo.

x Técnicas de observación, normas y estándares, y compilación de manuales y

normas internas: No se consideran técnicas de usabilidad.

Tabla resumen:

Técnicas Momento inicial Valorización total

Generación de ideas Especialmente Apropiada Muy útil

(escenarios y Storyboards)

Grupos de enfoque (Focus Especialmente apropiada útil

Group)

Entrevistas. Especialmente apropiada útil

Cuestionarios Especialmente apropiada útil

Observación Etnográfica o Especialmente apropiada útil

de campo

Análisis de tareas Especialmente apropiada Muy útil

Test de prototipos Especialmente apropiada Muy útil

(Prototipos de papel)
 Desarrollo de escenarios Neutra útil
(Escenarios de tareas)

Recorridos cognitivos Neutra útil

Listas de control o Neutra útil

comprobación

Evaluación heurística de Neutra útil

expertos

Test de usuarios Neutra útil

Tabla 14: Caracterización de técnicas por momentos de aplicación inicial y valorización

total para la actividad de análisis.
Diseño: Para la actividad de análisis se consideran solo los momentos de aplicación
centrales.

x Evaluación heurística de expertos: Como mencionamos anteriormente, esta técnica se

considera neutra ya que se puede aplicar en cualquier etapa de desarrollo.

x Inspección (normas, características y consistencia): Al igual que la técnica anterior,

también se considera neutra y útil.

x Listas de control o comprobación: Esta técnica también se considera neutra y útil por
las razones ya mencionadas con anterioridad.

Tabla resumen:

Técnicas Momento central Valorización total

 Evaluación heurística de Neutra útil
expertos

Inspección (normas, Neutra Muy útil

características y
consistencia)

Listas de control o Neutra útil

comprobación

Tabla 15: Caracterización de técnicas por momentos de aplicación central y valor total
para la actividad de diseño.
Evaluación: Para la actividad de análisis se consideran solo los momentos de aplicación
centrales.

Evaluación heurística de expertos: Técnica que se puede aplicar en cualquier etapa de

desarrollo, por lo cual se considera útil y neutra.

x Control de Logs: Consiste en analizar estadísticamente los Logs que generan los
servidores web sobre el tráfico de usuarios.

x Recorridos cognitivos: Se pueden aplicar en todo el desarrollo por lo cual se

consideran neutras y útiles.

x Test de usuarios: Se considera una técnica neutra y útil, ya que puede aplicarse a todo
el desarrollo.

Tabla resumen:

Técnicas Momento evolución Valorización total

 Evaluación heurística de Neutra útil
expertos

Control de Logs Neutra Muy útil

Recorridos cognitivos Neutra útil

Test de usuarios Neutra útil

Tabla 16: Caracterización de técnicas por momentos de aplicación de evolución y valor

total para la actividad de evaluación.

4.1.4. Intercepción entre la Propuesta de Xavier Ferré y Jesús Tramullas

En el apartado anterior fue necesario realizar un ajuste para poder comparar e interceptar
ambas propuestas. Respecto a esta intercepción, por efectos de estudio se limita solo al
contenido (teórico) y terminología (nomenclatura) entre ambas propuestas, la cual reducirá
el conjunto de técnicas con el fin de tener un número más reducido de técnicas para el
posterior análisis, en cada caso de estudio en particular.

Por esto nuestra población se ve acotada por las siguientes técnicas:

Terminología y Contenido:

Análisis:

Investigación contextual.

Observación de campo o etnográfica.

Generación de ideas o Escenarios y Storyboards.

Test de prototipos (prototipado horizontal, vertical, alta fidelidad, baja fidelidad,

papel) solo Prototipo de papel.

Diseño:

No existe coincidencia entre ambas propuestas.

Evaluación:

No existe coincidencia entre ambas propuestas.

4.1.5. Técnicas de Usabilidad de Mayor Utilidad en el Ambiente Web

Para el estudio es necesario adicionar técnicas que se consideren de mayor utilidad según el
ambiente Web, para esto el estudio se basó en la investigación del enfoque en la propuesta
de Hassan [Hassan, 04] aplicado completamente en el ambiente Web y ambas propuestas
bases.

Propuesta de Hassan: “Diseño Web Centrado en el Usuario: Usabilidad y Arquitectura de la

Información”, se divide en varias fases o etapas, las que se presentan en la Fig. 11:

Fig. 5. Proceso de Diseño Web centrado en el usuario.

x Planificación: En esta etapa se identifican los objetivos del sitio, así como las
necesidades, requerimientos y objetivos de la audiencia potencial. Confrontando esta
información se definen los requerimientos del sitio Web, entre los que podemos contar
requerimientos técnicos (back-end y front-end), recursos humanos y perfiles
profesionales necesarios, y adecuación del presupuesto disponible. Las técnicas de
usabilidad para el estudio de la audiencia son mediante los métodos de indagación.
Éstos engloban métodos de aproximación contextual, estudios de campo o etnográficos,
métodos de aproximación por grupos y métodos de aproximación individual (encuestas,
cuestionarios y entrevistas).

x Diseño: La etapa de Diseño es el momento del proceso de desarrollo para la toma de

decisiones acerca de cómo diseñar o rediseñar, en base siempre al conocimiento
obtenido en la etapa de planificación, así como a los problemas de usabilidad
descubiertos en etapas de prototipado y evaluación.

x Modelado del usuario: Toda la información obtenida de los estudios de usuarios

realizados en la anterior fase de planificación debe servir como base para comenzar el
diseño, pero para ello se debe resumir y sintetizar dicha información. Este paso se
denomina modelado del usuario y consiste en la definición de clases o perfiles de
usuarios en base, a atributos comunes. La técnica de usabilidad recomendada utilizar
en esta etapa es Personas.

x Diseño conceptual: El objetivo de esta fase es definir el esquema de organización,

funcionamiento y navegación del sitio. No se especifica qué apariencia va a tener el
sitio, sino que se centra en el concepto mismo del sitio: su arquitectura de información.
Las técnicas de usabilidad recomendadas y de mayor utilidad son las de Mapas Web o
Mapas de Navegación, Card Sorting y Diagramas de afinidad.
x Diseño visual y definición del estilo: En esta fase se especifica el aspecto visual del
sitio Web: composición de cada tipo de página, aspecto y comportamiento de los
elementos de interacción y presentación de elementos multimedia. La técnica de
usabilidad recomendada en esta etapa es la de Guías de Estilo del Producto.

x Diseño de contenidos: En el diseño de contenidos hipermedia se debe mantener un

equilibrio entre lo que serían contenidos que no aprovechasen las nuevas posibilidades
hipertexto y multimedia, y lo que serían contenidos caóticos o desorientativos debido a
un uso excesivo y no sosegado de las posibilidades hipermedia. Se trata de diseñar
contenidos interrelacionados y vinculados, manteniendo cierta coherencia informativa,
comunicacional y organizativa.

x Prototipado: La etapa de prototipado se basa en la elaboración de modelos o prototipos

de la interfaz del sitio. Su aspecto no se corresponde exactamente con el que tendrá el
sitio una vez finalizado, pero pueden servir para evaluar la usabilidad del sitio sin
necesidad de esperar a su implementación.

Según Floría Cortés [Floría, 02], podemos clasificar los tipos de prototipado según el nivel
de funcionalidad reproducida:

x Prototipado horizontal: Se reproduce gran parte del aspecto visual del sitio, pero sin
que esos modelos de interfaz estén respaldados por la funcionalidad real que tendrá
finalmente el sitio.

x Prototipado vertical: Se reproduce únicamente el aspecto visual de una parte del sitio,
pero la parte reproducida poseerá la misma funcionalidad que el sitio Web una vez
implementado.

Según el grado de fidelidad o calidad del prototipo se distingue entre:

x Prototipado de alta fidelidad: El prototipo será muy parecido al sitio Web una vez
terminado.

x Prototipado de baja fidelidad: El aspecto del prototipo distará bastante del que tenga el
sitio Web final.

La técnica de usabilidad recomendada en esta etapa es la de Prototipos de Papel por ser

más económica.

x Evaluación: La evaluación de la usabilidad se puede realizar a través de varios

métodos o técnicas y sobre diferentes representaciones del sitio (prototipos en papel,
prototipos software, sitio Web implementado, etc.)

Existe una gran diversidad de métodos para evaluación de usabilidad, aunque en el presente
estudio únicamente se describirán aquellos que creemos de más utilidad y aplicabilidad real
en el contexto del desarrollo de aplicaciones Web.

• Método por Inspección:

o Evaluación heurística.

• Método de Test con Usuarios:

o Pruebas informales o Test de 'guerrilla'.

• Implementación y Lanzamiento: En la implementación del sitio es recomendable

utilizar estándares (HTML, XHTML, etc.) para asegurar la futura compatibilidad y
escalabilidad del sitio. Esto se debe a que, aunque puede ser tentador utilizar tecnologías
propietarias, el panorama tecnológico puede hacerlas desaparecer o cambiar en poco
tiempo. Una vez implementado el sitio y testada su funcionalidad se procede al lanzamiento
del sitio, que consiste en su puesta a disposición para los usuarios. Se trata de un evento
importante, muchas veces erróneamente apresurado debido a la necesidad de cumplir
plazos de entrega.
Una vez realizado el lanzamiento se debe utilizar técnicas de promoción para atraer a los
usuarios hacia el sitio:

Banners publicitarios.

Inclusión en buscadores y directorios.

Campañas de correo.

Por otro lado, las técnicas que se consideran de mayor utilidad entre ambas propuestas:

x Encuestas y entrevistas: Resultan ser de utilidad para todo tipo de proyectos, requieren
una formación de cierta entidad, mientras que el esfuerzo de aplicación es considerable
por lo el trabajo que toma la elaboración de estas, la selección de los participantes y el
análisis de los resultados recogidos. La aportación de usabilidad es importante, acorde
con el esfuerzo que requiere su aplicación.

x Card Sorting: Es una técnica participativa con necesidad de formación con baja
respecto a los desarrolladores, y sencilla de aplicar. Permite conocer el mapa mental del
usuario acerca del dominio de aplicación. Proporciona una gran mejora de la usabilidad
respecto al esfuerzo invertido en aplicar esta técnica.

x Personas: útil cuando ha varios tipos de usuarios, esta técnica requiere un cierto
esfuerzo de aprendizaje y aplicación. El retorno en usabilidad que se obtiene de su
aplicación es considerable.

x Mapas de Roles de Usuario: Técnica relativamente sencilla, con un tipo de modelado

como el habitual en la IS. Aplicable cuando el número de tipos de usuarios es alto y se
pueden establecer relaciones entre ellos. Aporta la profundidad en el estudio del usuario
necesaria para poder hacer aportes a la usabilidad del sistema.
x Perfiles de usuario: Técnica aplicable a un rango amplio de proyectos, la cual requiere
ciertos esfuerzos de aprendizaje. Se trata de una técnica básica en cualquier desarrollo
preocupado por la usabilidad, por lo que su aporte en este sentido es muy importante.

x Inspecciones: Técnica que requiere una formación previa de cierta importancia, que se
puede aplicar a todo tipo de proyectos. Tipo de técnica común en la IS, aunque no en
referente a la usabilidad. Puede realizar un aporte importante a la usabilidad del sistema
final.

x Casos de Uso esenciales: Esta técnica tiene una cercanía considerable con la IS, puesto
que se trata de unos casos de uso a un nivel mayor de abstracción. Aplicable a un rango
amplio de proyectos, requiere cierto aprendizaje, pero puede aportar una mejora
sustancial en usabilidad.

x Escenarios de Tareas: Técnica útil cuando no están bien definidas las tareas que los
usuarios medios van a realizar con el sistema. Es necesaria una formación específica
para su aplicación. Ayudan a centrarse en la usabilidad del sistema, aunque se aporte no
es tan alto como el de otras técnicas.

x Especificaciones de usabilidad: Requiere un gran aprendizaje, ya que es difícil de

dominar. Aplicable cuando se conoce con precisión por anticipado las tareas a las que
se va a dar soporte, mayoritariamente en entornos de oficina. Cercanía a la IS por ser
parte de los requisitos no funcionales. Gran aportación a la usabilidad del sistema.

x Recorrido Pluralista: Se trata de una variante de Walkthrough de carácter

participativo. Al igual que con otras técnicas de este tipo, requiere una predisposición a
aceptar la validez de este tipo de técnicas por parte de todos los implicados en el
 desarrollo. Las necesidades de formación son bajas, aunque el esfuerzo de aplicación es
alto por tratarse de una técnica de grupo. Aún así, el rendimiento obtenido en mejora de
la usabilidad es considerable.

x Diagramas de afinidad: Técnica de carácter participativo que requiere muy poca

formación y es sencilla de aplicar. Su aplicación puede ofrecer una importante mejora
de usabilidad en el producto final.

x Árboles de menús: Técnica de especificación relativamente sencilla, aplicable en los

sistemas que cuentan con algún tipo de menú. Es de un tipo de modelado cercano al de
la IS. Su aplicación produce unos resultados e la usabilidad del producto importantes
frente al esfuerzo invertido.

x Evaluación Heurística: La aplicación de esta técnica requiere una formación en

usabilidad alta, debido a la experiencia para aplicar la técnica de forma adecuada. Puede
ser aplicada a todo tipo de proyectos, y puede influir de forma importante en la
usabilidad del sistema final si se plantea como complemento a técnicas de Test de
usabilidad con usuarios. Puede servir para hacer algunos ciclos iterativos más cortos,
pues su aplicación por expertos no es excesivamente costosa en tiempo.

x Guías de estilo del producto: La complejidad de aplicación de esta técnica se justifica

únicamente en sistemas de cierta envergadura. La formación necesaria para aplicarla es
amplia. La aportación en usabilidad puede resultar muy importante, si bien requiere un
empleo de recursos considerables para toda la gestión que envuelve el uso de esta
técnica.
x Mapas de navegación: Apropiada cuando la interfaz se compone de distintos contextos
o ventanas entre los cuales navega el usuario. Requiere una formación de cierta
extensión, y su aplicación resulta compleja. Así, las posibles mejoras en usabilidad son
importantes, aunque requiere un esforzó igualmente importante.

x Inspecciones colaborativas: Este tipo de inspecciones de carácter participativo

requiere una predisposición de todas las partes involucradas en el desarrollo a este tipo
de prácticas. No requiere una formación extensa, pero es relativamente costosa su
aplicación. Aún así, las mejoras obtenidas en usabilidad son destacables.

x Test de usabilidad en laboratorio: Adecuada para proyectos en los que el rendimiento

alcanzado por los usuarios tiene una especial relevancia. Es necesario realizar una
formación de cierta extensión para poder aplicarla, y su coste es elevado por el
equipamiento especial que requiere. El aporte de usabilidad que se consigue mediante
su aplicación es importante, sin ser excesivamente alto.

x Pensar en voz alta: Útil para un abanico amplio de proyectos. Requiere cierta
formación por no tratarse de un tipo de técnicas habitual en la IS. La aportación a la
usabilidad que se logra por medio de la enumeración en voz alta de las intenciones y
problemas del usuario es muy importantes. El esfuerzo invertido en este tipo de Test no
es demasiado excesivo.

x Retroalimentación del usuario: La consideración de las quejas y/o sugerencias del

usuario no resulta ajena a la IS. El coste de esta técnica es bajo, pues requiere
únicamente el establecimiento de un modo de reporte de incidencias que permitan
identificar los problemas de usabilidad. En cuanto a la aportación a la usabilidad del
producto final, resulta destacable frente al coste de aplicación.
Por lo tanto, el conjunto de técnicas queda de la siguiente forma:

Mayor utilidad y contenido:

Análisis:

Entrevistas.

Card Sorting.

Personas.

Mapas de Roles de usuario.

Perfiles de usuario.

Inspecciones.

Casos de Uso esenciales.

Escenarios de Tareas.

Especificaciones de usabilidad.

Recorrido Pluralista.

Diagramas de afinidad.

Diseño:

Árboles de menús.

Evaluación heurística.

Guías de estilo del producto.

Mapas de navegación.

Evaluación:

Inspecciones colaborativas.

Recorrido Pluralístico.

Test de usabilidad en laboratorio.

 Pensar en voz alta.

Retroalimentación del usuario.

Cuestionarios, entrevistas y encuestas.

4.1.6. Estudio de las Técnicas más importantes utilizadas en el Diseño

Centrado en el Usuario
Otro factor a considerar para la elección del conjunto de técnicas de usabilidad, es cuán
importante son consideradas las técnicas de usabilidad por los desarrolladores que llevan en
la práctica esta técnicas. Un estudio realizado en el 2002, se realizó una encuesta remitida a
100 especialistas, y el estudio de los datos obtenidos, Mao, Vredenburg, Smith y Carey
[Vredenburg, 02] han establecido experimentalmente el impacto, coste y efectividad del
diseño centrado en el usuario en el desarrollo de aplicaciones y otros productos de
información digital, al tiempo que han obtenido una ordenación por importancia de las
técnicas usadas en el DCU, ilustrado en la Tabla 19:

Técnica Ranking

1 2 3 4 5 Ranking Frecuencia Nivel de

Promedio Importancia

Estudios de Campo 12 6 5 2 1 2.00 28 112.0

(investigación Contextual)

Análisis de los Requerimientos 3 3 0 0 1 2.00 7 28.0

del Usuario

Diseño Iterativo 17 21 9 5 2 2.15 65 250.4

Evaluaciones de Usabilidad 12 8 10 7 1 2.39 43 155.0

Análisis de Tareas 6 8 6 7 1 2.61 34 115.4

Focus Group 5 2 2 1 4 2.79 16 51.4

Evaluación Heurística Formal 3 2 5 2 2 2.86 15 47.1

Entrevistas a Usuarios 2 0 3 4 0 3.00 11 33.0

Prototipos sin Test de Usuarios 1 3 5 4 1 3.07 15 43.9

Encuestas 0 2 2 1 1 3.17 9 25.5

Revisión Informal experta 4 6 3 10 6 3.28 31 84.4

Card Sorting 0 1 1 0 1 3.33 5 13.3

Diseño Participativo 1 0 1 2 1 3.40 7 18.2

Sin código/ bosquejo de 64

categorización

Tabla 17: Importancia de las Técnicas utilizadas en el Diseño centrado en Usuario (tomado
de [Vredenburg, 02]) (*).
(*)Nota: Él número 1 del ranking significa el más importante, y el 5 el quinto más
importante. Por lo tanto, la importancia total de las técnicas de DCU es calculada como
Frecuencia * (6 – Ranking Promedio).

La tabla 19 ilustra las técnicas más importantes para los desarrolladores, pudiendo concluir
que las técnicas más importantes son: Estudios de campo, Evaluaciones Heurísticas y de
Usabilidad.

Cabe destacar, que la revisión de las mismas técnicas permite apreciar que todavía no se
utilizan en toda la amplitud que deberían en los procesos de diseño. Por otra parte, se
aprecia que, en contraste con la variedad de técnicas disponibles, las organizaciones se
centran en aquellas que consideran que les pueden suponer un coste de recursos inferior.
Este razonamiento explica la escasa importancia de los métodos con participación directa
del usuario, a excepción de los estudios de campo, y el papel preponderante dado a los
expertos en el diseño iterativo y las evaluaciones heurísticas y de usabilidad.

4.1.7. Conjunto de Técnicas de Usabilidad Acotado para la Propuesta

Preliminar
Después de realizar la intercepción entre ambas propuestas, revisar también las técnicas de
mayor utilidad entre ambas propuestas y la importancia de las técnicas más utilizadas
nuestro conjunto de técnicas se ve acotado por las siguientes técnicas:

1. Casos de Uso esenciales.

2. Card Sorting.

3. Diagramas de afinidad.

4. Escenarios de Tareas.

5. Especificaciones de usabilidad.

6. Escenarios y Storyboards.

7. Investigación contextual.

8. Inspecciones.

9. Inspecciones colaborativas.

10. Mapas de Roles de usuario.

11. Observación de campo o etnográfica.

12. Personas.

13. Perfiles de usuario.

14. Prototipo de papel.

15. Árboles de menús.

16. Evaluación heurística.

17. Guías de estilo del producto.

18. Mapas de navegación.

19. Recorrido Pluralístico.

20. Test de usabilidad en laboratorio.

21. Pensar en voz alta.

22. Retroalimentación del usuario.

23. Cuestionarios, entrevistas y encuestas.

Quedando de la siguiente forma por actividades de desarrollo:

Análisis

Casos de Uso esenciales.

Card Sorting.

Diagramas de afinidad.

Entrevistas.

Escenarios de Tareas.

Especificaciones de usabilidad.

Generación de ideas o Escenarios y Storyboards.

Investigación contextual.

Inspecciones.

Inspecciones colaborativas.

Mapas de Roles de usuario.

 Observación de campo o etnográfica.

Personas.

Perfiles de usuario.

Recorrido Pluralista

Prototipo de papel.

Diseño

Árboles de menús.

Evaluación heurística.

Guías de estilo del producto.

Mapas de navegación.

Evaluación

Inspecciones colaborativas.

Recorrido Pluralístico.

Test de usabilidad en laboratorio.

Pensar en voz alta.

Retroalimentación del usuario.

Cuestionarios, entrevistas y encuestas.

4.1.8. Factibilidad de Aplicación de las Técnicas de Usabilidad

Cada una de las técnicas de usabilidad tiene características singulares, ya sea en la forma en
cómo se emplean, recursos que utilizan, cantidad de desarrolladores necesarios según sea el
caso. De manera, que es importante tomar en cuenta la factibilidad respecto a su aplicación
en el desarrollo del sistema software. Los factores en los cuales evaluamos esta factibilidad
de aplicación son los siguientes:

La falta de evaluadores u expertos.

 La disponibilidad de tiempo de los usuarios.

La falta de insumos.

Aporte en la usabilidad.

Cercanía a la IS.

Por consiguiente, se presenta un análisis de las técnicas ya acotadas sobre la base de las
propuestas principales del estudio:

Casos de Uso esenciales:

Ofrece un aporte importante en la usabilidad del producto final mediante su

aplicación.

Tiene un valor alto respecto a la cercanía con la IS, por ser una técnica de modelado.

En cuanto a los insumos y factor humano es necesario como mínimo de un

desarrollador u experto con una formación media y un espacio físico,
respectivamente.

Los usuarios no participan en esta técnica por lo que el tiempo empleado en esta no se
considera.

Card Sorting:

El aporte en cuanto a la usabilidad puede ser sustancial.

Tiene una cercanía media con la IS, pero no son técnicas participativas que suelan
realizarse por ingenieros de software.

En cuanto a los insumos y factor humano es necesario como mínimo de un

desarrollador u experto con una formación baja y la participación de al menos 5
usuarios y un espacio físico, respectivamente.

El Tiempo que ocupan los usuarios en estas técnicas puede llegar a ser considerable.

Diagramas de afinidad:
 Su aplicación puede ofrecer una importante mejora en la usabilidad del producto
final.

Tiene una cercanía media con la IS, pero no son técnicas participativas que suelan
realizarse por ingenieros de software.

En cuanto a los insumos y factor humano es solo necesario como mínimo de un

desarrollador u experto con una formación media y a lo más de 3 a 5 usuarios (basta
con un equipo de 4 a 6 personas) y un espacio físico, respectivamente.

Los usuarios tienen un carácter participativo en esta técnica, por lo que el tiempo
puede llegar a ser considerable.

Escenarios de Tareas:

Ayudan a centrarse en la usabilidad del sistema, aunque su aporte no es tan alto como
en otras técnicas.

Su cercanía es media a la IS, puesto que su objetivo es abstraer, pero tampoco

responden a n planteamiento clásico de la IS.

En cuanto a los insumos y factor humano es necesario como mínimo de un

desarrollador u experto con una formación media y un número variable de usuarios
un espacio físico, respectivamente.

Los usuarios tienen un carácter participativo, donde el tiempo puede llegar a ser
considerable.

Especificaciones de usabilidad:

Es de gran aporte en cuanto a la usabilidad del sistema.

Es de una cercanía media respecto a la IS por ser parte de los requisitos no

funcionales del sistema.

Necesita de un gran aprendizaje por lo que los desarrolladores necesitan de una

formación media, en cuanto al factor humano y es independiente del espacio físico y
los insumos para llevarla a cabo.
 Esta técnica no es de carácter participativo respecto a los usuarios por lo que el
tiempo requerido por parte de los usuarios es irrelevante.

Escenarios y Storyboards:

La mejora respecto a la usabilidad puede llegar a ser considerable.

Su cercanía respecto a la IS es baja, ya que se trata de una técnica que no es habitual.

En cuanto a los insumos y al factor humano, es necesario que los desarrolladores

tengan una formación media y un número variable de usuarios, además de ser
independientes del espacio fisco e insumos ocupados para ser llevada a cabo
respectivamente.

Es una técnica de carácter participativo, donde el tiempo ocupado por los usuarios
puede llegar a ser considerable.

Investigación contextual:

La aportación en la usabilidad del sistema es alta.

Tiene una cercanía media respecto a la IS.

En cuanto a los insumos y el factor humano, necesitan de un espacio físico e insumos

para llevarla a cabo, además de la participación de desarrolladores con una formación
alta en esta técnica.

Es una técnica de carácter representativo por lo que el tiempo en el cual incurren los
usuarios puede llegar a ser considerable.

Inspecciones:

Puede realizar un aporte importante en la usabilidad del producto final.

Es una técnica común en la IS, por lo que tiene una cercanía media.

En cuanto a los insumos y el factor humano, es necesario de un espacio físico y los

insumos necesarios para llevarla a cabo, además de una formación previa de cierta
importancia para los desarrolladores.
 Esta técnica no es de carácter participativo, por lo que el tiempo no es relevante.

Inspecciones colaborativas:

Las mejoras obtenidas en la usabilidad son consideras destacables.

Es considerada de una cercanía media respecto de la IS, puesto que son similares en
cuanto a la mecánica de la técnica misma en la IS, ejemplo de esto: inspecciones de
código.

En cuanto a los insumos y el factor humano, no requiere de un gran número de

insumos y los desarrolladores no requieren de una formación extensa por lo q se
considera media, respectivamente.

Técnica de carácter participativo, donde el tiempo ocupado en su aplicación puede

llegar a ser considerable.

Mapas de Roles de usuario:

Aporta la profundidad en el estudio del usuario necesaria para poder hacer aportes a
la usabilidad del sistema.

Se considera de una cercanía alta a la IS, para los casos en que el tipo de modelado es
como el habitual en la IS.

En cuanto a los insumos y el factor humano, son necesarios los insumos básicos
(espacio físico, papel, lápiz, etc.) y de desarrolladores con una formación baja en esta
ya que es muy sencilla de aprender y aplicar.

Esta técnica no de carácter participativo por lo que el tiempo no es relevante.

Observación de campo o etnográfica:

El aporte en la usabilidad es bajo ya que se necesita mucho tiempo para observar un

número suficiente de problemas de usabilidad.

Esta técnica no se considera cercana a la IS, ya que no se suele evaluar el producto

instalado de esta forma.
 En cuanto a los insumos y el factor humano, son necesarios los insumos básicos y
desarrolladores con una alta formación y que requiere de aptitudes de observación sin
intervenir.

Esta técnica no es de carácter participativo para los usuarios, por ende el tiempo es
irrelevante.

Personas:

Su aporte en usabilidad puede ser muy importante.

Se considera cercana a la IS por su objetivo de abstraer y es similar a lo que se hace

en los estudios de mercado en los procesos de la IS.

En cuanto a los insumos y el factor humano, son necesarios los insumos básicos y
desarrolladores con una formación media (requiere un cierto esfuerzo d aprendizaje y
aplicación) para llevarla a cabo.

No es una técnica de carácter participativo para el usuario, por ende el tiempo no es

considerable.

Perfiles de usuario:

Su aporte en usabilidad puede llegar a ser considerable.

Se considera una técnica altamente cercana a la IS, puesto que es una tarea de
especificación y modelado.

En cuanto a los insumos y el factor humano, son necesarios los insumos básicos y
desarrolladores con una formación alta en ésta, puesto que se requiere conocimientos
altos de los principios de usabilidad, para poder comprender qué información puede
ser o no ser relevante para la usabilidad del sistema final, respectivamente.

No es una técnica de carácter participativo para el usuario, por ende el tiempo no es

considerable.

Prototipo de papel:

El aporte que contribuye en la usabilidad del sistema final es muy importante.

 Se consideran altamente cercanos a la IS, ya que son análogos a algunas maquetas
que se utilizan como “demo” para el cliente.

En cuanto a los insumos y el factor humano, son necesario los insumos básicos y
desarrolladores con una baja formación es está ya que son técnicas sencillas que no
requieren excesiva formación.

Esta técnica es de carácter participativo y el tiempo empleado en su aplicación es

variable, dependiendo de la disponibilidad del usuario y la organización de la prueba
respectivamente.

Árboles de menús:

Los beneficios de usabilidad pueden resultar de importancia.

Se considera altamente cercana a la IS, puesto que es similar a otras técnicas de

modelado pertenecientes a la IS.

En cuanto a los insumos y el factor humano, son necesario los insumos básicos y
desarrolladores con una formación baja en ésta, puesto que es una técnica de
especificación relativamente sencilla.

No es una técnica de carácter participativo, por ende el tiempo que emplea el usuario
no es relevante.

Evaluación heurística:

Las mejoras que puede aportar a la usabilidad son importantes.

Se considera de una cercanía baja a la IS, por ser una técnica poco estructurada.

En cuanto a los insumos y factor humano, son necesarios los insumos básicos y
desarrolladores con una formación alta, ya que el grado de experiencia por parte de
los evaluadores debe ser mayor. Además se necesita una cantidad considerable de
evaluadores, como mínimo 5.

No es una técnica de carácter participativo, por ende el tiempo que emplea el usuario
no es considerable.
Guías de estilo del producto:

Se considera que el aporte a la usabilidad del sistema final es importante, pero no

tanto como lo obtenido con otras técnicas, además que el esfuerzo en su aplicación es
considerable.

Esta técnica se considera de una cercanía media a la IS, puesto que por una parte
responde a la necesidad de especificar las reglas por las que se va a guiar el diseño
(objetivo no muy ajeno a la IS), mientras que por otra parte, dichas reglas se ocupan
de los elementos que forman parte de la IU, cuyo diseño no es parte de la IS
[Swebok, 04].

En cuanto a los insumos y el factor humano, son necesarios los insumos básicos y
desarrolladores con una formación alta, puesto que requiere de una experiencia
amplia en temas de usabilidad, además una guía de estilo del producto sólo se
justifica en sistemas de cierta complejidad, especialmente cuando se trata de familia
de productos.

No es una técnica de carácter participativo, por ende el tiempo empleado por el

usuario no es considerable.

Mapas de navegación:

Las posibles mejoras en usabilidad son importantes.

Se considera con una cercanía alta a la IS, puesto que el modelado es una actividad
típica de la IS.

En cuanto a los insumos y el factor humano, no necesita más allá de los insumos
básicos (espacio físico, lápiz, papel, etc.), por otro lado, necesita de una formación de
cierta extensión (media) y su aplicación resulta ser compleja.

Los usuarios no participan es esta técnica por lo que el tiempo no es relevante.

Test de usabilidad en laboratorio:

Se considera que su aporte en usabilidad es importante.

 Se considera una técnica medianamente cercana a la IS, ya que no es una técnica
ajena y supone un complemento a lo que habitualmente se realiza en el marco de la
IS.

En cuanto a los insumos y el factor humano, son necesario insumos específicos

además de los básicos (un laboratorio de usabilidad, o los equipos, espacio físico, etc.
para montar uno) y desarrolladores con una necesidad de formación media, puesto
que tiene una mecánica que es necesaria aprender y requiere de cierto entrenamiento.

Técnica de carácter participativo, y el tiempo empleado por el usuario es variable,

pero no excesivo.

Pensar en voz alta:

La aportación de usabilidad se considera alta.

Esta técnica se considera de una cercanía baja a la IS.

En cuanto a los insumos y el factor humano, son necesarios los insumos básicos y de
desarrolladores con un nivel medio, respectivamente.

Es una técnica de carácter participativo, y el tiempo empleado por el usuario (se

considera variable) depende de la duración de la prueba.

Retroalimentación del usuario:

Las mejoras obtenidas en la usabilidad son consideras destacables.

Es considerada de una cercanía alta respecto de la IS, puesto que las quejas del
usuario en general son algo común para los ingenieros de software.

En cuanto a los insumos y el factor humano, no requiere de un gran número de

insumos, solo de un modo de reporte de incidencias que permita identificar los
problemas de usabilidad, y los desarrolladores no requieren de una formación extensa
por la que se considera baja, respectivamente.

Técnica de carácter participativo, donde el tiempo ocupado en su aplicación puede

llegar a ser considerable.
Cuestionarios, entrevistas y encuestas:

A pesar del gran esfuerzo en su elaboración, distribución y análisis de los

cuestionarios es considerable, pueden llegar a reflejar un número importante de
problemas de usabilidad.

Se considera una técnica de una cercanía media a la IS, puesto que se manejan en
cierta medida cuestionarios en la IS (Test beta).

En cuanto a los insumos y el factor humano, son necesario los insumos básicos y de
desarrolladores con una formación media para llevarlas a cabo.

Es una técnica participativa, donde el tiempo empleado es variable, el cual depende

de la extensibilidad, coordinación y cantidad de usuarios.

4.1.9. Elección de las Técnicas de Usabilidad para la Propuesta

Preliminar
Para la elección del conjunto de técnicas de usabilidad que conformará la pauta de
usabilidad, es necesario tomar en cuenta los factores anteriormente analizados: Factibilidad
en la aplicación, técnicas más utilizadas por los desarrolladores y el conjunto resultado
obtenido al ser acotada la población de técnicas disponibles por ambas propuestas. Por
consiguiente, se presenta un análisis en base, a los factores anteriormente mencionados, de
donde se indica las razones de la utilización de cada técnica, en caso contrario, las razones
de por qué no se utilizará la técnica según corresponda.

Es importante destacar que el factor de mayor peso en el análisis es la factibilidad de

aplicación de la técnica en particular, puesto que los dos factores restantes ya se consideran
en este factor (solo se consideraron las técnicas ya acotadas, las cuales incluían las técnicas
más utilizadas), por lo que el análisis se refleja mayormente en este punto.

1. Caso de estudio: Sitio Web para una Empresa Privada

Análisis de los factores por cada técnica de usabilidad que se utilizará en la pauta:
x Caso de Uso Esencial: Esta técnica se utilizará, ya que esta técnica es factible de
aplicar, puesto que al menos un desarrollador tiene formación en ésta y no se requiere
de mayor interacción del usuario, además de disponer de un espacio físico y los
insumos necesarios para llevarla a cabo. Es importante desatacar, que el desarrollador
tiene conocimiento del modelo del negocio de la organización y por ende de la
operatividad que debe tener el sistema en sí, la cual servirá de gran apoyo para esta
técnica.

x Card Sorting: Esta técnica no se utilizará, ya que no es factible de aplicar en este caso
de estudio, porque se requiere de un gran número y tiempo considerable para el usuario,
a pesar de disponer de un espacio físico y los insumos necesarios para llevarla a cabo.

x Diagramas de Afinidad: Esta técnica no se utilizará, ya que no es factible de aplicar en

el presente caso de estudio, puesto que se requiere de un gran número de usuarios,
además de un tiempo considerable en su aplicación, a pesar de disponer de un espacio
físico y los insumos necesarios para llevarla a cabo. También, los desarrolladores no
tienen formación en este tipo de técnicas, pues la experiencia necesaria debe ser a lo
menos media.

x Escenarios de Tareas: Esta técnica no se utilizará, ya que no es factible de aplicar en

el presente caso de estudio, ya que los desarrolladores no tienen una formación
específica en ésta, además de tener un número reducido de usuarios disponibles para
esta técnica. También se toma en consideración que el aporte en cuanto a la usabilidad
no es tan alto como en otras técnicas.

x Especificaciones de Usabilidad: Esta técnica se utilizará, ya que es factible de aplicar

en este caso de estudio, pues se considera de gran aporte en la usabilidad del producto
 final. Además, los desarrolladores tienen experiencia en cuanto a la especificación de
los requisitos no funcionales del sistema.

x Escenarios y Storyboards: Esta técnica no se utilizará, ya que no es factible de aplicar

en este caso de estudio, ya que los desarrolladores no poseen la formación necesaria.

x Investigación Contextual: Esta técnica no se utilizará, ya que no es factible de aplicar

en este cado de estudio, puesto que se dispone de una cantidad reducida de usuarios y
los desarrolladores no tienen la formación necesaria para llevarla a cabo.

Es importante destacar, que esta prueba no es tan necesaria, ya que el desarrollador

previamente conoce el entorno, contexto y operatividad del usuario.

x Inspecciones: Esta técnica no se utilizará, ya que no es factible su aplicación en el caso

de estudio, puesto que los desarrolladores no poseen una formación previa en cuanto a
su aplicación. A pesar de ser un aporte importante en la usabilidad del producto final y
no tener una participación del usuario.

x Inspecciones Colaborativas: Esta técnica no se utilizará, ya no es factible de aplicar en

este caso de estudio, puesto que los desarrolladores no poseen una formación previa de
esta técnica, además de contar con un número reducido de usuarios para llevarla a cabo.

x Mapas de Roles de Usuario: Esta técnica se utilizará, ya que se considera factible su

aplicación, puesto que es un gran aporte en la usabilidad del sistema final. Además, no
requiere de la participación del usuario y la formación de los desarrolladores es baja, no
necesita de una experiencia excesiva, de manera que los desarrolladores la pueden
llevarla a cabo sin problema alguno.
x Observación de Campo o Etnográfica: Esta técnica no se utilizará, ya que no es
factible su aplicación en el presente caso de estudio, puesto que los desarrolladores no
poseen una formación alta en esta técnica, además, que su aporte en usabilidad es baja,
debido a que se necesita mucho tiempo para observar los problemas de usabilidad.

x Personas: Esta técnica se utilizará, ya que su aplicación se considera factible en este

caso de estudio, puesto que su aporte en usabilidad es importante, y los desarrolladores
consideran que su aprendizaje no incurriría en un mayor esfuerzo.

x Perfiles de Usuario: No se utilizará, ya que no se considera factible su aplicación,

puesto que los desarrolladores no poseen la formación suficiente en ésta.

x Prototipo de Papel: Esta técnica se utilizará, puesto que se considera factible su

aplicación, ya que por parte de los desarrolladores, implica una técnica sencilla de
aplicar y no requiere de una experiencia excesiva. Además, contribuye un aporte
considerable en la usabilidad del sistema final y se destaca su cercanía con la IS.

x Árboles de Menús: Esta técnica se utilizará, ya que es factible de aplicar en el caso de

estudio, puesto que la formación de los desarrolladores es baja y no necesita
participación del usuario. También, es importante su contribución en la usabilidad del
sistema final.

x Evaluación Heurística: Esta técnica no se utilizará, ya que su aplicación no se

considera factible, puesto que es necesaria una cantidad de evaluadores elevada, a pesar
de contribuir en mejoras importantes respecto la usabilidad del sistema final.
x Guías de Estilo del Producto: Esta técnica no se utilizará, puesto que su aporte en
usabilidad no está alto como en otras técnicas, además de requerir una amplia
experiencia por parte de los desarrolladores. Además, el caso de estudio no se considera
complejo.

x Mapas de Navegación: Esta técnica no se utilizara, ya que no es factible de aplicar en

este caso de estudio, puesto que los desarrolladores no poseen experiencia en este tipo
de técnicas, donde su aprendizaje suele ser complejo.

x Test de Usabilidad en Laboratorio: Esta técnica no se utilizará, puesto que no se

tienen los insumos suficientes (no existe la factibilidad de montar un laboratorio de
usabilidad), ni la disponibilidad de los usuarios para este tipo de pruebas. Por otro lado,
no se tienen los evaluadores suficientes para poder aplicarla.

x Pensar en Voz Alta: Esta técnica se utilizará, puesto que se considera factible su
aplicación, ya que se poseen los recursos necesarios, a pesar de la experiencia de los
desarrolladores. Sin embargo, se considera que su aprendizaje no será complejo.

x Retroalimentación del Usuario: Esta técnica no se utilizará, pues no es factible de

aplicar en este caso de estudio, ya que no se posee un modo de reportes de incidencias,
además de contar con un número reducido de usuarios para llevarla a cabo.

x Cuestionarios, Entrevistas y Encuestas: Esta técnica se utilizará, ya que se considera

factible su aplicación, puesto que se disponen de los recursos necesarios la
disponibilidad previa del usuario. Además, los desarrolladores poseen experiencia
previa en este tipo de pruebas, a pesar del esfuerzo que conlleva.
Pauta para el caso de estudio: Sitio Web para una Empresa Privada

1. Entrevista.

2. Personas.

3. Casos de Uso Esenciales.

4. Especificaciones de Usabilidad.

5. Pensar en Voz Alta.

6. Prototipos de Papel.

7. Árboles de Menús.

8. Mapas de Roles de Usuario.

9. Cuestionario de Usabilidad.

2. Caso de estudio: Sitio Web para el Control de Remuneraciones Multiempresas

Análisis de los factores por cada técnica de usabilidad que se utilizará en la pauta:

x Caso de Uso Esencial: Esta técnica se utilizará, ya que esta técnica es factible de
aplicar, puesto que al menos un desarrollador tiene formación en ésta y no se requiere
de mayor interacción del usuario, además de disponer de un espacio físico y los
insumos necesarios para llevarla a cabo.

x Card Sorting: Esta técnica no se utilizará, ya que no es factible de aplicar en este caso
de estudio, porque se requiere de un gran número de usuarios, donde en particular no se
dispone de tantos de ellos, a pesar de disponer de un espacio físico y los insumos
necesarios para llevarla a cabo.
x Diagramas de Afinidad: Esta técnica no se utilizará, ya que no es factible de aplicar en
el presente caso de estudio, puesto que se requiere de un gran número de usuarios,
además de un tiempo considerable en su aplicación, a pesar de disponer de un espacio
físico y los insumos necesarios para llevarla a cabo. También, los desarrolladores no
tienen formación en este tipo de técnicas, pues la experiencia necesaria debe ser a lo
menos media.

x Escenarios de Tareas: Esta técnica se utilizará, ya que se considera factible de aplicar

en el presente caso de estudio, puesto que los desarrolladores tienen cierta experiencia
en la definición de escenarios.

x Especificaciones de Usabilidad: Esta técnica se utilizará, ya que es factible de aplicar

en este caso de estudio, pues se considera de gran aporte en la usabilidad del producto
final. Además, los desarrolladores tienen experiencia en cuanto a la especificación de
los requisitos no funcionales del sistema.

x Escenarios y Storyboards: Esta técnica no se utilizará, ya que no es factible de aplicar

en este caso de estudio, ya que los desarrolladores no poseen la formación necesaria.

x Investigación Contextual: Esta técnica no se utilizará, ya que no es factible de aplicar

en este cado de estudio, puesto que se dispone de una cantidad reducida de usuarios y
los desarrolladores no tienen la formación necesaria para llevarla a cabo.

x Inspecciones: Esta técnica no se utilizará, ya que no es factible su aplicación en el caso

de estudio, puesto que los desarrolladores no poseen una formación previa en cuanto a
su aplicación. A pesar de ser un aporte importante en la usabilidad del producto final y
no tener una participación del usuario.
x Inspecciones Colaborativas: Esta técnica no se utilizará, ya no es factible de aplicar en
este caso de estudio, puesto que los desarrolladores no poseen una formación previa de
esta técnica, además de contar con un número reducido de usuarios para llevarla a cabo.

x Mapas de Roles de Usuario: Esta técnica se utilizará, ya que se considera factible su

aplicación, puesto que es un gran aporte en la usabilidad del sistema final. Además, no
requiere de la participación del usuario y la formación de los desarrolladores es baja, no
necesita de una experiencia excesiva, de manera que los desarrolladores la pueden
llevarla a cabo sin problema alguno.

x Observación de Campo o Etnográfica: Esta técnica no se utilizará, ya que no es

factible su aplicación en el presente caso de estudio, puesto que los desarrolladores no
poseen una formación alta en esta técnica, además, que su aporte en usabilidad es baja,
debido a que se necesita mucho tiempo para observar los problemas de usabilidad.

x Personas: Esta técnica no se utilizará, ya que su aplicación no se considera factible en

este caso de estudio, puesto que a pesar de su aporte en usabilidad es importante, los
desarrolladores consideran que su aprendizaje incurriría en un mayor esfuerzo.

x Perfiles de Usuario: Esta técnica se utilizará, ya que se considera de gran aporte en

cuanto a la usabilidad. Además los desarrolladores poseen la formación suficiente para
llevarla a cabo.

x Prototipo de Papel: Esta técnica se utilizará, puesto que se considera factible su

aplicación, ya que por parte de los desarrolladores, implica una técnica sencilla de
 aplicar y no requiere de una experiencia excesiva. Además, contribuye un aporte
considerable en la usabilidad del sistema final y se destaca su cercanía con la IS.

x Árboles de Menús: Esta técnica no se utilizará, puesto que a pesar que la formación de
los desarrolladores es baja y no necesita participación del usuario no se considera tan
necesaria para este caso de estudio.

x Evaluación heurística: Esta técnica no se utilizará, ya que su aplicación no se

considera factible, puesto que es necesaria una cantidad de evaluadores elevada.

x Guías de Estilo del Producto: Esta técnica no se utilizará, puesto que su aporte en
usabilidad no está alto como en otras técnicas, además de requerir una amplia
experiencia por parte de los desarrolladores. Además, el caso de estudio no se considera
complejo.

x Mapas de navegación: Esta técnica no se utilizará, ya que no es factible de aplicar en

este caso de estudio, puesto que los desarrolladores no poseen experiencia en este tipo
de técnicas, donde su aprendizaje suele ser complejo.

x Test de Usabilidad en Laboratorio: Esta técnica no se utilizará, puesto que no se

tienen los insumos suficientes (no existe la factibilidad de montar un laboratorio de
usabilidad), ni la disponibilidad de los usuarios para este tipo de pruebas. Por otro lado,
no se tienen los evaluadores suficientes para poder aplicarla.
x Pensar en voz alta: Esta técnica se utilizará, puesto que se considera factible su
aplicación, ya que se poseen los recursos necesarios, a pesar de la experiencia de los
desarrolladores. Sin embargo, se considera que su aprendizaje no será complejo.

x Retroalimentación del usuario: Esta técnica se utilizará, puesto que es factible de

aplicar en este caso de estudio, ya que se posee un modo de reportes de incidencias,
además de contar con de la disponibilidad de los usuarios para llevarla a cabo.

x Cuestionarios, entrevistas y encuestas: Esta técnica se utilizará, ya que se considera

factible su aplicación, puesto que se disponen de los recursos necesarios la
disponibilidad previa del usuario. Además, los desarrolladores poseen experiencia
previa en este tipo de pruebas, a pesar del esfuerzo que conlleva.

• Pauta para el caso de estudio: Sitio Web para el Control de Remuneraciones

Multiempresas

1. Entrevista.

2. Perfiles de usuario.

3. Casos de Uso esenciales.

4. Escenario de tareas.

5. Especificaciones de Usabilidad.

6. Pensar en voz alta.

7. Prototipos de papel.

8. Mapas de Roles de usuario.

9. Retroalimentación con el usuario.

10. Cuestionario de usabilidad.

4.2. Definición Final de la Propuesta: Pautas de Usabilidad

A raíz de la elaboración de la Propuesta Preliminar, para la definición Final de ésta se
refina la propuesta por razones de tiempo en:

Elegir solo un caso de estudio.

Elaborar una pauta la que se aplicará al caso de estudio elegido.

En el siguiente apartado se presentará el proceso de refinamiento de la propuesta

preliminar.

4.2.1. Refinamiento de la Propuesta Preliminar

El contenido (conjunto de técnicas) de las pautas de la propuesta preliminar se modificó
con el fin de especificar y enfocar la elección de cada una de las técnicas al caso de estudio
elegido: “Sitio Web para el Control de Remuneraciones Multiempresas”, centrándose en
integrar al usuario como una entidad participe de todo el proceso de desarrollo. Cada una de
las técnicas seleccionadas se encuentra estrechamente elegida en base al entorno y
naturaleza del caso de estudio mencionado, además de considerar el conjunto final en el
cual se basó la propuesta preliminar este proyecto. La importancia de refinar la propuesta
preliminar yace en la integración de las técnicas de usabilidad en las etapas de desarrollo
del proyecto enfocadas en el caso de estudio elegido, a pesar de no ser objeto de estudio del
proyecto en general, sino que más bien, de entender que es un factor importante que afecta
de manera directa la aplicación del DCU, tanto por el aporte que prestan las técnicas para
incluir al usuario desde el inicio del proceso de desarrollo, como para la aplicación de los
procesos mismos del enfoque.

4.2.2. Elección de Técnicas de Usabilidad para la Propuesta Definitiva

Para llevar a cabo el enfoque DCU en el caso de estudio Sitio Web para el Control de
Remuneraciones Multiempresas, es necesario aplicar una serie de técnicas de usabilidad,
las cuales componen la Pauta que conforma el Refinamiento de la Propuesta Preliminar del
proyecto. Para esta elección, es necesario tomar en cuenta los factores anteriormente
analizados (en la Propuesta Preliminar de la etapa de elaboración): Factibilidad en la
aplicación, Técnicas más utilizadas por los desarrolladores y el conjunto resultado obtenido
al acotada la población de técnicas disponibles por ambas propuestas. Por consiguiente, se
presenta un análisis en base, a los factores anteriormente mencionados, de donde se indican
las razones de la utilización de cada técnica, en caso contrario, las razones de por qué no se
utilizará la técnica según corresponda.

Es importante destacar que el factor de mayor peso en el análisis, además de la factibilidad

de aplicación de la técnica en particular, es la mejora (económica, usabilidad, tiempo etc.)
que se produciría en el producto final si se incluye una técnica específica y también en
cuanto a la inclusión del usuario en el proceso.

Cabe destacar que la utilización de cada una de las técnicas seleccionadas brindan un
importante apoyo en cuanto la mejora en la usabilidad del producto, la cual se traduce en lo
que el usuario necesita y espera del sistema en construcción. Estas técnicas, cada una por
separado y en conjunto se centran en actividades específicas del Enfoque Centrado en el
Usuario, incluyendo al usuario como participante de alguna de ellas y en caso contrario se
enfocan explícitamente en él, tratando aspectos que sin duda con otro enfoque son dejados
de lado.

1. Análisis de cada una de las Técnicas de Usabilidad

El análisis de cada una de las técnicas de usabilidad, se enfoca en la aplicación de técnicas

que no implican gastos económicos relativamente grandes, a la disponibilidad del cliente y
el aporte en usabilidad de cada técnica, las cuales cubren en su mayoría las actividades
descritas en el enfoque DCU.

x Caso de Uso Esencial: Esta técnica se utilizará, ya que independiente de que el sitio
Web se modele con UML, los casos de uso esenciales entregan en un nivel más alto de
abstracción respecto a los casos de uso tradicionales, definiéndose en términos de
intenciones del usuario y responsabilidades del sistema, sin tener en cuenta la
tecnología usada y la implementación, lo cual brinda una descripción precisa de las
 tareas del usuario transformándose en una técnica de gran aporte para describir y definir
las tareas realizadas por éste.

x Card Sorting: Esta técnica no se utilizará, ya que en efecto para poder aplicar esta
técnica se necesita de la disponibilidad por parte de los usuarios del sistema, factor que
para este caso no se encuentra disponible en un 100%. Cabe destacar, que mediante esta
técnica se tiene una mejor idea del modelo mental del usuario, pero por tratarse de
usuarios que ya han trabajados con sistemas de este tipo, no será muy complejo
interpretar este modelo.

x Diagramas de Afinidad: Esta técnica no se utilizará, puesto que entre los métodos de
categorización no es la más apropiada para la naturaleza del proyecto, ya que no aporta
una mayor mejora en la usabilidad del sistema. Por otra parte, requiere de un gran
número de personas (como equipo) para llevarla a cabo y un alto grado de complejidad,
lo cual incurriría en mayores gastos para su capacitación y disposición de tiempo.

x Escenarios de Tareas: Esta técnica no se utilizará, puesto que para la descripción de

tareas se utilizarán los casos de uso esenciales, con el fin de interpretar las tareas de una
manera más algorítmica, incluyendo la representación total de las tareas más relevantes
para el sistema en construcción, considerando todos los posibles escenarios.

x Especificaciones de Usabilidad: Esta técnica se utilizará, ya que para medir la

usabilidad se necesita estipular cual será la meta aceptable y alcanzable del software
respecto la usabilidad, además, esta técnica no incluye al usuario, lo que implica un
ahorro en cuanto a presupuesto y tiempo.
x Escenarios y Storyboards: Esta técnica se utilizará, ya que ésta entrega una visión
general respecto al usuario y su entorno mientras interactúa con el sistema. La
importancia de esta técnica de prototipado es que considera ya sea la situación actual de
los usuarios con el sistema que interactúan y la situación futura (mejoras) de la
interacción con el nuevo sistema propuesto, proporcionando una visión global de cómo
será el nuevo sistema en construcción.

x Investigación Contextual: Esta técnica no se utilizará, ya que se conoce previamente

y de manera específica el entorno de trabajo de la empresa en cuestión. Además, los
usuarios y el cliente tienen una idea clara de lo que se pretende como producto,
basándose en el sistema anteriormente utilizado.

x Inspecciones e Inspecciones Colaborativas: Estas técnicas no se utilizarán, ya que en

preferencia a este tipo de técnicas se utilizará la evaluación heurística, por parte de los
Test de inspección por evaluadores expertos, considerando que los usuarios no se
encuentran en conocimiento de los estándares y guías de estilo. Además de contar con
un número reducido de usuarios para llevarla a cabo.

x Mapas de Roles de Usuario: Esta técnica no se utilizará, ya que desde la técnica

Perfiles de Usuarios se desprenden implícitamente los roles de cada uno de los usuarios
más significativos.

x Observación de Campo o Etnográfica: Esta técnica no se utilizará, ya que para

conceptualizar el modelo mental del usuario se considerará el análisis de tareas como
tal, por otra parte, los clientes en este caso no poseen una disponibilidad completa para
efectuar este tipo de técnicas, además de tomar un gran esfuerzo para llevarlas a cabo.
x Personas: Esta técnica no se utilizará, ya que el rango de usuarios no es amplio y con
técnicas del mismo tipo se pueden abstraer los posibles usuarios y tareas, por ejemplo
Perfiles de usuarios, entre otros.

x Perfiles de Usuario: Esta técnica se utilizará, los perfiles de usuario son necesarios
para cualquier proyecto en general, puesto que es esencial el conocimiento de los
futuros usuarios del sistema. Técnica de preferencia ya que el número de usuarios no es
amplio y es conocido en cuanto a sus roles.

x Prototipo de Papel: Esta técnica se utilizará, ya que permite una gran velocidad y
flexibilidad en el momento de hacer los prototipos, por otra parte, al solo necesitar de
materiales básicos se convierte en una técnica bastante económica lo cual facilita su
implementación.

x Árboles de Menús: Esta técnica no se utilizará, no se considera necesaria ya que el

sistema en si no se encuentra basado en menús. Por otro lado, la estructuración
jerárquica del sistema se encuentra implícita por cada futura interfaz del sistema.

x Evaluación Heurística: Esta técnica se utilizará, ya que es necesario identificar las

posibles deficiencias de usabilidad en el sistema software. Es una variante de las
inspecciones de usabilidad donde los especialistas juzgan si cada elemento de la interfaz
de usuario sigue los principios de usabilidad establecidos. A pesar de no contar con
expertos de amplia experiencia se cuenta con un grupo de alumnos que poseen los
cimentos teóricos y experiencias (ramo de Human Computer Interaction impartido por
la Escuela) en realizar este tipo de evaluaciones.
x Guías de Estilo del Producto: Esta técnica no se utilizará, ya que se considera que su
aplicación es compleja. Esta técnica se justifica para proyectos en los cuales sea
necesario agrupaciones de familias de distinta envergadura, además de un gran esfuerzo
por parte de los desarrolladores que comparado a su mejoras en usabilidad no son lo
suficientemente altas como para aplicarlas, al menos en este caso de estudio.

x Mapas de navegación: Esta técnica se utilizará, ya que propone una visualización

gráfica de los posibles caminos (interacción del usuario) que se pueden navegar en un
sitio, su nomenclatura no es complicada y se puede enfocar al usuario para su mejor
entendimiento y representación del sitio Web a construir.

x Test de usabilidad en laboratorio: Esta técnica se utilizará, ya que todo sitio Web
necesita de una medición, ésta es una técnica que proporciona una medida empírica de
un sitio, tomada a partir de la observación sistemática de usuarios llevando a cabo
tareas reales. La utilización de esta técnica en preferencia de otras es gracias a la
posibilidad de utilizar el laboratorio de usabilidad proporcionado por la Escuela de
Informática de la universidad y los ámbitos que se cubren con su aplicación. Es una de
las técnicas más importantes y utilizadas por los desarrolladores y evaluadores en
cuanto a usabilidad.

x Pensar en voz alta: Esta técnica no se utilizará, ya que a pesar de ser una técnica que
proporciona mejoras importantes de usabilidad al encontrarse relacionada directamente
con el usuario frente al producto, se prefiere utilizar una técnica similar (Test de
Usabilidad con usuarios), puesto que su funcionalidad y efectividad está directamente
relacionada con datos cualitativos y no con medidas de funcionamiento (a diferencia del
Test de Usabilidad con usuarios).
x Retroalimentación del usuario: Esta técnica no se utilizará, ya que el presupuesto del
proyecto no incluye métodos como grupos de noticias, foros, etc. para llevar a cabo esta
técnica. Se deja para desarrollos futuros esta interacción con el usuario.

x Cuestionarios, entrevistas y encuestas: Estas técnicas se utilizarán, ya que se

consideran de gran aporte a la usabilidad del producto, se convierte en una antesala y un
después respecto a las necesidades del usuario interactuando directamente con él,
algunas proporcionando información subjetiva de las necesidades de los usuarios, otras
de la opinión y apreciación de los usuarios respecto al producto.

4.3. Pautas de Usabilidad

4.3.1. Pauta de Usabilidad de la Elaboración de la Propuesta Preliminar

del Proyecto
Pauta de la Elaboración de la Propuesta Preliminar:

1. Entrevista.

2. Perfiles de usuario.

3. Casos de Uso esenciales.

4. Escenario de tareas.

5. Especificaciones de Usabilidad.

6. Pensar en voz alta.

7. Prototipos de papel.

8. Mapas de Roles de usuario.

9. Retroalimentación con el usuario.

10. Cuestionario de usabilidad.

4.3.2. Pauta de Usabilidad Definitiva de la Propuesta del Proyecto
Pauta Refinada:

1. Entrevista.

2. Cuestionario de usabilidad.

3. Casos de Uso Esenciales.

4. Escenario y Storyboards.

5. Especificaciones de Usabilidad.

6. Evaluación Heurística.

7. Mapas de navegación.

8. Perfiles de usuario.

9. Prototipos de papel.

10. Test de Usabilidad en Laboratorio.

4.3.3. Pauta Definitiva en los Procesos de Desarrollo

a) Análisis:

Educción y Análisis de Requisitos:

Entrevistas.

Análisis de Usuarios:

Perfiles de Usuario.

Análisis de Tareas:

Casos de Uso Esenciales.

Desarrollo del concepto del producto:

 Escenario y Storyboards.

Prototipado:

Prototipos de Papel.

Especificación de Requisitos:

Especificaciones de Usabilidad.

Validación de Requisitos:

Evaluación Heurística.

a) Diseño:

Diseño de la Interacción:

Mapas de Navegación.

b) Evaluación:

Evaluación por Expertos:

Evaluación Heurística.

Test de Usabilidad:

Test de Usabilidad en Laboratorio.

Estudio de Seguimiento de Sistemas Instalados:

Cuestionario de Usabilidad.
Capítulo 5
Aplicación del Diseño Centrado en el Usuario en el
Caso de Estudio

5.1. Criterio para Aplicar el Diseño Centrado en el Usuario

Para comenzar la aplicación del Enfoque DCU en el caso de estudio elegido, es necesario
definir lo siguiente:

El Modelo de Proceso del Proceso Unificado de Desarrollo.

• Proceso Unificado de Desarrollo

El Proceso Unificado de Desarrollo realiza una evolución del sistema software a través del
uso de prototipos, los que favorecen una interacción continua entre el cliente y sus
requisitos con el desarrollo del software, posibilitando la retroalimentación con el cliente
con el fin de implementar correcciones posteriores. Consiste en lo siguiente:

El Proceso Unificado es un proceso de desarrollo de software configurable que se

adapta a proyectos que varían en tamaño y complejidad.

Está basado en componentes, de modo que el producto desarrollado también se basa

en componentes comunicados a través de interfaces.

Este paradigma se guía por modelos realizados con UML (lenguaje unificado de
desarrollo), específicamente en los casos de uso, que representan las funcionalidades
del sistema, y guían el diseño, implementación y prueba del sistema, describe los
diversos pasos involucrados en la captura de los requerimientos y en el
establecimiento de una guía arquitectónica lo más pronto, para diseñar y probar el
sistema hecho de acuerdo a los requerimientos y a la arquitectura, detalla qué
entregables producir, cómo desarrollarlos y también provee patrones. El Proceso
 Unificado de Desarrollo es soportado por herramientas que automatizan entre otras
cosas, el modelado visual, la administración de cambios y las pruebas.

Características

Dirigido por los casos de uso.

Centrado en la arquitectura.

Iterativo e incremental.

Configurable, adaptable a diferentes proyectos.

Ventajas

Trabaja perfectamente aunque los requerimientos no estén completamente definidos

al inicio del proyecto.

Reducción de los costos del riesgo, pues se avanza paso a paso.

Altas posibilidades de cumplir con los calendarios de entrega previstos.

Este paradigma consta de 4 etapas:

x Inicio: Se establece la razón de ser del proyecto y se determina su alcance; es aquí

cuando se obtiene el compromiso del patrocinador del proyecto para proseguir.

x Elaboración: Establecer un plan y una arquitectura correcta. Se reúnen requerimientos

más detallados, se hacen análisis y diseño de alto nivel, a fin de establecer una
arquitectura base, y se crea el plan de construcción.

x Construcción: Desarrollo del sistema. Consta de muchas iteraciones, cada una de las
cuales construye software de calidad para producción, probado e integrado, que cumple
un subconjunto de los requerimientos del proyecto, es decir sigue un modelo
incremental. Cada una de estas iteraciones contiene todas las fases del ciclo de vida:
análisis, diseño, implementación y puesta en marcha.
x Transición: Proporcionar el sistema a los usuarios finales. También se realizan las
pruebas beta, el afinamiento del desempeño y el entrenamiento del usuario.

Esquema visual del Proceso Unificado de Desarrollo:

Fig. 12. Proceso Unificado de Desarrollo.

5.2. Planificación del Proceso Centrado en el Usuario

La planificación del proceso centrado en el usuario consiste en establecer el procedimiento
que integra las actividades del DCU en el proceso de desarrollo. Para este caso de estudio
especifico, a continuación se define el procedimiento en donde se integran las actividades
del DCU en el Proceso Unificado de Desarrollo.

El Diseño Centrado en el Usuario en el Proceso Unificado de Desarrollo

La integración de las actividades del DCU en el proceso Unificado de Desarrollo se

presenta en el siguiente esquema visual, el cual muestra una vista general desde la
perspectiva del Proceso Unificado:
Fig. 13. Integración de las Técnicas de Usabilidad en el Proceso Unificado de Desarrollo.
La Fig. 13, caracteriza la fase de Iniciación por parte del Proceso Unificado de Desarrollo,
que se ve complementada con las técnicas de usabilidad: Entrevistas y Perfiles de Usuario,
las cuales en un comienzo proponen a los usuarios del sistema, tanto por sus perfiles y roles
proporcionando gran funcionalidad para entender los tipos de usuario existentes. En la Fase
de Elaboración, podemos apreciar que se incluyen técnicas de análisis de tareas, como lo
son, Casos de Uso Esenciales, Escenarios y Storyboards y Prototipos de papel, con el fin de
incluir al usuario de una manera más cercana y representativa para la fase en donde se
construye la arquitectura del sistema como tal, cada una de éstas entrega descripciones de
las tareas realizadas por el usuario en su entorno de trabajo, con el fin de clasificar la
información y proporcionar una estructura bien definida para la automatización de estas en
el sistema. En la Fase de Construcción se incluyen técnicas de usabilidad enfocadas en la
parametrización y medición de las metas de usabilidad de los prototipos hasta el momento,
como lo son: las Especificaciones de Usabilidad, Evaluación Heurística y apoyadas de
técnicas que esquematizan la interacción del sistema: Mapas de Navegación. Por último, la
Fase de Transición en donde se implementa el prototipo entregable, con el fin de que los
usuarios validen la construcción del sistema, es importante conocer la opinión del usuario y
a su vez probar si el software construido cumple con las expectativas que se depositaron en
él, se aplican técnicas como Test de Usabilidad con usuarios y cuestionarios de usabilidad.

El siguiente esquema visualiza la planificación de las técnicas de usabilidad según las

iteraciones propuestas para el sistema. El número iteraciones definidas para la construcción
del sistema se limitan a 2 por razones de tiempo. El esquema consiste en lo siguiente:

Fig. 14. Iteraciones del Sistema de Remuneraciones Multiempresas según la Integración de

Técnicas de Usabilidad.
La Fig. 14, presenta una vista generalizada en cuanto a las iteraciones propuestas para el
sistema. Cada iteración incluye las técnicas de usabilidad de la pauta (propuesta preliminar
refinada) del proyecto según los hitos del Proceso Unificado de Desarrollo para cada
iteración.
En el siguiente apartado, después de conocer la planificación del DCU, se especificará el
contexto de uso del sistema en construcción.

5.3. Comprender y Especificar el contexto de uso

El Comprender y Especificar el contexto de uso tiene como objetivo comprender y registrar
las características del entorno de trabajo de los usuarios. Para esto el contexto de uso consta
de los siguientes componentes:

Análisis de Usuarios.

Análisis de Tareas.

El entorno en que los usuarios van a utilizar el sistema, incluyendo el Hardware,

Software y materiales que se van a utilizar.

5.3.1. Análisis de los Usuarios

Este Análisis identifica para los usuarios sus conocimientos, necesidades y características
relevantes en su interacción con el sistema. Es importante identificar la destreza,
experiencia, formación, conocimiento del dominio, características físicas, preferencias,
actitudes, entre otras. De manera, que el sistema se adapte a sus usuarios.

Para comenzar con el análisis de los usuarios, es necesario conocer las funciones básicas
del estudio contable para el cual se construye el Sistema de Remuneraciones
Multiempresas.

1. La Organización

La organización para la cual el Sistema de Remuneraciones Multiempresas se desarrollara

tiene como nombre jurídico: Studio Tributario Contable. Este es un estudio de contabilidad,
con personalidad jurídica que lo hace perteneciente al sector privado, el cual se ubica en
Avenida Isidoro Dubournais Nº 225 Tercer piso, El Quisco. Este estudio funciona desde el
año 1980 y presta servicios a las PYMES del sector nacional; del rubro contable o
tributario, los cuales ejercen actividades, como por ejemplo: impuestos mensuales,
remuneraciones, asesorías, balances, renta, entre otros.
La función principal que ofrece el estudio, es la siguiente:

Prestar asesorías para que las empresas puedan trabajar de manera regular con
instituciones como el Servicio de Impuestos Internos e Inspección del Trabajo.

El estudio consta con una estructura basada en 3 departamentos, los cuales se organizan
según la siguiente estructura jerárquica:

Fig. 15. Estructura jerárquica del Studio Tributario Contable.

En la Fig. 15. Podemos apreciar la estructura jerárquica de la organización, la cual consta
de 3 departamentos: Operaciones IVA, Remuneraciones y Renta. De los cuales a
continuación se describirán a continuación:

Departamento Operación IVA:

Controlar las ventas y compras de las Pymes que disponen de sus servicios.

Informar de posibles cambios en las disposiciones del Servicio de Impuestos Internos

a sus clientes.

Confeccionar Formulario Nº 29, para declarar sus impuestos.

 Traspasar la información del movimiento mensual de las empresas, a sus respectivos
libros diarios.

Realizar trámites de contables de una empresa, tales como: términos de giro,

timbrajes de documentos, avisos de ventas de vehículos, transferencias, inicio de
actividades, etc.

Realizar resumen anual y actualizado, para confeccionar la declaración de renta.

Departamento Operación Renta:

Confeccionar balance, declaraciones juradas (1887, 1879, 1811 etc.) y posteriormente

la declaración de capital.

Elaborar la declaración de renta. Formulario Nº 22.

Departamento Remuneraciones:

Realizar las liquidaciones de sueldo mensual, para cada trabajador que existe en cada
una de las empresas.

Elaborar planillas de pago provisional, ya sea para: Isapres, AFP, INP, Mutuales, etc.

Confeccionar los finiquitos y contratos de trabajo de los trabajadores.

Informar nuevas disposiciones de la Inspección del trabajo, Isapre, AFP, etc.

Realizar resumen anual y actualizado, de cada uno de los trabajadores, por empresa
para confeccionar la declaración de renta.

Cabe destacar, que para la organización el sistema en construcción solo representará el

departamento de Remuneraciones.

2. Entorno Físico

Para un análisis completo de los usuarios es necesario tomar en cuenta el entorno físico con
el cual este interactúa. Este se centra básicamente en el análisis de elementos como: niveles
excesivos de ruido, luminosidad, entre otros, básicamente lo relacionado con las
herramientas que utilizan los usuarios para llevar a cabo sus tareas.
El Studio Contable consta con 2 oficinas espaciosas, ambas alfombradas y con colores
claros para adquirir una iluminación adecuada (en base las recomendaciones ergonómicas).

Consta con los artículos de oficina adecuados para llevar a cabo sus tareas, es decir:

Escritorios de oficina.

Carpetas, resmas de papel, etc.

PC de escritorio.

Impresoras.

Otras.

3. Entorno Laboral Social

El análisis del entorno laboral-social es importante para la organización, puesto la

normativa legal con la cual trabaja interpone una serie de restricciones. Esta se centra
básicamente en las restricciones de tipo:

Problemas causados por el tipo de trabajo que se efectúa.

Problemas con los usuarios.

3.1. Restricciones Laborales

El estudio contable debe cumplir con las normas legales que corresponden a su rubro,
ajustarse a las leyes del código del trabajo. A continuación, se explicarán algunos
conceptos, de acuerdo a la ley del trabajo.

Ley 19728: Seguro de Cesantía

El seguro de cesantía contempla un financiamiento compartido: aportan trabajador,

empleador y Estado.

La cotización mensual depende del tipo de contrato del afiliado:

Cuando se trata de un contrato a plazo fijo, por obra o faena, todo el costo del seguro
es de cargo del empleador, quien debe cotizar mensualmente el 3% de la
 remuneración imponible del trabajador, con tope de UF 90. Ese porcentaje se
acumula íntegramente en la cuenta individual del trabajador.

Cuando se trata de un contrato a plazo indefinido, en cambio, el trabajador debe

aportar mensualmente de su bolsillo un 0,6% de su remuneración imponible, con tope
de UF 90, en tanto su empleador cotiza un 2,4% de ese mismo monto. Del aporte de
la empresa, sólo un 1,6% se abona en la cuenta individual del trabajador, y el 0,8%
restante ingresa a un fondo de reparto, denominado “fondo de cesantía solidario”.

Cabe señalar que el aporte de 1,6% con cargo del empleador es deducible de la
indemnización a que tiene derecho el trabajador con contrato indefinido cuando es
despedido “por necesidades de la empresa”.

El Fondo de Cesantía Solidario se financia con una fracción de la cotización del empleador
(0,8%) sólo en el caso de los contratos indefinidos, y con aportes del Estados definidos por
Ley. Su finalidad es financiar las prestaciones mínimas que la ley garantiza a aquellos
afiliados que –cumpliendo con los requisitos pertinentes- han agotado o no disponen de
recursos suficientes en su cuenta individual al momento de quedar cesantes.

Ley 19.988: Remuneraciones horas extraordinarias (Anexo D)

La jornada extraordinaria es aquella que exceda el máximo legal (10 horas diarias) o que
supere el número de horas pactado en el contrato (suponiendo que se estableció una jornada
menor a 45 horas).

La jornada extraordinaria corresponde al período de tiempo trabajado inmediatamente

después de la jornada ordinaria, por lo tanto una persona sólo puede trabajar horas
extraordinarias en la medida que haya cumplido con la jornada ordinaria.

La normativa laboral establece que como máximo se pueden trabajar dos horas
extraordinarias al día.

A partir del 1 de diciembre de 2001 la ley obliga a que las horas extraordinarias deban
necesariamente pactarse por escrito, y su finalidad será atender necesidades transitorias o
temporales de la empresa. El pacto no debe tener una duración superior a tres meses,
pudiendo renovarse por acuerdo de las partes.

A falta de pacto escrito, se consideran extraordinarias las que se trabajen en exceso de la

jornada pactada con conocimiento del empleador. Con este último punto quedan cubiertas
las situaciones imprevistas que no alcancen a ser previamente pactadas. La ley no se
pronuncia sobre el número de veces que el pacto puede ser renovado. Una jornada menor al
máximo semanal, por ejemplo, 42 horas a la semana, las tres restantes (que enterarían 45)
no constituyen una especie de "reserva" para ser trabajadas cuando el empleador así lo
estime; por lo tanto, si son requeridas, deberán pagarse como horas extraordinarias.

Ley 16.840: Libro de Remuneraciones, confección de un Libro de Remuneraciones

(Anexo E)

Esta ley define los parámetros que deben cumplirse en la confección de un libro de
Remuneraciones, como por ejemplo:

1º Nombre y apellido del trabajador,

2º Remuneración imponible, no imponible y remuneración total.

Ley Asignación Familiar. Ley Nº 18.469

Pertenecen al Régimen, los dependientes del sector público y privado, que hayan cotizado
los últimos cuatro meses, en los últimos doce meses del calendario, manteniendo la calidad
de afiliados por los doce meses siguientes; así como también, los trabajadores dependientes
contratados diariamente por turnos o jornadas, que registren al menos 60 días de
cotizaciones en los doce meses de calendario anteriores, mantendrán la calidad de afiliados
por los próximos doce meses [Ley 18.469, 2004].

Ley de Gratificación

Esta ley significa que las empresas, que persigan fines de lucro, que tengan la obligación de
llevar libros de contabilidad y que tengan utilidades o excedentes líquidos en sus giros
comerciales, deben pagar a sus trabajadores un porcentaje de ésta. El porcentaje puede ser
acordado de la siguiente manera:

Consiste en repartir el 30% de la utilidad líquida entre todos los trabajadores, en proporción
a las remuneraciones percibidas por cada uno de ellos.

Consiste en pagar o abonar al trabajador el 25% de las remuneraciones devengadas durante

el año, cualquiera sea la utilidad líquida que obtenga la empresa. Esta gratificación tiene un
tope equivalente a 4,75 Ingresos Mínimos Mensuales (IMM). De esta manera, se regula el
pago de las gratificaciones a los trabajadores.

Indemnización

La indemnización consiste en entregar al trabajador despedido una cantidad de dinero que

va en proporción al tiempo que ha desempeñado labores en la empresa, y su financiamiento
corre por cuenta exclusiva del empleador. Este derecho consiste en pagar un mes de la
última remuneración por cada año de servicio y fracción superior a seis meses con un tope
máximo de 11 años.

Cuando la ley habla de “por cada año de servicio”, quiere decir que si el trabajador no ha
enterado el año de funciones, no tendrá derecho a percibir indemnización alguna (al menos
desde el punto de vista legal).

En tanto, lo de “fracción superior a seis meses” implica que si un trabajador lleva

trabajando un año y cinco meses, en caso de ser despedido se le considerará sólo un año
trabajado; en cambio, si es despedido al año y siete meses, se le contabilizarán dos años, y
así sucesivamente.

“Con tope de 11 años”: aquellos trabajadores que hayan sido contratados después del 14 de
agosto de 1981, como máximo se les reconocerá 11 años trabajados en la empresa
independientemente de si llevan más tiempo trabajando, es decir, tendrán derecho a 11
sueldos como tope.

En cambio, aquellos trabajadores contratados antes del 14 de agosto de 1981, podrán exigir
el pago de su indemnización sin tope de años.
La excepción será la jornada parcial, pues la base de cálculo para la indemnización no
necesariamente es la última remuneración. Aquí tenemos las siguientes posibilidades:
puede ser la última remuneración, el promedio de las remuneraciones durante toda la
vigencia del contrato o el promedio de los últimos 11 años de contrato (suponiendo que
alguien pudiera trabajar tantos años bajo una jornada como ésta). La suma que resulte
mayor que cualquiera de estas opciones se tomará como base de cálculo para el mes por
año.

El tope de sueldo mensual, para el cálculo de la indemnización, es de $ 1.657.593 por año;

cambiando este sólo en caso de acuerdo mutuo con el empleador.

Contrato de Trabajo

Código del Trabajo, Capítulo I. del Nº 7 al Nº 12, explica los parámetros que deben ser
contenidos en los contratos, para ser respetados tanto por el empleador como el trabajador.
Como por ejemplo:

Lugar y fecha de trabajo.

Individualización de las partes con indicación de la nacionalidad, fecha de nacimiento

e ingreso del trabajador.

Determinación de la naturaleza de los servicios y del lugar o ciudad en que haya de

presentarse El contrato podrá señalar dos o más funciones específicas

Esta es la normativa legal, que regula el pago de las remuneraciones y previsiones en Chile;
teniendo presente estas leyes se desarrollara el “Sistema de Remuneraciones
Multiempresas”.

3.2. Problemas con los usuarios

Es de gran importancia analizar las relaciones con los usuarios, por consideraciones para la
construcción futura las cuales son de gran aporte. Este consiste en lo siguiente:

La interacción entre los trabajadores con los usuarios se basa en el buen servicio, factor que
apremia la eficiencia, acertibidad y rapidez frente a la solución de posibles problemas que
se presenten, en la mayoría de los casos estos se resuelven al instante, a no ser de que sean
trámites que involucren cedula de identidad y/o licencia. Por tanto, la importancia de este
análisis radica en que el sistema en construcción tendrá que tener un tiempo de respuesta
adecuado para poder producir estas soluciones. Además, de una baja utilización del mouse,
lo cual agiliza la utilización del sistema en general, optimizando los tiempos para llevar a
cabo las tareas.

4. Los Usuarios del Studio Contable

El Análisis de los usuarios del estudio contable consiste en lo siguiente:

Dar una definición, clasificación y agrupación de los usuarios más relevantes para el
sistema, es decir, definir los Perfiles de Usuario existentes, tanto por sus características y
roles mediante técnicas que apoyen a la captura de datos, para este caso las Entrevistas.

A continuación se presenta el desarrollo de las técnicas de usabilidad: Entrevistas y Perfiles

de usuario.

4.1. Diseño de la Técnica de Usabilidad: Entrevistas

Las entrevistas tienen como fin adquirir información relativa, en este caso, a los usuarios y
las tareas que llevan a cabo, saber qué es lo que quieren, etc.

A continuación se presenta la estructura y resultados de la entrevista aplicada al estudio

contable en cuestión, enfocada en recopilar información sobre qué es lo que se quiere del
sistema:

Entrevista a: El administrador (usuario responsable del proceso de remuneraciones) y el

asistente (usuario generador de reportes en el sistema).

Fecha: 04/04/08

Lugar: Avenida Isidoro Dubournais Nº 225 Tercer piso, El Quisco.

Guión de la Entrevista:
 Opinión del usuario respecto al sistema que utiliza en la actualidad.

Falencias que ameritan urgencia resolver.

Consideraciones como: rapidez, eficacia, eficiencia, estructura, etc.

Estado anterior a la entrevista:

La entrevista se llevó a cabo en el estudio contable, en una de las oficinas correspondiente a

las operaciones remuneraciones, en un ambiente ameno para realizar la entrevista, con un
espacio físico acorde y cómodo.

Se notó amplio interés por parte del usuario, el cual se encontraba motivado por el apoyo
mediante el sistema futuro para su labor profesional.

Objetivo:

El objetivo para el entrevistador es recopilar la mayor información respecto a las tareas

realizadas en el proceso de remuneraciones, a partir de la clasificación de estos, lo que se
traduce en el Sistema de Control de Remuneraciones. Las tareas realizadas por los usuarios
no se conocían previamente, a lo más, se tenía la idea general de cómo operaba el proceso
de remuneraciones como modelo de Negocio.

Entrevista en sí:

Entrevistador: ¿Qué funcionalidades busca en el Sistema de Control de Remuneraciones?

Entrevistado: El sistema además de lo que permite en la actualidad, se deben agregar

modalidades en donde se permita el ingreso de licencias medicas, permisos relacionados a
los trabajadores, vacaciones, planillas de pago, etc. Además, que este genere informes a
través de los históricos que el sistema actual posee. En términos generales, que se mejore el
manejo de la información a través de informes resúmenes y consistentes, para no manipular
información de forma manual.

Observación: El entrevistado tenía una idea clara respecto al funcionamiento de un Sistema

de Remuneraciones, por ende conocía al menos como quería organizar, tanto por parte de
los datos, qué quería almacenar, los filtros de búsquedas que necesitaba para realizar sus
informes y los proceso que quería automatizar.

Este comienzo dio una estructuración en bloques respecto a la entrevista.

Entrevistador: ¿Desea que el sistema genere el proceso de remuneraciones

automáticamente?

Entrevistado: Lo ideal es que el sistema genere la recopilación de todas las remuneraciones

por empresas, para llevar un control e histórico de la información, con sus correspondientes
informes asociados.

Observación: Se hace la acotación de algunos filtro prácticos para mejorar las salidas
respecto los cálculo de las remuneraciones, mediante ordenamientos ascendentes y/o
descendentes, por fechas, por empresas, trabajadores, etc. Con la finalidad de estructurar la
información, poder gestionar de mejor manera la presentación de la información, evitando
los cambios manuales que se efectuaban una vez obtenidos los cálculos correspondientes.

Entrevistador: ¿Qué tipo de informes desea generar con el nuevo sistema?

Entrevistado: informes de los cálculos totales de las planillas de pago por empresa,
informes anuales de remuneraciones e información presentada a las distintas instituciones
(INP, AFP, caja de compensación Los Andes, etc.), Informes de cada una de las
liquidaciones, donde se incluyan descuentos, bonos, permisos etc.

Observación: Se proponen ideas respecto a los tipos de informes, como por ejemplo
informes por trabajador de cada empresa, informes que totalicen las remuneraciones por
empresa, planillas de pagos estándares alimentadas por el sistema, etc.

Entrevistador: ¿Algún registro auditor que guarde los movimientos de paso por el Sistema
(Historial de transacciones y por parte de los usuarios)?

Entrevistado: Un historial ordenado para saber en detalle de los trabajadores, empresas,

parámetros del sistema, en forma de listado.
Observación: Se hace la acotación de agregar los listados de los cálculos de
remuneraciones generados por cada empresa.

Entrevistador: ¿Ayuda en línea?

Entrevistado: Ayuda preestablecida en caso de no tener claro los pasos a seguir mediante
posicionamientos del mouse.

Observación: Sugerencia del entrevistado respecto a que esta ayuda se enfoque

directamente en las interfaces con cada campo para evitar abrir un modulo anexo de la
aplicación. El entrevistado muestra una idea clara respecto a la pregunta.

Entrevistador: ¿Quiénes manejaran el sistema? ¿Qué hace cada uno?

Entrevistado: Manejan el sistema 2 personas: La persona encargada de generar todo el

proceso de remuneraciones, que con anterioridad ingresaba todo lo relacionado con los
trabajadores, empresas, parámetros nuevos (AFP, tipos de monedas, etc.). También se
encuentra su asistente, que se encarga de generar reportes de todo tipo.

Puntos no abarcados por el entrevistador:

1 Disminuir el uso del Mouse con el fin de agilizar el ingreso de los datos, sugerido por el
usuario.

2 Respecto a la interfaz gráfica, que esta sea cómoda visualmente, respecto a colores,
letra, etc. Que sea similar al sistema ya existente sin cambiar mucho su organización
temática, sugerido por el usuario.

3 Posibilidad de que en un futuro se pueda el sistema comunicar con las instituciones

declarables enviando y cargando la información de manera automática a través de los
portales Web. Sugerido por el usuario.

4.2. Diseño de la Técnica de Usabilidad: Perfiles de Usuario

Los perfiles de usuarios describen a los usuarios previstos del sistema, según las siguientes
características:
 Características psicológicas (por ej. actitud, motivación).

Conocimiento y experiencia (por ej. velocidad de mecanografiado, experiencia en la

tarea).

Características del puesto y de las tareas (por ej. frecuencia de uso, estructura de
tareas).

Características físicas (por ej. daltonismo).

Para obtener los distintos tipos de perfiles, existen varios métodos que entregan una
definición clara y característica de los distintos usuarios, estos son: Los cuestionarios y
entrevistas, una vez analizados permiten identificar patrones de usuarios (características y
necesidades similares) los que se traducirán en perfiles para el sistema en construcción.

Para encontrar los perfiles de usuarios más relevantes del sistema se aplicó un cuestionario
de Perfiles de Usuarios (Anexo C), el cual arrojo los siguientes resultados:

Perfiles:

x Administrador: Encargado de llevar a cabo todo el proceso de remuneraciones en el

sistema. Es decir, liquidaciones, finiquitos, cálculo de planilla previsional, ajuste de
factores, ingreso de trabajadores de las empresas, etc.

x Asistente: Administra la información correspondiente a historiales, listados,

liquidaciones de sueldo, contratos y finiquitos.

La encuesta aplicada para conocer los perfiles de usuario fue aplicada el personal del
departamento Remuneraciones, específicamente a la señora Luz Pizarro Carrasco,
administrador del departamento y a los asistentes que apoyan el proceso: Rossana
Giovanetti G. y Yolanda Yáñez M. Para poder concluir los perfiles, se analizaron en
profundidad las frecuencias y coincidencias del test, además de los propios cargos y tareas
realizadas. El cuestionario sirvió a su vez como referencia para conocer las tareas
especificas de cada uno.
Entre las coincidencias se denotó que el administrador es el encargado de generar en su
completitud el proceso, es decir: el ingreso de trabajadores, empresas, planillas de pago,
etc. A diferencia de los asistentes, que solo se encargaban de generar los reportes de
remuneraciones, planillas, informes resúmenes, etc.

El cruce entre las tareas que realizaban los operarios se compararon en cuanto su la
frecuencia, que para el administrador sumarizó la frecuencia de 1 para todas las actividades
descritas en ella. Para los asistentes solo hubieron actividades especificas sumarizadas entre
0 a 4.

5. Factores relevantes

Los factores relevantes para el usuario son: el tipo de Hardware y Software a utilizar,
además de la experiencia que estos tengan con sistemas similares.

En este caso, los usuarios tienen un buen manejo e interacción con el Hardware y Software.
Para el caso de los Software se encuentran familiarizados con el manejo de herramientas de
este tipo, puesto que todos los departamentos interactuaban con un sistema de
características similares. Por parte del Hardware, los usuarios interactúan con el sin
problema alguno utilizando como herramienta de apoyo para llevar a cabo su trabajo.

5.3.2. Análisis de Tareas

El análisis de tareas tiene como fin describir lo que los usuarios hacen para llevar a cabo
sus tareas. Esta descripción, representa las tareas en el sistema, representando siempre los
objetivos de los usuarios. A continuación se describe el procedimiento general que los
usuarios realizan para llevar a cabo sus tareas.

Calculo de Remuneraciones y las Liquidaciones:

x Los últimos días del mes se reúne la información de cada una de las Pymes, referente
al movimiento que tuvieron sus trabajadores en el periodo, ya sea: licencias médicas,
permisos sin goce de sueldo, ausencias a trabajar, vacaciones, cese de labores de algún
trabajador, nuevas contrataciones, incentivos, bonos, anticipos, cargas familiares, etc.
x Los fines de mes (30 o 31 de cada mes) se confeccionan cada una de las liquidaciones
de sueldo.

x Los primeros 10 días del mes (01 al 09 de cada mes) se lleva a cabo el cálculo de las
declaraciones de pago y no pago de las distintas instituciones (AFP, INP, etc.).

x Los días 10 de cada mes se presentan en la Caja de Compensación Los Andes y AFP
BBVA PROVIDA cada una de las declaraciones obtenidas.

x Los días entre el 11 al 31 de cada mes se entregan los distintos documentos

solicitados por Pymes, como por ejemplo: copia de contrato, copia de liquidaciones de
meses anteriores, tramitación de cargas familiares, tramitación de tarjetas de salud,
licencias médicas, etc.

Diseño de la Técnica de Usabilidad: Casos de Uso Esenciales

Para una obtención más detallada de cada una de las tareas que el usuario realiza, la técnica
de análisis de tareas Casos de Uso Esenciales entregan una vista concisa de cada una de las
tareas que se deben representar en el sistema.

Los Casos de Uso Esenciales consisten en representar, en un nivel más alto de abstracción,
las intenciones del usuario (objetivos) y responsabilidades que el sistema tiene con estos,
dejando fuera las especificaciones respecto a la tecnología utilizada y su implementación.

A continuación se entregan los Casos de Uso Esenciales organizados por los perfiles de
usuario obtenidos desde el análisis de usuarios en los apartados anteriores:

a) Administrador:

Caso de Uso Esencial: Ingreso por parte del Administrador de un Usuario nuevo.
 El Administrador ingresa a la opción de El Sistema verifica si el código ingresado
“Ingresar Usuario” y registra un nuevo se encuentra disponible y despliega
código, compuesto por letras, para el formulario de ingreso.
usuario que se desea crear.

El Administrador acepta el código.

El Administrador nombra el nuevo usuario El Sistema envía un mensaje. “¿Confirma

y restringe su acceso. la información? SI NO”.

El Administrador selecciona SI. El Sistema envía un mensaje. “El proceso

ha finalizado exitosamente”.

Caso de Uso Esencial: Ingreso por parte del Administrador de un Usuario para
condiciones en que exista.

El Administrador ingresa a la opción de El Sistema verifica si el código ingresado

“Ingresar Usuario” y registra un nuevo se encuentra disponible y despliega
código, compuesto por letras, para el formulario de ingreso.
usuario que se desea crear.
El código ingresado no se encuentra
disponible.
 El Sistema envía un mensaje. “El código
no se encuentra disponible. ACEPTAR”.
Retorna a la opción Ingresar Usuario.

El Administrador selecciona ACEPTAR.

El Administrador acepta el código.

El Administrador nombra el nuevo usuario El Sistema envía un mensaje. “¿Confirma

y restringe su acceso. la información? SI NO”.

El Administrador selecciona la opción NO. El Sistema retorna al usuario que está

siendo ingresado.

El Sistema envía un mensaje. “El proceso

ha finalizado exitosamente”.

Caso de Uso Esencial: Modificar Usuario caso exitoso.

Administrador ingresa en la opción El Sistema lista los usuarios que se

“Modificar Usuario”. encuentran vigentes.

El Administrador busca y selecciona del El Sistema envía un mensaje. “¿Está Ud.

listado que se encuentra visible, el usuario Seguro que desea modificar el usuario
y perfil que desea modificar. seleccionado? SI NO.”

El Administrador selecciona la opción El Sistema despliega los datos autorizados

“SI”. para modificar.
 El Administrador modifica el usuario. El Sistema envía un mensaje. “¿Confirma la
modificación del usuario? SI NO”.

El Administrador selecciona SI. El Sistema envía un mensaje. “El proceso

ha finalizado exitosamente”.

Caso de Uso Esencial: Modificar Usuario caso no exitoso.

Administrador ingresa en la opción El Sistema lista los usuarios que se

“Modificar Usuario”. encuentran vigentes.

El Administrador busca y selecciona del El Sistema envía un mensaje. “¿Está Ud.

listado que se encuentra visible, el usuario Seguro que desea modificar el usuario
y perfil que desea modificar. seleccionado? SI NO.”

El Administrador selecciona la opción El Sistema retorna al listado de usuarios

NO. existentes.

El Administrador modifica el usuario. El Sistema envía un mensaje. “¿Confirma la

modificación del usuario? SI NO”.

El Administrador selecciona la opción El Sistema retorna al usuario que está

NO. siendo modificado.

El Sistema envía un mensaje. “El proceso

no ha finalizado exitosamente”.

Caso de Uso Esencial: Eliminar Usuario caso exitoso.

 Administrador ingresa en la opción “Baja El Sistema lista los usuarios que se
de Usuario”. encuentran vigentes.

El Administrador busca y selecciona del El Sistema envía un mensaje. “¿Está Ud.

listado de usuarios que se encuentran Seguro que desea eliminar al usuario
visibles, el usuario que desea eliminar. seleccionado? SI NO.”

El Administrador selecciona la opción SI. El Sistema envía un mensaje. “El proceso

ha finalizado exitosamente”.

Caso de Uso Esencial: Eliminar Usuario caso no exitoso.

Administrador ingresa en la opción “Baja El Sistema lista los usuarios que se

de Usuario”. encuentran vigentes.

El Administrador busca y selecciona del El Sistema envía un mensaje. “¿Está Ud.

listado de usuarios que se encuentran Seguro que desea eliminar al usuario
visibles, el usuario que desea eliminar. seleccionado? SI NO.”

El Administrador selecciona la opción El Sistema retorna al listado de parámetros

NO. existentes.

El Sistema envía un mensaje. “El proceso

no ha finalizado exitosamente”.
Caso de Uso Esencial: Consultar Usuario exitoso.

Administrador ingresa en la opción El Sistema lista los usuarios que se

“Listar Usuarios”. encuentran vigentes actualmente.

El Administrador busca y selecciona del El Sistema despliega el usuario seleccionado.

listado usuarios que se encuentra visible,
el usuario que desea consultar.

El Administrador observa el usuario El Sistema retorna a la opción LISTAR

consultado, posteriormente presiona USUARIOS.
ACEPTAR.

Caso de Uso Esencial: Ingresar Parámetro exitoso: haberes, descuentos, AFP, caja de
compensación, mutuales de seguridad, Isapre, cargos desempeñados por los trabajadores,
bonos.

El Administrador ingresa a la opción de El Sistema verifica si el código ingresado se

“Ingresar Parámetro” y registra un nuevo encuentra disponible y despliega formulario
código, compuesto por números, para el de ingreso.
parámetro que se desea crear.

El Administrador acepta el código.

El Administrador nombra el nuevo El Sistema envía un mensaje. “¿Confirma la

parámetro y lo clasifica, según su
 naturaleza, en: Descuentos, Haberes, información? SI NO”.
AFP, Mutual, Caja de Compensación,
Salud.

El Administrador selecciona SI. El Sistema envía un mensaje. “El proceso

ha finalizado exitosamente
satisfactoriamente”.

Caso de Uso Esencial: Ingresar Parámetro no exitoso: haberes, descuentos, AFP, caja de
compensación, mutuales de seguridad, Isapre, cargos desempeñados por los trabajadores,
bonos.

El Administrador ingresa a la opción de El Sistema verifica si el código ingresado se

“Ingresar Parámetro” y registra un nuevo encuentra disponible y despliega formulario
código, compuesto por números, para el de ingreso.
parámetro que se desea crear.
El código ingresado no se encuentra
disponible. El Sistema envía un mensaje.
“El código no se encuentra disponible.
ACEPTAR”. Retorna a la opción Ingresar
Parámetro.

El Administrador acepta el código.

El Administrador nombra el nuevo El Sistema envía un mensaje. “¿Confirma la

parámetro y lo clasifica, según su información? SI NO”.
naturaleza, en: Descuentos, Haberes,
AFP, Mutual, Caja de Compensación,
 Salud.

El Administrador selecciona la opción El Sistema retorna al parámetro que está

NO. siendo ingresado.

El Sistema envía un mensaje. “El proceso

no ha finalizado exitosamente
satisfactoriamente”.

Caso de Uso Esencial: Modificar Parámetro exitoso: haberes, descuentos, AFP, caja de
compensación, mutuales de seguridad, Isapre, cargos desempeñados por los trabajadores,
bonos.

Administrador ingresa en la opción El Sistema lista los parámetros que se

“Modificar Parámetros”. encuentran vigentes.

El Administrador busca y selecciona del El Sistema envía un mensaje. “¿Está Ud.

listado que se encuentra visible, el Seguro que desea modificar el parámetro
parámetro que desea modificar. seleccionado? SI NO.”

El Administrador selecciona la opción El Sistema despliega los datos autorizados a

“SI”. modificar.

El Administrador modifica el parámetro. El Sistema envía un mensaje. “¿Confirma la

modificación del parámetro? SI NO”.

El Sistema envía un mensaje. “El proceso ha

 El Administrador selecciona SI. sido modificado satisfactoriamente”.

Caso de Uso Esencial: Modificar Parámetro no exitoso: haberes, descuentos, AFP, caja de
compensación, mutuales de seguridad, Isapre, cargos desempeñados por los trabajadores,
bonos.

Administrador ingresa en la opción El Sistema lista los parámetros que se

“Modificar Parámetros”. encuentran vigentes.

El Administrador busca y selecciona del El Sistema envía un mensaje. “¿Está Ud.

listado que se encuentra visible, el Seguro que desea modificar el parámetro
parámetro que desea modificar. seleccionado? SI NO.”

El Administrador selecciona la opción El Sistema retorna al listado de parámetros

NO. existentes.

El Administrador modifica el parámetro. El Sistema envía un mensaje. “¿Confirma la

modificación del parámetro? SI NO”.

El Sistema retorna al parámetro que está

siendo modificado.
El Administrador selecciona la opción
NO.

El Sistema envía un mensaje. “El proceso

no ha sido modificado satisfactoriamente”.
Caso de Uso Esencial: Eliminar Parámetro exitoso: haberes, descuentos, AFP, caja de
compensación, mutuales de seguridad, Isapre, cargos desempeñados por los trabajadores,
bonos.

Administrador ingresa en la opción El Sistema lista los parámetros que se

“Eliminar Parámetros”. encuentran vigentes actualmente.

El Administrador busca y selecciona del El Sistema envía un mensaje. “¿Está Ud.

listado que se encuentra visible, el Seguro que desea eliminar el parámetro
parámetro que desea eliminar. seleccionado? SI NO.”

El Administrador selecciona la opción SI. El Sistema envía un mensaje. “El proceso ha

sido modificado satisfactoriamente”.

Caso de Uso Esencial: Eliminar Parámetro no exitoso: haberes, descuentos, AFP, caja de
compensación, mutuales de seguridad, Isapre, cargos desempeñados por los trabajadores,
bonos.

Administrador ingresa en la opción El Sistema lista los parámetros que se

“Eliminar Parámetros”. encuentran vigentes actualmente.

El Administrador busca y selecciona del El Sistema envía un mensaje. “¿Está Ud.

listado que se encuentra visible, el Seguro que desea eliminar el parámetro
parámetro que desea eliminar. seleccionado? SI NO.”

El Administrador selecciona la opción El Sistema retorna al listado de parámetros

 NO. existentes.

El Sistema envía un mensaje. “El proceso ha

sido modificado satisfactoriamente”.

Caso de Uso Esencial: Consultar Parámetro exitoso: haberes, descuentos, AFP, caja de
compensación, mutuales de seguridad, Isapre, cargos desempeñados por los trabajadores,
bonos.

Administrador ingresa en la opción El Sistema lista los parámetros que se

“Listar Parámetros”. encuentran vigentes actualmente.

El Administrador busca y selecciona del El Sistema despliega el parámetro

listado que se encuentra visible, el seleccionado.
parámetro que desea consultar.

El Administrador observa el parámetro El Sistema retorna a la opción

consultado, posteriormente presiona CONSULTAR DATOS PARAMETRICOS.
ACEPTAR.

Caso de Uso Esencial: Ingresar Empresa exitoso.

El Administrador selecciona la opción El Sistema despliega en la pantalla el

“Ingresar Empresa”. formulario con los datos requeridos.
 El Administrador ingresa los datos El Sistema envía un mensaje. “¿Confirma la
solicitados y selecciona “INGRESAR” información? SI NO”.

El Administrador selecciona SI. El Sistema envía un mensaje. “El proceso

ha finalizado exitosamente”.

Caso de Uso Esencial: Ingresar Empresa no exitoso.

El Administrador selecciona la opción El Sistema despliega en la pantalla el

“Ingresar Empresa”. formulario con los datos requeridos.

El Administrador ingresa los datos La empresa ingresada ya se encontraba

solicitados y selecciona “INGRESAR” registrada en el sistema. El sistema envía un
mensaje. “Empresa ingresada ya se
encuentra registrada.”

El Sistema envía un mensaje. “¿Confirma la

información? SI NO”.

El Administrador selecciona la opción El Sistema retorna a la empresa que está

NO. siendo ingresada.

El Sistema envía un mensaje. “El proceso

no ha finalizado exitosamente”.

Caso de Uso Esencial: Modificar Empresa exitoso.

 El Administrador ingresa en la opción El Sistema lista las empresas que se
“Modificar Empresa”. encuentran vigentes actualmente.

El Administrador busca y selecciona del El Sistema envía un mensaje. “¿Está Ud.

listado que se encuentra visible, la Seguro que desea modificar la empresa
empresa que desea modificar. seleccionada? SI NO.”

El Administrador selecciona la opción El Sistema despliega los datos autorizados a

“SI”. modificar.

El Administrador modifica los datos El Sistema envía un mensaje. “¿Confirma la

necesarios de la empresa. modificación de la empresa? SI NO”.

El Administrador selecciona SI. El Sistema envía un mensaje. “El proceso

ha finalizado exitosamente”.

Caso de Uso Esencial: Modificar Empresa no exitoso.

El Administrador ingresa en la opción El Sistema lista las empresas que se

“Modificar Empresa”. encuentran vigentes actualmente.

El Administrador busca y selecciona del El Sistema envía un mensaje. “¿Está Ud.

listado que se encuentra visible, la Seguro que desea modificar la empresa
empresa que desea modificar. seleccionada? SI NO.”

El Administrador selecciona la opción El Sistema retorna al listado de empresa s

NO. existentes.
 El Administrador modifica los datos El Sistema envía un mensaje. “¿Confirma la
necesarios de la empresa. modificación de la empresa? SI NO”.

El Administrador selecciona la opción El Sistema retorna a la empresa que está

NO. siendo modificada.

El Sistema envía un mensaje. “El proceso

no ha finalizado exitosamente”.

Caso de Uso Esencial: Eliminar Empresa exitoso.

Administrador ingresa en la opción El Sistema lista las empresas que se

“Desactivar Empresa” del mantenedor de encuentran vigentes actualmente de
Empresa e ingresa el parámetro de acuerdo al resultado de la búsqueda.
búsqueda que desea (Rut, apellido).

El Administrador busca y selecciona del El Sistema envía un mensaje. “¿Está Ud.

listado que se encuentra visible, la Seguro que desea dejar inactiva la empresa
empresa que desea dejar inactiva. seleccionada? SI NO.”

El Administrador selecciona la opción SI. El Sistema envía un mensaje. “La Empresa

ha quedado inactiva satisfactoriamente”.

Caso de Uso Esencial: Eliminar Empresa no exitoso.

 Administrador ingresa en la opción El Sistema lista las empresas que se
“Desactivar Empresa” del mantenedor de encuentran vigentes actualmente de
Empresa e ingresa el parámetro de acuerdo al resultado de la búsqueda.
búsqueda que desea (Rut, apellido).

El Administrador busca y selecciona del El Sistema envía un mensaje. “¿Está Ud.

listado que se encuentra visible, la Seguro que desea dejar inactiva la empresa
empresa que desea dejar inactiva. seleccionada? SI NO.”

El Administrador selecciona la opción El Sistema retorna al listado de empresas

NO. existentes.

El Sistema envía un mensaje. “La Empresa

no ha quedado inactiva satisfactoriamente”.

Caso de Uso Esencial: Consultar Empresa exitosamente.

El Administrador ingresa en la opción El Sistema lista las empresas que se

“Consultar Empresas”. encuentran vigentes actualmente.

El Administrador busca y selecciona del El Sistema despliega información de la

listado que se encuentra visible, la empresa seleccionada para visualizar.
empresa que desea consultar.

El Administrador observa y selecciona la El Sistema retorna a la opción

información específica consultada, CONSULTAR EMPRESA.
posteriormente presiona ACEPTAR.
Caso de Uso Esencial: Ingresar Trabajador exitosamente.

El Administrador ingresa a la opción de El Sistema despliega el formulario

“Nuevo Empleado” del mantenedor de correspondiente donde se indica los datos
Trabajadores. que se deben ingresar.

El Administrador ingresa los datos El Sistema verifica los datos ingresados y

solicitados por el Sistema tales como envía un mensaje. “¿Confirma la
nombre, cedula de identidad, dirección, información? SI NO”.
cargas familiares, estado civil, fecha de
nacimiento, fecha de ingreso, sistema de
salud, sistema de previsión.

El Administrador selecciona SI. El Sistema envía un mensaje. “El Empleado

se ha ingresado satisfactoriamente”.

Caso de Uso Esencial: Ingresar Trabajador no exitoso.

El Administrador ingresa a la opción de El Sistema despliega el formulario

“Nuevo Empleado” del mantenedor de correspondiente donde se indica los datos
Trabajadores. que se deben ingresar.

El Administrador ingresa los datos El Sistema verifica los datos ingresados y

solicitados por el Sistema tales como envía un mensaje. “¿Confirma la
nombre, cedula de identidad, dirección, información? SI NO”.
 cargas familiares, estado civil, fecha de
nacimiento, fecha de ingreso, sistema de
salud, sistema de previsión.

El Administrador selecciona la opción El Sistema retorna al formulario que está

NO. siendo ingresado.

El Sistema envía un mensaje. “El Empleado

no se ha ingresado satisfactoriamente”.

Caso de Uso Esencial: Modificar Trabajador exitosamente.

Administrador ingresa en la opción El Sistema despliega un listado con los

“Modificar Empleado” del mantenedor de resultados de la búsqueda.
Trabajadores e ingresa el parámetro de
búsqueda que desea (Rut o apellido).

El Administrador selecciona del listado El Sistema envía un mensaje. “¿Está Ud.

que se encuentra visible, el empleado que Seguro que desea modificar el empleado
desea modificar. seleccionado? SI NO.”

El Administrador selecciona la opción El Sistema despliega los datos autorizados

“SI”. a modificar.

El Administrador modifica el empleado. El Sistema envía un mensaje. “¿Confirma

la modificación del empleado? SI NO”.
 El Administrador selecciona SI. El Sistema envía un mensaje. “El empleado
ha sido modificado satisfactoriamente”.

Caso de Uso Esencial: Modificar Trabajador no exitoso.

Administrador ingresa en la opción El Sistema despliega un listado con los

“Modificar Empleado” del mantenedor de resultados de la búsqueda.
Trabajadores e ingresa el parámetro de
búsqueda que desea (Rut o apellido).

El Administrador selecciona del listado El Sistema envía un mensaje. “¿Está Ud.

que se encuentra visible, el empleado que Seguro que desea modificar el empleado
desea modificar. seleccionado? SI NO.”

El Administrador selecciona la opción El Sistema retorna al listado de empleados

NO. buscados.

El Administrador modifica el empleado. El Sistema envía un mensaje. “¿Confirma

la modificación del empleado? SI NO”.

El Administrador selecciona la opción El Sistema retorna al formulario del

NO. empleado que está siendo modificado.

El Sistema envía un mensaje. “El empleado

no ha sido modificado satisfactoriamente”.
Caso de Uso Esencial: Eliminar Trabajador exitosamente.

Administrador ingresa en la opción El Sistema lista los trabajadores que se

“Eliminar Trabajador” del mantenedor de encuentran vigentes actualmente de
Trabajador e ingresa el parámetro de acuerdo al resultado de la búsqueda.
búsqueda que desea.

El Administrador busca y selecciona del El Sistema envía un mensaje. “¿Está Ud.

listado que se encuentra visible, el Seguro que desea cesar las labores del
trabajador que desea dejar inactivo. trabajador seleccionado? SI NO.”

El Administrador selecciona la opción SI. El Sistema envía un mensaje. “El

Trabajador ha quedado inactivo
satisfactoriamente”.

Caso de Uso Esencial: Eliminar Trabajador no exitoso.

Administrador ingresa en la opción El Sistema lista los trabajadores que se

“Eliminar Trabajador” del mantenedor de encuentran vigentes actualmente de
Trabajador e ingresa el parámetro de acuerdo al resultado de la búsqueda.
búsqueda que desea.

El Administrador busca y selecciona del El Sistema envía un mensaje. “¿Está Ud.

listado que se encuentra visible, el Seguro que desea cesar las labores del
trabajador que desea dejar inactivo. trabajador seleccionado? SI NO.”
 El Administrador selecciona la opción NO. El Sistema retorna al listado de
trabajadores buscados.

El Sistema envía un mensaje. “El

Trabajador no ha quedado inactivo
satisfactoriamente”.

Caso de Uso Esencial: Consultar Trabajador exitosamente.

El Administrador ingresa en la opción El Sistema lista los trabajadores que se

“Historial Trabajador”. encuentran vigentes.

El Administrador busca y selecciona del El Sistema despliega información del

listado que se encuentra visible, el trabajador seleccionado para visualizar.
trabajador que desea consultar.

El Administrador observa y selecciona la El Sistema retorna a la opción

información específica consultada, HISTORIAL TRABAJADOR
posteriormente presiona ACEPTAR.

Caso de Uso Esencial: Generar Contratos de Trabajo exitosamente.

El administrador ingresa a la opción El Sistema visualiza los trabajadores que se

Generar Contrato de Trabajo. encuentran ingresados y envía un mensaje.
 “Ingrese Rut del trabajador:
ACEPTAR”.

El Administrador selecciona del listado el El Sistema devuelve un formulario con los

trabajador y presiona ACEPTAR. datos que se deben ingresar (fecha de
ingreso del trabajador, cargo a desempeñar,
establecimiento, dirección, jornada de
trabajo, fecha de emisión del contrato) y
opción ACEPTAR.

El Administrador ingresa los datos y El Sistema envía un mensaje. “¿Desea

presiona ACEPTAR. confirmar la información? SI NO”.

El Administrador selecciona SI. El Sistema retorna a la opción Generar

Contratos de trabajo.

Caso de Uso Esencial: Generar Contratos de Trabajo no exitoso.

El administrador ingresa a la opción El Sistema visualiza los trabajadores que se

Generar Contrato de Trabajo. encuentran ingresados y envía un mensaje.
“Ingrese Rut del trabajador:
ACEPTAR”.

El Administrador selecciona del listado el El Sistema devuelve un formulario con los

trabajador y presiona ACEPTAR. datos que se deben ingresar (fecha de
ingreso del trabajador, cargo a desempeñar,
establecimiento, dirección, jornada de
trabajo, fecha de emisión del contrato) y
 opción ACEPTAR.

El Administrador ingresa los datos y El Sistema envía un mensaje. “¿Desea

presiona ACEPTAR. confirmar la información? SI NO”.

El Administrador selecciona la opción NO El Sistema retorna al formulario de

contrato de trabajo.

Caso de Uso Esencial: Generar Finiquito de Trabajo exitosamente.

El administrador ingresa a la opción El Sistema visualiza los trabajadores que se

Generar Finiquito de Trabajo. encuentran ingresados y envía un mensaje.
“Ingrese Rut del trabajador:
ACEPTAR”.

El Administrador selecciona del listado el El Sistema devuelve un formulario con los

trabajador y presiona ACEPTAR. datos que se deben ingresar, para generar el
finiquito (fecha de cese de labores, causal
de finiquito, fecha de emisión del finiquito,
indemnización) y opción ACEPTAR.

El Administrador ingresa los datos y El Sistema envía un mensaje. “¿Desea

presiona ACEPTAR. confirmar la información? SI NO”.

El Administrador selecciona SI. El Sistema retorna a la opción Generar

Finiquito de trabajo.

Caso de Uso Esencial: Generar Finiquito de Trabajo no exitoso.

 El administrador ingresa a la opción El Sistema visualiza los trabajadores que se
Generar Finiquito de Trabajo. encuentran ingresados y envía un mensaje.
“Ingrese Rut del trabajador:
ACEPTAR”.

El Administrador selecciona del listado el El Sistema devuelve un formulario con los

trabajador y presiona ACEPTAR. datos que se deben ingresar, para generar el
finiquito (fecha de cese de labores, causal
de finiquito, fecha de emisión del finiquito,
indemnización) y opción ACEPTAR.

El Administrador ingresa los datos y El Sistema envía un mensaje. “¿Desea

presiona ACEPTAR. confirmar la información? SI NO”.

El Administrador selecciona la opción NO El Sistema retorna al formulario de

finiquito de trabajo.

Caso de Uso Esencial: Generar Liquidaciones de Sueldo exitosamente.

El Administrador ingresa en la opción El Sistema arroja un submenú:

Generar liquidaciones de Sueldo.
Ingrese opción:

1. Liquidación por Trabajador.

 2. Liquidación por Empresa.

0. Retornar

1a.- El Administrador ingresa la opción 1b.- El Sistema visualiza los trabajadores

Liquidación por trabajador. que se encuentran disponibles y envía un
mensaje. “Ingrese el RUT del trabajador
que desea calcular ACEPTAR”.

1c.- El administrador selecciona Rut del 1d.- El Sistema calcula la liquidación de

trabajador y presiona ACEPTAR. sueldo del trabajador y envía un mensaje.
“El proceso ha terminado
satisfactoriamente. IMPRIMIR
ACEPTAR”

1e.- El Administrador selecciona 1f.- El Sistema retorna al submenú.

ACEPTAR

2a.- El Administrador ingresa a la opción 2b.- El Sistema envía un mensaje. “¿Desea

Liquidación por empresa. calcular las liquidaciones de sueldo de todos
los trabajadores de la empresa seleccionada?
SI NO”.

2c.- El Administrador selecciona la 2d.- El Sistema calcula todas las

opción SI. liquidaciones de sueldo de la empresa en la
que se encuentra y envía un mensaje. “El
proceso ha terminado satisfactoriamente.
IMPRIMIR ACEPTAR”

2e.- El Administrador ingresa a la opción 2f.- El sistema retorna a la opción Generar

ACEPTAR. Liquidaciones de sueldo.

0a.- El Administrador ingresa a la opción 0b.- El sistema retorna a la opción Generar

 Retornar. Liquidación de Sueldo.

Caso de Uso Esencial: Generar Liquidaciones de Sueldo no exitoso.

El Administrador ingresa en la opción El Sistema arroja un submenú:

Generar liquidaciones de Sueldo.
Ingrese opción:

1. Liquidación por Trabajador.

2. Liquidación por Empresa.

0. Retornar

1a.- El Administrador ingresa la opción 1b.- El Sistema visualiza los trabajadores

Liquidación por trabajador. que se encuentran disponibles y envía un
mensaje. “Ingrese el RUT del trabajador
que desea calcular ACEPTAR”.

1c.- El administrador selecciona Rut del 1d.- El Sistema calcula la liquidación de

trabajador y presiona ACEPTAR. sueldo del trabajador y envía un mensaje.
“El proceso ha terminado
satisfactoriamente. IMPRIMIR
ACEPTAR”

1e.- El Administrador presiona 1f.- El Sistema imprime la liquidación de

IMPRIMIR sueldo y retorna a la opción Generar
Liquidación de Sueldo

2a.- El Administrador ingresa a la opción 2b.- El Sistema envía un mensaje. “¿Desea

 Liquidación por empresa. calcular las liquidaciones de sueldo de todos
los trabajadores de la empresa seleccionada?
SI NO”.

2c.- El Administrador selecciona la 2d.- El Sistema no calcula todas las

opción NO. liquidaciones de sueldo de la empresa en la
que se encuentra y envía un mensaje. “El
proceso no ha terminado satisfactoriamente.
IMPRIMIR ACEPTAR”

2e.- El Administrador selecciona la 2f.- El sistema imprime las liquidaciones de

opción IMPRIMIR. sueldo de todos los trabajadores de esa
empresa y retorna a la opción Generar
Liquidación de Sueldo.

0a.- El Administrador ingresa a la opción 0b.- El sistema retorna a la opción Generar

Retornar. Liquidación de Sueldo.

Caso de Uso Esencial: Ingresar Movimiento Mensual exitosamente.

El Administrador ingresa en la opción El sistema visualiza los trabajadores que se

Ingresar Movimiento Mensual. encuentran vigentes y envía un mensaje:
“Ingrese Rut del trabajador
ACEPTAR”.

El Administrador ingresa el Rut del El sistema muestra el formulario para

trabajador y presiona ACEPTAR. ingresar el movimiento mensual; los datos
son: anticipos, bonos, licencias médicas,
 permisos sin goce de sueldo, vacaciones,
cargas familiares, días trabajados.

El Administrador ingresa los datos y El sistema envía un mensaje. “¿Confirma la

presiona ACEPTAR. información ingresada? SI NO.”

El Administrador presiona la opción SI. El sistema retorna a la opción Ingresar

Movimiento Mensual

Caso de Uso Esencial: Ingresar Movimiento Mensual no exitoso.

El Administrador ingresa en la opción El sistema visualiza los trabajadores que se

Ingresar Movimiento Mensual. encuentran vigentes y envía un mensaje:
“Ingrese Rut del trabajador
ACEPTAR”.

El Administrador ingresa el Rut del El sistema muestra el formulario para

trabajador y presiona ACEPTAR. ingresar el movimiento mensual; los datos
son: anticipos, bonos, licencias médicas,
permisos sin goce de sueldo, vacaciones,
cargas familiares, días trabajados.

El Administrador ingresa los datos y El sistema envía un mensaje. “¿Confirma la

presiona ACEPTAR. información ingresada? SI NO.”

El Administrador presiona la opción NO. El Sistema retorna al formulario para

ingresar movimiento mensual.
Caso de Uso Esencial: Crear Mes Tributario exitosamente.

El Administrador selecciona la opción El Sistema envía un mensaje. “¿Desea

“Crear Mes Tributario”. cerrar el mes anterior? SI NO”.

El Administrador selecciona la opción SI. El Sistema envía un mensaje: “Ingresar

Contraseña”.

El Sistema traspasa la información al nuevo

mes.

El Sistema envía un mensaje. “Se ha creado

satisfactoriamente. ACEPTAR”.

El Administrador ingresa la contraseña. El sistema retorna al menú principal.

El Administrador selecciona ACEPTAR.

Caso de Uso Esencial: Crear Mes Tributario no exitoso.

El Administrador selecciona la opción El Sistema envía un mensaje. “¿Desea

“Crear Mes Tributario”. cerrar el mes anterior? SI NO”.

El Administrador selecciona la opción El Sistema retorna al menú principal.

NO.
Caso de Uso Esencial: Crear Mes Tributario contraseña errónea.

El Administrador selecciona la opción El Sistema envía un mensaje. “¿Desea

“Crear Mes Tributario”. cerrar el mes anterior? SI NO”.

El Administrador selecciona la opción SI. El Sistema envía un mensaje: “Ingresar

Contraseña”.

El Sistema traspasa la información al nuevo

mes.

El Sistema envía un mensaje. “Se ha creado

satisfactoriamente. ACEPTAR”.

El Administrador ingresa erróneamente la El Sistema retorna a la opción Ingresar

contraseña. Contraseña.

Caso de Uso Esencial: Modificar Mes Tributario exitosamente.

El Administrador selecciona la opción El Sistema envía un mensaje. “Ingresar

“Modificar Mes Tributario”. Contraseña”.

El Administrador ingresa la contraseña. El Sistema arroja un mensaje. “Ingrese mes

tributario”.

El Administrador ingresa el mes El Sistema despliega el mes que se desea

 tributario. modificar y la opción Aceptar.

El Administrador modifica el mes y, una El Sistema envía un mensaje. “¿Confirma la

vez finalizado, selecciona la opción modificación del mes? SI NO”.
ACEPTAR.

El Administrador selecciona SI. El Sistema envía un mensaje. “El mes ha

sido modificado satisfactoriamente”.

Caso de Uso Esencial: Modificar Mes Tributario no exitoso.

El Administrador selecciona la opción El Sistema envía un mensaje. “Ingresar

“Modificar Mes Tributario”. Contraseña”.

El Administrador ingresa la contraseña. El Sistema arroja un mensaje. “Ingrese mes

tributario”.

El Administrador ingresa el mes El Sistema despliega el mes que se desea

tributario. modificar y la opción Aceptar.

El Administrador modifica el mes y, una El Sistema envía un mensaje. “¿Confirma la

vez finalizado, selecciona la opción modificación del mes? SI NO”.
ACEPTAR.

El Administrador selecciona la opción El Sistema retorna a visualizar el mes que

NO. está siendo modificado.

Caso de Uso Esencial: Modificar Mes Tributario contraseña errónea.

 El Administrador selecciona la opción El Sistema envía un mensaje. “Ingresar
“Modificar Mes Tributario”. Contraseña”.

El Administrador ingresa erróneamente la El Sistema retorna a la opción Ingresar

contraseña. Contraseña.

Caso de Uso Esencial: Modificar Mes Tributario exitosamente.

El Administrador selecciona la opción El Sistema envía un mensaje. “Ingresar

“Modificar Mes Tributario”. Contraseña”.

El Administrador ingresa la contraseña. El Sistema arroja un mensaje. “Ingrese mes

tributario”.

El Administrador ingresa erróneamente el El Sistema retorna a la opción Ingrese mes

mes tributario. tributario.

Caso de Uso Esencial: Consultar Remuneración exitosamente.

El Administrador selecciona la opción El Sistema arroja un mensaje. “Ingrese

 “Consultar Remuneración” mes tributario”.

El Administrador ingresa el mes tributario. El Sistema lista, por medio del nombre de
las empresas, las remuneraciones del mes
ingresado.

El Administrador selecciona la empresa El Sistema despliega el detalle de la

que desea consultar. remuneración de la empresa seleccionada.

Una vez visto, el Administrador El Sistema retorna a la opción “Consultar

selecciona la opción ACEPTAR. Remuneración”.

Caso de Uso Esencial: Consultar Remuneración con mes tributario erróneo.

El Administrador selecciona la opción El Sistema arroja un mensaje. “Ingrese

“Consultar Remuneración” mes tributario”.

El Administrador ingresa erróneamente el El Sistema retorna a la opción Ingrese mes

mes tributario. tributario.

Caso de Uso Esencial: Consultar Remuneración con mes tributario fuera de rango.

El Administrador selecciona la opción El Sistema arroja un mensaje. “Ingrese

“Consultar Remuneración” mes tributario”.
 El Administrador ingresa un mes tributario El sistema envía un mensaje. “Mes
fuera de rango. Tributario NO EXISTE” ACEPTAR

El Administrador presiona ACEPTAR. El sistema retorna ingrese mes tributario.

Caso de Uso Esencial: Calcular Libro de Remuneraciones exitosamente (almacenar).

El Administrador ingresa a la opción El Sistema despliega un listado con las

“Libro de Remuneraciones”. empresas.

El Administrador selecciona la empresa a El Sistema envía un mensaje. “¿Desea

la cual le desea calcular el Libro de generar el libro de remuneraciones? SI
Remuneraciones. NO”.

El Administrador selecciona la opción SI. El Sistema genera el libro de

remuneraciones y lo despliega por pantalla
con las opciones correspondiente (guardar e
imprimir).

El Administrador escoge guardar el libro. El Sistema envía un mensaje. “EL

PROCESO HA FINALIZADO
EXITOSAMENTE.”

Caso de Uso Esencial: Calcular Libro de Remuneraciones no exitoso.

 El Administrador ingresa a la opción El Sistema despliega un listado con las
“Libro de Remuneraciones”. empresas.

El Administrador selecciona la empresa a El Sistema envía un mensaje. “¿Desea

la cual le desea calcular el Libro de generar el libro de remuneraciones? SI
Remuneraciones. NO”.

El Administrador selecciona la opción NO El Sistema retorna al listado de empresas

Caso de Uso Esencial: Calcular Libro de Remuneraciones exitosamente (Impresión).

El Administrador ingresa a la opción El Sistema despliega un listado con las

“Libro de Remuneraciones”. empresas.

El Administrador selecciona la empresa a El Sistema envía un mensaje. “¿Desea

la cual le desea calcular el Libro de generar el libro de remuneraciones? SI
Remuneraciones. NO”.

El Administrador selecciona la opción SI. El Sistema genera el libro de

remuneraciones y lo despliega por pantalla
con las opciones correspondiente (guardar e
imprimir).

El Administrador escoge imprimir el libro El Sistema imprime el libro de

de remuneraciones. remuneraciones.

Caso de Uso Esencial: Calcular Planilla exitosamente.

El Administrador ingresa a la opción El sistema envía un sub menú.
calcular planilla.
“ Ingrese la opción:

1.- Calcular un empleador.

2.- Calcular todos los empleadores.

0.- Retornar.

1a.- El Administrador ingresa la opción 1b.- El sistema envía un mensaje. “Ingrese

Calcular un empleador. el RUT de la empresa que desea calcular”.

1c.- El administrador ingresa el Rut de la 1d.- El Sistema calcula las planillas de la

empresa. empresa y envía un mensaje. “El proceso ha
terminado satisfactoriamente. ACEPTAR”

1e.- El Administrador selecciona 1f.- El sistema retorna al submenú.

ACEPTAR.

2a.- El Administrador ingresa a la opción 2b.- El sistema calcula las planillas de todas
Calcular todos los empleadores. las empresas que se encuentran vigentes y
envía un mensaje. “El proceso ha terminado
satisfactoriamente. ACEPTAR”

2c.- El Administrador selecciona 2d.- El sistema retorna al submenú.

ACEPTAR.

0a.- El Administrador ingresa a la opción 0b El sistema retorna al menú principal.

Retornar.
Caso de Uso Esencial: Calcular Planilla con Rut erróneo.

El Administrador ingresa a la opción El sistema envía un sub menú.

calcular planilla.
“ Ingrese la opción:

1.- Calcular un empleador.

2.- Calcular todos los empleadores.

0.- Retornar.

1a.- El Administrador ingresa la opción 1b.- El sistema envía un mensaje. “Ingrese

Calcular un empleador. el RUT de la empresa que desea calcular”.

1c.- El Administrador ingresa el Rut 1d.- El sistema retorna a la opción Ingrese

erróneamente. el RUT de la empresa que desea calcular.

1e.- El Administrador ingresa el Rut 1f.- El Sistema calcula las planillas de la

correctamente. empresa y envía un mensaje. “El proceso ha
terminado satisfactoriamente. ACEPTAR”

1g.- El Administrador selecciona 1h.- El sistema retorna al submenú.

ACEPTAR.

2a.- El Administrador ingresa a la opción 2b.- El sistema calcula las planillas de todas
Calcular todos los empleadores. las empresas que se encuentran vigentes y
envía un mensaje. “El proceso ha terminado
satisfactoriamente. ACEPTAR”
 2c.- El Administrador selecciona 2d.- El sistema retorna al submenú.
ACEPTAR.

0a.- El Administrador ingresa a la opción 0b El sistema retorna al menú principal.

Retornar.

Caso de Uso Esencial: Generar Informe Anual exitosamente.

El Administrador ingresa a la opción El sistema envía un sub menú.

Generar Informe Anual.
“ Ingrese la opción:

1.- Certificado Anual.

2.- Declaración Jurada 1887.

0.- Retornar

1a.- El Administrador ingresa la opción 1b.- El sistema envía un mensaje. “Ingrese

Certificado Anual. el RUT de la trabajador y año que desea
emitir”.

1c.- El administrador ingresa Rut y el año 1d.- El sistema valida el año y el Rut del
que desea emitir. trabajador y visualiza el certificado. Opción
IMPRIMIR ACEPTAR.

1e.- El Administrador selecciona 1f.- El sistema retorna al submenú.

ACEPTAR.

2a.- El Administrador ingresa a la opción 2b.- El sistema envía un mensaje. “Ingrese

el Rut de la empresa y el año para emitir
 Declaración Jurada 1887. declaración. ACEPTAR”

2c.- El Administrador ingresa el Rut y el 2d.- El sistema visualiza la declaración y la

año y presiona ACEPTAR. opción IMPRIMIR BORRADOR
ACEPTAR.

2e.- El Administrador selecciona la 2f.- El sistema imprime el borrador de la

opción IMPRIMIR BORRADOR. declaración jurada y retorna a la opción
Generar Informe Anual.

0a.- El Administrador ingresa a la opción 0b.- El sistema retorna al menú principal.

Retornar.

Caso de Uso Esencial: Generar Informe Anual con Rut del trabajador y/o año
erróneamente.

El Administrador ingresa a la opción El sistema envía un sub menú.

Generar Informe Anual.
Ingrese la opción:

1.- Certificado Anual.

2.- Declaración Jurada 1887.

0.- Retornar

1a.- El Administrador ingresa la opción 1b.- El sistema envía un mensaje. “Ingrese

Certificado Anual. el RUT de la trabajador y año que desea
emitir”.

1c.- El Administrador ingresa Rut del 1d.- El sistema retorna a la opción. “Ingrese
 trabajador y/o año erróneamente. el RUT de la trabajador y año que desea
emitir”.

1e.- El Administrador ingresa Rut del 1f.- El sistema valida el año y el Rut del
trabajador y/o año correctamente. trabajador y visualiza el certificado. Opción
IMPRIMIR ACEPTAR.

1g.- El Administrador selecciona 1h.- El sistema retorna al submenú.

ACEPTAR.

2a.- El Administrador ingresa a la opción 2b.- El sistema envía un mensaje. “Ingrese

Declaración Jurada 1887. el Rut de la empresa y el año para emitir
declaración. ACEPTAR”

2c.- El Administrador ingresa Rut de la 2d.- El sistema retorna a la opción. “Ingrese

empresa y/o año erróneamente y presiona el RUT de la trabajador y año que desea
ACEPTAR. emitir”.

2e.- El Administrador ingresa Rut del 2f.- El sistema visualiza la declaración y la

trabajador y/o año correctamente. opción IMPRIMIR BORRADOR
ACEPTAR.

2g.- El Administrador selecciona la 2h.- El sistema imprime el borrador de la

opción IMPRIMIR BORRADOR. declaración jurada y retorna a la opción
Generar Informe Anual.

0a.- El Administrador ingresa a la opción 0b.- El sistema retorna al menú principal.

Retornar.

b) Asistente:
Caso de Uso Esencial: Consultar Empresa exitosamente.

El Asistente ingresa en la opción El Sistema lista las empresas que se

“Consultar Empresas”. encuentran vigentes actualmente.

El Asistente busca y selecciona del listado El Sistema despliega información de la

que se encuentra visible, la empresa que empresa seleccionada para visualizar.
desea consultar.

El Asistente observa y selecciona la El Sistema retorna a la opción

información específica consultada, CONSULTAR EMPRESA.
posteriormente presiona ACEPTAR.

Caso de Uso Esencial: Consultar Trabajador exitosamente.

El Administrador ingresa en la opción El Sistema lista los trabajadores que se

“Historial Trabajador”. encuentran vigentes.

El Administrador busca y selecciona del El Sistema despliega información del

listado que se encuentra visible, el trabajador seleccionado para visualizar.
trabajador que desea consultar.

El Administrador observa y selecciona la El Sistema retorna a la opción

información específica consultada, HISTORIAL TRABAJADOR
posteriormente presiona ACEPTAR.
Caso de Uso Esencial: Consultar Remuneración exitosamente.

El Asistente selecciona la opción El Sistema arroja un mensaje. “Ingrese

“Consultar Remuneración” mes tributario”.

El Asistente ingresa el mes tributario. El Sistema lista, por medio del nombre de
las empresas, las remuneraciones del mes
ingresado.

El Asistente selecciona la empresa que El Sistema despliega el detalle de la

desea consultar. remuneración de la empresa seleccionada.

Una vez visto, el Asistente selecciona la El Sistema retorna a la opción “Consultar

opción ACEPTAR. Remuneración”.

Caso de Uso Esencial: Consultar Remuneración con mes tributario erróneo.

El Asistente selecciona la opción El Sistema arroja un mensaje. “Ingrese

“Consultar Remuneración” mes tributario”.

El Asistente ingresa erróneamente el mes El Sistema retorna a la opción Ingrese mes

tributario. tributario.
Caso de Uso Esencial: Consultar Remuneración con mes tributario fuera de rango.

El Asistente selecciona la opción El Sistema arroja un mensaje. “Ingrese

“Consultar Remuneración” mes tributario”.

El Asistente ingresa un mes tributario El sistema envía un mensaje. “Mes

fuera de rango. Tributario NO EXISTE” ACEPTAR

El Asistente presiona ACEPTAR. El sistema retorna ingrese mes tributario.

Mediante los casos de uso esenciales descritos anteriormente, se describieron las tareas
desde una perspectiva más abstracta, sin considerar especificidades de diseño ni
construcción, sino que más bien, la formulación de los algoritmos de cada tarea
representativa para el Sistema de Remuneraciones Multiempresas.

5.4. Especificación de los requisitos del usuario y la

Organización

5.4.1. Requerimientos Funcionales del Usuario

Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar.
Describen las transformaciones que el sistema realiza sobre las entradas para producir
salidas. Para el sistema en construcción, los requisitos funcionales del Usuario son los
siguientes:

Componente REMUNERACIONES

Creación, se produce cuando se cierra un mes en proceso. Se cierra el mes y se crea

un nuevo mes tributario con la información del mes anterior (empleadores,
 empleados, movimiento mensual de cada uno de ellos, remuneraciones, datos
paramétricos).

Modificación: Bloqueo de Meses en Proceso de Cierre, con posible modificación

autorizada por el administrador.

Consultar remuneraciones de una empresa determinada en cierto mes.

Emisión de formularios de pago y no pago de AFP, Isapres, INP, CCAF (Caja de

compensación y asignación familiar) y Mutuales, en formularios computacionales,
válido para presentación directa a cada entidad.

Emisión del Libro de Remuneraciones.

Emisión de certificados de impuesto Único y Formulario 1887, de acuerdo a la Res.

Nº 6836 del S.I.I. (D.O. 06/01/94).

Componente EMPLEADOS

Creación de un nuevo empleado para una determinada empresa, mediante sus datos
personales.

Modificación de los datos de un empleado, ya existente, para una empresa.

Eliminación de un empleado para una determinada empresa, sin eliminar el historial

del éste. Entendiendo por eliminación, el cese de labores para la empresa y el no
contemplarlo para realizar el movimiento mensual.

Consulta sobre uno o más empleados dentro de una empresa, a través de parámetros
que el usuario ingrese.

Ingreso de movimiento mensual de cada uno de los trabajadores de la empresa

(licencia médica, cese de labores, permiso sin goce de sueldo, nuevas contrataciones,
asignación familiar, horas extraordinarias, bonos, anticipos, vacaciones).

Informe de horas extraordinarias por mes.

Emisión de Contratos, finiquitos y liquidación de sueldo.

Mantenedor de distintos tipos de gratificación (Calculada e informada).

 Consulta de liquidaciones de sueldo por fecha de emisión.

Control de Vacaciones.

Historial de cada uno de los trabajadores de la empresa (cargos desempeñados).

Componente EMPLEADORES

Creación de una nueva empresa, indicando: Rut, razón social, rubro, domicilio,
código actividad económica, nombre comercial, logo.

Modificación en los datos de : rubro, domicilio, código de actividad económica

nombre comercial, logo

Eliminación de una empresa. Cese de labores, conservando el histórico.

Consultar sobre una empresa en específico a través del Rut.

Emisión de listado de empleadores.

Componente DATOS DE PARAMETROS

Creación de nuevos parámetros, así como: haberes, descuentos, AFP, caja de

compensación, mutuales de seguridad, Isapre, cargos desempeñados por los
trabajadores, bonos.

Modificación de uno o más parámetros ya existentes tasa de AFP y/o caja de

compensación y/o plan de Isapres y/o mutuales de seguridad.

Eliminación: Conservando la utilización de los parámetros en los meses antecesores.

Consulta de los parámetros existentes.

Consultar períodos tributarios anteriores en línea; es decir: mantenerse en el mes en

proceso actual para consultar meses anteriores.

Configuración de haberes y descuentos.

Exportar datos a otras herramientas Microsoft Office; Contratos de Trabajo y

finiquitos a Microsoft Word y liquidaciones de sueldo a Microsoft Excel.
 Mantener mes y año de proceso al cambiar de empresa dentro del sistema; es decir: se
modifica y/o consulta una empresa y mes determinada, se cierra la empresa para
cambiar a otra y se debe mantener el mismo mes, sin necesidad modificarlo.

Componente CONTROL DE ACCESO Y PERFILAMIENTO

Creación: proceso de creación de nuevos perfiles y usuarios que tendrán acceso al

sistema.

Modificación: modificación de perfiles de usuarios o de datos de usuarios ya

existentes.

Eliminación: proceso para dar de baja a un usuario del sistema o eliminación de algún
perfil existente

Consulta: consulta de perfiles y usuarios existentes.

Historial de accesos al Sistema por los distintos usuarios.

5.4.2. Requerimientos No Funcionales del Sistema

Los requerimientos no funcionales tienen que ver con características que de una u otra
forma puedan limitar el sistema: “restricciones”, como por ejemplo, el rendimiento (en
tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de
equipo), mantenimiento, seguridad, portabilidad, estándares, etc. En vista de estas
características se identifican los siguientes requerimientos no funcionales del sistema:

El sistema debe permitir que todos los equipos conectados a la Intranet puedan
acceder de igual forma al sistema.

Se debe tratar de omitir el uso del Mouse, tanto en el ingreso de los datos, como en la
manipulación del sistema.

La interfaz y el sistema, deben ser amigables para todos los usuarios.

5.4.3. Requisitos Organizacionales

Los requisitos de la organización, hacen referencia, desde la perspectiva del contexto de
uso, a los siguientes aspectos (previamente contextualizados al sistema):
 Para la empresa es importante que el nuevo sistema en construcción cumpla con los
objetivos financieros y operacionales. En este caso en particular, la empresa en
cuestión requiere que sus salidas de información sean consistentes al histórico de
datos que reúnen mes a mes. Este requisito es primordial, puesto que a partir del
procesamiento de la información se puede procesar y efectuar gestión sobre estos (por
parte de las Pymes) con el fin de cumplir sus objetivos propuestos.

El sistema debe asignar explícitamente las funciones del usuario, separando lo que
implica a la tecnología en sí y lo que le corresponde al usuario como obligación. Para
esto el sistema se divide en subsistemas que agloban las responsabilidades de cada
usuario, dejando claro cada una de los compromisos, ya sea por parte de los usuarios
y el sistema (tecnológico).

Mediante los requisitos funcionales se distribuyen en particular de cada tarea por

subsistema especificando cada una de las responsabilidades (tecnología y los usuarios),
como por ejemplo:

Creación de nuevos parámetros, así como: haberes, descuentos, AFP, caja de

compensación, mutuales de seguridad, Isapre, cargos desempeñados por los
trabajadores, bonos.

Exportar datos a otras herramientas Microsoft Office; Contratos de Trabajo y

finiquitos a Microsoft Word y liquidaciones de sueldo a Microsoft Excel.

Para este ejemplo, las responsabilidades de los usuarios van desde el ingreso de cada uno de
los documentos al sistema y por parte de la tecnología las salidas de información que se
proporcionan a partir de los datos ingresados.

El diseño de las interfaces debe ser por subsistema para mantener una mejor
distribución de las tareas operacionales. Las características funcionales de estas
interfaces deben proporcionar una dinámica didáctica por parte del ingreso de los
datos.
5.4.4. Especificaciones de Usabilidad
Las Especificaciones de Usabilidad son objetivos de usabilidad cuantitativos y una guía
para poder determinar cuándo un sistema alcanza los niveles de usabilidad adecuado. Para
el sistema en construcción, los objetivos de usabilidad se definen de la siguiente forma:

a) Facilidad de Aprendizaje:

Los usuarios del sistema serán capaces de usar la Web la primera vez sin ningún tipo
de aprendizaje. El usuario deberá tener un previo conocimiento de los cálculos de
remuneraciones como proceso contable como tal.

La interfaz ha de ser simple, fácil de aprender y utilizar, con funcionalidades

accesibles y bien definidas.

b) Consistencia:

Se consideraran el uso de las convenciones propuestas en el diseño del sistema

anterior siempre que sea posible. Los usuarios se verán presionados a recordar
cualquier truco especial interactivo de una visita a otra del sitio, dada la operatividad
del sistema. Para entonces, los usuarios habrán acumulado un modelo mental
genérico del sistema centrado en la forma que debe funcionar cada página Web del
sitio, en base a la experiencia con el sistema anterior.

Utilizaremos los estándares y normas del sistema anterior y crearemos guías de estilo,
que permitan alcanzar la consistencia del look & feel del sitio. Estas guías se
generaran de acorde al diseño de cada página, con el fin posteriores diseños.

En el texto, evitaremos lo fondos oscuros y los colores llamativos, a excepción de los

que el cliente proponga y un acuerdo en común con los desarrolladores. También
evitaremos subrayar las palabras, porque un usuario las podría confundir con
hipervínculos.

Subrayaremos los vínculos y usaremos el azul como el color para los vínculos no visitados
y morado para identificar los ya visitados. Si los vínculos son azules, los usuarios sabrán
qué hacer, al igual que los morados. Excepto en las barras de navegación que utilicen un
diseño que deje más que claro dónde puede hacer clic el usuario.

c) Flexibilidad:

Evitaremos requerir escritura cuando un botón de selección o un enlace lo puedan

hacer.

Evitaremos requerir que el usuario tenga que cambiar constantemente entre hacer clic
y escribir, priorizando el uso de los TAB.

d) Robustez:

Evitaremos el uso de marcos (frames). Ciertos navegadores no soportan esta

característica.

Minimizaremos en lo posible el uso de DHTML o java. Elementos como los rollovers

o popups no estándares son difíciles de interpretar para los programas lectores de
pantalla.

e) Recuperabilidad:

Hay que contemplar los errores del usuario. Debe haber una retroalimentación
apropiada del sistema (copias de seguridad).

f) Tiempo de respuesta:

El tiempo máximo de descarga ha de ser de 10 segundos a la velocidad de conexión

media de los usuarios.

g) Disminución de la carga cognitiva:

El usuario deberá alcanzar cualquier página en el menor número posible de clics por
hipervínculo, a ser posible menos de 4.

h) Estética:
 Proporcionar un entorno agradable que contribuya al entendimiento por parte del
usuario de la información presentada.

5.5. Soluciones de Diseño

El prototipado en el DCU es un proceso fundamental que abarca una representación de todo
o parte de un producto o sistema. Para este proceso se utilizan 2 técnicas de usabilidad:
Storyboards y Prototipos de Papel, las cuales representan, por una parte, los escenarios de
la situación actual de la empresa con el software ya existente y la situación futura al utilizar
el nuevo sistema, por el otro, prototipos simples pero versátiles.

A continuación se presentan los resultados de ambas técnicas al aplicarlas para representar

el sistema en cuestión:

1. Diseño de Técnicas de Usabilidad: Storyboards

Los Storyboards consisten en una serie de dibujos o imágenes dispuestos en formato

secuencial de viñetas, que representan cómo un determinado sistema será usado durante la
consecución de una determinada tarea. Para el sistema en cuestión se representaron los
escenarios con el sistema ya existente y el nuevo sistema.

Storyboard: Caso del sistema existente para el Sistema de Control de Remuneraciones.

Fig. 16. Storyboar de la Situación actual del estudio contable.

Storyboard: Caso del sistema nuevo para el Sistema de Control de Remuneraciones.

Fig. 17. Storyboard de la Situación Futura del estudio contable.
Los Storyboard se enfocan en las interacciones que tiene el usuario con el sistema,
denotando la de importancia de los escenarios respecto a un antes y después de la
aplicación del nuevo sistema.

Tanto la situación actual como la situación futura de la empresa se proporcionaron gracias a

la cooperación del departamento de Operaciones Remuneraciones. El cual describió de
manera gráfica, visual y en lenguaje natural cada una de las tareas realizadas en el
departamento. En particular, esta técnica sirvió como medio gráfico para representar las
tareas realizadas por el administrador del sistema. El escenario del sistema futuro se vio
apoyado por las falencias fielmente conocidas por los usuario, es decir, todos los usuarios
que interactuaban con el sistema conocían en alrededor de un 90% sus inconsistencias,
llevando un tiempo considerable generándolas manualmente, de las cuales indudablemente
el sistema futuro debía mejorar.

2. Prototipos de Papel

Los prototipos permiten al desarrollador comunicarse con mayor efectividad con los
usuarios y clientes. Necesitamos construir prototipos porque las especificaciones técnicas
abstractas no son un buen medio de comunicación cuando queremos implicar a los usuarios
en el proceso de desarrollo. Es por esto que para mejorar la retroalimentación entre los
desarrolladores y el usuario se utilizaron los siguientes prototipos:

Prototipo: Sistema de Remuneraciones versión 1.0

Escenario: Inicio de Sesión

Fig. 18. Prototipo de papel para el Inicio de Sesión.

Prototipo: Sistema de Remuneraciones versión 1.0

Escenario: Inicio de Sesión

Fig. 19. Prototipo de papel para la Página Principal.

Prototipo: Sistema de Remuneraciones versión 1.0

Escenario: Manejo de usuarios

Fig. 20. Prototipo de papel para la Administración de Usuarios (modificar y eliminar).

Fig. 21. Prototipo de papel para el Ingreso de Usuarios.

Fig. 22. Prototipo de papel para el Listado de Usuarios.

Prototipo: Sistema de Remuneraciones versión 1.0

Escenario: Parámetros
Fig. 23. Prototipo de papel para los Datos Paramétricos.

Prototipo: Sistema de Remuneraciones versión 1.0

Escenario: Empresas
Fig. 24. Prototipo de papel para el Ingreso de Empresas.

Fig. 25. Prototipo de papel para Eliminar Empresas.

Fig. 26. Prototipo de papel el Listado de Empresas.

Prototipo: Sistema de Remuneraciones versión 1.0

Escenario: Trabajador

Fig. 27. Prototipo de papel para la Organización del Ingreso de datos de un Trabajador.

Prototipo: Sistema de Remuneraciones versión 1.0

Escenario: Remuneraciones
Fig. 28. Prototipo de papel para el Movimiento Mensual del módulo Remuneraciones.

Esta técnica fue empleada a través de un medio visual simple como lo es Microsoft Office
Power Point para representar digitalmente los prototipos que se presentaron en un principio
para organizar la estructura del sistema en general. Para entender un poco el contexto, las
imágenes poseen un número el cual identifica a que parte del menú principal se hace
alusión, comenzando desde el inicio de sesión Fig. 16, en donde el usuario se registra para
iniciar con su perfil (N° 0). Como se puede apreciar, la estética de la interfaz es algo
secundario importando la estructura de cómo será organizada la información. Luego en la
Fig. 17, se muestra la organización de la página principal donde se organizan los módulos
(basado en los casos de uso): Usuarios, Parámetros, Empresa, Trabajador y
Remuneraciones, esta organización se hizo en conjunto con los usuarios y basado en el
sistema anterior que poseía una organización similar (N° 0). La Fig. 18, Fig. 19, Fig. 20
muestran una esquematización de cómo podría ser el sistema para el módulo de
administración de usuarios (N° 1). Las Fig. 21 muestra la estructuración de cada uno de los
parámetros configurables del sistema (N° 2). Las Fig. 22, Fig. 23, Fig. 24 muestran la
posible organización del módulo de Empresas (N° 3). Finalmente las Fig. 25 y Fig. 26,
muestran la organización del módulo Trabajador y parte del módulo remuneraciones el cual
se definirá en base al sistema anterior (N° 4 y N° 5 respectivamente).

Sistema remuneraciones Multiempresas versión 1.0

Se presentan algunas imágenes del sistema construido en su versión 1.0, como primera
iteración del proceso Centrado en el usuario. Este se divide según la organización
previamente definida en los prototipos de papel anteriormente presentados.

Módulo Usuarios:

Menú Principal
Fig. 29. Imagen del Menú Principal para la administración de Usuarios del Sistema
Remuneraciones Multiempresas.
Ingreso de Usuarios

Fig. 30. Imagen del Ingreso de Usuarios del Sistema de Remuneraciones Multiempresas.
Módulo Datos Paramétricos:

Menú Principal
Fig. 31. Imagen del Menú de Datos Paramétricos del Sistema de Remuneraciones
Multiempresas.
Ingreso de Datos Paramétricos
Fig. 32. Imagen del Ingreso de Datos Paramétricos del Sistema de Remuneraciones
Multiempresas.
Módulo Empresas:

Menú Principal
Fig. 33. Imagen del Menú del módulo Empresas del Sistema de Remuneraciones
Multiempresas.
Ingreso de Empresas
Fig. 34. Imagen del Ingreso de Empresas del Sistema de Remuneraciones Multiempresas.
Módulo Trabajador:

Menú Principal
Fig. 35. Imagen del Menú del Módulo Trabajador del Sistema de Remuneraciones
Multiempresas.
Ingreso Trabajador
Fig. 36. Imagen de la Ficha de cada Trabajador del Sistema de Remuneraciones
Multiempresas.
Módulo Remuneraciones:

Menú Principal
Fig. 37. Imagen del Menú del Módulo Remuneraciones del Sistema de Remuneraciones
Multiempresas.
Movimiento Mensual
Fig. 38. Imagen del Movimiento Mensual del Sistema de Remuneraciones Multiempresas.

Se muestra como se ven reflejadas las técnicas de usabilidad de los apartados anteriores,
que sirvieron de medio de comunicación para una mejor comprensión con los usuarios del
sistema.

Este sistema se encuentra apto en el servidor Hera de la Escuela de Informática de la

Pontificia Universidad Católica de Valparaíso.

En el siguiente apartado se presenta la interacción de cada una de las interfaces del Sistema
Remuneraciones Multiempresas.
5.6. Diseño de la Interacción
El Diseño de la Interacción se encarga de la definición de los entornos de interacción y su
comportamiento. Incluye el diseño de los elementos visuales que forman la interfaz gráfica
de usuario, cuando la interfaz es de dicho estilo.

1. Diseño de Técnicas de Usabilidad: Mapas de Navegación

Los Mapas de Navegación representa la arquitectura general de la Interfaz de Usuario

modelando las relaciones entre contextos de interacción. Esta técnica es representada
mediante una nomenclatura específica: para el contexto un rectángulo y para las posibles
transacciones entre un espacio de interacción las flechas.

A continuación se presentan los diagramas que representan las interacciones más

importantes del sistema:

Mapa de Navegación: Organización General del Sistema de Remuneraciones.

Fig. 39. Mapa de Navegación General del Sistema Remuneraciones Multiempresas.
La Fig. 39 muestra la organización del sistema, desde el punto de vista de la interacción
entre interfaces del sistema y los procesos que comparten en particular, como lo es la
generación de informes o reportes asociados entre cada interfaz del sistema. En estos es
posible asociar de una manera abstracta las funcionalidades y posibles navegaciones por
parte del usuario en las distintas interfaces del sistema.

Mapa de Navegación: Organización Manejo de Usuarios.

Fig. 40. Mapa de Navegación del Ingreso de Usuarios del sistema.

La Fig. 40 muestra la Interacción que el usuario podría llevar a cabo según su interés en el
módulo de usuarios. La generación de informes solo es posible para el caso en que se
examinen usuarios específicos o un total de estos.

Mapa de Navegación: Organización del Módulo Empresas.

Fig. 41. Mapa de Navegación del Módulo Empresas del sistema.
La Fig. 41 muestra la interacción con la que el usuario puede navegar en el módulo
Empresas del sistema, en este modelo se puede apreciar cómo se organizan las opciones
relacionadas en la administración de la información de cada una de las empresas
pertenecientes al estudio contable (Pymes). La navegación por parte del usuario se realiza
con la organización definida en el Mapa de Navegación de la Figura.

Mapa de Navegación: Organización del Módulo Datos Paramétricos.

Fig. 42. Mapa de Navegación para los Datos Paramétricos.
La Fig. 42 muestra la organización del módulo de Datos Paramétricos. Esta organización
muestra la navegación en detalle con la que el usuario podrá interactuar. Cada Parámetro se
encuentra previamente definido en base a los casos de uso del sistema y con una estructura
similar a la del sistema anterior. Estos parámetros son configurables para los usuarios
administradores del sistema y se encuentran divididos jerárquicamente según el concepto
contable del estudio.

Mapa de Navegación: Organización del Módulo Trabajador.

Fig. 43. Mapa de Navegación para el módulo Trabajador.

La Fig. 43 muestra la organización del módulo Trabajador, donde se estructura todo el
contenido en una página con cada una de las opciones que se aprecian en la Figura: Ficha
personal del trabajador, descripción del contrato, previsión y cargas por trabajador.

Mapa de Navegación: Organización del Módulo Remuneraciones.

Fig. 44. Mapa de Navegación para el módulo Remuneraciones.
La Fig. 44 muestra la organización del módulo Remuneraciones, esta se estructura
secuencialmente siguiendo la siguiente secuencia: Movimiento mensual (por trabajador de
una empresa en particular), cálculo de las remuneraciones por institución, total institución y
cierre mensual contable (balances mensuales, anuales, estados resultados, etc.) Para el
usuario cada una de estas opciones les permite generar informes acordes al contexto. La
navegación del usuario es arbitraria, siempre que los procesos se hayan terminado, ejemplo
de esto: Cierre mensual, para este es necesario tener todos los cálculos de remuneraciones
previamente generados, con sus totalizaciones y sumarizaciones.

5.7. Evaluaciones de Usabilidad

Las actividades de Evaluación de Usabilidad son necesarias a lo largo de todo el
desarrollo, especialmente al final de cada ciclo iterativo, para conocer qué nivel de
usabilidad que ha alcanzado el producto, y cuánta mejora será necesaria para cumplir los
objetivos de usabilidad establecidos.
En la primera iteración y última iteración del Sistema de Remuneraciones Multiempresas se
realizaron evaluaciones de usabilidad por expertos y Test de Usabilidad en Laboratorios,
los cuales se efectuaron en el prototipo versión 1.0 y 2.0 del sistema encontrando lo
siguiente:

1. Diseño de Técnicas de Usabilidad: Evaluación de heurística por Expertos

Las evaluaciones de usabilidad miden y ayudan en los siguientes aspectos:

Proporcionar retroalimentación que sirva para la mejora del diseño.

Evaluar si los objetivos del usuario y organizacionales se han alcanzado.

Monitorizar el uso a largo plazo del producto o sistema.

A continuación se presentan los resultados de las Evaluaciones Heurísticas aplicadas sobre

el Sistema de Remuneraciones Multiempresas, las cuales se separan en las 2 iteraciones
definidas previamente en la planificación del Proceso Centrado en Usuario (el formato
utilizado para las Evaluaciones Heurísticas se encuentra en el Anexo D):

a) Primera Iteración:

La primera evaluación sobre la construcción del sistema fue realizada en la versión 1.0, la
cual fue evaluada por alumnos de Pregrado y Postgrado de la Pontificia Universidad
Católica de Valparaíso. Los evaluadores fueron los siguientes:

Monitor: Carmen Benavides A.

Evaluador 1: Johanna Toledo.

Evaluador 2: Diego Zamorano.

Evaluador 3: Jaime Norambuena.

Listado Final de Problemas:

1. El ingreso de un mal Password dice que no existe usuario o está inactivo, lo que puede
provocar confusión a la hora de detectar un error.
2. El sistema no posee ayuda.

3. Para la mayoría de las paginas que tienen un icono con una la lupa aparece una ventana
en la cual aparece como titulo ASISTENCIA lo cual confunde al usuario ya que no es un
nombre de acorde a una búsqueda.

4. En la mayoría de las páginas aparece el mismo nombre del título de esta confundiendo al
usuario, puesto que no tiene ninguna funcionalidad, ejemplo: Titulo Ingreso de Usuarios
aparece la palabra Ingreso en la página.

5. Para las fechas de cada página sería de ayuda para el usuario poder ingresarlas de
manera visual.

6. El formato de la pagina inicial es muy plano pudiendo tener al menos el logo de la

empresa o del sistema.

7. Podría aparecer el Nombre del usuario y el perfil que tiene.

8. El sistema no tiene un icono para poder salir de la sesión actual en la cual uno se
encuentra.

9. El sistema no tiene la hora actual o fecha actual.

Análisis Heurístico:

N° Evaluador Evaluador Evaluador Severidad Frecuencia Criticidad

Problema 1 2 3

S F C S F C S F C

1 3 2 5 3 1 4 2 4 6 2.7 2.3 5

2 3 3 6 3 3 6 4 4 8 3.3 3.3 6.7

3 3 2 5 2 2 4 2 4 6 2.3 2.7 5

4 2 3 5 2 2 4 2 4 6 2 3 5

5 1 3 4 1 2 3 1 4 5 1 3 4

6 1 2 3 1 2 3 1 4 5 1 2.7 3.7

7 1 3 4 1 3 4 1 4 5 1 3.3 4.3

8 4 4 8 1 3 4 4 4 8 3 3.7 6.7

9 1 3 4 1 3 4 1 4 5 1 3.3 4.3

Tabla 20: Tabla de Análisis Heurístico sobre el Sistema Remuneraciones Multiempresas.

El análisis de severidad y frecuencia para cada uno de los problemas encontrados obtenido
de la Tabla 20 se traduce en lo siguiente:

Problema 1: 2.7 y 2.3, Problema menor con una frecuencia entre un 11% a un 50%.

Problema 2: 3.3 y 3.3, Problema mayor con una frecuencia entre un 51% a un 89%.

Problema 3: 2.3 y 2.7, Problema menor con una frecuencia entre un 11% a un 50%.

Problema 4: 2 y 3, Problema menor con una frecuencia entre un 51% a un 89%.

Problema 5: 1 y 3, Problema cosmético con una frecuencia entre un 51% a un 89%.

Problema 6: 1 y 2.7, Problema cosmético con una frecuencia entre un 11% a un 50%.

Problema 7: 1 y 3.3, Problema cosmético con una frecuencia entre un 51% a un 89%.

Problema 8: 3 y 3.7, Problema mayor con una frecuencia entre un 51% a un 89%.

Problema 9: 1 y 3.3, Problema cosmético con una frecuencia entre un 51% a un 89%.
Dentro de los problemas encontrados por los evaluadores de usabilidad se encuentra
problemas que además de no cumplir con los principios heurísticos no cumplían con las
especificaciones de usabilidad determinadas en el presente proyecto, como por ejemplo:

Problemas en la facilidad de Aprendizaje de la interfaz.

Problemas de Estética.

Las posibles mejoras en el sistema consisten en lo siguiente:

Mejorar los formatos de las fechas de los formularios.

Mejorar el aspecto de la página principal del sistema.

Agregar un icono de cierre de Sesión.

Agregar el nombre del usuario y perfil que se encuentra activo en el sistema.

Mejoras realizadas:

Cambios en la página principal del sistema, agregando usuario, perfil cierre de sesión
y hora del sistema:

Versión 1.0:
Fig. 45. Página Principal del Sistema de Remuneraciones versión 1.0.
Versión 2.0:
Fig. 46. Página Principal del Sistema de Remuneraciones versión 2.0.
Como se puede apreciar en la Fig. 45 y la Fig. 46 el cambio producido en la página
principal del sistema, las mejoras proporcionadas fueron el agregar el Perfil de Usuario,
nombre del Usuario y el cierre de sesión del sistema. Se cambio el fondo superior de la
pagina a uno con una imagen superior que hace alusión a los cálculos de remuneraciones y
la imagen de fondo con el logo de la empresa. También se agrego la hora en formato:
Horas: Minutos: Segundos.

Cambios en el formato de fechas de los formularios:

Versión 1.0:
Fig. 47. Página del Ingreso de Parámetros Mensuales por Tramo Carga Familiar versión
1.0.
Versión 2.0

:
Fig. 48. Página del Ingreso de Parámetros Mensuales por Tramo Carga Familiar versión
2.0.

Como se puede apreciar en la Fig. 47. y la Fig. 48. El cambio producido en el ingreso de
fechas en el sistema es notable, para ingresar las fechas se puede hacer mediante un
formulario visual que permite setear las fechas según un calendario mes a mes del año
actual. Los días feriados se denotan con un color celeste y el día actual con un color rosado
que hace su distinción respecto al resto de los días del calendario. Por otra parte se quitó la
palabra Tramo Carga Familiar que no tenía ninguna utilidad para el sistema, este cambio se
proporciono para todos los formularios.

b) Segunda Iteración:
La segunda y última evaluación se realizó sobre la versión 2.0 (con las mejoras
implementadas a raíz de la evaluación anterior), la cual fue evaluada por el grupo de
evaluadores anteriormente mencionado.

Monitor: Carmen Benavides.

Evaluador 1: Johanna Toledo.

Evaluador 2: Diego Zamorano.

Evaluador 3: Jaime Norambuena.

Listado Final de Problemas:

1. Al estar ingresando data y apretar el link atrás no hay advertencia de que se va a perder
la información ni posibilidad de guardar un borrador.

2. El botón para cerrar sesión es poco claro.

3. El cuadro de mensaje de ingreso exitoso al iniciar sesión es redundante, ya que basta con
ingresar al sistema.

Análisis Heurístico:

N° Evaluador Evaluador Evaluador Severidad Frecuencia Criticidad

Problema 1 2 3

S F C S F C S F C

1 2 2 4 3 2 5 3 4 8 2.7 2.7 5,3

2 1 2 3 2 1 3 2 4 6 1.7 2.3 4

3 1 2 3 1 1 2 1 4 5 1 2.7 3.3

Tabla 21: Tabla de Análisis Heurístico sobre el Sistema Remuneraciones Multiempresas.

El análisis de severidad y frecuencia para cada uno de los problemas encontrados obtenido
de la Tabla 21 se traduce en lo siguiente:

Problema 1: 2.7 y 2.7, Problema menor con una frecuencia entre un 11% a un 50%.

Problema 2: 1.7 y 2.3, Problema cosmético con una frecuencia entre un 11% a un 50%.

Problema 3: 1 y 2.7, Problema cosmético con una frecuencia entre un 11% a un 50%.

Evaluaciones en general:

Las evaluaciones se efectuaron en un espacio cerrado y con los medios para llevar a cabo la
evaluación. Cada evaluador tuvo la oportunidad de inspeccionar el sitio Web de
Remuneraciones alrededor de una hora para después entregar el listado de los problemas
encontrados al monitor de la evaluación, quien agrupó las evaluaciones de los evaluadores
para generar un listado único, el cual fue entregado nuevamente a los evaluadores para
valorizar su severidad y frecuencia. Luego cada evaluador valorizó los criterios
mencionados y el monitor calculó la criticidad y porcentaje de cada uno de los problemas
según sus criterios, con el fin de entregar el posterior análisis de severidad y frecuencia de
cada uno de los problemas encontrados en la evaluación.

2. Diseño de Técnicas de Usabilidad: Test de Usabilidad en Laboratorios

En este tipo de test, en lugar de llevarle al usuario la interfaz, se trae al usuario a la interfaz.
Los participantes son llevados a unas instalaciones tipo laboratorio de usabilidad donde
llevan a cabo las tareas de referencia y todo lo asociado a un test de usabilidad.

El test de usabilidad utilizado para medir la usabilidad por parte de los usuarios se llevo a
cabo en el prototipo versión 2.0, proveniente de la segunda iteración de la fase de
construcción del Software, el diseño de la prueba consistió en lo siguiente:

Producto a evaluar: Sitio Web de Remuneraciones 2.0.

Atributo a evaluar: Rendimiento.

Descripción del Tipo de Prueba

Este tipo de prueba permitirá obtener datos cuantitativos acerca del rendimiento que
usuarios representativos tienen cuando ejecutan ciertas tareas sobre el producto evaluado.
Su objetivo principal es verificar si el producto a evaluar satisface ciertas metas de
usabilidad previamente establecidas (en las especificaciones de usabilidad previamente
definida en los apartados anteriores) y establecer una comparación con algún producto de la
competencia.

Recomendaciones para el Evaluador y el Usuario

El evaluador y el usuario no deben tener ningún tipo de interacción durante el desarrollo de

la prueba.

El número mínimo de participantes en la prueba debe ser el total de usuarios que

interactúan con el software para obtener resultados fiables.

Procedimiento para generar el Test de Usabilidad

Definir los objetivos de la prueba y los factores a medir.

Realizar la prueba con usuarios representativos.

Analizar los datos para esbozar las conclusiones.

Tipo de Producto a Evaluar: Sistema de Remuneraciones

Un sistema de Remuneraciones es una herramienta cuyo propósito es permitir la

comunicación entre las personas que necesitan organizar, procesar y calcular todo lo
relacionado con procesos del ámbito contable, legal y tributario. Ejemplo de esto son las
liquidaciones de sueldo, planillas de pago, etc.

Producto Específico a Evaluar

El producto que se debe evaluar es un Sitio Web de Remuneraciones el cual provee un

servicio para llevar a cabo los procesos contables de las distintas empresas asociadas a un
estudio contable y tributario.
Además, el Sitio Web de Remuneraciones, permite administrar los procesos mensuales de
remuneraciones, históricos de cada empresa asociada e informes solicitados por cada uno
de los usuarios de las empresas en cuestión, proporcionando funcionalidades tales como,
listar usuarios, eliminar empresas, parametrizar parámetros utilizados por los procesos
contables mensuales, buscar y crear filtros para las empresas, usuarios, trabajadores, etc.

Objetivos del Test

Obtener medidas sobre la eficiencia de uso del producto.

Obtener medidas sobre la cantidad de errores que comete el usuario al usar el

producto.

Obtener opiniones acerca de la satisfacción de uso.

Factores a medir

Tiempo que los usuarios toman en completar una tarea específica.

Cantidad de tareas que el usuario puede realizar en un tiempo límite dado.

Cantidad de errores que comete el usuario al usar el producto.

Tasa de interacciones exitosas y erróneas.

Tiempo utilizado por el usuario en recuperarse de los errores.

Proporción de usuarios que usan estrategias de trabajo eficientes en caso de que

exista más de una forma de realizar una tarea.

Perfiles de Usuarios

Se considerará:

x Usuario Novato: el usuario que no ha trabajado con un Sistema de Remuneraciones.

x Usuario Experto: el usuario que ha trabajado con un Sistema de Remuneraciones.

Definición de tareas
Tarea N°1:

Descripción: Ingresar al sistema con un perfil definido.

Tiempo Máximo (Usuario Novato): 1 minuto.

Tiempo Máximo (Usuario Experto): 1 minuto.

Caso Éxito: Ingresar al sistema de remuneraciones con un perfil definido.

Error: No lograr ingresar al sistema de remuneraciones con un perfil definido.

Tarea N°2:

Descripción: Creación de una cuenta de usuario en el Sistema.

Tiempo Máximo (Usuario Novato): 1 minuto.

Tiempo Máximo (Usuario Experto): 1 minuto.

Caso Éxito: Crear el usuario definido.

Error: No lograr crear usuario definido.

Tarea N°3:

Descripción: Ingresar con la cuenta de usuario creada.

Tiempo Máximo (Usuario Novato): 1 minuto.

Tiempo Máximo (Usuario Experto): 1 minuto.

Caso Éxito: Ingresar con la cuenta creada.

Error: No lograr ingresar con la cuenta creada.

Tarea N°4:

Descripción: Listar los usuarios del sistema.

Tiempo Máximo (Usuario Novato): 2 minutos.

Tiempo Máximo (Usuario Experto): 1 minuto.

Caso Éxito: Listar los usuarios del sistema.

Error: No lograr listar los usuarios del sistema.

Tarea N°5:

Descripción: Encontrar los parámetros Generales Sexo y Región y asignarle valores

predefinidos.

Tiempo Máximo (Usuario Novato): 3 minutos.

Tiempo Máximo (Usuario Experto): 2 minutos.

Caso Éxito: Encontrar los parámetros Generales Sexo y Región y asignarle valores
definidos.

Error: No lograr encontrar los parámetros Generales Sexo y Región y/o no poder asignarle
valores definidos.

Tarea N°6:

Descripción: Encontrar el parámetro Previsional AFP y asignarle los valores predefinidos.

Tiempo Máximo (Usuario Novato): 3 minutos.

Tiempo Máximo (Usuario Experto): 2 minutos.

Caso Éxito: Encontrar los parámetros provisionales AFP y asignarle los valores definidos.

Error: No lograr encontrar los parámetros provisionales AFP y/o no poder asignarle los
valores definidos.

Tarea N°7:
Descripción: Encontrar la empresa de Gianinna Reyes Bustos.

Tiempo Máximo (Usuario Novato): 3 minutos.

Tiempo Máximo (Usuario Experto): 2 minutos.

Caso Éxito: Encontrar la empresa definida.

Error: No lograr encontrar la empresa definida.

Tarea N°8:

Descripción: Ingresar la ficha personal de un trabajador con valores predefinidos.

Tiempo Máximo (Usuario Novato): 3 minutos.

Tiempo Máximo (Usuario Experto): 3 minutos.

Caso Éxito: Ingresar la ficha personal de un trabajador y asignarle los valores predefinidos.

Error: No lograr ingresar la ficha personal de un trabajador y/o no poder asignarle los
valores definidos.

Tarea N°9:

Descripción: Ingrese un movimiento mensual del trabajador anteriormente señalado (Tarea

N° 8).

Tiempo Máximo (Usuario Novato): 3 minutos.

Tiempo Máximo (Usuario Experto): 2 minutos.

Caso Éxito: Ingresar el movimiento mensual del trabajador creado en la tarea anterior.

Error: No lograr ingresar el movimiento mensual del trabajador creado en la tarea anterior.

Tarea N°10:
Descripción: Ingrese un movimiento mensual de otro trabajador (distinto al de la Tarea
N°10).

Tiempo Máximo (Usuario Novato): 3 minutos.

Tiempo Máximo (Usuario Experto): 2 minutos.

Caso Éxito: Ingresar el movimiento mensual del trabajador.

Error: No lograr ingresar el movimiento mensual del trabajador.

Tarea N°11:

Descripción: Generar el cálculo de remuneraciones de la empresa de Gianinna Reyes

Bustos.

Tiempo Máximo (Usuario Novato): 2 minutos.

Tiempo Máximo (Usuario Experto): 1 minuto.

Caso Éxito: Generar el cálculo de remuneraciones de la empresa indicada.

Error: No lograr generar el cálculo de remuneraciones de la empresa indicada.

Después de aplicar el Test, se obtuvieron los siguientes resultados:

Descripción del ambiente del Test

El test se desarrollo en un ambiente completamente cerrado, controlado por un supervisor

monitoreando las actividades de cada usuario evaluado.

Se montó un laboratorio de Usabilidad en las dependencias de la empresa. El evaluador se

encontraba en una sala con un computador visualizando y registrando las tareas de cada
usuario llevadas a cabo en el test de Usabilidad, en un computador con las características
soportables para la actividad.

Los usuarios participantes en el test de Usabilidad del sitio propuesto se encontraban en una
sala contigua asilados de cualquier intervención externa que pudiese afectar el desarrollo
normal de la actividad. Trabajaron en un computador dispuesto específicamente para
realizar el listado de tareas, el cual transmitía las capturas de imágenes hacia los
evaluadores para poder ser evaluadas con un software llamado Brother Eyes. Los
evaluadores y los usuarios participantes se encontraban separados en diferentes
habitaciones, pero con la posibilidad de observar a través de un vidrio que permite al
evaluador observar todo tipo de comportamiento expuesto por los usuarios frente al
desarrollo de las tareas.

Descripción del Test:

El Test de Usabilidad fue empleado sobre distintos tipos de usuarios: usuarios medios y
usuarios avanzados. En resumen fueron 3 usuarios, ambos con experiencias en el proceso
de remuneraciones. El test duró alrededor de 20 a 25 minutos. Cada usuario firmó un
acuerdo de confidencialidad el cual resguarda su identidad respecto al test, explicándoles
que debían llevar a cabo el listado de tareas entregado, pudiendo consultar en caso de no
comprender alguna de sus tareas durante el desarrollo del test. El test consistió básicamente
en ingresar al sitio anteriormente descrito, con el propósito de crear una cuenta personal y
editar los módulos del sistema de remuneraciones propuesto por el listado de tareas
proporcionado por el evaluador del test.

Resultados

Los resultados del experimento fueron satisfactorios, cada usuario respondió a las tareas
propuestas a pesar de poseer dudas al respecto a tareas específicas.

Usuario n°1: Usuario Novato

Usuario n°2: Usuario Novato

Usuario n°3: Usuario Experto

El usuario nº 1 respondió el total de las tareas descritas en el test antes del tiempo límite del
experimento, sin dudas algunas respecto a las tareas proporcionadas, siendo este el usuario
más ágil en cuanto al tiempo de duración indicado, tomando los caminos más rápidos para
llevarlas a cabo, demostrando que el sitio Web cumplía con su propósito. A pesar de que en
el test había una tarea que no se podía llevarse a cabo (Tarea N° 10, con un tiempo
estimado de 3 minutos), el usuario logró darse cuenta que el sitio no permitía tal acción,
continuando con las demás tareas asignadas. El tiempo total empleado para realizar las
tareas del test fue de 22 minutos dentro de un margen de hasta 25 minutos para usuarios
novatos.

Respecto al usuario nº 2, llevo a cabo las tareas asignadas dentro del tiempo límite del
experimento, con dudas respecto a las tareas asignadas, como en el caso de la tarea N º 10 ,
la cual no se podía llevar a cabo sin ingresar previamente un trabajador, tomándose 2
minutos más del tiempo estimado en la realización de ésta. A raíz de lo anterior este fue el
usuario más lento respecto a los demás usuarios novatos. Sin embargo, a pesar de las
problemáticas que surgieron, el usuario llevó a cabo las tareas asignadas exitosamente,
demostrando que el sistema cumplía con cada tarea en cuestión y que las problemáticas
estaban asociadas al usuario en sí y no al sistema. El tiempo total empleado en la
realización de todas las tareas del test fue de 25 minutos dentro de un margen de hasta 25
minutos para usuarios novatos.

Finalmente el usuario n° 3, llevo a cabo las tareas asignadas antes del tiempo límite del
experimento, sin dudas respecto a las tareas. El usuario para el caso de la tarea n° 10 tenía
conocimiento previo de que para llevarla a cabo se necesitaba el ingreso de un trabajador,
por lo que continuar con las demás tareas no le fue difícil. En conclusión para este usuario
se cumplieron cabalmente todas las tareas, demostrando que el sistema es lo bastante
utilizable, usable y eficiente. El tiempo total empleado en la realización de todas las tareas
del test fue de 17 minutos dentro de un margen de hasta 18 minutos para usuarios expertos.

5.8. Resultados Obtenidos en la Aplicación del Enfoque del

Diseño Centrado en el Usuario

5.8.1. Impacto en el Proceso de Desarrollo

Tras la finalización de los dos ciclos de desarrollo que se realizaron en el proyecto del
estudio (Sistema Remuneraciones Multiempresas), se distribuyó entre los desarrolladores
un cuestionario de usabilidad. Dicho cuestionario se incluye en el Anexo F.
Estos cuestionarios tuvieron los siguientes resultados:

Los cuestionarios recogidos reflejan un uso bastante alto de técnicas cercanas a la IS y solo
2 cercanas a la comunidad HCI, lo cual ratifica las consideraciones tomadas por los
desarrolladores a la hora de elegir sus técnicas. Es de vital importancia incluir técnicas
cercanas a la IS puesto que los desarrolladores se encuentran más familiarizados con
técnicas de este tipo. La utilización de técnicas familiares no implica que no se utilicen
técnicas desconocidas, puesto que por parte de la comunidad HCI el desarrollo de técnicas
de usabilidad cumple un principio, algunas más y otras menos, que sean realmente usables
y bajo este criterio las técnicas de usabilidad en su mayoría son aplicables según el tipo de
proyecto.

Por otra parte, se puede destacar que respecto a la valorización de las técnicas empleadas,
que ninguno de los desarrolladores considera que resulte difícil su aplicación ni que
aumenten los tiempos de desarrollo al aplicarlas (en su mayoría la media de cada uno es 2
la cual indica un desacuerdo respecto a las expresiones “Técnica difícil de aplicar” y
“Tomo más tiempo en el desarrollo el aplicar esta técnica”). En la Tabla 22 se puede
observar los resultados detallados por los desarrolladores en los cuestionarios. Los valores
de la tabla indican el grado de acuerdo con las afirmaciones “Técnica difícil de entender”,
“Técnica difícil de Aplicar”, “Técnica difícil de integrar en el resto del desarrollo” y “Tomo
más tiempo en el desarrollo el aplicar la técnica” que encabeza la columna en una escala 1-
5, donde 1 significa en Muy desacuerdo, 2 desacuerdo, 3 opinión Neutra, 4 de acuerdo y
5 Muy de acuerdo. En la tabla se pueden apreciar las medias recogidas de un total de 6
cuestionarios aplicados a cada uno de los desarrolladores del proyecto (Anexo F):

Tabla 22: Valorización de las Técnicas de Usabilidad empleadas.

La Tabla 22 indica las medias y desviaciones estándar de cada uno de los resultados
obtenidos a través de los cuestionarios aplicados, obteniendo los siguientes resultados:

Los desarrolladores consideran en general, que en promedio las técnicas no son difíciles de
entender, ni difíciles de aplicar e integrar en el resto del desarrollo y que no toman más
tiempo, con un promedio de 2, que bajo la escala definida indica un desacuerdo. Por otra
parte, la variabilidad para cada afirmación respecto a la media fue de un: 0.33 para “difícil
de entender”, 0.34 para “difícil de aplicar”, 016 para “integrar en el resto del desarrollo” y
0.31 para “toma más tiempo en el desarrollo su aplicación”, de acuerdo a los valores
obtenidos, se puede concluir que en general la dispersión de las opiniones es menor por lo
que la media es más representativa.

Los desarrolladores participantes en el estudio claramente identifican la aplicación de este

tipo de técnicas como una ayuda en el desarrollo de la parte visible de la interfaz gráfica del
usuario (media de 4: De acuerdo, en una escala 1-5). Por otra parte, el grado de acuerdo con
la afirmación de que la aplicación de las técnicas ha sido de ayuda en el desarrollo del resto
del sistema, se mantiene en la misma media de 4 (de acuerdo). Por tanto, la mayoría de los
desarrolladores participantes ha identificado el factibilidad de aplicar el enfoque del diseño
centrado en el usuario y las técnicas de usabilidad, considerando la aplicación de las
actividades y técnicas centradas en el usuario como un apoyo al desarrollo de software más
que una actividad que se encuentre demás o inservible. Por consiguiente, es posible afirmar
que se rompe el estigma que asocia la usabilidad con la Interfaz de usuario, demostrando
que esta no necesariamente se relaciona directamente sino que se encuentra presente desde
los comienzos del desarrollo de software hasta sus etapas finales. Dentro de las actividades
afectadas por los procesos centrados en el usuario, con mayor frecuencia se encontraron las
actividades de evaluación donde los Test de Usabilidad y la Evaluación Heurística, se
identifican como técnicas que han permitido mejorar la interfaz gráfica de usuario y los
procesos que el usuario lleva a cabo con el sistema.

En cuanto al esfuerzo empleado en las actividades de usabilidad, los desarrolladores

participantes se inclinan claramente por encontrarse muy de acuerdo con los resultados
obtenidos por la aplicación del enfoque, puesto que el grado de acuerdo con la afirmación
“el esfuerzo que conlleva aplicar el enfoque centrado en el usuario se ve compensado por
los resultados obtenidos” obtuvo una mayor frecuencia valorizada con el criterio Muy de
acuerdo.

Conclusiones al respecto:

Los resultados obtenidos permiten afirmar que la aplicación del Enfoque del Diseño
Centrado en El Usuario es viable, sirviendo a su propósito de crear productos adaptados a
las necesidades reales de los usuarios, que en muchos casos aún no han sido identificadas y,
en consecuencia, pueden suponer una importante e innovadora oportunidad para las
empresas.

En particular, la inclusión aplicación de actividades centradas en el usuario y de técnicas de

usabilidad se ha realizado con éxito, obteniéndose una apreciación por parte de los
desarrolladores participantes en los distintos proyectos en comparación de las ventajas de
aplicación de las técnicas en cuanto a los resultados obtenidos.

Para la aceptación de un cambio de las prácticas de desarrollo es muy importante contar

también con la aprobación de los miembros del equipo de desarrollo. La elección de las
técnicas de usabilidad aplicadas en ambos Proyectos según el estudio previamente
dispuesto no resultó ser una tarea difícil, ya que gracias a su coordinación y alineación en el
proceso de desarrollo, además del previo conocimiento de la aplicación de cada una de ellas
facilitó su ejecución.

De la amplia gama de técnicas disponibles solo se han aplicado únicamente 10 de ellas. . La

aplicación del total de técnicas sería lo ideal, pero la selección de aquellas que mejor se
acomoden a las circunstancias del proyecto brindan una flexibilidad necesaria que apoya en
los desarrollos de software de cualquier la organización, pudiendo concluir que se cumple
el propósito del Diseño Centrado en el usuario al ofrecer una realidad innovadora, flexible
y estructurada para la producción de soluciones. Cualquier organización interesada en
mejorar la usabilidad de sus productos software podrá seguir como guía, para proyectos
similares, basándose en la información proporcionada en el estudio propuesto, las
actividades y técnicas de usabilidad que puedan encajar mejor con los objetivos
organizacionales y del proyecto en cuestión.

Para el Proyecto desarrollado en el presente estudio el incluir al usuario en todo el proceso

de desarrollo provocó una definición clara de los requisitos del usuario, que a pesar de que
estos no estuvieran completamente definidos en las etapas tempranas se abarcaron mediante
los resultados de las técnicas d usabilidad aplicadas a lo largo del desarrollo completo.

Es importante señalar que los desarrolladores en desconocimiento en muchos casos

conocen un conjunto de productos que deben producir. Así, a no ser que una técnica de
usabilidad incida directamente sobre un producto y tal relación esté expresada
explícitamente, pueden no descubrir tal relación. Por otra parte, los desarrolladores en
conocimiento consideran y valoran cualquier herramienta que permita mejorar la
comunicación con el cliente y los usuarios, pudiendo haber influido así mismo este factor
en la diferencia observada con los desarrolladores en desconocimiento.
5.8.2. Impacto en la Usabilidad Percibida del Producto
El grado de satisfacción expresado por los usuarios sobre el proyecto desarrollado en
cuanto a la usabilidad del producto obtenido fue alto.

Para poder evaluar la posible mejora en la usabilidad del producto se contaba con el
software utilizado anteriormente por el estudio contable. Dicho software se probó con los
mismos usuarios que lo utilizaban con anterioridad. El cuestionario distribuido entre los
desarrolladores participantes en el estudio se incluye en el Anexo G.

Los miembros del equipo que desarrollaron el nuevo sistema con el enfoque DCU,
realizaron a su vez test de usabilidad con usuarios que habían probado previamente el
sistema anterior. En la Tabla 23 se detalla los resultados de las respuestas dadas en los
cuestionarios por los usuarios a la pregunta de satisfacción general, con la cual se puede
observar una mejora apreciable respecto a la satisfacción general expresada por los usuarios
del nuevo sistema (valor medio 5, es decir Muy Satisfecho) en comparación con la
expresada por los usuarios del software anterior (valor medio 2.5, es decir Insatisfecho).

Tabla 23: Cuadro comparativo de satisfacción expresado por los usuarios del Sistema de
Remuneraciones Multiempresas.
En la Tabla 23 podemos apreciar los porcentajes y valores medios los cuales muestran el
cambio de perspectiva frente al sistema y la satisfacción por parte de los usuarios del nuevo
sistema.
5.9. Comparación entre un Sistema Centrado en el Usuario y
un Sistema Centrado en el Desarrollo de Sistemas Clásico
Para poder comparar cómo afecta el abordar la usabilidad de los sistemas, se contó con un
prototipo desarrollado que permitiera dicha comparación. En el proyecto en comparación
(Sistema para el Control de Inventarios) se desarrollo una aplicación similar que coincidía
en los objetivos del proyecto llevado a cabo por los tesistas de la carrera de Ingeniería en
Ejecución Informática de la Pontificia Universidad Católica de Valparaíso. En dicho
proyecto los alumnos del ramo Ingeniería de Software no disponían del conocimiento de
los procesos centrados en el usuario construyendo su prototipo centrado en el desarrollo de
sistemas, en el cual se había tratado la usabilidad implícitamente, sin el previo
conocimiento de la Usabilidad y el Diseño Centrado en el Usuario, sólo contaron con una
inducción introductoria al tema de la Usabilidad y el Diseño Centrado en el Usuario (Anexo
H). De esta manera, pudimos equiparar los conocimientos teóricos (aunque en un menor
nivel) para poder demostrar el impacto de los procesos centrados en el usuario al contar
con una agrupación de equipos formados por desarrolladores con un nivel de experiencia
similar.

5.9.1. Sistema Centrado en el Usuario

El equipo de trabajo formado por el autor del proyecto y los tesistas de la carrera de
Ingeniería en Ejecución Informática de la Escuela de Informática, consta con la siguiente
organización:

Equipo multidisciplinar se dividió en:

Jefe de Proyectos: Natalia Carrasco Pizarro.

Analista - Programador: Gianinna Reyes Bustos.

Analista - Programador: Natalia Carrasco Pizarro.

Analista - Desarrollador de Usabilidad: Carmen Benavides Allendes.

Evaluador Heurístico: Johanna Toledo.

Evaluador Heurístico: Diego Zamorano.

 Evaluador Heurístico: Jaime Norambuena.

Se seleccionaron las Técnicas de Usabilidad que podían adecuarse mejor a las

características del Proyecto, donde los analistas, desarrollador de usabilidad y evaluadores
heurísticos tenían una breve formación en cada una de las técnicas por parte del ramo
dictado por la Escuela de Informática Human Computer Interaction. Las técnicas aplicadas
por el equipo multidisciplinar son las siguientes:

1 Entrevista.

2 Cuestionario de usabilidad.

3 Casos de Uso Esenciales.

4 Escenario y Storyboards.

5 Especificaciones de Usabilidad.

6 Evaluación Heurística.

7 Mapas de navegación.

8 Perfiles de usuario.

9 Prototipos de papel.

10 Test de Usabilidad en Laboratorio.

El desarrollo se dividió en dos ciclos al final de los cuales se debía realizar un test de
usabilidad y cuestionarios de satisfacción con los usuarios del Studio Contable Tributario,
para conocer el nivel y percepción de la usabilidad del sistema software.

5.9.2. Sistema Centrado en el Desarrollo de Sistemas

El equipo de trabajado del proyecto en comparación (Sistema para el Control de
Inventarios) se encuentra formado por:

Jefe de Proyectos: Gustavo Cisternas Silva.

 Analista - Programador: Gustavo Cisternas Silva.

Analista - Programador: Carlos Toledo.

Este Proyecto nació de una situación en la que no se empleaban actividades ni técnicas

centradas en el usuario, tratando la usabilidad tangiblemente según las bases de análisis y
programación de los desarrolladores.

Sistema Top Machine:

Captura de imágenes para los módulos de Ingreso de Artículos, Recetas, Mayor Auxiliar de
Existencias y Búsqueda de Artículos.

Ingreso de Artículos:

Fig. 49. Módulo de Artículos del Sistema de Control de Inventarios.

Recetas:
Fig. 50. Módulo de Recetas para el Sistema de Control de Inventario.

Mayor Auxiliar de Existencias:

Fig. 51. Módulo de Control de Entradas y salidas de Inventario del Sistema de Control de
Inventarios.
Búsqueda de Artículos:

Fig. 52. Módulo de Búsqueda de Artículos del Sistema de Control de Inventarios.

Para el proyecto en comparación se aplicaron test de usabilidad con usuarios para poder
conocer el nivel de usabilidad del sistema y cuestionarios de satisfacción para conocer el
nivel con el cual se percibe la usabilidad del sistema, para poder comparar la usabilidad de
ambos sistemas.

1. Diseño del Test de Usabilidad para el Sistema de Control de Inventarios

El test de usabilidad aplicado en sobre el Sistema de Control de Inventarios fue aplicado

sobre usuarios con conocimientos del proceso de negocio. Fue aplicado sobre 3 usuarios,
donde todos se consideraban Usuarios Expertos. La aplicación de este test fue similar al
aplicado sobre los operadores del estudio contable.

El diseño consistió en lo siguiente:

Producto a evaluar: Sistema de Control de Inventario (Top Machine @) 1.0.

Atributo a evaluar: Rendimiento.

Descripción del Tipo de Prueba

Este tipo de prueba permitirá obtener datos cuantitativos acerca del rendimiento que
usuarios representativos tienen cuando ejecutan ciertas tareas sobre el producto evaluado.
Su objetivo principal es verificar si el producto a evaluar satisface ciertas metas de
usabilidad y establecer una comparación con algún producto de la competencia.

Recomendaciones para el Evaluador y el Usuario

El evaluador y el usuario no deben tener ningún tipo de interacción durante el desarrollo de

la prueba.

El número mínimo de participantes en la prueba es de al menos 3 usuarios que interactúan

con el software para obtener resultados fiables.

Procedimiento para generar el Test de Usabilidad

Definir los objetivos de la prueba y los factores a medir.

Realizar la prueba con usuarios representativos.

Analizar los datos para esbozar las conclusiones.

Tipo de Producto a Evaluar: Sistema de Control de Inventarios

Un sistema de control de Inventarios es una herramienta cuyo propósito es permitir la

comunicación entre las personas que necesitan llevar a cabo todos los procesos operativos
del control de inventarios, regulando tanto las herramientas, materias primas, productos en
procesos y terminados, protegiendo a la empresa de costos innecesarios por
acumulamientos o falta de existencias en el almacén. Ejemplo de esto son el control de
existencias, manejo de stock en bodegas, etc.

Producto Específico a Evaluar

El producto que se debe evaluar es un Sitio Web para el Control de Inventario el cual
provee un servicio para llevar a cabo los procesos de inventario desde el ingreso hasta la
salida de existencias de una empresa banquetera.

También, este sitio permite administrar los procesos mensuales de entradas y salidas de
stock de los almacenes, almacenando datos estadísticos de los costos asociados (históricos
de ingreso y costos), con un módulo de reportes que permite generar datos estadísticos de
control de las existencias y costos de cada uno de los artículos inventariados, etc.

Objetivos del Test

Obtener medidas sobre la eficiencia de uso del producto.

Obtener medidas sobre la cantidad de errores que comete el usuario al usar el

producto.

Obtener opiniones acerca de la satisfacción de uso.

Factores a medir

Tiempo que los usuarios toman en completar una tarea específica.

Cantidad de tareas que el usuario puede realizar en un tiempo límite dado.

Cantidad de errores que comete el usuario al usar el producto.

Tasa de interacciones exitosas y erróneas.

Tiempo utilizado por el usuario en recuperarse de los errores.

Proporción de usuarios que usan estrategias de trabajo eficientes en caso de que

exista más de una forma de realizar una tarea.

Perfiles de Usuarios

Se considerará:

x Usuario Novato: el usuario que no ha trabajado con un Sistema de Control de

Inventario.
x Usuario Experto: el usuario que ha trabajado con un Sistema de Control de Inventario.

Definición de tareas

Tarea N°1:

Descripción: Ingresar al sistema con un perfil definido.

Tiempo Máximo (Usuario Novato): 1 minuto.

Tiempo Máximo (Usuario Experto): 1 minuto.

Caso Éxito: Ingresar al sistema de Control de Inventario con un perfil definido.

Error: No lograr ingresar al sistema de Control de Inventario con un perfil definido.

Tarea N°2:

Descripción: Creación de una cuenta de usuario en el Sistema.

Tiempo Máximo (Usuario Novato): 1 minuto.

Tiempo Máximo (Usuario Experto): 1 minuto.

Caso Éxito: Ingresar al sistema de Control de Inventario con la cuenta definida.

Error: No lograr ingresar al sistema de Control de Inventario con la cuenta definida.

Caso Éxito: Crear el usuario definido.

Error: No lograr crear usuario definido.

Tarea N°3:

Descripción: Ingresar con la cuenta de usuario creada.

Tiempo Máximo (Usuario Novato): 1 minuto.

Tiempo Máximo (Usuario Experto): 1 minuto.

Caso Éxito: Ingresar con la cuenta creada.

Error: No lograr ingresar con la cuenta creada.

Tarea N°4:

Descripción: Generar el Ingreso de un Artículo en particular e identificar características de

éste.

Tiempo Máximo (Usuario Novato): 8 minutos.

Tiempo Máximo (Usuario Experto): 6 minutos.

Caso Éxito: Ingresar el artículo asignando los valores definidos por la tarea.

Error: No ingresar el artículo y/o asignar los valores definidos por la tarea.

Tarea N°5:

Descripción: Encontrar el artículo anterior e ingresar la última entrada y salida de este.

Tiempo Máximo (Usuario Novato): 7 minutos.

Tiempo Máximo (Usuario Experto): 4 minutos.

Caso Éxito: Ingresar la última entrada y salida del artículo definido.

Error: No ingresar la última entrada y salida del artículo definido.

Tarea N°6:

Descripción: Encontrar el artículo: coctel de almejas e ingresar el número total de

existencias y costo asociado.

Tiempo Máximo (Usuario Novato): 7 minutos.

Tiempo Máximo (Usuario Experto): 5 minutos.

Caso Éxito: Ingresar el número total de existencias y el costo asociado del artículo coctel
de almejas.

Error: No ingresar el número total de existencias y el costo asociado del artículo coctel de
almejas.

Descripción del ambiente del Test

El test se desarrollo en un ambiente completamente cerrado, controlado por un supervisor

monitoreando las actividades de cada usuario evaluado. Este espacio se montó con el fin de
simular un laboratorio de usabilidad.

El evaluador se encontraba en una sala contigua con un computador visualizando y

registrando las tareas de cada usuario llevadas a cabo en el test de Usabilidad, en un
computador con las características soportables para la actividad.

Los usuarios participantes en el test de Usabilidad se encontraban en una sala contigua

asilados de cualquier intervención externa que pudiese afectar el desarrollo normal de la
actividad. Trabajaron en un computador dispuesto específicamente para realizar el listado
de tareas, el cual transmitía las capturas de imágenes a través de una webcam hacia los
evaluadores para poder ser evaluadas. Los evaluadores y los usuarios participantes se
encontraban separados en diferentes habitaciones, pero con la posibilidad de observar a
través del vidrio de la puerta el cual permitía observar todo tipo de comportamiento
expuesto por los usuarios frente al desarrollo de las tareas, dicha observación se efectuó con
cautela para no distraer al usuario en el desarrollo del test.

Descripción del Test:

El test duró alrededor de 20 minutos a 25 minutos. Cada usuario firmó un acuerdo de

confidencialidad el cual resguarda su identidad respecto al test, explicándoles que debían
llevar a cabo el listado de tareas entregado, pudiendo consultar en caso de no comprender
alguna de sus tareas durante el desarrollo del test. El test consistió básicamente en ingresar
al sitio anteriormente descrito, con el propósito de crear una cuenta personal y editar los
módulos del sistema de Control de Inventarios propuesto por el listado de tareas
proporcionado por el evaluador del test.

Resultados

Los resultados del experimento fueron satisfactorios, cada usuario respondió a las tareas
propuestas a pesar de poseer dudas al respecto a tareas específicas.

Usuario n°1: Usuario Novato

Usuario n°2: Usuario Experto

Usuario n°3: Usuario Experto

Respecto al usuario nº 1, no alcanzó a llevar a cabo las tareas asignadas dentro del tiempo
límite del experimento, con dudas respecto a las tareas. Esto demostraba que el usuario se
encontraba con problemas conceptuales respecto al proceso de negocio. De esta manera,
este usuario relentizó su labor convirtiéndose así en el usuario más lento. Pudiendo
concluir, que las problemáticas que surgieron se debían a problemáticas asociadas al
usuario en sí (desde un aspecto teórico). El tiempo total empleado en el desarrollo de cada
una de las tareas asignadas fue de 27 minutos dentro de un margen de 25 minutos como
máximo para usuarios novatos.

El usuario n° 2, llevo a cabo las tareas asignadas dentro del tiempo límite, con dudas
respecto a las tareas, básicamente por la ubicación de los módulos del sistema,
convirtiéndose en el usuario más dudoso respecto a los demás. Sin embargo pudo concluir
el test exitosamente tomando un tiempo total de 17 con un margen de 18 minutos para
usuarios expertos.

Finalmente al usuario n° 3, llevo a cabo las tareas asignadas dentro del tiempo límite del
experimento, con dudas respecto las tareas que no se podían realizar (Tarea N° 6 con una
margen de 5 minutos) tomando alrededor de 1 minuto más de lo esperado. A pesar de esto y
gracias a las indicaciones del evaluador el usuario logró llevar a cabo el test completo. En
conclusión que el test se llevó a cabo exitosamente tomando un tiempo total de 18 minutos
con un margen de 18 minutos para usuarios expertos.
Conclusiones Generales:

La prueba de usabilidad para los usuarios que llevaron a cabo el test fue exitosa. Denotando
que el sistema cumplía sus funcionalidades básicas, pero sin embargo, el test arrojó
problemas con tareas que se podían llevar a cabo sin problema alguno, donde el sistema era
poco intuitivo y dificultoso en su organización.

2. Impacto percibido en la Usabilidad del Producto

El impacto percibido en la Usabilidad del Producto se midió en base al cuestionario de

satisfacción (Anexo G), el cual obtuvo los siguientes resultados:

El grado de satisfacción expresado por los usuarios sobre el proyecto en comparación, en

cuanto a la usabilidad del producto obtenido fue Medio (Neutro).

En la Tabla 24 se detalla los resultados de las respuestas dadas en los cuestionarios por los
usuarios a la pregunta de satisfacción general, con la cual se puede observar una opinión
neutra respecto a la satisfacción general expresada por los usuarios del sistema (valor
medio 3, es decir Neutro).

Tabla 24: Cuadro comparativo de satisfacción expresado por los usuarios del Sistema de
Control de Inventario.
Esta opinión también se vio reflejada en la opinión general del sistema, la cual tuvo
también un valor medio de 3, lo que significa que los usuarios tienen una opinión neutra
con el sistema.
5.9.3. Comparación de Ambos Sistemas
El test de usabilidad permitió comparar ambos sistemas pudiendo concluir que la
efectividad y usabilidad de los sistemas depende de cómo se aborde la usabilidad de estos,
lo que se vio reflejado en los usuarios, puesto que el sistema que se diseñó con el enfoque
DCU tuvo una mejor aceptación por parte estos, a diferencia de los usuarios que
interactuaron con el Sistema Centrado en Sistemas, los cuales llevaron a cabo sus tareas
con mayores dudas y menor efectividad. Es importante destacar que si bien el sistema
desarrollado con el enfoque DCU tuvo una mejor aceptación por parte de los usuarios, por
la parte intuitiva de cada una de las tareas y la rapidez con que se podían llevar a cabo cada
una de ellas, esto no implica que los sistemas centrados en el desarrollo de sistemas (DCS)
no aborden la usabilidad, sino que más bien depende de cómo aborde la usabilidad el
equipo de trabajo que desarrolle el sistema en cuestión.

Los sistemas centrados en el desarrollo de sistemas se encuentran en desventaja respecto a

los procesos centrados en el usuario, ya que depende de la efectividad con la que se recojan
los requerimientos del usuario, pudiendo estos variar en todo el desarrollo de Sistemas
transformándose en reestructuraciones riesgosas a la hora de interferir en el diseño actual.
Para el caso de los procesos centrados en el usuario, no significa que estos requerimientos
no cambien, sino que se tienen medios que recogen de una mejor manera los
requerimientos del usuario (a través de técnicas) y en caso de cambiar, al incluirlo dentro de
todas las fases de desarrollo se trabaja directamente y oportunamente los cambios
reduciendo los riesgos del proceso de desarrollo.

Por otra parte, el cuestionario de satisfacción (Anexo G) demostró que para los usuarios el
Sistema Centrado en el Desarrollo de Sistemas (DCS) la opinión sobre estos no era ni
buena ni mala, es decir neutra, a diferencia de los usuarios por parte del sistema con el
enfoque DCU que tuvieron una opinión satisfactoria respecto al sistema, demostrando que
la percepción por parte de los usuarios se vio influenciada por la usabilidad de los sistemas
en cuestión.
Capitulo 6
Conclusiones

La usabilidad en esta última década, en el desarrollo de Sistemas Software se ha

desmedrado su importancia y ha sido considerada como un atributo de calidad menor, al
que se le dedica un menor esfuerzo que a otros atributos. Es por esto, que hasta no muy
poco, la intervención del usuario fue contemplada como participativa en lo que
correspondía a la evaluación de interfaces, siendo aplicado exclusivamente en las
actividades de evaluación del producto final, pero se ha demostrado que existe un gran
número de ventajas respecto a la anticipación de problemas, ya sea no previstos o
posteriores al desarrollo, al gran ahorro de costos y tiempo que se evitan al incluirlo desde
las etapas tempranas. Es por esto, que las organizaciones de desarrollo de software han
tomado una nueva perspectiva respecto a cómo perciben este atributo de calidad y se han
preocupado de incluirlo en su desarrollo, tomando la usabilidad como un objetivo
estratégico para poder responder el impacto que hoy en día demandan los usuarios de los
sistemas software.

Hace no mucho tiempo los desarrolladores de software se encontraban en gran desventaja

frente a los usuarios, los cuales con el tiempo poseían una desmedrada imagen a la hora de
responder por software que no cumplían con sus necesidades, convirtiéndose en los
culpables por no representar lo solicitado. Por otra parte, los mismos desarrolladores
culpaban a los usuarios por no saber exponer sus necesidades, cambiando constantemente
los requerimientos solicitados en un principio. A consecuencia de esto, se generó el
conflicto de quién tiene la razón, respuesta que por sí sola es implícita: ambos. A causa de
esto, los desarrolladores de software han considerado que para no construir aplicaciones
que no representen las necesidades de los usuarios, se hace necesario incluirlo de una forma
más participativa en el todo el proceso de desarrollo con el fin de no seguir cometiendo este
tipo de errores, denotando la importancia que éste tiene a la hora de desarrollar un sistema
software. El Diseño Centrado en el Usuario incluye a los usuarios en cada una de sus
actividades mediante técnicas de usabilidad, algunas siendo participe y otras basándose en
éstos.

Cabe destacar, la amplia gama de técnicas que se pueden aplicar en el Diseño Centrado en
el Usuario, las cuales abarcan el proceso completo de desarrollo, previendo distintas
alternativas, algunas más costosas en cuanto a esfuerzo y otras que a pesar de su
complejidad o sencillez son económicas de aplicar.

La primera etapa de este proyecto se basó en la adquisición de conocimientos sobre los

distintos conceptos del enfoque del Diseño Centrado en el Usuario, involucrando un
extensivo análisis y comprensión de los componentes más importantes: la usabilidad y el
Modelo de desarrollo de los Procesos Centrados en el Usuario, además de adquirir una
visión global de las distintas técnicas de usabilidad existentes en esta área y la gran
cantidad de clasificaciones que encontramos de ellas. Posteriormente, se realizó un análisis
exhaustivo de cada una, para la elaboración de la propuesta preliminar, las cuales dieron
como resultado pautas de usabilidad según cada caso de estudio.

La segunda etapa de este proyecto, tomó la propuesta preliminar de la primera etapa y la

refinó con el fin de confeccionar solo una pauta enfocada en un caso de estudio, por
razones de tiempo. Después de obtener la propuesta definitiva se definió en qué parte del
proceso de desarrollo (análisis, diseño y/o evaluación) se incluirán cada una de las técnicas
de Usabilidad, para luego comenzar con su implementación en el caso de estudio.

La implementación del enfoque en este proyecto, consistió en la planificación del Diseño

Centrado en el Usuario, tanto por el desarrollo de cada una de las actividades de éste, como
para su integración en el Modelo de Desarrollo de Software con el cual se construirá el
caso de estudio a implementar (Proceso Unificado), Luego se definieron las distintas
actividades que propone el enfoque: Especificación del contexto de uso: análisis del usuario
y análisis de tareas, las especificaciones de requisitos del usuario y la organización con sus
correspondientes especificaciones de usabilidad, en la producción de soluciones de diseño
conformadas por las dos versiones del sistema, el diseño de la interacción y las
evaluaciones de usabilidad, cada una de ellas aplicadas con el apoyo de las técnicas de
usabilidad establecidas en la pauta de usabilidad propuesta: Perfiles de usuario, Casos de
Uso Esenciales, Mapas de Navegación, Evaluaciones Heurísticas, Test de Usabilidad, etc.

Luego de implementar el sistema software con el enfoque DCU, se midió la usabilidad

percibida por los usuarios, los cuales determinaron que la usabilidad del sistema fue alta,
mediante un test de usabilidad que tomaba en comparación el software anterior con el cual
trabajaban actualmente y el nuevo software con el enfoque DCU. En la comparación de
ambos software, se pudo concluir que el impacto de los procesos centrados en el usuario
mejora la usabilidad de los sistemas, abriendo una brecha para su utilización y que
mediante la retroalimentación con los usuarios, a través de técnicas especializadas en el
proceso de desarrollo completo, se pueden alcanzar sus necesidades de una forma más
precisa, siendo recomendable para su utilización.

También, se midió el impacto en el proceso de desarrollo a través de Cuestionarios de

Usabilidad, donde se determinó que la utilización del enfoque DCU y la pauta de usabilidad
propuesta no involucran un mayor esfuerzo a los desarrolladores, considerando la
compensación que implica aplicar el enfoque respecto a los resultados obtenidos. Esta
apreciación permite afirmar que la aplicación del Enfoque del Diseño Centrado en El
Usuario es viable, sirviendo a su propósito de crear productos adaptados a las necesidades
reales de los usuarios, los cuales en muchos casos aún no han sido identificadas y, en
consecuencia, pueden suponer una importante e innovadora oportunidad para las empresas.

Por otra parte, es importante destacar que en la comparación de los sistemas desarrollados
con el enfoque del Diseño Centrado en Usuario (DCU) y los sistemas desarrollados con el
enfoque de Sistemas Centrados en Sistemas (DCS), se pudo concluir que el impacto de los
procesos centrados en el usuario mejora la usabilidad de los sistemas software teniendo una
mejor aceptación por parte de los usuarios y dependen de cómo aborde la usabilidad el
equipo de trabajo que desarrolle el sistema en cuestión.

De la investigación realizada queda la satisfacción de haber desarrollado un tema

relativamente nuevo con pocos precedentes anteriores. Como investigaciones futuras se
propone continuar con un estudio que permita definir y ampliar el enfoque del Diseño
Centrado en Usuario mediante pautas estándar para los distintos tipos de software.
Referencias
[Ferré, 05] X. Ferré, Tesis doctoral: “Marco de la Integración de la Usabilidad en el
Proceso de Desarrollo de Software”, Universidad Politécnica de Madrid, 2005.
[Floría, 02] A. Floría, Recopilación de Métodos de Usabilidad. SIDAR. Disponible en:
http://www.sidar.org/recur/desdi/traduc/es/visitable/Herramientas.htm
[Gediga, 99a] G. Gediga, K. Hambor, I. Düntsch: Evaluation of software systems. Institut
für Evaluation und Marktanalysen Brinkstr, 19 49143, Jeggen, Germany. School of
Information and Software Engineering University of Ulster Newtownabbey, BT 37 0QB,
N. Ireland (1999).
[Hassan, 04] Y. Hassan, Arquitectura de la Información en los entornos virtuales de
aprendizaje. Aplicación de la técnica de Card Sorting y análisis cuantitativo de los
resultados. En: El Profesional de la Información, marzo-abril, v. 13, n. 2, pp. 93-99, 2004.
[Hassan, 04] Y. Hassan, F. Fernández, G. Iazza, Diseño Web Centrado en el Usuario:
Usabilidad y Arquitectura de la Información. "Hipertext.net", núm. 2, 2004. ISSN 1695-
5498.
[Hernández, 98] Metodología de la investigación. 2da Edición. DF., México : McGraw
Hill, 1998.
[Hex, 93] D. Hex, H. R. Hartson. Developing User Interfaces: Ensuring Usability Through
Product and Process, John Wiley and Sons, New York (NY), USA, 1993.
[ISO, 98] ISO 9241-11:1998 Ergonomic requirements for office work with visual display
terminals (VDTs), Part 11: Guidance on usability, 1998.
[ISO, 99] ISO, ISO 13407, Human-Centred Design Processes for Interactive Systems, ISO,
Geneva (Switzerland), 1999.
[Ley 18.469, 2004]. Ley 18.469: Prestaciones de Salud, 2004 última revisión. Encontrado
en http://www.rsc-chile.cl/legislacion/Ley18.469%20Prestaciones%20de%20Salud.pdf
[Lorés, 01] J. Lorés, T. Granollers, S. Lana, Introducción a la Interacción Persona-
Ordenador, en La Interacción Persona-Ordenador. Ed. Por J. Lorés. AIPO, 2001.
[Mayhew, 99] D. Mayhew, the Usability Engineering Lifecycle, Morgan Kaufmann, San
Francisco (CA), USA, 1999.
[Nielsen, 93] J. Nielsen, Usability Engineering, AP Professional, Boston, USA, 1993.
[Nielsen, 92] J. Nielsen, “The Usability Engineering Life Cycle”, IEEE Computer, Vol. 25
nº3, march 1992.
[Price, 94] J. Price, Y. Rogers, H. Sharp D. Benyon, S. Holland, T. Carey, Human-
Computer Interaction. Addison Wesley, Harlow, England, 1994.
[Rauch, 96] T. Rauch, C. Soderston y G. Hill, Defining a User-Centered Design Process.
En Proceedings of the 1996 Annual Conference of the Society for Technical
Communication, 1996.
[Rusu, 07] C. Rusu, Apuntes del Curso: “Human Computer Interaction”, Pontificia
Universidad Católica de Valparaíso, Chile, 2007.
[Swebok, 04] IEEE Computer Society Professional Practices Comité. “Guide to the
Software Engineering Body of Knowledge – 2004 Version”. IEEE Computer Society, Los
Alamitos (CA), USA, 2004.
[Tramullas, 92] J. Tramullas’, Propuestas de análisis de usabilidad para sedes Web. En:
Workshop Contenidos y Aspectos Legales en la Sociedad de la Información. Valencia:
Universidad Politécnica de Valencia, 2002.
[Vredenburg, 02] K. Vredenburg, A Survey of User-Centered Design Practice. En:
Proceedings of the SIGCHI Conference on Human Factors in Computing Systems:
Changing Our World, Changing Ourselves. New York: ACM, 471-478, 2002.

Anexo A Estándar ISO 13407

En este anexo se detallan las cláusulas más relevantes del estándar ISO 13407.

El estándar ISO 13407 (ISO 13407 Standard. Human-Centred Design Processes for
Interactive Systems) [6] provee de una guía sobre las actividades de Diseño Centrado en el
Usuario, a través del ciclo de vida de Sistemas Interactivos basados en computadora. Se
ocupan tanto componentes Software como Hardware.

En su cláusula 4 el estándar perfila las razones para adoptar un proceso DCU. Identifica un
proceso de ese estilo con la producción de un sistema más usable, y detalla las ventajas de
un producto desarrollado así:

Es más fácil de entender y usar, por tanto reduciendo los costes de formación y
soporte,
 Mejora la satisfacción del usuario y reduce la incomodidad y el estrés,

Mejora la productividad de los usuarios y la eficiencia operacional de las

organizaciones, y

Mejora la calidad del producto, atrae a los usuarios y puede aportar una ventaja
competitiva.

Este enfoque se caracteriza por lo siguiente:

La implicación activa de usuarios y una clara comprensión de los requisitos de

usuarios y sus tareas,

Una adecuada asignación de funciones entre usuarios y la tecnología,

La iteración de soluciones de diseño, y

El diseño multidisciplinar.

Este estándar no cubre todas las actividades necesarias para asegurar un diseño efectivo. Es
un complemento a métodos de diseño existentes y propone una perspectiva centrada en el
usuario que puede ser integrada en distintas formas de procesos de diseño de una forma
adecuada al contexto en particular. Cabe destacar, que la incompletitud del enfoque se
traduce en una desventaja respecto a su aplicación, causando problemas en su aplicación y
por ende, un incremento en la desconfianza de los desarrolladores a la hora de aplicar dicho
enfoque.

En su cláusula 6 el estándar define directrices para planificar un proceso DCU. Dicho plan
especifica como encajan las actividades centradas en el usuario en el proceso de desarrollo
general del sistema. Según este estándar, un plan del proceso de DCU debe identificar las
actividades del desarrollo, las responsables de cada actividad y su rango de capacidades,
procedimientos efectivos para establecer retroalimentación y comunicación en actividades
de DCU cuando afectan a otras actividades, hitos para las actividades DCU, y escalas de
tiempo apropiadas para permitir retroalimentación y cambios de diseño a incorporar en la
planificación del proyecto. Este plan de proceso de DCU debe ser parte del plan de
proyecto del desarrollo general del sistema.
Las actividades de DCU que deben realizarse durante un proyecto de desarrollo de un
sistema se muestran en la Figura 1. El proceso debe comenzar en la etapa más temprana del
proyecto (por ejemplo, cuando el sistema se está formulado), y debe ser repetido
iterativamente hasta que el sistema cumpla los requisitos.

La necesidad de un enfoque DCU debe identificarse a partir de los objetivos operacionales

del sistema, por ejemplo, satisfacer los requisitos de usabilidad del cliente.

Cuando se planifica un proyecto, la descripción de cada actividad y sus subtareas debe

estudiarse y usarse como guía para diseñar o seleccionar los métodos y técnicas DCU para
llevar a cabo la actividad, y documentar progreso y resultados. El esfuerzo dedicado y la
importancia relativa de cada actividad dependerán del tamaño y tipo del producto a
desarrollar.

A continuación se describen las actividades de Diseño Centrado en el Usuario que detalla el

estándar 13407[6]:

Comprender y especificar el contexto de uso: el contexto de uso del que se ocupa esta
actividad debe identificarse según lo siguiente:

Las características de los usuarios previstas.

Las tareas que los usuarios realizarán, incluyendo los objetivos generales de uso del
sistema. El estándar menciona que las tareas no deben ser descritas únicamente en
base a las funciones o funcionalidades previstas por un producto o sistema.

El entorno en el que los usuarios usarían el sistema: Hardware, Software y materiales

que se van a utilizar.

También debe incluir las características relevantes del entorno físico y social. La salida de
esta actividad debe ser una descripción de las características relevantes de los usuarios,
tareas y entorno que identifican los aspectos que tienen un impacto importante en el diseño
del sistema.

Especificar los requisitos organizacionales y del usuario: extiende la actividad

tradicional de requisitos para crear una declaración explícita de los requisitos de usuario y
organizacionales en relación a la descripción del contexto de uso. Para definir estos
requisitos hay que considerar los siguientes aspectos:

Rendimiento requerido para el nuevo sistema según los objetivos financieros y

operacionales.

Requisitos estatuarios o legales de relevancia.

Cooperación y comunicación entre usuarios y otras partes relevantes.

El trabajo de los usuarios (incluyendo la asignación de tareas, el bienestar de los

usuarios y su motivación).

Rendimiento de tareas.

Diseño del trabajo y organización.

Gestión del cambio, incluyendo la formación y el personal involucrado.

Viabilidad de la operación y mantenimiento.

La interfaz humana computador y el diseño de las estaciones de trabajo.

La especificación debería definir también la asignación de funciones: la división de las

tareas del sistema entre aquellas realizadas por humanos y aquellas realizadas por la
tecnología.

Producir soluciones de diseño: el proceso de producir soluciones de diseño implica las

siguientes actividades:

Usar el conocimiento existente para desarrollar propuestas de diseño con entrada

multidisciplinar.

Hacer más concretas las soluciones de diseño utilizando simulaciones, modelos,

maquetas (mock-ups), etc. Es decir, se refiere al uso de cualquier tipo de prototipo.

Presentar las soluciones de diseño a los usuarios y permitirles realizar tareas (o tareas
simuladas).

Alterar el diseño en respuesta a la retroalimentación de los usuarios e iterar este

proceso hasta que los objetivos de DCU se cumplan.
 Gestionar la iteración de soluciones de diseño. Consiste en registrar los resultados de
las 4 actividades anteriores en una documentación que incluiría las fuentes de
conocimiento existente o estándares utilizados, los pasos tomados para asegurar que
el prototipo cubre requisitos clave y siguen buenas prácticas, y la naturaleza de los
problemas encontrados y los subsiguientes cambios realizados al diseño.

Evaluar diseños contra requisitos: la evaluación es un paso esencial en el DCU, y debe

realizarse en todas las etapas del ciclo de vida del sistema. Se puede utilizar la evaluación
para obtener retroalimentación, la cual puede usarse para mejorar el diseño, para evaluar si
los objetivos del usuario y organizacionales se han alcanzado, y para observar el uso a largo
plazo del producto o sistema. Cuando más cerca se está del comienzo del desarrollo, más se
centran las actividades de evaluación en el desarrollo, cuando ya se tiene un prototipo
completo, se pueden realizar evaluaciones contra los objetivos de usuario y
organizacionales.

Se debe confeccionar un plan de evaluación que identifique:

Los objetivos de DCU.

Quién es responsable de la evaluación.

Qué partes del sistema se van a evaluar y cómo.

De qué forma se van a realizar las evaluaciones y los procedimientos para llevar a
cabo las pruebas.

Los recursos necesarios para la evaluación, análisis de los resultados y acceso a los
usuarios.

La planificación de actividades de evaluación en relación a la planificación del

proyecto.

La retroalimentación y utilización de los resultados en otras actividades de diseño.

La evaluación puede utilizarse para:

Demostrar que un diseño particular cumple los requisitos centrados en el usuario.

 Evaluar conformidad a estándares estatuarios, corporativos, locales, nacionales e
internacionales.

Los resultados de evaluación deben ser registrados de forma sistemática.

El estándar detalla los temas relativos a cada tipo de informe de evaluación: informe de
retroalimentación al diseño, informe de pruebas del diseño contra estándares específicos, e
informe de pruebas con usuarios.

En forma de análisis, podemos concluir que este estándar no es suficientemente detallado

como para ser directamente aplicado por una organización de desarrollo de Software, pues
no especifica técnicas para todas las actividades. Nombra el prototipado en la producción
de soluciones de diseño, y nombra también técnicas de evaluación de usabilidad, pero no
menciona ninguna técnica para la comprensión y especificación del contexto de uso, ni para
la especificación de requisitos de usuario y organizacionales. En estas dos últimas
actividades únicamente se describe qué debe incluir la especificación del contexto de uso y
la especificación de requisitos del usuario y organizacionales, respectivamente. En la
cláusula inicial de ámbito ya se indica que el estándar no ofrece cobertura detallada de los
métodos y técnicas requeridos para el DCU.

En cuanto a la integración de las actividades de usabilidad con el resto de actividades del

desarrollo, el estándar indica que hay que definir para cada proyecto cómo se integran
ambos tipos de actividades. Sin embargo, únicamente nombra una actividad tradicional, la
de especificación de requisitos, que se dice que se extiende con los requisitos de usuario y
organizacionales. No hay mas referencias a actividades tradicionales de la IS. Por tanto, se
presenta como descriptor de las actividades complementarias a procesos de desarrollo
existentes, pero deja la integración de ambos tipos de actividades como tarea a resolver casi
completamente por la organización de desarrollo de Software que desee aplicar practicas de
usabilidad en su proceso.

Anexo B Técnicas de Evaluación de Usabilidad

En el siguiente anexo se encuentra la descripción sobre la base de la Referencia básica de la
propuesta de Xavier Ferré, de cada una de las técnicas de evaluación de usabilidad según su
orden alfabético.

1. Análisis competitivo

Se trata de analizar heurísticamente productos existentes y realizar Test de usabilidad

empíricos con estos productos.

Descripción: Tomando un producto de la competencia como un prototipo, podemos

evaluarlo para ver si consigue los objetivos de usabilidad establecidos para nuestro propio
sistema.

En particular, podemos analizar heurísticamente productos existentes, y podemos realizar

test de usabilidad con usuarios. Un producto de la competencia, como ya está
implementado totalmente puede ser probado fácilmente.

Si vamos a analizar más de un producto de la competencia, podemos realizar un análisis

comparativo de las diferentes soluciones para conseguir los objetivos del usuario.

Esto proporcionará ideas para el sistema que estamos desarrollando, especialmente para
desarrollar el concepto de producto. También puede darnos una visión sobre cosas que
pueden funcionar, y cosas que se deben evitar.

El análisis competitivo implica básicamente el estudiar de productos existentes para

descubrir sus cualidades y deficiencias. Los productos analizados pueden ser productos de
la competencia, pero pueden también ser otros productos de diversos campos que traten
temas parecidos a los que nuestro sistema debe implementar.

Los productos comerciales que son famosos, sirven como buenas referencias para
establecer el concepto del producto, y un análisis competitivo de sus ventajas desde el
punto de vista de la usabilidad, pueden ayudar a enfocar la discusión y el procedimiento de
toma de decisión.
Aplicación: Cuando el análisis competitivo se utiliza para conseguir niveles previstos en
las especificaciones de usabilidad, el test de usabilidad se realiza con productos de la
competencia para medir valores en benchmarks.

Cuando se usa para desarrollar el concepto del producto, el análisis competitivo implica
realizar una evaluación heurística de los productos software existente para identificar sus
principales cualidades y deficiencias, y para identificar las soluciones más valiosas para el
usuario.

Estas soluciones o ideas del diseño se pueden revisar para decidir a si son apropiados para
el sistema que vamos a desarrollar.

Participantes:

Desarrolladores.

Usuarios: Pueden decirnos productos que identifican como muy usables y/o útiles,
como candidatos a análisis competitivo. Enseñar productos existentes a los usuarios
puede ayudar también a enfocar la discusión, pues estará basada en productos
tangibles en vez de abstracciones.

2. Análisis de Impacto

Se trata de encontrar problemas de usabilidad y luego volver a ver las cintas de video para
investigar exactamente cuántos usuarios tuvieron cada problema de usabilidad y cuanto
retraso sufrieron por cada problema.

Pueden ser usados para priorizar los arreglos de los problemas de usabilidad en un rediseño.

Descripción: Análisis de Impacto o Análisis de Coste / importancia es una técnica para

decidir entre distintas opciones de diseño, relacionando las opciones con los problemas de
usabilidad y escogiendo la opción que tiene los problemas de usabilidad más importantes.

Se realiza una vez que tengamos un conjunto de problemas de usabilidad identificados en

cualquier clase de actividad de la evaluación de usabilidad.
Para cada problema de usabilidad, podemos proponer distintas opciones de diseño, y usar el
análisis de impacto para dar prioridades a estas opciones y enterrar así posibles esfuerzos de
rediseño. Es una técnica para hacer los procedimientos necesarios en cualquier proceso del
diseño, que se basan, en este caso, en los problemas de usabilidad.

Aplicación: En un análisis de impacto, el equipo de desarrollo tiene en cuenta la

importancia relativa de los problemas de usabilidad encontrados y el coste de las
soluciones, tal y como están representadas en la tabla siguiente:
de

Efecto en el
rendimiento del Importancia Solución Coste Resolución
usabilidad
Problema

usuario

Posicionar las ventanas

Demasiada
10 de 35 automáticamente, pero
manipulación de Alta 6 horas
minutos permitir al usuario
ventanas
reposicionarlas

Invertir el color de la
Flecha negra en
No Disponible Baja flecha a blanco cuando se 1 hora
fondo negro
posicione sobre el negro

Realmente, el análisis del impacto comienza una vez que todas las columnas excepto la
columna de la resolución se hayan terminado para cada problema observado. Dependiendo
del número de las opciones de diseño que se han tomado en consideración, las herramientas
se pueden utilizar para la toma de decisión adecuada, tal y como se representa gráficamente
en la tabla anterior.

En principio, los problemas realmente importantes se deben abordar primero, pero el

equipo del desarrollo debe también considerar los recursos asignados para la actividad de
diseño y actuar en consecuencia. El proceso de decidir entre las mejoras del diseño que
necesiten realizarse no es fácil, y toda esto proporciona la información de una manera
estructurada de modo que el equipo del desarrollo pueda tomar una buena decisión.

Participantes:

Desarrolladores, y usuarios si participaron en el proceso de diseño.

3. Árboles de Menús

Representan la estructura de árbol en la que está organizado un sistema de menús,

mostrando las relaciones entre los distintos elementos de la jerarquía.

Descripción: En un sistema basado en menús, los árboles de menús representan la

estructura de la navegación del menú.

Los árboles del menú son una herramienta de especificación muy útil, puesto que
demuestran a usuarios y a otros implicados la funcionalidad completa y detallada del
sistema.

Como cualquier mapa, un árbol del menú muestra relaciones de alto nivel y los detalles de
niveles más bajos.

Podríamos decir lo mismo de los cuadros de diálogo (dialog boxes): Si pintamos los
cuadros de diálogo y sus relaciones en una cartulina y las colgamos de una pared
obtendremos una descripción completa del sistema y podremos comprobar su consistencia.

Aplicación: Cuando no podemos crear un esquema de la interacción basado en la

manipulación directa (como en la idea de escritorio en los sistemas operativos del Mac y de
Windows), podemos utilizar selecciones del menú. Si se escriben usando terminología
familiar y se organizan los elementos de menú en una estructura y una secuencia
convenientes, los usuarios podrán escoger un elemento de menú fácilmente. Cuando una
lista de elementos de menú crece y es difícil memorizarla, los diseñadores pueden formar
categorías de elementos similares, creando una estructura arborescente.

Los árboles del menú representan esta estructura:

En sistemas grandes, el árbol del menú quizá tenga que ser mostrado en una pared o un piso
grande, pero es importante poder ver la estructura entera de una vez, e ir mirando si hay
consistencia, completitud, y carencia de ambigüedades o de redundancias.

Es difícil agrupar elementos de menú en un árbol de modo que sean comprensibles a los
usuarios y encajen con la estructura de la tarea a realizar.

Los problemas que podemos encontrar incluyen categorías solapadas, elementos de menú
extraños, clasificaciones que están en conflicto en el mismo menú, jerga desconocida, y
términos genéricos.

Los miembros del equipo de desarrollo pueden discutir todas estas cuestiones mientras
miran la estructura arborescente completa representada en árbol de selección de menús.

Los sitios Web que se organizan en una estructura altamente jerárquica se pueden
representar fácilmente por medio de menús del árbol.

La siguiente figura muestra los elementos de menú de un sitio Web.

Fig. 53. Ejemplo de Árboles de Menú.

Participantes

Desarrolladores.
 Usuarios que puedan participar en la reunión sobre las distintas alternativas del árbol
de menús.

4. Card Sorting

Esta técnica permite comprender la representación de información que manejan los

usuarios.

Consiste en pedir a los usuarios que agrupen una serie de conceptos del dominio, para
obtener como resultado una agrupación representativa del modelo del dominio que tiene el
usuario en la cabeza.

Cada concepto se escribe en una tarjeta, y se pide al usuario que organice las tarjetas en
pilas.

Descripción: Al principio de cualquier diseño de la arquitectura de un sistema de

información, es frecuente enfrentarse a una lista muy larga de temas susceptibles de ser
incluidos en el diseño.

El reto es organizar esta información de una manera que sea útil y significativa para los
usuarios del sistema.

La investigación y el análisis cuidadoso de la información pueden revelar algunas pistas,

sin embargo, si hacemos colaborar a los usuarios, el organizar estos temas puede ser más
rentable. Así, el Card Sorting consiste en pedir que los usuarios categoricen una lista de
términos.

Es útil cuando ya existe la lista de temas.

Aplicación: El "Card Sorting" es muy similar a los diagramas de afinidad, pero está
dirigido al diseño de la estructura de un sistema de información (Ej.: un sitio Web, o un
árbol de menús).

Al crear la lista de temas debemos tener en cuenta algunas consideraciones:

La longitud de la lista debe ser manejable.

 No se deben mostrar estructuras existentes.

No exponer ideas que conduzcan a los usuarios a solucionar asuntos de una forma
específica.

Que cada asunto no debe ser demasiado general ni demasiado específico.

Los asuntos elegidos deben ser significativos para los participantes en la sesión.

Primero debemos crear las tarjetas (cards), y después seleccionar a los participantes. Deben
ser los usuarios finales reales del sistema que se está construyendo. Si el participante es el
jefe del usuario en vez del usuario final, los resultados no reflejarán un modelo mental que
sea natural al usuario final. Cada sesión se debe dedicar a un grupo homogéneo de usuarios.
Si se hace participar a varios grupos de usuarios, se debe hacer una sesión de "Card
Sorting" diferente para cada grupo. En la sesión de "Card Sorting" se debe explicar a los
participantes cuidadosamente la mecánica y el resultado previsto de la sesión. Después,
pediremos a los participantes que organicen las tarjetas de una manera que tenga sentido
para ellos. Cuando acaben el agrupamiento, pida que etiqueten cada categoría con una
tarjeta. Se puede permitir una agrupación "por determinar" o "no estoy seguro", pero no
debe decírselo al principio de la sesión.

Utilice un cuaderno para tomar notas sobre cualquier acontecimiento importante que se
presente durante la sesión:

Preguntas del usuario del usuario.

Comentarios del usuario o sugerencias.

Comportamientos no-verbales del usuario

Considere que una sesión de "Card Sorting" no produce un diseño terminado, es sólo una
pista elaborada, que es muy útil porque se ha construido según las expectativas del usuario.

Participantes:

Desarrolladores.

Usuarios.
5. Casos de Uso Esenciales

En un nivel más alto de abstracción, los casos se definen en términos de intenciones de

usuario y responsabilidades del sistema, sin tener en cuenta la tecnología usada y la
implementación.

Se pueden usar junto con los casos de uso al principio del proceso de desarrollo, sin tener
que tomar demasiadas decisiones sobre detalles de la interfaz de usuario.

El mapa de casos de uso separa la funcionalidad total del sistema en una colección de casos
de uso esenciales interrelacionados entre sí.

Con "esenciales" queremos hacer referencia a la abstracción empleada en la descripción de

los casos de uso, no para especificar los detalles de la interfaz.

Además, esto se aplica a todos ellos, no solo a un conjunto particular de casos de uso
especialmente importantes.

6. Cuestionarios, Entrevistas y Encuestas

Son métodos indirectos para estudios de la interfaz de usuario, porque proveen al equipo de
desarrollo de la opinión de los usuarios, y no información directa de la interfaz de usuario.
Se usan para obtener la satisfacción subjetiva del usuario. Los cuestionarios se pueden
enviar por correo ordinario, correo electrónico o con el propio software.
Las entrevistas se pueden conducir personalmente o por teléfono.

x Cuestionarios: Para obtener información de un número más amplio de usuarios se

pueden elaborar, distribuir y analizar cuestionarios estructurados que incluyen
preguntas sobre la usabilidad del producto.

x Entrevistas: Llevar a cabo entrevistas para obtener las reacciones subjetivas de los
usuarios.
x Encuestas: Los cuestionarios se pasan a grupos de muchas personas.

Esta técnica se propone para el caso de tener que organizar las notas obtenidas de una serie
de entrevistas contextuales, realizadas por varios observadores en distintas sesiones.

La técnica consiste en que cada observador anota en un Post-It cada una de las
observaciones que va recogiendo de la observación de los usuarios en su entorno habitual
de trabajo. Cuando se reúnen todos los observadores, van poniendo sus notas en una pared
blanca grande, de una en una, agrupando juntas las notas que parecen estar relacionadas.

Según se van añadiendo notas el grupo va reagrupando las notas según criterios en los que
esté de acuerdo todo el grupo. Se presenta como paso de organización de ideas, previo a
sesiones tipo tormenta de ideas (brainstorming).

7. Diagramas de Transición de Estados de la Interfaz

En este tipo de diagramas los nodos representan estados de la interfaz o pantallas, y los
arcos representan transiciones de estado basadas en las entradas.

Estos diagramas pueden usarse para complementar las representaciones UAN, indicando
secuenciamiento e información de estado o modo.

8. Escenarios de Tareas

Los escenarios de tareas son instancias de casos de uso que representan las tareas del
trabajo en la vida real.

Se elaboran estos escenarios para las tareas más representativas de cada tipo de usuario.

No hace falta que correspondan exactamente con una tarea concreta que se haya observado
en las entrevistas contextuales, pues un escenario puede incorporar los aspectos más
interesantes de varias tareas reales combinados.

9. Escenarios y Storyboards

Un escenario es una historia de ficción, personalizada con personajes, eventos, productos y

entornos.
Las instantáneas son imágenes visuales individuales (normalmente tipo cómic), que
capturan una posible acción significativa.

Los Storyboards son secuencias de instantáneas que se centran en las principales acciones
en una posible situación.

10. Especificaciones de Usabilidad

Son metas cuantitativas de usabilidad, que se usan como guía para saber cuándo una
interfaz es suficientemente buena.

Las especificaciones pueden ser basadas en medidas objetivas o subjetivas.

Las medidas objetivas se asocian normalmente a tareas de benchmark, mientras que las
subjetivas se asocian normalmente con cuestionarios de usuario.

11. Evaluación Heurística

La evaluación heurística se hace observando un interfaz de usuario e intentando obtener

una opinión sobre qué es bueno y malo del interfaz.

Es mejor tener varios evaluadores para evaluar el mismo diseño de forma independiente,
pues descubren muchos más errores que un solo evaluador.

Lo ideal es que sean especialistas de la usabilidad los que realicen la evaluación heurística.

Un tipo particular de evaluación heurística es el Recorrido Pluralístico.

12. Guía de Estilo del Producto

Este documento recoge el Modelo Conceptual (esto es, reglas de presentación) y los
estándares de diseño de pantallas.

Organiza en un único documento todas las decisiones de diseño de la IU con el objetivo

principal de conseguir la consistencia en la IU de todo el producto.

Puede establecerse a varios niveles:

 Plataforma

Organización

Familia de productos

Un producto particular

Es útil que además de las decisiones de diseño incluya la lógica que ha motivado dichas
decisiones para permitir futuros cambios.

12. HTA (Hierarchical Task Analysis)

Se trata de un método clásico de análisis de tareas, según los autores es uno de los más
conocidos.

Implica un proceso iterativo de identificación, categorización y descomposición de tareas

en subtareas, junto con la comprobación de la precisión de tal descomposición.

Se divide en tres etapas:

Inicio

Progreso

Finalización

Para la representación gráfica de la descomposición utiliza los diagramas de estructuras.

Estos diagramas muestran la secuencia de actividades ordenándolas de izquierda a derecha;

las actividades que se pueden repetir se marcan con un asterisco dentro de la caja, y cuando
hay una elección entre un número de actividades éstas se marcan con un pequeño círculo
dentro de la caja.

13. Información Post-Test

Se puede planificar una recogida de información del participante una vez realizado el test
de usabilidad.
En esta tipo de entrevistas normalmente se agradece la participación y se le recuerda que su
aportación es muy importante y sirve para mejorar el software.

Se trata de compaginar un test de usabilidad con medida del rendimiento del usuario (por
tanto, con medición del tiempo que emplea en cada tarea), con recogida de información
sobre el razonamiento seguido por el usuario.

Esta técnica es alternativa a la de Pensar en Voz Alta cuando ésta no se puede aplicar por la
medición del rendimiento.

14. Inspecciones

En el desarrollo de software el objetivo de una inspección es encontrar defectos. Las

inspecciones de usabilidad tienen por objetivo descubrir defectos de usabilidad. Se trata de
un proceso sistemático, frente a la evaluación heurística que no tiene un proceso
establecido.

Hay dos tipos de inspecciones de usabilidad:

Inspecciones de conformidad (con una guía de estilo, o un estándar): En las

inspecciones de conformidad, los participantes inspeccionan el diseño de la
interacción del sistema para comprobar que si cumple lo estipulado en determinados
estándares o guías de estilo. Todos los participantes deben estar familiarizados con
los estándares o guías sobre los que se evalúa.

Inspecciones de consistencia: En las inspecciones de consistencia, el objetivo consiste

en identificar inconsistencias entre contextos de interacción y sus contenidos. El
evaluador intenta encontrar inconsistencias en terminología, color, disposición,
formatos de entrada y salida de datos, etc. Cuando el producto pertenece a una familia
de productos, se juntan representantes de los distintos equipos de diseñadores para
inspeccionar la consistencia entre los productos de la familia.

15. Inspecciones Colaborativas

Las inspecciones colaborativas son una variante de las inspecciones de usabilidad, en la que
participan todas las partes involucradas. Se trata de un procedimiento estructurado para
promover la participación del usuario en el proceso de inspección. Un rol especial en el
equipo puede ser el revisor de continuidad, que tiene una responsabilidad especial en la
identificación de inconsistencias.

Los miembros del equipo de desarrollo que participan en el proceso de inspección tienen
prohibido defender, explicar o racionalizar ningún aspecto de su diseño o las decisiones que
le han llevado a él. Además, los desarrolladores deberían evitar hacer promesas implícitas a
los usuarios. Las aportaciones de los usuarios deberían tener un peso especial en el proceso
de inspección, aunque sin permitir que dicten decisiones de diseño de la interacción.

El facilitador de la reunión debería alentar la participación de los usuarios y protegerles de

las críticas o de preguntas de carácter antagónico por parte de los desarrolladores. Los
usuarios y los expertos en el dominio deberían considerarse autoridades, pero no árbitros.

16. Investigación Contextual

Es una forma de obtención de información que se puede utilizar en la evaluación.

Los usuarios y los investigadores participan para identificar y para entender problemas de
la utilidad dentro del entorno de trabajo normal del usuario.

17. JEM (Joint Essential Modelling)

Es un proceso estructurado para colaborar con los usuarios para desarrollar especificaciones
de requisitos centradas en la usabilidad a través de modelado concurrente. Se asemeja a su
antepasado JAD (Joint Application Design).

Las actividades realizadas en JEM son:

Pre-modelado y consolidación.

Modelado de roles.

Modelado de tareas.
 Auditoria del modelo.

Ubicación de características.

18. Mapa de Roles de Usuario

Los roles de usuarios y sus relaciones se representan por medio de un Mapa de Roles
de Usuario.

Captura la visión general de los usuarios del sistema.

Las relaciones que se representan pueden ser de afinidad, clasificación o de

composición.

19. Mapa de Navegación entre contextos

Representa la arquitectura general de la Interfaz de Usuario modelando las relaciones entre

contextos de interacción.

Cada contexto se representa con un rectángulo y las flechas que los conectan representan
posibles transiciones entre un espacio de interacción y otro.

20. Medición del Rendimiento

La medición del rendimiento en un test de usabilidad se realiza para evaluar si los

requisitos de usabilidad establecidos previamente se han alcanzado. También puede usarse
para realizar comparaciones con productos competidores. Esta técnica se aplica con un
grupo de usuarios a los que se les pide realizar una seria de tareas de referencia, midiéndose
durante su realización el tiempo empleado y el número de errores.

Pasos a realizar para realizar un test de usabilidad:

Seleccionar participantes: Debe ser una muestra representativa de la población de

usuarios objetivo. La selección se puede realizar basándose en los resultados del
análisis de usuarios.

Establecer las tareas a emplear en el test: Deben ser las tareas que aparezcan en las
especificaciones de usabilidad, más otras tareas que se consideren representativas.
 Escribir las instrucciones que el participante debe seguir para llevar a cabo cada tarea.

Definir el plan de test (protocolo y el procedimiento para el test): Es conveniente

preparar un comentario introductorio dirigido a los participantes.

Realizar unos pocos test pilotos.

Refinar el plan de test (procedimiento, expresión de las instrucciones para el

participante).

Llevar a cabo la sesión de test.

Pedir a los participantes que lleven a cabo las tareas.

Si se está midiendo el rendimiento: Medir el tiempo empleado.

Si no se está midiendo el rendimiento: Interrumpir al usuario para preguntar cuando

se necesite.

Anotar el número de errores en cada tarea.

Darles un cuestionario de satisfacción cuando terminan.

Analizar los datos recogidos.

Presentar los resultados al equipo de desarrollo y/o a dirección.

Se puede tener una entrevista post-test para recoger retroalimentación del usuario sobre qué
es lo que debería mejorarse en el sistema.

21. Modelo del Contenido de la Interfaz

Es una representación abstracta de los contenidos de los distintos espacios de interacción de

un sistema.

El contenido se puede modelar por medio de papel (una hoja por cada espacio de
interacción) y Post-Its que representan las herramientas y materiales que se van a ofrecer al
usuario.

22. Observación Etnográfica

Como los usuarios de interfaces son una única cultura, los métodos etnográficos para
observarles en su lugar de trabajo son cada vez más importantes.

Como etnógrafos, los diseñadores de interfaces de usuario se fijan en el comportamiento

individual y el contexto organizativo.

23. Organización de la Ayuda según Casos de Uso

Si los casos de uso esenciales se han construido bien, reflejarán cómo piensan los usuarios
y cómo organizan su trabajo.

Cada caso de uso se convierte en una sección en manual de usuario.

24. Pensar en Voz Alta

Tal y como menciona Nielsen en sus técnicas, es un caso especial de protocolo verbal, en el
cual el usuario dice en voz alta lo que piensa mientras realiza una tarea o resuelve un
problema.

Nielsen distingue el pensamiento en voz alta de otras técnicas de usabilidad precisando que
puede ser el método de ingeniería de usabilidad más valioso.

Una prueba de pensamiento en voz alta implica el tener a un participante usando el sistema
mientras que piensa en voz alta. Su efectividad está en datos cualitativos y no en medidas
de funcionamiento.

La idea es conseguir la opinión del usuario mientras usa el sistema para evitar posteriores
racionalizaciones.

25. Perfiles de Usuario

Los perfiles de usuarios describen a los usuarios previstos del sistema, según las siguientes
características:

Características psicológicas (por ej. actitud, motivación)

 Conocimiento y experiencia (por ej. velocidad de mecanografiado, experiencia en la
tarea)

Características del puesto y de las tareas (por ej. frecuencia de uso, estructura de
tareas)

Características físicas (por ej. daltonismo)

Para cada usuario se incluye una descripción general, una descripción de las características
de los usuarios, y un apartado sobre los requisitos de usabilidad para ese tipo de usuario.

26. Personas

Esta técnica ayuda a sintetizar todos los datos de que se dispongan sobre los usuarios
previstos del sistema, en unos usuarios arquetípicos que puedan usarse para alcanzar
consenso en el equipo de desarrollo y para centrar las discusiones de diseño. Ayuda
también a determinar qué es lo que el producto debe hacer, relacionado con las necesidades
a satisfacer, por lo que puede contribuir a todo el proceso de análisis y negociación de
requisitos. Al proveer un lenguaje común para referirse a los usuarios concretos del sistema
(concreto, frente al término genérico y a menudo equívoco "usuarios del sistema"), ayuda a
alcanzar consenso en el equipo de desarrollo. En concreto, evita un problema típico entre
un cierto número de desarrolladores:

El identificar las capacidades y querencias de los futuros usuarios del sistema con las
propias (del desarrollador), conduciendo este tipo de actitud a la producción de sistemas
software que únicamente usuarios con marcado perfil tecnológico pueden usar.

27. Prototipos de Papel

Los prototipos permiten al desarrollador comunicarse con mayor efectividad con los
usuarios y clientes. Necesitamos construir prototipos porque las especificaciones técnicas
abstractas no son un buen medio de comunicación cuando queremos implicar a los usuarios
en el proceso de desarrollo.

El prototipado está estrechamente ligado al desarrollo iterativo. Los prototipos pueden

usarse para probar ideas de diseño con los usuarios para obtener su retroalimentación. Con
este fin, los prototipos menos costosos (de papel), son suficientes. Los prototipos de papel
son útiles para obtener opiniones del usuario mejor que los prototipos que se asemejan al
sistema final, pues al confrontarse con un trabajo con un buen acabado, muchos usuarios
pueden convencerse erróneamente de que esa es la única o la mejor solución al problema
planteado.

Los prototipos de papel cuentan con la ventaja de que son mucho más baratos de elaborar
que los prototipos software, a no ser que se disponga de una herramienta de prototipado
rápido.

28. Recorrido Cognitivo

En un Recorrido Cognitivo, el grupo avanza lentamente a través de la tarea de un escenario,

haciendo para cada acción del usuario, un análisis detallado de sus intenciones, su
conocimiento, procesos mentales e interpretaciones. Hay que focalizar un único objetivo de
la usabilidad: "la facilidad de aprendizaje".

29. Recorrido Pluralístico

Esto es un proceso de colaboración que implica a usuarios finales, desarrolladores y

expertos en usabilidad, esperando que todos participen con el rol de usuario. La meta es
"empatías coordinadas".

30. Registro del Uso

Se trata de que el ordenador recoja automáticamente estadísticas sobre el uso detallado del
sistema. Es una manera de conseguir la información sobre el uso de un sistema después de
lanzamiento al mercado, pero puede también utilizarse como método adicional en pruebas
de usabilidad.

En la técnica:

La arquitectura del software debería hacer fácil a los jefes de sistema recolectar datos sobre
patrones de uso del sistema, velocidad de rendimiento del usuario, ratios de errores o
frecuencia de peticiones de ayuda on-line.
Registro del software (software logging). El registro del software tiene dos ventajas
principales:

No requiere que el investigador esté presente

Es discreto.

Hay dos tipos de Logging, que pueden combinarse uno con otro y también con
grabaciones de video. A continuación se explican:

Logging de interacción: Se graba la interacción completa, para poder ser reproducida

en tiempo real.

Registro de Pulsaciones en el Tiempo: Se registra cada tecla pulsada, junto con el

tiempo exacto del evento.

31. Retroalimentación del Usuario

La retroalimentación se puede obtener dando a los usuarios acceso a:

Direcciones especiales de correo electrónico

Grupos de noticias

Foros.

Los usuarios pueden de este modo enviar sus quejas o peticiones de cambio o mejora.

32. Test de Usabilidad en Laboratorio

En este tipo de test, en lugar de llevarle al usuario la interfaz, se trae al usuario a la interfaz.

Es decir, los participantes son llevados a unas instalaciones tipo laboratorio de usabilidad
donde llevan a cabo las tareas de referencia y todo lo asociado a un test de usabilidad.

33. Tormenta de Ideas Visual

Esto es una técnica de bocetos empleada para explorar diseños alternativos.

Después de hacer bocetos iniciales, las mejores ideas se pueden desarrollar más en
profundidad construyendo representaciones del diseño en cartulina, que pueden ser
evaluados por los usuarios.

Se puede continuar desarrollando escenarios, software o prototipos en video.

Anexo C Cuestionario Perfil de Usuario

En este anexo se presenta un cuestionario usado para indagar sobre los posibles perfiles de
usuario.

Cuestionario Perfil de Usuario

Proyecto Sistema de Remuneraciones Multiempresas

Sector correspondiente a la empresa donde trabaja.

__Contable __Logística __Servicio __Construcción

Nombre: _____________________________________________________________

Cargo en la Empresa: __________________________________________________

A. Características Generales

1.- Edad

__Menos de 30 años.

__Entre 31 y 40 años.

__Entre 41 y 50 años.

__Entre 51 y 60 años.

__Más de 60 años.

2.- Género:
__Femenino __Masculino

3.- Nivel Educativo:

__Básica __Media __Superior

4.- ¿Qué idioma prefieres?

__Ingles.

__Francés.

__Español.

__Portugués.

5.- ¿Necesitas gafas o lentes?

__SI __NO

6.- ¿Te gusta trabajar con Computadores?

__SI __NO

7.- ¿Cuál de estas aplicaciones sabes utilizar?

__Correo Electrónico.

__Internet.

__Microsoft Word.

__Microsoft Excel.

__Microsoft Access.

__Otros

(indicar):__________________________________________________________________
B. Características con el Estudio contable (Módulo Remuneraciones)

1.- ¿Hace cuánto tiempo trabajas en el Estudio Contable?

__Semanas __Meses __Años (indicar):__

2.- ¿Consideras que el proceso de cálculo de planillas se lleva a cabo con facilidad?

__SI __NO

3.- ¿Consideras que el proceso de la información de cada trabajador se lleva a cabo con
facilidad?

__SI __NO

4.- ¿Consideras que el proceso de la información de cada empresa se lleva a cabo con
facilidad?

__SI __NO

5.- ¿Consideras que el sistema anterior era sencillo de utilizar?

__SI __NO

Comentarios_______________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
________________________________________________________________________

6.- Dominio de los procesos: Marca con una X la afirmación más adecuada.

Actividad La realizo La realizo de a No la realizo

siempre veces

Liquidaciones de sueldo
mensual

Elaborar planillas de pago

previsional

Finiquitos

Contratos de trabajo

Nuevas disposiciones

Resumen anual de cada

trabajador

7.- ¿Para tu trabajo, qué cuales son las actividades más importante?

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________

8.- Según tu punto de vista ¿cuáles crees que son las razones por la que tu trabajo se ve
demorado? (si no tienes problemas con tu trabajo no respondas)

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________

Anexo D Evaluación Heurística

En el presente anexo se presenta el formato utilizado para las Evaluaciones Heurísticas
realizadas sobre las versiones del Sistema.

~ Evaluación heurística por evaluador:

Evaluación Heurística: Sistema Remuneraciones Multiempresas

Versión:
Listado de Tareas por Evaluador:

Principios Heurísticos:

x Visibilidad del Status del Sistema (tiempo de respuesta).

x Cruce entre el Sistema y el mundo real (hablar el lenguaje del usuario).

x Control y libertad para el usuario.

x Consistencia y Estándares.

x Prevención de errores.

x Reconocimiento en vez de volver.

x Flexibilidad y eficiencia del uso.

x Estética y diseño minimalista.

x Reconocimiento de la ayuda, diagnostico y recuperación de los errores. (Mensajes de

error).

x Ayuda y documentación.
Nota: Usar versiones superiores a la versión 5.5 de Internet Explorer.

1.- Ingrese al sistema con el siguiente perfil:

a) Usuario: 15097751-7

b) Clave: admin

2.- Nombre del Evaluador

3.- Problemas encontrados: Listado de problemas por evaluador

~ Recopilación de las evaluaciones de cada evaluador valorizadas según su criticidad:

Evaluación Heurística: Sistema de Remuneraciones Multiempresas

Nombre del Monitor:

Evaluadores:

1.- Listado Final de los problemas encontrados por cada evaluador.

2.- Análisis Heurístico Final

Número Problema Severidad Frecuencia Criticidad

3.- Posibles Mejoras

Anexo E Test de Usabilidad en Laboratorio

Los Test de usabilidad aplicados en el estudio consistieron en lo siguiente:

x Test de Usabilidad aplicado sobre el Sistema de Remuneraciones Multiempresas:

El test de usabilidad en laboratorio se compuso por un acuerdo de confidencialidad y el test

mismo, el cual tuvo el siguiente formato:

Acuerdo de Confidencialidad:

Yo____________________ Acepto a participar en una prueba de usabilidad supervisada

por _________________, el día __/__/__, en el Laboratorio de Usabilidad montado en las
dependencias de la empresa, en Avenida Isidoro Dubournais Nº 225 Tercer piso, El Quisco.
Entiendo y estoy de acuerdo con las condiciones mencionadas en adelante

Entiendo que el experimento se hace sólo para evaluar un sistema software, No mis
capacidades/habilidades/conocimientos.

Entiendo que los resultados del experimento se utilizaran sólo para propósitos académicos
y/o de investigación, sin que mi identidad sea revelada.

Entiendo que puedo comunicar al supervisor del experimento, en cualquier momento, mi

malestar, molestia o inconformidad. Entiendo que puedo abandonar que puedo abandonar
el experimento y el laboratorio en cualquier momento.

_________________________

Firma

Instrucciones:

Estimado(a) colaborador(a) a continuación Ud. participará en una prueba para evaluar el

grado de usabilidad del Sitio Web Sistema de Remuneraciones. Esta prueba tiene por
objetivo detectar la existencia de problemas en el uso de algunas de las funcionalidades que
brinda este sistema a sus usuarios, en el marco de una investigación sobre la usabilidad en
este tipo de servicios.

La prueba tiene 3 etapas:

1. En la primera etapa Ud. deberá completar un breve cuestionario con preguntas relativas
a su experiencia y contexto habitual de uso de este tipo de Sitios.

2. En la segunda etapa se le proporcionarán un conjunto de tareas las que deberá tratar de

realizar en el Sistema de Remuneraciones.

3. En la tercera etapa se le entregará otro breve cuestionario que tiene por objetivo obtener
la impresión general que Ud. tuvo luego de su experiencia de uso del Sistema de
Remuneraciones.

¡No se preocupe si comete algún error, es normal, no existen malos o buenos desempeños!
¡Recuerde que no lo estamos evaluando a Ud. sino al servicio del Sistema de
Remuneraciones!

Toda la información que Ud., nos proporciona es absolutamente confidencial y muy

relevante para nuestro estudio, por lo cual le agradecemos su desinteresada cooperación.

SI TIENE ALGUNA DUDA DURANTE EL DESARROLLO DEL TEST, POR FAVOR

CONTACTESE CON EL EVALUADOR.

Test de Usabilidad: Sistema de Remuneraciones Multiempresas

Sitio Web: http://hera.inf.ucv.cl/~ncarrasco/remuneraciones

Listado de Tareas:

Tarea N°1:

Descripción: Ingresar al sistema con un perfil definido.

Ingrese al sistema con el siguiente perfil:

a) Usuario: 15097751-7

b) Clave: admin

Tarea N°2:
Descripción: Creación de una cuenta de usuario en el Sistema.

Módulo Usuarios: Crear un usuario con los siguientes datos.

a) Nombre Completo: Prueba de Usabilidad

b) Usuario: (Tu Rut).

c) Clave: Test

d) Tipo de Usuario: Administrador

Tarea N°3:

Descripción: Ingresar con la cuenta de usuario creada.

Una vez generado salir del sistema e iniciar sesión con la cuenta:

a) Usuario: (Tu Rut).

b) Clave: Test

Tarea N°4:

Descripción: Listar los usuarios del sistema.

Listar los usuarios del sistema.

Tarea N°5:

Descripción: Encontrar los parámetros Generales Sexo y Región y asignarle valores

predefinidos.

Encuentra el parámetro General Sexo y Región dándole los siguientes valores:

a) Código Sexo: 02

b) Sexo: 2
c) Nombre de Sexo: Femenino

d) Región: 5

e) Código Región: 05

f) Nombre Región: Quinta Región

g) Nombre corto: V

Tarea N°6:

Descripción: Encontrar el parámetro Previsional AFP y asignarle los valores predefinidos.

Encuentra el parámetro Previsional AFP dándole los siguientes valores:

a) Nombre AFP: Hábitat.

b) Código: 11

c) Porcentaje %: 12,47

d) Vigencia Desde: (día Actual)

e) Vigencia Hasta: (dos semanas después de la actual)

Tarea N°7:

Descripción: Encontrar la empresa de Gianinna Reyes Bustos.

Encuentre la empresa de Gianinna Reyes Bustos.

Tarea N°8:

Descripción: Ingresar la ficha personal de un trabajador con valores predefinidos.

Ingrese la ficha personal de un trabajador con los siguientes parámetros:

a) RUN: 16574414-4
b) Nombres y Apellidos: Juanito Esteban Pérez González

c) Nacionalidad: Chileno

d) Sexo: hombre

e) Dirección: calle del agua 512

f) Cuidad: Viña del Mar

g) Teléfonos: 2555555

h) Fecha de Nacimiento: 13/03/1999

i) Estado civil: Soltero

Tarea N°9:

Descripción: Ingrese un movimiento mensual del trabajador anteriormente señalado (Tarea

N° 8).

Ingrese un movimiento mensual del trabajador anteriormente señalado (Tarea N° 8).

Tarea N°10:

Descripción: Ingrese un movimiento mensual de otro trabajador (distinto al de la Tarea

N°10).

Ingrese un movimiento mensual de otro trabajador (distinto al anterior).

Tarea N°11:

Descripción: Generar el cálculo de remuneraciones de la empresa de Gianinna Reyes

Bustos.

Genere el cálculo de remuneraciones de la empresa de Gianinna Reyes Bustos.

x Test de Usabilidad aplicado sobre el Sistema de Control de Inventarios:

El test de usabilidad en laboratorio se compuso por un acuerdo de confidencialidad y el test
mismo, el cual tuvo el siguiente formato:

Acuerdo de Confidencialidad:

Yo____________________ Acepto a participar en una prueba de usabilidad supervisada

por _________________, el día __/__/__, en el Laboratorio de Usabilidad montado en 12
Norte con ½ Oriente, casa 11135 A. Entiendo y estoy de acuerdo con las condiciones
mencionadas en adelante

Entiendo que el experimento se hace sólo para evaluar un sistema software, No mis
capacidades/habilidades/conocimientos.

Entiendo que los resultados del experimento se utilizaran sólo para propósitos académicos
y/o de investigación, sin que mi identidad sea revelada.

Entiendo que puedo comunicar al supervisor del experimento, en cualquier momento, mi

malestar, molestia o inconformidad. Entiendo que puedo abandonar que puedo abandonar
el experimento y el laboratorio en cualquier momento.

__________________________

Firma

Test de Usabilidad: Sistema de Control de Inventarios

Sitio Web: http:\\localhost\topmachine

Listado de Tareas:

Tarea N°1:

Descripción: Ingresar al sistema con el perfil predefinida.

Ingrese al sistema con el siguiente perfil:

a) Usser: Administrador
b) Password: 12345

Tarea N°2:

Descripción: Creación de una cuenta de usuario en el Sistema.

Módulo Usuarios: Crear un usuario con los siguientes datos.

a) Nombre: Prueba de Usabilidad

b) Usser: Test

c) Password: 12345

d) Rol: Encargado de Inventario

Tarea N°3:

Descripción: Ingresar con la cuenta de usuario creada.

Una vez generado salir del sistema e iniciar sesión con la cuenta anteriormente creada:

a) Usuario: Test

b) Password: 12345

Tarea N°4:

Descripción: Generar el Ingreso de un Artículo en particular e identificar características de

éste.

Genere un Ingreso de Artículos con las siguientes especificaciones:

a) Numero de Artículo: 314

b) Descripción del Producto: Aceite de Ajonjolí.

c) Unidad de Compra: Lata

d) Unidad de Almacenaje: Almacén General.

e) Grupo: Aceites y Grasas Comestibles.

Identifique:

Existencias del producto_____ Precio de Venta_____ Ultima Salida_____

Ultima Compra_________ Proveedor____________________

Tarea N°5:

Descripción: Encontrar el artículo anterior e ingresar la última entrada y salida de este.

Busque en el mayor Auxiliar de Existencias el Artículo ingresado en el punto anterior e

identifique:

Ultima Entrada_________ Última Salida__________

Tarea N°6:

Descripción: Encontrar el artículo: coctel de almejas e ingresar el número total de

existencias y costo asociado.

En el módulo de búsquedas, encuentre el coctel de Almejas del almacén General e

identifique lo siguiente:

Número total de Existencias_____ Costo_____

Anexo F Cuestionario de Usabilidad para Desarrolladores

del Sistema de Remuneraciones Multiempresas
El cuestionario aplicado consistió en lo siguiente:

1. Información sobre el Desarrollador

a) Nombre_______________________________________________________________
b) Cargo en el Equipo de Trabajo_____________________________________________

c) Conocimiento respecto a los procesos centrados en el usuario_____________________

2. Indica cuáles de las siguientes técnicas se han aplicado en el desarrollo del proyecto
indicando con una cruz en qué ciclo (1º y/o 2º) se han empleado.

Técnicas de Usabilidad Construcción 1 Construcción 2

Análisis Competitivo

Casos de Uso Esenciales

Perfiles de Usuario

Storyboards

Prototipos de Papel

Especificaciones de Usabilidad

Mapa de Navegación

Evaluación Heurística

Test de Usabilidad con Usuarios

Pensar en voz alta

Cuestionarios , Entrevistas y Encuestas

3. Indica para cada técnica utilizada el grado de acuerdo con la afirmación de cada
columna, con un valor entre valor entre 1 a 5 (1 = Muy desacuerdo, 2 = Desacuerdo, 3 =
Neutro, 4 = de Acuerdo, 5 = Muy de acuerdo).
Técnicas de Usabilidad Técnica difícil Técnica difícil Técnica difícil Tomó más
de entender de aplicar de integrar en tiempo en el
el resto del desarrollo el
desarrollo aplicar la
técnica

4. Para qué crees que te han sido de ayuda las técnicas en el desarrollo del proyecto:

5. Marca con una cruz (X) tu opinión al respecto si se ha visto afectado el resultado de las
actividades de usabilidad al:

a) Desarrollo de la parte visible interfaz gráfica de usuario

__Muy No ha Afectado __No ha Afectado __Neutro __Ha Afectado __Muy Ha
Afectado

b) Desarrollo del resto del sistema

__Muy No ha Afectado __No ha Afectado __Neutro __Ha Afectado __Muy Ha

Afectado

c) Reflexiona e indica a qué actividades concretas ha afectado y de qué manera:

6. ¿Qué influencia ha tenido la aplicación de las técnicas de usabilidad utilizadas en la

comprensión de los requerimientos?

7. Marca con una cruz (X) la opinión de la siguiente afirmación: “el esfuerzo que conlleva
aplicar el enfoque centrado en el usuario se ve compensado por los resultados obtenidos”:

__Muy Desacuerdo __Desacuerdo __Neutro __de Acuerdo __Muy de Acuerdo

8. ¿Crees que las técnicas de usabilidad son aplicables para cualquier tipo de problema o
específicamente para algún problema particular (o dominio particular)?

Anexo G Cuestionario de Satisfacción

El cuestionario de satisfacción aplicado sobre los usuarios de ambos sistemas tuvo el
siguiente formato:

Nombre:

Fecha:

Perspectiva General

Marca con una cruz (X) tu opinión personal de los siguientes puntos relativos al sistema
que acabas de probar:

Muy Muy
 Insatisfecho Satisfecho

Satisfacción General 1 2 3 4 5

Peor Mejor

Valoración respecto a 1 2 3 4 5
la versión anterior

(Marcar únicamente si se ha probado anteriormente otra versión del sistema)

Opinión sobre el sistema:

Muy Malo Muy Bueno

1 2 3 4 5

Muy Muy
Desilusionante Satisfactorio

1 2 3 4 5

Muy Muy Sencillo

Complejo

1 2 3 4 5

Muy Rígido Muy Flexible

1 2 3 4 5

Facilidad de Aprendizaje y de Comprensión:

Marca con una cruz (X) tu grado de acuerdo con las siguientes afirmaciones sobre el
sistema que acabas de probar:

Muy en Muy de
desacuerdo acuerdo

El sistema es fácil de 1 2 3 4 5
aprender

Muy en Muy de
desacuerdo acuerdo

Cuando el sistema se 1 2 3 4 5
utiliza por primera vez
es fácil de comprender
la forma de trabajar
con él

Muy en Muy de
desacuerdo acuerdo

El número de pasos 1 2 3 4 5
para realizar cada tarea
es el adecuado

Muy en Muy de
desacuerdo acuerdo

Los pasos que se 1 2 3 4 5

requieren para llevar a
cabo una tarea siguen
una secuencia lógica
 Muy en Muy de
desacuerdo acuerdo

El sistema ofrece 1 2 3 4 5
suficiente información
sobre cada paso de

cada operación
realizada

Marca con una cruz (X) tu opinión acerca del siguiente punto relativo al sistema que acabas
de probar:

Siempre Nunca

El modo en el que 1 2 3 4 5
funciona el sistema
favorece que el usuario
cometa errores

Sobre la Interfaz de Usuario:

Marca con una cruz (X) tu grado de acuerdo con las siguientes afirmaciones sobre la
interfaz de usuario del sistema que acabas de probar:

Muy en Muy de
desacuerdo acuerdo
La terminología usada 1 2 3 4 5
en las pantallas del
sistema es la adecuada
para los usuarios del
sistema

Muy en Muy de
desacuerdo acuerdo

Se puede deducir qué 1 2 3 4 5

hace cada función del
sistema

Muy en Muy de
desacuerdo acuerdo

Los mensajes y 1 2 3 4 5
respuestas que ofrece
el sistema son
consistentes en cuanto
a la terminología y
forma

Muy en Muy de
desacuerdo acuerdo

Los pasos que se 1 2 3 4 5

requieren para llevar a
cabo una tarea siguen
una secuencia lógica de
expresar la información

Muy en Muy de
 desacuerdo acuerdo

El sistema ofrece 1 2 3 4 5
suficiente información
sobre cada paso de
cada operación
realizada

Marca con una cruz (X) tu opinión acerca de los siguientes puntos relativos a la interfaz de
usuario del sistema que acabas de probar:

Muy Oscura Muy Clara

La lectura y 1 2 3 4 5
comprensión de fuentes
de letras y dibujos es

Muy Muy
Complejas Intuitivas

Las pantallas en 1 2 3 4 5
sentido general pueden
ser consideradas como
con él

Muy Escasa Muy

Excesiva

La información 1 2 3 4 5
mostrada por pantalla
es

Muy Confusa Muy Clara

La secuencia entre 1 2 3 4 5
pantallas es

Muy Nunca Muy Siempre

La interfaz muestra la 1 2 3 4 5
situación actual del
sistema

Muy Escasas Muy

Excesivas

Las opciones en 1 2 3 4 5
pantallas son

Nada adecuada Muy

adecuada

La distribución de los 1 2 3 4 5
componentes en las
ventanas es

Comentarios:

Anexo H Inducción de Usabilidad y El enfoque del Diseño

Centrado en el Usuario
Se desarrolló una Inducción para los desarrolladores del Sistema de Control de Inventarios,
la cual consistió en lo siguiente:
¿Qué es la usabilidad?

Se define usabilidad como:

“La medida en la que un producto se puede usar por determinados usuarios para conseguir
objetivos específicos con efectividad, eficiencia y satisfacción en un contexto especificado”
[Nielsen, 1993].

“Es el grado con el cual un producto puede ser utilizado por usuarios específicos para
lograr metas específicas con efectividad y satisfacción en un contexto específico de uso”
[ISO 13407, 1999].

¿Qué toma en cuenta la usabilidad?

Rapidez y facilidad de hacer las cosas.

Aproximación al usuario.

Conocimiento del contexto de uso.

Satisfacer las necesidades del usuario.

Los usuarios son los que determina si el producto es fácil de usar.

¿Cuál es su importancia?

Una reducción de los costos de producción.

Reducción de los costos de mantenimiento y apoyo.

Reducción de los costos de uso.

Mejora en la calidad del producto.

Desarrollos previos a los procesos centrados en el Usuario:

A través de los tiempos, se han desarrollado diversas formas de entender el problema y

plantear una solución; cada una de ellas ha marcado el tiempo y la época en la que
evolucionaron.

Diseño Centrado en la Sistemas (Máquina):

La primera, denominada, Centrado en la Máquina, culpaba al usuario de los errores y
dificultades encontradas en la interacción con el software, esto quiere decir, la máquina
estaba bien, la culpa era del usuario.

Después, los usuarios empezaron a quejarse; los desarrolladores escucharon. Entonces

culparon a los diseñadores.

Aunque no resolvía el problema totalmente, se sentaron las bases para el Diseño Centrado
en el Usuario.

Diseño Centrado al Usuario:

La solución no sólo requería de buenas intenciones. Se requería, además, iterar la solución

una y otra vez. Se necesitaba interrelacionar, de alguna manera, al diseño, y el proceso del
diseño, con los usuarios, así surgió la metodología de DCU.

El Proceso Centrado en el Usuario:

Se puede definir mediante la siguiente Figura:

Fig. 54. Modelo de los Procesos Centrados en el Usuario.

Donde cada uno de las actividades se define brevemente a continuación:
x Comprensión y especificación del contexto de uso: Se deben identificar las
características de los usuarios potenciales, las tareas que estos van a desarrollar así
como el entorno en el cual el sistema se va a utilizar.

x Especificación de los requisitos del usuario y de la organización respecto a la

descripción del contexto de uso: Se deben fijar los objetivos identificando los
compromisos y prioridades entre los diferentes requisitos.

x Producción de soluciones de diseño: A partir de los conocimientos existentes

procedentes de equipos multidisciplinares, se deben llevar a cabo las soluciones de
diseño concretas utilizando algún tipo de prototipado. Estos prototipos se presentan a
los usuarios y se recoge la información de retorno a partir de la cual se realiza la
modificación del diseño. Este proceso se repite hasta alcanzar los objetivos
especificados.

x Evaluación de los diseños respecto a los requisitos: La evaluación debe estar presente
durante todo el ciclo de vida con la intención de proporcionar un retorno de información
que contribuya a mejorar el diseño, también determinará si se han alcanzado los
objetivos especificados y verificará el uso a largo plazo del producto.

Para desarrollar con esta metodología se debe tomar en cuenta el siguiente ciclo de vida:

1. Conocer al usuario:

Características del usuario individual.

Tareas actuales y deseadas del usuario.

Análisis funcional.

Evolución del usuario y su trabajo.

2. Análisis de la competencia.
3. Establecimiento de las metas de usabilidad:

Análisis de impacto financiero.

4. Diseño paralelo.

5. Diseño participativo.

6. Diseño coordinado del conjunto de la interfaz.

7. Aplicación de guías y análisis heurístico.

8. Prototipos.

9. Test empírico.

10. Diseño iterativo:

Captura de los fundamentos del diseño.

11. Reunión de retroalimentación del uso en campo [Nielsen, 1993].

Independientemente del método de desarrollo del sistema, idealmente debe de considerarse

a la usabilidad a lo largo de todo el proyecto para así no tener que hacer cambios drásticos
en etapas futuras del sistema.