TESIS DE MAESTRÍA EN CIENCIAS - CENIDET...Los LBS surgen de la convergencia de diferentes...
Transcript of TESIS DE MAESTRÍA EN CIENCIAS - CENIDET...Los LBS surgen de la convergencia de diferentes...
Centro Nacional de Investigación y Desarrollo Tecnológico
Departamento de Ciencias Computacionales
TESIS DE MAESTRÍA EN CIENCIAS
Integración de Usabilidad en el Desarrollo de Ambientes de Cómputo Móvil Aplicados a Servicios Contextuales Basados en Localización (LBS)
presentada por
Nazir Ossiel Molina Coronel Ing. en Sistemas Computacionales por el Instituto Tecnológico de Veracruz
como requisito para la obtención del grado de:
Maestría en Ciencias en Ciencias de la Computación
Director de tesis: Dr. Javier Ortiz Hernández
Co-Directora de tesis:
Dra. Natalia Juristo Juzgado
Jurado:
Dr. Juan G. González Serna – Presidente MC. Luis Carlos Santillán Hernández – Secretario
Dr. Javier Ortiz Hernández – Vocal
Cuernavaca, Morelos, México. 23 de febrero de 2012
Dedicatoria
Dedico este trabajo a todas aquellas personas que me demostraron su apoyo dentro de esta
investigación, así como también a los que me motivaron a continuar hasta el final.
Agradecimientos
Quiero agradecer a mi director y a mi codirectora de tesis, al Dr. Javier Ortiz Hernández y a
la Dra. Natalia Juristo Juzgado, por los conocimientos y consejos que me brindaron en
beneficio de mi crecimiento profesional. También quiero agradecer a mis revisores, el Dr.
Juan Gabriel González Serna y el M.C. Luis Carlos Santillán Hernández por el valioso
apoyo y asesoría recibidos.
Quiero agradecer también a mi familia empezando por mi madre Luz María Coronel
Yáñez, y mis hermanos Javier A. Molina Coronel y Carlos A. Molina Coronel, por el apoyo
moral y motivación durante esta etapa de mi vida, me gustaría agradecer también a mi
padre Carlos Molina Mireles, a mi novia Gina M. Pineda Ortiz por la paciencia y el apoyo
que me brindó a lo largo de esta etapa, también agradecer a mis suegros el señor Roberto
Pineda Ocampo y la Sra. Carolina Ortiz por su apoyo.
No podría dejar de mencionar a mis compañeros y amigos que hicieron de esta estancia
algo muy agradable a Ricardo Estrada, Felipe Román, Sabino Pariente, Everardo Munguía,
Karen Hernández, Emmanuel Vázquez y Eliel Morales, agradecerles sus consejos y los
buenos momentos que me hicieron pasar durante esta etapa.
Agradezco al CONACYT por el apoyo para la realización de esta investigación
Resumen
Los avances tecnológicos que permiten las conexiones inalámbricas, así como la
miniaturización de componentes electrónicos, han dado lugar a un enorme crecimiento en
el empleo de aplicaciones móviles, ofreciendo nuevos servicios y creando nuevos mercados
que ya tienen en la economía un enorme impacto. Dentro de estas aplicaciones móviles, los
servicios basados en localización (LBS), son de las aplicaciones que, de acuerdo a expertos,
tendrá una mayor demanda y mayor desarrollo en los próximos años.
Los LBS surgen de la convergencia de diferentes tecnologías de información como son los
sistemas de información geográfica (GIS), el internet, y los dispositivos móviles, y se trata
de servicios personalizados basados en información acerca de la ubicación geográfica de
los usuarios.
Si bien en la literatura científica no encontramos evidencia de problemas específicos de
insatisfacción en el empleo de estas aplicaciones, sí encontramos reportes en revistas de
divulgación y en foros no especializados señalando dificultades para su empleo por parte de
ciertos segmentos de mercado, o para utilizar adecuadamente las funcionalidades ofertadas.
Para atender esta problemática se propone un marco metodológico para la incorporación de
usabilidad en el análisis, diseño y desarrollo de servicios contextuales basados en
localización (LBS), a partir de técnicas para el desarrollo de sistemas de interacción
persona ordenador (IPO) y tomando en cuenta los perfiles de los dispositivos móviles y de
los usuarios.
La solución que se propone consiste en un proceso unificado de integración que toma en
cuenta la usabilidad, las aplicaciones móviles y la ingeniería de software, incorporando a
este proceso unificado un conjunto de técnicas relacionadas con los diferentes contextos a
considerar dentro de los LBS.
Abstract
Technological advances enabled by wireless connections, and miniaturization of electronic
components, have led to tremendous growth in the use of mobile applications, offering new
services and creating new markets that already have a huge economic impact. Within these
mobile applications, location based services (LBS) are applications that, according to
experts, will have a greater demand and greater development in the upcoming years.
The LBS emerge from the convergence of the information of different technologies such as
geographic information systems (GIS), the Internet and mobile devices, and are about
custom services based on information about the geographic location of users.
Although we cannot find evidence of specific problems of dissatisfaction in the use of these
applications in the scientific literature, we do find reports in popular science magazines and
in non-specialized forums, pointing the difficulties for their use by certain market segments,
or to properly use the features offered. To address this problem we propose a
methodological framework to incorporate the usability in the analysis, design and
development of contextual services, based on locating (LBS), from techniques for
developing Human-computer interaction (HCI) systems and taking consideration profiles of
mobile devices and users.
The solution proposed consist of an unified process of integration that takes into account
the usability, mobile applications and software engineering, incorporating to this unified
process, a set of techniques related to the different contexts to be considered within the
LBS.
i
Contenido CAPÍTULO I Introducción ..................................................................................................................... 1
1.1 Introducción .................................................................................................................................. 2
1.1.1 Marco Teórico ........................................................................................................................ 3
1.1.1.1 Proceso de Desarrollo de Software. ................................................................................ 3
1.1.1.2 Arquitectura de Software. ............................................................................................... 4
1.1.1.3 Disciplina Interacción Persona Ordenador (IPO). ............................................................ 5
1.1.1.4 Propuestas IPO ................................................................................................................ 6
1.1.1.4 Cómputo Móvil. ............................................................................................................. 12
1.1.1.5 Servicios Basados en Localización. ................................................................................ 13
CAPÍTULO II Problema Abordado ...................................................................................................... 22
2.1 Introducción. ............................................................................................................................... 23
2.2 Identificación del Problema. ....................................................................................................... 24
2.2.1 Complejidad del problema. .................................................................................................. 24
2.3. Aproximación de la Solución. ..................................................................................................... 25
2.3.1 Primer Propuesta de Solución. ............................................................................................. 25
2.3.2 Segunda Propuesta de Solución. .......................................................................................... 26
2.3.3 Tercera Propuesta de Solución. ........................................................................................... 27
2.4 Objetivo General ......................................................................................................................... 29
2.4.1 Objetivos Específicos ............................................................................................................ 29
2.5 Alcances ....................................................................................................................................... 29
2.6 Limitaciones ................................................................................................................................ 30
CAPÍTULO III Estado del Arte ............................................................................................................. 31
3.1 Incorporación de usabilidad en el proceso de desarrollo de software ....................................... 32
3.1.1 Integración de la IPO y la Ingeniería del Software: MPIu+a ................................................. 32
3.1.2 Integrating Usability Techniques into Software Development ............................................. 33
3.1.3 Paper or Interactive? A Study of Prototyping Techniques for Ubiquitous Computing
Environments ................................................................................................................................. 34
3.1.4 Usability Engineering Methods for Software Developers ..................................................... 35
3.1.5 Marco de Integración de la Usabilidad en el Proceso de Desarrollo de Software. .............. 35
3.1.6 Comparativa de trabajos ...................................................................................................... 36
ii
3.2 Incorporación de Usabilidad en Aplicaciones Móviles ................................................................ 38
3.2.1 A Qualitative Review of Empirical Mobile Usability Studies ................................................. 38
3.1.2 Exploring the benefits of the combination of a software architecture analysis and a
usability evaluation of a mobile application ................................................................................. 38
3.1.3 Usability of Mobile Devices and Intelligently Adapting to a User’s Needs ........................... 39
3.1.4 User needs for location-aware mobile services .................................................................... 40
3.1.6 Comparativa de trabajos ...................................................................................................... 40
CAPÍTULO IV Contextos Móviles ....................................................................................................... 42
4.1 Introducción ................................................................................................................................ 43
4.2 Contexto. ..................................................................................................................................... 44
4.3 Identificación de contextos ......................................................................................................... 45
4.3.1 Contexto Móvil. .................................................................................................................... 46
4.3.2 Contexto Aplicación. ............................................................................................................ 46
4.3.3 Contexto Usuario. ................................................................................................................ 48
4.4 Identificación de productos ........................................................................................................ 51
4.4.1 Contexto Móvil ..................................................................................................................... 51
4.4.2 Contexto de Aplicación ........................................................................................................ 51
4.4.3 Contexto Usuario ................................................................................................................. 52
4.5 Identificación de Sub-Productos ................................................................................................. 53
4.5.1 Sub-productos de contexto Usuario .................................................................................... 53
4.5.2 Sub-productos de contexo Móvil ......................................................................................... 53
4.5.3 Sub-productos de contexto de Aplicación ........................................................................... 53
CAPÍTULO V Selección de Técnicas IPO ............................................................................................. 55
5.1 Introducción ................................................................................................................................ 56
5.2 Clasificación de técnicas dentro de las actividades de desarrollo de los Servicios Basados en
Localización (LBS) .............................................................................................................................. 57
5.3 Análisis de Propuestas ................................................................................................................. 58
5.3.1 Análisis del Ciclo de Vida de la Usabilidad (Mayhew). ......................................................... 58
5.3.2 Análisis del Ciclo de la Ingeniería de Usabilidad (Nielsen). .................................................. 58
5.4 Análisis de posibles técnicas aplicables a los LBS ........................................................................ 58
5.5 Técnicas seleccionadas ................................................................................................................ 59
CAPÍTULO VI Construcción del Proceso de Desarrollo ...................................................................... 62
iii
6.1 Introducción ................................................................................................................................ 63
6.2 Proceso de desarrollo de la Usabilidad ....................................................................................... 64
6.2.1 Análisis .................................................................................................................................. 65
6.2.1.1 Especificación del Contexto de Uso .............................................................................. 65
6.2.1.2 Especificaciones de Usabilidad ...................................................................................... 66
6.2.2 Diseño ................................................................................................................................... 66
6.2.2.1 Desarrollo del Concepto del Producto ........................................................................... 66
6.2.2.2 Prototipado .................................................................................................................... 66
6.2.2.3 Diseño de la Interacción ............................................................................................... 66
6.2.3 Evaluación ............................................................................................................................ 66
6.2.3.1 Evaluación de Usabilidad............................................................................................... 66
6.3 Proceso de desarrollo del Software ............................................................................................ 67
6.3.1 Análisis .................................................................................................................................. 68
6.3.2 Diseño ................................................................................................................................... 69
6.3.3 Implementación ................................................................................................................... 70
6.3.4 Evaluación ............................................................................................................................ 70
6.3.5 Mantenimiento .................................................................................................................... 70
6.4 Proceso de desarrollo de una Aplicación Móvil .......................................................................... 70
6.4.1 Estructura convencional de la metodología de una aplicación móvil .................................. 71
6.4.1 Metodología de WORKPA .................................................................................................... 73
6.5 Construcción del proceso de desarrollo ...................................................................................... 75
CAPÍTULO VII Caso de Estudio y Evaluación del Proceso de Desarrollo ........................................... 81
7.1 Introducción ................................................................................................................................ 82
7.2 Proyecto de mejora de una aplicación LBS ya existente ............................................................. 84
7.2.1 Fase de Evaluación ............................................................................................................... 84
7.2.1.1 Pruebas de Usabilidad ................................................................................................... 85
7.2.2 Fase de Análisis .................................................................................................................... 98
Sección 1.................................................................................................................................... 98
Sección 2.................................................................................................................................. 106
Sección 3.................................................................................................................................. 108
Sección 3.................................................................................................................................. 108
7.3 Resultados de la evaluación del proceso de desarrollo ............................................................ 116
iv
7.3.1 Resultados de la evaluación de la maqueta de baja fidelidad ........................................... 117
7.3.1.1 Evaluación de Google Maps en su estado actual ........................................................ 117
7.3.1.2 Evaluación de Google Maps mejorado en usabilidad ................................................. 120
7.3.1.3 Tablas de tiempos obtenidos con los diferentes usuarios .......................................... 122
7.3.1.4 Tabla de tiempos promedio ........................................................................................ 123
CAPÍTULO VIII Conclusiones ............................................................................................................ 125
8.1 Conclusiones.............................................................................................................................. 126
8.1 Trabajos Futuros ........................................................................................................................ 127
Referencias bibliográficas ............................................................................................................... 128
Anexo A Análisis de Técnicas IPO .................................................................................................... 134
Anexo B Análisis de Requerimientos ............................................................................................... 158
Anexo C Documento de Especificación de Requerimientos ........................................................... 161
Anexo D Guía de Estilo .................................................................................................................... 170
Contenido de Tablas Tabla 1.1: Servicios Básicos [Formica, 08] ......................................................................................... 14
Tabla 1.2: Ejemplos de servicios PULL [ESRI, 2002]. ......................................................................... 15
Tabla 1.3: Ejemplos de servicios PUSH [ESRI, 02]. ............................................................................ 16
Tabla A.5: Análisis de técnicas ........................................................................................................ 135
Tabla A.6: Relación de sub-productos y técnicas IPO ..................................................................... 143
Tabla A.7: Análisis de Usuarios ........................................................................................................ 150
Tabla A.8: Análisis de Tareas ........................................................................................................... 151
Tabla A.9: Especificación de Usabilidad .......................................................................................... 152
Tabla A.10: Desarrollo del concepto del producto ......................................................................... 152
Tabla A.11: Prototipado .................................................................................................................. 153
Tabla A.12: Diseño de la Interacción ............................................................................................... 154
Tabla A.13: Evaluación de Usabilidad ............................................................................................. 155
Tabla A.14: Restricción de plataforma ............................................................................................ 157
Tabla C.15: Perfil de usuario 1......................................................................................................... 165
Tabla C.16: Perfil de usuario 2......................................................................................................... 165
Tabla C.17: Requerimiento 1 ........................................................................................................... 166
Tabla C.18: Requerimiento 2 ........................................................................................................... 166
Tabla C.19: Requerimiento 3 ........................................................................................................... 166
Tabla C.20: Requerimiento 4 ........................................................................................................... 167
Tabla C.21: Requerimiento 5 ........................................................................................................... 167
Tabla C.22: Requerimiento 6 ........................................................................................................... 167
v
Tabla 3. 1: Comparativa de métodos de evaluación de usabilidad [Holzinger, 05] .......................... 35
Tabla 3. 2: Comparativa de Trabajos ................................................................................................. 37
Tabla 3. 3: Comparativa de trabajos ................................................................................................. 41
Tabla 4. 1 Contextos .......................................................................................................................... 45
Tabla 4. 2: Factores ........................................................................................................................... 50
Tabla 5. 1: Clasificación de Técnicas.................................................................................................. 57
Tabla 5. 2: Técnicas seleccionadas .................................................................................................... 60
Tabla 6. 1: Proceso de desarrollo en paralelo ................................................................................... 76
Tabla 7. 1: Plantilla de Pruebas de Usabilidad .................................................................................. 85
Tabla 7. 2: Cronograma de Actividades............................................................................................. 87
Tabla 7. 3: Plantilla técnica de observación ...................................................................................... 87
Tabla 7. 4: Plantilla de observación usuario 1 (video 1) .................................................................... 88
Tabla 7. 5: Plantilla de observación usuario 2 (video 2) .................................................................... 88
Tabla 7. 6: Plantilla de observación usuario 3 (video 3) .................................................................... 88
Tabla 7. 7: Plantilla de observación usuario 4 (video 4) .................................................................... 89
Tabla 7. 8: Plantilla de observación usuario 5 (video 5) .................................................................... 89
Tabla 7. 9: Plantilla de observación usuario 6 (video 6) .................................................................... 89
Tabla 7. 10: Porcentajes de eficacia .................................................................................................. 90
Tabla 7. 11: Plantilla retroalimentación con los usuarios ................................................................. 90
Tabla 7. 12: Satisfacción .................................................................................................................... 95
Tabla 7. 13: Clasificación de problemas encontrados ....................................................................... 95
Tabla 7. 14: Problemas de satisfacción ............................................................................................. 97
Tabla 7. 15: Problemas de eficacia .................................................................................................... 97
Tabla 7. 16: Plantilla del cuestionario de Perfil de Usuario............................................................... 98
Tabla 7. 17: Criterios para identificación del Perfil de Usuario ......................................................... 99
Tabla 7. 18: Cuestionario para obtener el Perfil de Usuario ........................................................... 100
Tabla 7. 19: Perfiles de Usuario identificados ................................................................................. 102
Tabla 7. 20: RF-01 Ubicación ........................................................................................................... 104
Tabla 7. 21: RF-02 Búsqueda ........................................................................................................... 104
Tabla 7. 22: RF-03 Trazar ruta ......................................................................................................... 105
Tabla 7. 23: Matriz de frecuencia de modelos mentales de los usuarios ....................................... 107
Tabla 7. 24: Comparación de procesos de desarrollo ..................................................................... 116
Tabla 7. 25: Evaluación usuario 1 .................................................................................................... 122
Tabla 7. 26: Evaluación usuario 2 .................................................................................................... 122
Tabla 7. 27: Evaluación usuario 3 .................................................................................................... 122
Tabla 7. 28: Evaluación usuario 4 .................................................................................................... 123
Tabla 7. 29: Promedio de tiempo .................................................................................................... 123
Contenido de Figuras Figura 1. 1: Proceso de Desarrollo [Pressman, 97] ............................................................................. 3
Figura 1. 2: Ciclo de vida de la ingeniería de usabilidad [Mayhew, 99] .............................................. 9
vi
Figura 1. 3: Categorías de LBS [Steiniger, 06]. ................................................................................... 15
Figura 1. 4: Tecnologías que convergen en los LBS [Steiniger, 06]. .................................................. 16
Figura 1. 5: Los componentes básicos de un LBS [Steiniger, 06]. ..................................................... 18
Figura 1. 6: Elementos de los LBS [Seco, 08]. .................................................................................... 18
Figura 1. 7: Tecnologías de localización [Seco, 08] ........................................................................... 19
Figura 1. 8: Interiores (Indoor) [Seco, 08] ......................................................................................... 19
Figura 1. 9: Funcionamiento de los LBS [Steiniger, 06]. .................................................................... 20
Figura 2. 1: Capas .............................................................................................................................. 25
Figura 2. 2: Primera propuesta de solución ...................................................................................... 26
Figura 2. 3: Segunda propuesta de solución ..................................................................................... 27
Figura 2. 4: Aumento de nivel de métrica ......................................................................................... 27
Figura 2. 5: Tercera Propuesta de Solución....................................................................................... 28
Figura 3. 1: Modelo de proceso integración de usabilidad más accesibilidad [Granollers, 04]. ....... 32
Figura 3. 2: Construcción de la fase .................................................................................................. 33
Figura 4. 1: Contextos........................................................................................................................ 45
Figura 4. 2: Contexto aplicación ........................................................................................................ 46
Figura 4. 3: Contexto Aplicación ........................................................................................................ 47
Figura 4. 4: Contexto usuario ............................................................................................................ 49
Figura 4. 5: Productos de contexto móvil ......................................................................................... 51
Figura 4. 6: Productos de contexto aplicación .................................................................................. 52
Figura 4. 7: Productos de contexto usuario ...................................................................................... 53
Figura 6. 1: Ciclo de Vida de la Usabilidad [Ferre, 05] ...................................................................... 64
Figura 6. 2: Proceso de Desarrollo SWEBOK [SWEBOK, 04] .............................................................. 68
Figura 6. 3: Metodología para Aplicaciones Móviles [Mobinex, 11]. ................................................ 72
Figura 6. 4: Metodología WORKPAD [Humayoun, 09]. ..................................................................... 75
Figura 6. 5: Fase de Análisis............................................................................................................... 78
Figura 6. 6: Fase de Diseño y Codificación ........................................................................................ 79
Figura 6. 7: Fase de Evaluación y mantenimiento ............................................................................. 80
Figura 7. 1 Fases del caso de estudio ............................................................................................... 84
Figura 7. 2: Fase de evaluación ......................................................................................................... 85
Figura 7. 3: Punto de identificación .................................................................................................. 86
Figura 7. 4: Trazado de ruta .............................................................................................................. 86
Figura 7. 5: Búsqueda por texto ........................................................................................................ 87
Figura 7. 6: Grafica de satisfacción en la utilización.......................................................................... 90
Figura 7. 7: Grafica de satisfacción de dificultad en la identificación de puntos .............................. 91
Figura 7. 8: Grafica de satisfacción en el trazado de ruta ................................................................. 91
Figura 7. 9: Grafica de satisfacción de dificultad en la observación de objetos en el mapa............. 92
Figura 7. 10: Grafica de satisfacción de identificación de las funcionalidades ................................. 92
Figura 7. 11: Grafica de satisfacción dela información en el mapa .................................................. 93
Figura 7. 12: Grafica de satisfacción de interacción con la aplicación .............................................. 93
Figura 7. 13: Grafica de satisfacción de localización de las funcionalidades .................................... 93
Figura 7. 14: Grafica de satisfacción del tiempo utilizado ................................................................ 94
vii
Figura 7. 15: Grafica de satisfacción de la aplicación en lo general .................................................. 94
Figura 7. 16: Diagrama de caso de uso “Diagrama de caso de uso principal” ................................ 103
Figura 7. 17: Diagrama de caso de uso “Sistema de Integración de usabilidad” ........................... 103
Figura 7. 18: Diagrama de caso de uso "Trazado de ruta" .............................................................. 103
Figura 7. 19: Arquitectura de Información ...................................................................................... 108
Figura 7. 20: Diagrama de secuencia "Mi ubicación" ...................................................................... 109
Figura 7. 21: Diagrama de secuencia "Navegación" ........................................................................ 109
Figura 7. 22: Diagrama de secuencia "Indicaciones" ...................................................................... 110
Figura 7. 23: Diagrama de secuencia "Latitud" ............................................................................... 110
Figura 7. 24: Diagrama de secuencia "Páginas de Sitios" ................................................................ 111
Figura 7. 25: Diagrama de secuencia "Capas" ................................................................................. 111
Figura 7. 27: Inicio de la aplicación ................................................................................................ 112
Figura 7. 28: Mi ubicación ............................................................................................................... 113
Figura 7. 29: Buscar ......................................................................................................................... 113
Figura 7. 30: Latitud ........................................................................................................................ 114
Figura 7. 31: Indicaciones ................................................................................................................ 114
Figura 7. 32: Más ............................................................................................................................. 115
Figura 7. 33: Capas .......................................................................................................................... 115
Figura 7. 34: Objetos dentro del mapa ........................................................................................... 116
CAPÍTULO I
Introducción En este capítulo se presenta una visión general del tema de investigación, así como las
correspondientes definiciones que son necesarias para su comprensión.
Capítulo I
Página 2
1.1 Introducción
Una tendencia creciente en el uso de los dispositivos móviles, es la incorporación de
servicios basados en localización, conocidos por sus siglas en inglés como LBS, los cuales
surgen como una convergencia de Internet y los sistemas de información geográfica. Si
bien en la literatura científica no encontramos evidencia de problemas específicos de
insatisfacción en el empleo de estas aplicaciones, sí encontramos reportes en revistas de
divulgación y en foros no especializados señalando dificultades para su empleo por parte de
ciertos segmentos de mercado, o para utilizar adecuadamente las funcionalidades ofertadas.
Uno de los problemas abordados y causa de insatisfacción por parte de los usuarios es la
falta de usabilidad en los LBS, la cual se refiere a la capacidad del producto software de ser
entendido, aprendido y usado por el usuario, bajo condiciones específicas.
La “usabilidad” es un tema propio de la IPO (Interacción Persona Ordenador) o por sus
siglas en inglés HCI (Interacción Computadora Humano). Nos ofrece una serie de técnicas
establecidas por diferentes autores y por algunos estándares reconocidos de la organización
internacional de estándares, ISO, por sus siglas en inglés, con la finalidad de elevar los
niveles de satisfacción de los usuarios.
La problemática de estas técnicas es que se aplican en forma aislada dentro de algunas fases
del desarrollo de las aplicaciones, como un subproceso que corre en paralelo al desarrollo
clásico del software, o son muy genéricas y no detallan el momento el que deben ser
incorporadas dentro del desarrollo del software [Ferre, 05].
Aunado a lo anterior, las aplicaciones para dispositivos móviles, a diferencia de los
sistemas de escritorio, poseen características particulares que demandan métodos de
desarrollo específicos: interacción constante con los usuarios; gran cantidad de
funcionalidades, baja autonomía energética; limitaciones en sus capacidades de conexión;
variedad de tamaño, forma, niveles de luminosidad y resolución de la pantalla; así como un
ambiente físico de operación cambiante, sujeto a ruido y a la agresión de agentes
atmosféricos.
Capítulo I
Página 3
1.1.1 Marco Teórico
A continuación se describen los conceptos que dan soporte a nuestra investigación.
1.1.1.1 Proceso de Desarrollo de Software.
Es el control y gestión de un proyecto de software, que especifica las actividades
involucradas (¿Qué hacer?) y técnicas (¿Cómo hacerlo?) a aplicar para su desarrollo,
obteniendo productos a lo largo de este proceso (documentos, diagramas, datos, informes,
formularios, etc.) con la finalidad de ir comprendiendo las necesidades y traducirlas de la
manera más clara a un software.
Jacobson nos menciona que un proceso de desarrollo de software tiene como propósito la
producción eficaz y eficiente de un producto software que reúna los requerimientos del
cliente [Jacobson, 00]. Por otra parte Paulk define al proceso de desarrollo como un marco
de trabajo para un conjunto de tareas claves del proceso [Paulk, 93].
En la literatura encontramos una gran oferta de procesos de desarrollo, los cuales son
seleccionados dependiendo del tipo de aplicación de que se trate, de los costos y plazos
disponibles, del tamaño y complejidad de la solución, de la experiencia del equipo de
trabajo, entre otros factores.
Lo que es una realidad es que ninguno de estos procesos de desarrollo está exento de los
riesgos y complicaciones que corre todo desarrollo de software. Existen factores tales como
la captura de requerimientos la cual implica un largo lapso de tiempo, la interacción de los
sistemas con otras aplicaciones, las limitaciones del hardware sobre el cual se ejecuta, entre
otros, que hacen que fácilmente se salga de control el proceso de desarrollo.
Pressman caracteriza un proceso de desarrollo de software como se muestra en la figura
1.1.
Figura 1. 1: Proceso de Desarrollo [Pressman, 97]
Los elementos involucrados se describen a continuación [Pressman, 97]:
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 de software, con
independencia del tamaño o complejidad,
Un conjunto de tareas de ingeniería que involucran, dirección de proyectos, entregas
y productos de trabajo, y puntos de garantía de calidad, que permiten que las
Capítulo I
Página 4
actividades del marco de trabajo se adapten a las características del proyecto de
software y los requerimientos del equipo del proyecto,
Las actividades de protección, tales como garantía de calidad del software, gestión
de configuración del software y medición, abarcan el modelo del proceso. Las
actividades de protección son independientes de cualquier actividad del marco de
trabajo y aparecen durante todo el proceso.
A pesar de la variedad de propuestas de proceso de desarrollo de software, existe un
conjunto de actividades fundamentales que se encuentran presentes en todos ellos
[Sommerville, 02]:
1. Especificación de software: Se debe definir la funcionalidad y restricciones
operacionales que debe cumplir el software,
2. Diseño e Implementación: Se diseña y construye el software de acuerdo a la
especificación,
3. Validación: El software debe validarse, para asegurar que cumpla con lo que quiere
el cliente,
4. Evolución: El software debe evolucionar, para adaptarse a las necesidades del
cliente.
Por otra parte, la constante evolución de la tecnología es una de las principales fuentes de
cambio en el mercado, nos referimos a la evolución de los dispositivos en específico que ha
obligado a las empresas de desarrollo de software, y a los proveedores de diferentes
servicios a adaptar procesos de desarrollo rápidos y lo más eficientes posibles con la
finalidad de abarcar un mayor mercado.
Esta constante evolución de la innovación por momentos no permite adaptar los mejores
procesos de desarrollo a las diferentes aplicaciones (software) que se desarrollan para los
dispositivos, desaprovechando las capacidades tanto de los dispositivos como de las
aplicaciones que se desarrollan.
Este proceso de adaptación da como resultado marcadas limitaciones dentro de los
diferentes productos ofrecidos, ya que se diseñan aplicaciones con un enfoque que carece
de un profundo análisis y evaluación de estos productos, ya que todo este proceso obliga a
los proveedores y a las empresas a ofrecer productos de la manera más rápida posible para
mantenerse a la vanguardia.
1.1.1.2 Arquitectura de Software.
Existen diversas definiciones de la arquitectura de software una de ellas es la que nos
ofrece el estándar IEEE Std 1471-2000 el cual define a la arquitectura de software como “la
organización fundamental de un sistema formada por sus componentes, las relaciones entre
ellos y el contexto en el que se implantarán, y los principios que orientan su diseño y
evolución” [IEEE, 04].
En la actualidad las empresas desarrollan el software basados en una estructura de
componentes, ya que ayuda a minimizar los errores y optimizar los mantenimientos del
software, con la reutilización de los diferentes componentes que conforman el software.
1.1.1.2.1 Componente de software.
La literatura nos ofrece una serie de definiciones de componente de software como son las
siguientes:
Capítulo I
Página 5
Un componente de software es una unidad de composición con interfaces contractualmente
especificadas y explícitas sólo con dependencias dentro de un contexto. Un componente de
software puede ser desplegado independientemente y es sujeto a la composición de terceros
[Szyperski, 98]. Los componentes tienen un conjunto de características que se muestran a
continuación [Montilva, 03]:
Identificable: Debe tener una identificación que permita acceder fácilmente a sus
servicios y que permita su clasificación,
Auto contenido: Un componente no debe requerir de la utilización de otros para
finiquitar la función para la cual fue diseñado,
Puede ser remplazado por otro componente: Se puede remplazar por nuevas
versiones u otro componente que lo remplace y mejore,
Con acceso solamente a través de su interfaz: Debe asegurar que estas no
cambiaran a lo largo de su implementación,
Sus servicios no varían: Las funcionalidades ofrecidas en su interfaz no deben
variar, pero su implementación sí,
Bien Documentado: Un componente debe estar correctamente documentado para
facilitar su búsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc.,
Es genérico: Sus servicios debe servir para varias aplicaciones,
Reutilizado dinámicamente: Puede ser cargado en tiempo de ejecución en una
aplicación.,
Independiente de la plataforma: hardware, software, sistema operativo.
1.1.1.3 Disciplina Interacción Persona Ordenador (IPO).
Si bien esta disciplina también es conocida como Human-Computer Interaction (HCI), es
una disciplina la cual como sus siglas lo indican trata del estudio de la interacción entre los
ordenadores y las personas. Preece nos explica que la IPO se enfoque en “diseñar sistemas
informáticos que den soporte a personas de tal forma que éstas puedan llevar acabo sus
actividades productivamente y con seguridad personal” [Preece, 94].
Los objetivos de la IPO son desarrollar o mejorar la seguridad, utilidad, efectividad,
eficiencia y usabilidad de sistemas que incluyan computadoras [Diaper, 89]. Como nos
menciona Diaper la usabilidad es una de las preocupaciones de la IPO, y en ella involucra
no solo los factores de un software en ejecución, si no los aspectos culturales y sociales en
los que se desempeña un software, esta es una disciplina independiente del software.
Ferre nos explica que la principal problemática entre la ingeniería de software y la
usabilidad es que por ser de disciplinas diferentes es difícil entender el momento en que
deben realizarse las tareas de la IPO, ya que en la IPO se involucran una serie de disciplinas
diferentes como son la Psicología, la Sociología o Diseño Industrial y la Ergonomía [Ferre,
05].
1.1.1.3.1 Usabilidad.
Como bien sabemos es parte de la disciplina IPO, y la literatura nos ofrece las siguientes
definiciones:
Jakob Nielsen: “Un atributo de calidad que evalúa qué tan fácil son de usar las
interfaces de usuario. La palabra “usabilidad” también se refiere a métodos para
mejorar la facilidad de uso durante el proceso de diseño” [Nielsen, 93],
Capítulo I
Página 6
Eduardo Manchón: “se define coloquialmente como facilidad de uso, ya sea de una
página web, una aplicación informática o cualquier otro sistema que interactúe con
un usuario” [Manchón, 03],
ISO/IEC 9126-1: “La capacidad del producto software de ser entendido, aprendido,
usado y de ser atractivo para el usuario, cuando es usado bajo condiciones
específicas” [Abran, 03],
IEEE Std.610.12: “La facilidad con la cual un usuario puede aprender a operar,
preparar entradas, e interpretar salidas de un sistema o componente” [IEEE, 90],
ISO9241-11: “La medida en la cual un producto puede ser usado por usuarios
específicos, para cumplir objetivos específicos, con efectividad, eficiencia y
satisfacción en un contexto de uso específico” [ISO 9241-11, 98].
1.1.1.4 Propuestas IPO
Dentro de la literatura existen diferentes propuestas IPO, dentro de las cuales describiremos
dos, ya que son parte de esta investigación:
1.1.1.4.1 Ingeniería de Usabilidad (Nielsen)
Jakob Nielsen, una de las personas más reconocidas en el ámbito mundial sobre usabilidad
en la web, propone una serie de técnicas relacionadas con la usabilidad que constituyen hoy
en día une referencia básica en este tema [Nielsen, 93]. Dado que, de acuerdo a Ferre
[Ferre, 05], algunas de ellas no presentan un nombre y descripción apropiados,
presentaremos la clasificación elaborada por este último:
Características de Usuarios Individuales: Esta técnica permite información de usuarios
acerca de su experiencia de trabajo, nivel educativo, edad, experiencia previa con
computadoras, contexto de trabajo y social, etc.
Análisis Competitivo: Esta técnica permite analizar productos existentes de forma
heurística, de acuerdo a guías de usabilidad establecidas, y llevar a cabo test empíricos con
usuarios de estos productos.
Objetivos de Usabilidad: Esta técnica permite establecer objetivos de usabilidad y
distintos niveles de rendimiento para cada atributo (métrica) de usabilidad relevante. Se
recomienda establecer niveles independientes para cada atributo ej. Error, eficiencia,
satisfacción, aprendizaje, etc.
Análisis del Impacto Financiero: Esta técnica permite analizar el impacto financiero que
puede tener la usabilidad del sistema. Implica calcular cómo el grado de mejora de
usabilidad se traduce en ahorro en el tiempo del usuario (tiempo de empleado que cuesta
dinero a la organización usuaria), debido a la mejora en rendimiento del usuario. El tiempo
salvado por una mejora en la facilidad de aprendizaje también puede calcularse.
Diseño Paralelo: Esta técnica permite que varios diseñadores trabajen en diseños
preliminares (trabajando independientemente). Una variante se denomina diseño paralelo
diversificado, en el que se pide a cada diseñador que se centre en diferentes aspectos del
problema de diseño.
Evaluación Heurística: En esta técnica se lleva a cabo observando una interfaz e
intentando obtener una opinión acerca de lo bueno y malo de la interfaz. Es mejor tener a
varios evaluadores que revisen el mismo diseño de forma independiente, puesto que
descubren muchos más errores que un único evaluador. Lo ideal es que lo realicen
especialistas en usabilidad. Un tipo de evaluación heurística particular es el recorrido
Capítulo I
Página 7
pluralístico:
Recorrido Pluralístico: La Evaluación Heurística se lleva a cabo por usuarios
representativos, desarrolladores del producto y especialistas en usabilidad.
Prototipado: Los prototipos son versiones reducidas del sistema completo, bien por
recortar el número de funcionalidades del prototipo, bien por reducir el nivel de
funcionalidad de las opciones que parecen funcionar pero no hacen nada en realidad.
Escenarios: Son prototipos que están limitados en dos sentidos: Por una parte
reducen el número de funciones que ofrece el sistema, y por otra el usuario no
puede interactuar usando datos reales. Representan una sesión de interacción única,
por lo que sólo simulan la ingeniería de usabilidad (IU) mientras el usuario siga un
camino previamente definido. Se trata de un tipo especialmente poco costoso de
prototipos, y pueden ser tanto prototipos de papel como prototipos ejecutables
elaborados por una herramienta de prototipado.
Card Sorting: Esta técnica permite comprender la representación de la 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.
Test de Usabilidad: Un test de usabilidad implica probar la versión actual del sistema con
usuarios reales. Un test de usabilidad normalmente tiene cuatro etapas: Preparación,
introducción, el propio test, y elaboración del informe del test.
Análisis de Impacto: Esta técnica implica en primer lugar la identificación de problemas
de usabilidad, y a continuación volver a las grabaciones realizadas con el fin de investigar
exactamente cuántos usuarios han tenido cada problema de usabilidad y cuánto les retrasó
cada problema. Pueden usarse para priorizar el arreglo de los problemas de usabilidad en un
esfuerzo de rediseño.
Análisis de Impacto: Implica la identificación de problemas de usabilidad realizando
diversos tests y análisis, con el fin de determinar exactamente cuántos usuarios han tenido
cada problema de usabilidad y cuánto les retrasó cada problema. Pueden usarse para
priorizar el arreglo de los problemas de usabilidad en un esfuerzo de rediseño.
Pensar en Voz Alta: Nielsen distingue "pensar en voz alta" de otras técnicas del test de
usabilidad indicando que puede ser el método de ingeniería de usabilidad más valioso
considerado por sí mismo. Un test de pensar en voz alta implica tener a un sujeto usando el
sistema mientras, de forma continua, dice en voz alta lo que está pensando. Su punto fuerte
está en los datos cualitativos que se obtienen en vez de en medidas de rendimiento. La idea
es obtener la impresión del usuario mientras usa el sistema para evitar toda posible
racionalización posterior de sus acciones. Existen varias aproximaciones a la técnica de
pensar en voz alta:
Interacción Constructiva: Implica tener a dos usuarios del test utilizando el
sistema juntos. Se denomina también aprendizaje de codescubrimiento. Se basa en
el hecho de que las personas acostumbran a verbalizar cuando están intentando
resolver un problema de forma conjunta,
Test Retrospectivo: La sesión de test de usabilidad se graba en video y se pide al
usuario que vea la grabación. Los comentarios de un usuario cuando vea la
grabación son en ocasiones más extensos que los que realiza cuando está llevando a
cabo la tarea del test. El revisor puede parar la grabación y preguntar al usuario en
Capítulo I
Página 8
cualquier momento, sin miedo a interferir con el test, que esencialmente ha sido ya
completado,
Método de Entrenamiento: El experimentador o entrenador lleva al usuario en la
dirección adecuada cuando está usando el sistema. El usuario puede preguntar al
experimentador, y las preguntas pueden mostrar problemas de usabilidad que
permanecerían ocultos de otro modo. El experimentador contestará en base a su
conocimiento del sistema.
Laboratorios de Usabilidad: Se trata de instalaciones especialmente dedicadas a realizar
tests de usabilidad. Suelen tener espejos de una sola vía y cámaras de vídeo.
Grabación en video: Los test de usabilidad se pueden grabar en video para posterior
análisis. Un uso de los vídeos está en relación con la técnica de Análisis de Impacto, para,
una vez identificado cada problema de usabilidad, volver a los vídeos a comprobar cuántos
usuarios han tenido ese problema y cuánto les retardó en su tarea. También sirven las
grabaciones en video como medio de comunicación de la importancia de los problemas de
usabilidad, entre los expertos en usabilidad y los desarrolladores.
Observación: Esta técnica implica visitar a uno o más usuarios, tomar notas y tal vez
grabar en video las actividades del usuario. De todas formas, el observador no debería
interferir con el trabajo del usuario, de tal forma que todas las tareas del observador deben
realizarse de forma no obtrusiva.
Cuestionarios y Entrevistas: Esta técnica aplica métodos indirectos de estudio de la
usabilidad a través de las opiniones de los usuarios. Los cuestionarios pueden ser
distribuidos por correo, correo electrónico o directamente con el mismo software. Las
entrevistas se pueden llevar a cabo en persona o mediante conversación telefónica. Son
especialmente apropiadas para obtener la satisfacción subjetiva del usuario.
Focus Groups: En un focus group, se reúne a un grupo de entre seis y nueve usuarios para
discutir nuevos conceptos e identificar temas relevantes en un período de unas dos horas.
Cada grupo es llevado por un moderador que es responsable de mantener el enfoque del
grupo en cualesquiera que sean los temas de interés.
Registro del Uso Real: Registrar el uso implica tener un sistema de cómputo recogiendo
automáticamente estadísticas detalladas acerca del uso del sistema. Normalmente es una
forma de conseguir información acerca del uso de campo de un sistema tras su lanzamiento,
pero puede utilizarse como un método suplementario en test de usabilidad.
Retroalimentación del Usuario: Esta técnica consiste en recibir retroalimentación, dando
a los usuarios acceso a direcciones específicas de correo, grupos de noticias, o tablones de
anuncios electrónicos donde pueden enviar sus quejas y peticiones de cambio o mejora.
GOMS: Por sus siglas en inglés (Goals), Operadores (Operators), Métodos (Methods) y
reglas de selección (Selection rules). Esta técnica consiste en listar las posibles metas y sub-
metas del usuario, así como las acciones que tiene disponibles dentro del sistema
(operadores) y las alternativas (métodos), con los que el usuario cuenta para alcanzar las
metas, así como las reglas de selección para decidir la mejor alternativa para lograr una
meta en caso de contar con diferentes métodos.
1.1.1.4.1 Ciclo de Vida de la Usabilidad (Mayhew)
Mayhew [Mayhew, 99] presenta un método llamado ciclo de vida de la ingeniería de
usabilidad (ver figura 1.2), donde plantea las diferentes técnicas que pueden ser aplicadas,
mismas que a continuación se describen.
Capítulo I
Página 9
Figura 1. 2: Ciclo de vida de la ingeniería de usabilidad [Mayhew, 99]
Cuestionarios de Perfiles de Usuario: Los perfiles de usuario 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ística del puesto y de las tareas (por ej. Frecuencia de uso, estructura de
tareas),
Características físicas (por. Ej. Daltonismo).
Para cada usuario incluye una descripción general, una descripción de las características de
los usuarios, y un apartado sobre los requerimientos de usabilidad para cada tipo de usuario.
Entrevistas Contextuales: Tras reunir toda la información relacionada con el trabajo a
realizar (especificaciones de requerimientos, reunión con miembros del equipo, reunión con
Capítulo I
Página 10
los usuarios), y haber identificado a los actores y casos de uso clave, se realizan las
observaciones o entrevistas contextuales propiamente dichas. En las entrevistas el usuario
realiza sus tareas habituales, y el entrevistador le interroga sobre el porqué de sus
decisiones y acciones.
Diagramas de afinidad: En esta técnica cada observador anota en un Post-It cada una de
las observaciones que va recogiendo de lo observado de los usuarios en el entorno habitual
de trabajo. Cuando se reúnen todos los observadores, van poniendo sus notas en una pared
blanca, de una en una agrupando 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.
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
combinadas.
Task Sorting: esta técnica sirve para obtener el modelo de organización de tareas
directamente de los usuarios. Se les presentan las tareas de bajo nivel escritas en una tarjeta,
y se les pide que las agrupen del modo que tenga más sentido para ellos, dada la manera en
que suelen pensar y actuar en su trabajo. Una vez que están agrupadas se les pide que den
un nombre a cada grupo. Una vez que se tienen las jerarquías propuestas parea cada usuario
en el ejercicio, se intenta extraer de ellas una jerarquía que exprese las características
comunes a todas ellas.
Objetivos de Usabilidad: los objetivos de usabilidad se establecen al comienzo de un
proyecto con el fin de que dirijan todas las decisiones posteriores de diseño pueden ser de
varios tipos.
Objetivos Cualitativos: Este tipo de objetivos o requerimientos describen metas no
cuantificables. Son útiles para guiar los esfuerzos iniciales de diseño,
Objetivos Cuantitativos: se pueden cuantificar y existen tres tipos:
Objetivos de Rendimiento: Cuantifican el rendimiento real de un usuario
utilizando un sistema,
Objetivos de Satisfacción: Cuantifican el nivel de satisfacción del usuario
con una interfaz concreta,
Objetivos de Preferencia: cuantifican la preferencia de un usuario entre
interfaces alternativas, basadas en cierto grado de conocimientos de las
mismas.
Capacidades de Restricción de Plataforma: Esta técnica presenta una forma de describir
los aspectos relevantes de las plataformas hardware/software sobre las que va a funcionar el
sistema.
Maquetas de alta fidelidad: Son prototipos que se pueden ejecutar en una máquina. La
autora aconseja su uso cuando se dispone de una herramienta de creación de prototipos, y
se cuenta con experiencia en su uso.
Maquetas de Baja Fidelidad: son prototipos en papel. Únicamente incluyen suficiente
detalle en aquellos aspectos esenciales para dar al usuario el contexto necesario para poder
comprender cada paso en la navegación por la IU.
Guías de Estilo del Producto: Este documento recoge el modelo (estos es, reglas de
presentación) y los estándares de diseño de pantallas. Organiza en un único documento
Capítulo I
Página 11
todas las decisiones de diseño de IU con el objetivo principal de consignar la consistencia
en la IU en todo el producto. Puede establecerse a varios niveles: Plataforma, organización,
familia de productos o para un producto particular. Es útil que además de las decisiones de
diseño incluyan la lógica que ha motivado dichas decisiones para permitir futuros cambios.
Test Formales de Usabilidad: Se trata de los test más habituales en el campo de la IPO, en
los que s ele pide el usuario que realice una serie de tareas básicas con el prototipo del
sistema para poder observar que problemas experimenta el usuario, que errores comete y
como se recupera de los mismo. Cuando se realiza en la etapa de evaluación iterativa de
modelo conceptual, entonces se trata de seguir más al usuario que piense en voz alta que de
medir tiempo con exactitud. Por el contrario en niveles posteriores de diseño y pruebas, no
se interviene tanto por que se prueban objetivos de rendimiento específico.
Técnicas de Test Remoto: Permiten realizar el test de usabilidad en el entorno habitual de
trabajo del usuario, y ahorrar posibles desplazamientos y problemas con la agenda, la
autora describe cuatro variantes del test remoto:
Evaluación por Control Remoto: El ordenador del usuario se conecta vía internet
o vía telefónica con el ordenador del evaluador. El evaluador puede ver (y grabar) la
interacción del usuario con el sistema en tiempo real y comunicarse con el usuario,
de forma similar como se haría en un test de usabilidad tradicional,
Videoconferencia: El evaluador se comunica con el usuario, y puede ver la
interacción del usuario con el sistema mediante la videoconferencia,
Evaluación Remota Instrumentada: Consiste en la instalación de monitores
software que recogen datos de uso en el ordenador del usuario. Los datos se
empaquetan y se envían a los evaluadores para su análisis,
Evaluación Remota Semi-Instrumentada: Los usuarios identifican los problemas
de usabilidad en su uso normal de la aplicación. La aplicación tiene una función que
permite al usuario describir un problema de usabilidad que está experimentando en
un momento dado. La aplicación registra el estado del sistema en el momento que el
usuario invoca esta función y le pide la descripción del problema se empaqueta la
información de estado junto con la descripción del usuario y se envía a los
evaluadores.
Retroalimentación del Usuario: La autora nos propone una serie de técnicas para obtener
retroalimentación de los usuarios una vez que el sistema ha sido ya instalado:
Test de Usabilidad: Los mismos que se han descrito más arriba,
Entrevistas: Llevar a cabo las entrevistas para obtener las reacciones subjetivas de
los usuarios,
Cuestionario: Para obtener información de un número más amplio de usuarios se
puede elaborar, distribuir y analizar cuestionarios estructurados que incluyen
preguntas sobre la usabilidad del producto,
Estudios de Uso: Esta centrado en cómo se usa realmente el sistema. Un estudio de
este tipo puede revelar, por ejemplo, que funcionalidades se usan muy poco.
Entonces hay que estudiar porque, porque puede ser debido a que son muy difíciles
de encontrar debido a que son muy difíciles de aprender o recordar, y entonces ay
un problema de usabilidad identificado. Hay dos formas de llevar a cabo el estudio
de casos:
Observación Aleatoria: Se avisa a los usuarios que el observador va venir
algún momento de una franja horaria. El observador llega en cualquier
momento y observa la interacción del usuario con el sistema,
Capítulo I
Página 12
Monitores Software: Un monitor software se activa de forma aleatoria y
registra que funcionalidades se usan y cuando.
1.1.1.4 Cómputo Móvil.
Por “Cómputo Móvil" nos referimos a aquellas soluciones de alta tecnología donde no se
requieren cables que conecten visiblemente el equipo personal, e involucra dos avances
tecnológicos fundamentales: las redes inalámbricas para transmisión de datos, y la
miniaturización de los componentes de un equipo de cómputo. La cobertura de transmisión
y recepción de información en este tipo de dispositivos puede ser local o satelital (WiFi,
Bluetooth, RFID, GPRS, GPS). Todo lo anterior no sería posible sin el avance continuo del
desarrollo de aplicaciones y sistemas operativos sofisticados y especializados [Imielinski,
96]. Se puede definir la Computación Móvil como la serie de artefactos y equipos
portátiles, hardware, que hacen uso de la computación para lograr su funcionamiento, así,
se tiene a las computadoras portátiles, los cuadernos de notas computarizados, los teléfonos
celulares, smartphones, etc.
El campo de la computación móvil está basado en los principios de los sistemas
distribuidos y de la necesidad de integrar, en este tipo de arquitectura a clientes móviles.
Algunos de los conceptos asociados a este paradigma, que es actualmente un campo muy
activo en investigación y desarrollo, son los siguientes [Satyanarayanan, 96]:
Sistemas de redes móviles,
Acceso de información móvil,
Soporte para aplicaciones adaptativas,
Técnicas de ahorro de energía,
Sensibilidad respecto de la localización.
A continuación se detallan alguno de los requerimientos de hardware de los dispositivos
móviles:
Miniaturización. Uno de los requerimientos fundamentales de la miniaturización
en cómputo móvil es la capacidad de dotar de capacidades de computación a todos
los dispositivos que nos rodean en forma “invisible”. La situación actual de esta
tecnología cubre las necesidades de la computación ubicua,
Baja potencia. El desarrollo de los procesadores ha tenido siempre el objetivo de
aumentar su rendimiento. Para las aplicaciones de computación ubicua, la necesidad
de disponer de procesadores de baja potencia es prioritaria. Es necesario desarrollar
microprocesadores que funcionen en un gran rango de voltajes y que estén provistos
de mecanismos para el ahorro de energía,
Conexión sin hilos. La interconexión de todos los elementos que constituyen un
entorno y la incorporación del paradigma de la computación móvil tienen como
consecuencia la necesidad de establecer comunicaciones sin hilos. Aquí surge el
desafío de desarrollar el soporte físico necesario para lograr un gran ancho de
banda. Este campo es muy activo en investigación y desarrollo, ya que esta
tecnología permite el avance en otros campos de las telecomunicaciones y los
sistemas de información.
Respecto de las características que debe presentar el software de los dispositivos móviles,
se debe distinguir entre el requerido para establecer las conexiones entre los dispositivos
(software de soporte de la red) y el que gobierna las acciones de interacción entre el entorno
físico y el usuario.
Capítulo I
Página 13
Con relación a los problemas derivados de la interconexión de dispositivos, la computación
ubicua introduce nuevos desafíos en cuatro áreas principales: a) soporte total de
computación inalámbrica, b) ampliación del rango de ancho de banda, c) mejora de los
protocolos para tiempo real y d) mejora del enrutamiento de paquetes. Todas estas mejoras
son necesarias para hacer de la computación móvil un equivalente en desempeño a la
computación por cables físicos [Satyanarayanan, 96].
Un dato importante a considerar es el nivel de complejidad requerido para solucionar cada
uno de los problemas nuevos que surgen en cada propuesta, donde la complejidad es
creciente en un factor multiplicativo.
De esta manera el problema se traslada a la compatibilidad y a las soluciones propietarias
que existen con costos muy elevados, por lo que existe un área amplia de desarrollo y de
soluciones en esta línea de investigación. Otro de los problemas asociados al cómputo
móvil es la carencia de métodos y ambientes de modelado que permitan diseñar
configuraciones idóneas de dispositivos móviles a nivel conceptual y que permitan la
generación del código asociado a esta configuración.
1.1.1.5 Servicios Basados en Localización.
La literatura nos proporciona una serie de definiciones de estos servicios, como los que se
presentan a continuación:
El término servicio basado en localización, por sus siglas en inglés LBS, es un
término reciente donde denota las aplicaciones que integran la localización
geográfica (coordenadas espaciales), con la noción general de servicios [Schiller,
04],
En el contexto de las llamadas nuevas tecnologías de la información y las
telecomunicaciones, se describen a los LBS como una intersección entre: sistemas y
dispositivos móviles, Internet y sistemas de información geográfica con base de
datos espaciales [Steiniger, 06],
Un LBS es todo servicio o combinación de servicios que esté basado en la ubicación
del usuario en tiempo real [ASS, 11].
1.1.1.5.1 Servicios LBS
Los LBS son servicios personalizados basados en información acerca de la ubicación
geográfica de los usuarios. Para su operación se utiliza tecnología de posicionamiento
geográfico, por sus siglas en inglés GPS, bien sea del lado cliente/terminal o del lado
servidor/operador (servicio de posicionamiento suministrado por el operador de la red
basada en localización, por sus siglas en inglés NBL, y tecnología de comunicación de
redes para transmitir información hacia una aplicación LBS que pueda procesar y responder
la solicitud [wikiLBSpro, 11]. Formica nos muestra los servicios básicos que se ofrecen
dentro de estos servicios son los mostrados en la tabla 1.1 [Formica, 08]:
Capítulo I
Página 14
Tabla 1.1: Servicios Básicos [Formica, 08]
Acción Descripción
Orientación y Localización ¿Dónde estoy? ¿Dónde está?
Navegación ¿Cómo llego?
Búsqueda ¿Dónde está el más cercano?
Identificación ¿Quién es? ¿Cuál es?
Disparo de Alarmas ¿Qué sucede aquí?
Steiniger explica que existen una amplia gama de servicios basados en localización. La
figura 1.3 muestra una visión general de las principales categorías de aplicaciones LBS. Se
muestran las categorías para algunos campos de aplicación, es decir, navegación,
información, publicidad, facturación, juegos y ocio, y la diferente información sobre las
necesidades de la exactitud posicional, el medio ambiente y el tipo de servicio [Steiniger,
06].
Capítulo I
Página 15
Figura 1. 3: Categorías de LBS [Steiniger, 06].
1.1.1.5.2 Tipos de Servicios LBS
Formica clasifica más detalladamente estos mismos servicios de la siguiente manera
[Formica, 08]:
PULL: aquellos que entregan información en respuesta a pedidos generados
directamente por el usuario, algunos ejemplos se muestran en la tabla 1.2 [ESRI,
02],
Tabla 1.2: Ejemplos de servicios PULL [ESRI, 2002].
LBS Descripción
Asistencia en Emergencias (E-911)
Asistencia en carretera, seguimiento de vehículos, reporte y recuperación de vehículos robados, informes de tráfico (bajo demanda) entre otros.
Servicios Pull Instrucciones de viaje (Estoy aquí, cómo hago para llegar allá). Ej. Servicios de instrucciones de conducción.
Asignación de Recursos (Ej. Taxis)
Recursos que operan sobre un área cercana a donde se genera una solicitud pueden ser eficientemente asignados (Ej. despachados desde una central).
Páginas Amarillas Móviles
(¿Dónde está el negocio más cercano?) El usuario indica la categoría de negocio (hospitales, sitios de entretenimiento, etc.) en el cual está interesado y obtiene un conjunto de listados en orden de proximidad a la ubicación del usuario.
PUSH: aquellos que entregan información requerida indirectamente por usuarios,
algunos ejemplos se muestran en la tabla 1.3 [ESRI, 02].
Capítulo I
Página 16
Tabla 1.3: Ejemplos de servicios PUSH [ESRI, 02].
LBS Descripción
Publicidad Móvil Cupones electrónicos y otro tipo de descuentos o premios.
Buscadores de Amigos
Permite a los usuarios encontrar la ubicación de sus amigos o familia. El servicio automáticamente notifica a un usuario cuando una persona seleccionada (que cuenta con un dispositivo inalámbrico) está cerca o ha ingresado a una zona específica. Ej. Notificar a un padre cuando su hijo ha llegado a casa, al colegio o a otra ubicación específica.
Alertas de Zonas
Similar al anterior, indica cuando una persona o vehículo ha entrado en o ha salido de una región específica. Ej. Seguimiento de pacientes con enfermedad de Alzheimer o rastreo de usuarios con alguna restricción por parte de alguna corte.
Páginas Amarillas Móviles
¿Dónde está el negocio más cercano? El usuario indica las categorías de negocio (hospitales, sitios de entretenimiento, etc.) de su interés y obtiene un conjunto de listados en orden de proximidad a la ubicación del usuario.
Servicios de Compras
Notifica cuando está cerca de un proveedor que surta un producto en el cual pueda estar interesado o el cual haya estado buscando. Este tipo de servicio, conocido como comercio móvil (m-comercio), permite poner en contacto compradores y vendedores.
Información Instantánea
Permite a los usuarios obtener la información de un sitio de interés y obtener información sobre él, bien sea desde una base de datos central o desde el sitio en sí mismo a través de algún mecanismo de transferencia inalámbrica.
1.1.1.5.3 Arquitectura de los Servicios Basados en Localización (LBS).
Formica explica que los LBS son Servicios de información que pueden ser accedidos desde
dispositivos móviles a través de redes que hacen uso de la posición de los mismos.
Los datos consisten básicamente en coordenadas X-Y generadas por un sistema capaz de
determinar la ubicación, y nos muestra que estos servicios surgen de la convergencia de
diferentes tecnologías y sistemas como se muestra en la figura 1.4.
Figura 1. 4: Tecnologías que convergen en los LBS [Steiniger, 06].
Capítulo I
Página 17
Si bien podemos observar existe un gran parentesco entre los Sistemas de Información
Geográficos, GIS, y los LBS. Los GIS han sido creados para aplicaciones destinadas a
usuarios con amplia experiencia en sistemas geográficos, capaces de interpretar los datos
que se obtienen de estos sistemas, además de que su ejecución necesita de equipos de
cómputo con mayores capacidades que un dispositivo móvil, ya que las operaciones con
estos sistemas requieren de un consumo alto de los recursos del equipo.
Los LBS deben poder ser interpretados por cualquier usuario, sin necesidad de que los
usuarios requieran de un gran conocimiento de datos espaciales profesionales, ya que se
adaptan a las diferentes restricciones que presentan los dispositivos móviles, como son: las
pantallas pequeñas, la limitación de energía, los métodos de entrada, etc. Por mencionar
algunas restricciones.
Steiniger explica que los elementos necesarios para los LBS son los siguientes [Steiniger,
06]:
Dispositivos móviles: Una dispositivo el cual contenga una aplicación donde el
usuario solicita la información necesaria. Los resultados se pueden dar en forma de
voz, imágenes, o texto. Los posibles dispositivos pueden ser: PDA’s, teléfonos
móviles, computadoras portátiles, entre otros,
Red de Comunicación: La red móvil en donde se trasladan los datos del usuario y
la solicitud de servicio desde el terminal móvil al proveedor de servicios y, la
información requerida del usuario,
Posicionamiento de componentes: Para el tipo de servicio la posición del usuario
tiene que determinarse. La posición del usuario se puede obtener ya sea mediante el
uso de la red de comunicaciones móviles o mediante el Sistema de Posicionamiento
Global (GPS). Otras posibilidades para determinar la posición son estaciones
WLAN (Wireless Local Area Network). Los métodos de posicionamiento de este
último en particular, pueden ser utilizados para la navegación en interiores como en
un museo. Si la posición no es de forma automática también puede ser especificada
manualmente por el usuario,
Servicio y Proveedor de la Aplicación: El proveedor de servicios ofrece diferentes
servicios para el usuario y es responsable del procesamiento de la solicitud de
servicio. Estos servicios ofrecen el cálculo de la posición, de una ruta, la búsqueda
de páginas amarillas con respecto a la posición o la búsqueda información
específica sobre los objetos de interés de los usuarios,
Datos y proveedor de contenidos: Los prestadores de servicios no suelen
almacenar y mantener toda la información solicitada por los usuarios. Por lo tanto
consultan las bases de datos geográficas para la información de la ubicación.
Capítulo I
Página 18
Figura 1. 5: Los componentes básicos de un LBS [Steiniger, 06].
Estos servicios pueden ser utilizados no solo en exteriores, existe una división tanto para
interiores (indoor) como para exteriores (outdoor), y difieren en la forma de determinar el
posicionamiento de un usuario (dispositivo móvil).
La posición de un dispositivo actualmente es realizado comúnmente por el GPS y el Cell-
ID de la estación base más cercana del transmisor-receptor. El GPS proporciona una
posición muy precisa (de hasta 5 m) mientras que el Cell-ID entrega una posición más
imprecisa (de hasta 100 m). El GPS es un método de posicionamiento al aire libre. Para
obtener posiciones de interior con gran precisión se utilizan métodos de localización
basados en WLAN.
Fernando Seco explica que básicamente en estos servicios necesitamos estos elementos
como nos muestra una perspectiva de una manera diferente en la figura 1.6 [Seco, 08].
Figura 1. 6: Elementos de los LBS [Seco, 08].
En general, es importante señalar que la posición y la exactitud influyen en la aplicación de
los servicios basados en localización. La figura 1.7 muestra un número de métodos de
posicionamiento, con su precisión y su aplicabilidad a los usuarios en interiores y exteriores
[Steiniger, 06].
Capítulo I
Página 19
Figura 1. 7: Tecnologías de localización [Seco, 08]
1.1.1.5.3.1 Interiores (Indoor)
El GPS es la solución “casi universal” para obtener localización precisa y rápida en
cualquier punto del planeta. Lamentablemente solo es para determinados entornos en
exteriores, y en la mayoría de los interiores, el GPS no es operativo. Sin embargo, en dichos
lugares transcurre gran parte de la actividad humana.
Fernando Seco explica que las soluciones de localización en interiores se hacen a base de
sistemas de posicionamiento local (LPS, Local Positioning Systems) y define que son
sistemas de localización alternativos creados para funcionar en entornos locales.
De las varias posibilidades tecnológicas para el diseño de LPS, las basadas en señales de
radio frecuencia (RF) experimentan un gran auge en la actualidad.
A continuación se muestran las tecnologías más utilizadas en servicios basados en
interiores (indoor), como se muestra en la figura 1.8 [Seco, 08].
Infrarrojos (Active Badge),
Ultrasonidos (Cricket y Active Bat),
Posicionamiento Bluetooth,
Posicionamiento WiFi (RADAR y Ekahau),
Ultrawideband (Ubisense),
Indoor GPS.
Figura 1. 8: Interiores (Indoor) [Seco, 08]
Capítulo I
Página 20
1.1.1.5.3.2 Exteriores (Outdoor)
Estos servicios son los que se ofrecen para tener conocimiento de calles dentro de ciudades,
carreteras, servicios (autoservicios, hospitales, museos, restaurantes, hoteles, etc.), su medio
de identificación de posicionamiento se realiza por lo general por el GPS. Las tecnologías
más utilizadas para este tipo de servicios son [Seco, 08]:
GPS y sus derivados,
Posicionamiento en redes celulares GSM y UMTS.
1.1.1.5.4 Funcionamiento de los LBS
Steiniger en su trabajo Foundations of Location Based Services, explica el funcionamiento
básico de estos servicios. A continuación se describe un ejemplo de solicitud de estos
servicios y la descripción de los mismos.
Tomando como ejemplo la búsqueda de un restaurante chino, el proceso de esta solicitud se
describe a continuación, y se muestra en la figura 1.9.
Figura 1. 9: Funcionamiento de los LBS [Steiniger, 06].
El usuario expresa su necesidad de localizar un restaurante chino que se encuentre cerca de
donde se localiza. Por lo tanto, el usuario realiza su solicitud mediante la selección de la
función apropiada en su dispositivo móvil:
Por ejemplo, menú: información de la posición => búsquedas => restaurantes> Restaurante
chino.
Paso 1.- Ahora bien, si la función se ha activado, la posición real del dispositivo móvil se
obtiene del servicio de posicionamiento. Esto se puede ser por medio del GPS que está en
uso o un posicionamiento de la red de servicios. Después el cliente móvil envía la solicitud
de información, que contiene el objetivo de la búsqueda y la posición a través de la red de
comunicaciones, lo que llamamos gateway.
Paso 2.- El gateway tiene la tarea de intercambiar mensajes entre la red móvil y el Internet.
Por lo tanto conoce las direcciones web de servidores y varias rutas de la solicitud a un
Capítulo I
Página 21
servidor específico. El gateway almacenará también información sobre el dispositivo móvil
que ha solicitado la información.
Paso 3.- El servidor de aplicaciones lee la petición y se activa el servicio apropiado, en
nuestro caso un servicio de búsqueda.
Paso 4.- Ahora, el servicio analiza el mensaje nuevo y decide qué información adicionar,
aparte de los criterios de búsqueda (restaurante chino), la posición del usuario es necesaria
para responder a la solicitud. En nuestro caso el servicio se encuentra en las páginas
amarillas de una región específica, por lo que pedirá a un proveedor de datos esta
información.
Paso 5.- Además en el servicio se encuentra la información sobre las carreteras y caminos
que se necesita para comprobar si el restaurante es accesible (por ejemplo, a veces, un
restaurante en el otro lado del río podría no ser accesible, ya que no existe un puente cerca).
Paso 6.- Habiendo toda la información del servicio almacenada en un buffer espacial,
realizará la consulta de rutas para obtener la ubicación de restaurantes chinos. Después de
calcular una lista de los restaurantes cercanos, el resultado se envía al usuario a través de
Internet, el gateway y la red móvil.
Paso 7.- Los restaurantes ahora se mostraran al usuario, ya sea como una lista de texto
(ordenados por distancia) o dibujado en un mapa. Luego el usuario puede pedir más
información sobre los restaurantes (por ejemplo, el menú y los precios), activando un tipo
diferente de servicio.
CAPÍTULO II
Problema Abordado En este capítulo se presenta la problemática que aborda esta investigación, así como las
soluciones que fueron planteadas y la propuesta de solución, muestra los objetivos de la
investigación así como sus alcances y limitaciones.
Capítulo II
Página 23
2.1 Introducción. ¿Cuántas veces no nos hemos sentido perdidos o desorientados en una ciudad, carretera,
colonia, etc.?, ¿Cuántas veces no hemos necesitado de alguien que nos oriente?, ¿Cuántas
veces hemos consultado mapas o hacer alguna llamada telefónica de orientación?
Si bien existen diversas opciones de solución como son mapas, croquis, guías turísticas, etc.
que son un buen auxilio, estos documentos en soporte impreso tienen diversas limitaciones.
Por ejemplo, no están actualizadas al día en que deseamos consultarlos y no pueden
especificarnos la ubicación en donde nos encontramos, ni informarnos del contexto que
rodea al usuario, de los sitios que tiene interés en localizar, ni tampoco de las alternativas
que puede tener para desplazarse a estos sitios.
Atendiendo estas limitaciones, una de las soluciones de mayor impacto en los últimos años
son los servicios contextuales, los cuales son una convergencia de las tecnologías GPS y el
cómputo móvil y los GIS. Los servicios contextuales de localización permiten, entre otros:
orientar e informar a los usuarios acerca de vialidades, comercios y lugares turísticos; y
proporcionar en cualquier momento y en cualquier lugar, datos acerca de la ubicación de
personas, y conocimiento de diversos eventos con relación a la circulación vehicular, así
como mantener actualizada la información de la ciudad y carreteras, como son
modificaciones en sus vialidades y puntos de interés.
Como se desprende del párrafo anterior, este tipo de aplicaciones son una convergencia de
diversas tecnologías que demandan el empleo de métodos específicos para su desarrollo y
en particular para asegurar la satisfacción de los usuarios.
La disciplina Interacción Persona Ordenador (IPO), conocida por sus siglas en inglés como
HCI, se enfoca en la interacción de los usuarios con los sistemas, y la usabilidad por su
parte se enfoca en el desarrollo de métodos para mejorar la facilidad de uso de las
aplicaciones.
Existen estándares tales como ISO/IEC 9241 y ISO/IEC 9126 y diversos trabajos dentro de
la literatura IPO para el análisis, diseño y desarrollo de aplicaciones con una toma en cuenta
explícita de la usabilidad. Sin embargo, para el caso de sistemas de cómputo móvil
aplicados a servicios contextuales, por sus siglas LBS, no encontramos referencias de
estándares o metodologías específicos, en particular que permitan mejorar el uso de estas
aplicaciones y la satisfacción de los usuarios.
La usabilidad es un factor de calidad de suma importancia en el desarrollo de software, por
lo que su toma en cuenta para el desarrollo de LBS permitiría mejorar y desarrollar
aplicaciones usables en dispositivos móviles, para que el usuario final pueda realizar sus
tareas de manera que los LBS favorezcan sus habilidades y apoye sus debilidades.
Capítulo II
Página 24
2.2 Identificación del Problema. Los servicios contextuales basados en localización han surgido de los avances tecnológicos
en computación y en telecomunicaciones de los últimos años, como un auxiliar para
proporcionar a los usuarios información de su ubicación y del contexto que lo rodea con la
finalidad de sugerirle sitios de su interés, así como orientarlo y guiarlo hacia estos destinos
y proporcionarle otros servicios relacionados.
Pero estos servicios contextuales presentan limitaciones debidas al diseño de los propios
dispositivos móviles y de diseño de las aplicaciones de los servicios contextuales basados
en localización [Kjeldskov, 05]. En gran medida debido a que los fabricantes de estos
dispositivos hoy en día dan prioridad a mantener una línea propia de diseños de sus
dispositivos que a establecer criterios que cumplan con las expectativas de los usuarios o
atiendan los retos que las aplicaciones móviles presentan [Michael F.,11].
Los desarrolladores de los servicios contextuales basados en localización realizan diseños
que ofrecen funcionalidades de los servicios contextuales a los cuales los usuarios deben
adaptarse, reduciendo la facilidad de realización de tareas específicas. Lo anterior aumenta
de dificultad si tomamos en cuenta las nuevas funcionalidades y modalidades de interacción
que son incorporados constantemente a estos dispositivos [Hernán A, 06].
Una alternativa a este problema es proponer nuevos métodos para el desarrollo de sistemas
LBS enfocándonos a las necesidades de los usuarios y no solamente en la inclusión de
nuevas y más complejas funcionalidades.
La falta de consideración de la usabilidad dentro del desarrollo de los servicios impide que
los dispositivos móviles y los mismos servicios se aprovechen más ampliamente
disminuyendo la satisfacción de los usuarios, así como su interés en estas tecnologías.
2.2.1 Complejidad del problema.
Aunque hoy en día existen metodologías o procesos de desarrollo para el desarrollo de
servicios contextuales, no contemplan técnicas IPO que incorporen la usabilidad dentro de
su desarrollo, ni toman en cuenta las características específicas de los usuarios y los
servicios contextuales.
Atender esta problemática ha requerido una revisión y análisis comparativo muy detallado
del estado del arte en técnicas IPO, una revisión bibliográfica extensa acerca de
metodologías de desarrollo para aplicaciones de cómputo móvil, así como un estudio
amplio de las características y requerimientos para el desarrollo de aplicaciones LBS.
Con base en la investigación documental anteriormente descrita, se desarrolló una amplia
exploración de alternativas para el desarrollo nuevos métodos de desarrollo de LBS. El
énfasis principal de este trabajo fue la inclusión de la usabilidad como factor clave para
asegurar la satisfacción de los usuarios, a partir de una toma en cuenta explícita de las
características de los dispositivos móviles y de los diferentes usuarios de estos servicios.
Se tiene adicionalmente como producto de esta tesis un manual para desarrollo de LBS que
se pondrá a disposición de desarrolladores de este tipo de aplicaciones en CENIDET. Una
vez que sea empleado para construir algunas aplicaciones y se le hagan eventuales ajustes
se considerará su difusión por parte de las autoridades de este Centro.
Capítulo II
Página 25
2.3. Aproximación de la Solución. En esta sección mostramos tres propuestas de solución pensadas para esta problemática, las
cuales explicamos en las siguientes secciones.
2.3.1 Primer Propuesta de Solución.
Figura 2. 1: Capas
En esta propuesta de solución se muestran tres diferentes capas, donde en la capa superior
se contempla la principal fuente de los elementos que necesitaremos para el desarrollo de
esta investigación: los diferentes estándares de usabilidad ya existentes, los dispositivos
móviles, los servicios contextuales y los usuarios.
La segunda capa denominada de filtrado, es donde se efectúan cuatro diferentes filtros:
De los dispositivos móviles estudian las diferentes capacidades que deben ser
propias del dispositivo, para cumplir con los requerimientos mínimos necesarios
para la ejecución de un servicio contextual basado en localización (indoor y
outdoor),
De los dispositivos móviles estudian las diferentes capacidades que deben ser
propias del dispositivo, para cumplir con los requerimientos mínimos necesarios
para la ejecución de un servicio contextual basado en localización (indoor y
outdoor),
De los servicios contextuales se filtran algunos de los servicios basados en
localización más comunes (indoor y outdoor) y sus características,
De los usuarios de los servicios contextuales basados en localización (indoor y
outdoor), se filtran sus diferentes particularidades, para así poder realizar la
definición de perfiles.
Una vez filtrados y analizados estos elementos, se determinan los factores de usabilidad
más adecuados para el desarrollo de servicios contextuales basados en localización (indoor
y outdoor).
Una vez determinados los factores de usabilidad se propone su inclusión en un proceso
metodológico que permita guiar el desarrollo de aplicaciones LBS, el cual sería sometido a
una evaluación heurística para verificar si cumple con los términos de usabilidad que se
busca implementar dentro de los servicios contextuales.
Una vez creada la metodología servirá como guía para el desarrollo de LBS, con
características de usabilidad apropiadas para ese tipo de aplicaciones en específico. La
figura 2.2 muestra un panorama más descriptivo de estas capas.
Capítulo II
Página 26
Esta propuesta de solución no fue viable ya que los estándares no son lo suficiente
descriptivos para el desarrollo de software, tienen un enfoque más normativo y de
evaluación que de desarrollo, es por ello que optamos por buscar otra solución.
Figura 2. 2: Primera propuesta de solución
2.3.2 Segunda Propuesta de Solución.
Esta propuesta de solución consiste en relacionar un conjunto de métricas seleccionadas de
la literatura con los diferentes componentes que pueden formar un LBS, como se muestra
en la figura 2.3.
Capítulo II
Página 27
Figura 2. 3: Segunda propuesta de solución
La idea general de esta propuesta es encontrar una métrica que tenga relación directa con
algún componente LBS. Se parte del supuesto de que al realizar modificaciones a un
componente del LBS, tengamos una mejora de dicha métrica. La idea central se presenta en
la figura 2.4.
Figura 2. 4: Aumento de nivel de métrica
Esta propuesta fue descartada ya que carecemos de estudios en la literatura, que demuestren
que con la modificación de ciertos componentes se obtenga el aumento en métrica de
usabilidad.
2.3.3 Tercera Propuesta de Solución.
La tercera propuesta de solución se basa en realizar un filtrado de técnicas de la disciplina
IPO que nos permita obtener los diferentes artefactos requeridos en las fases de análisis,
diseño y desarrollo de servicios contextuales basados en localización (LBS).
Para realizar el filtrado, se hará una selección de técnicas IPO tomando en cuenta las
especificidades de los artefactos requeridos para los siguientes tres contextos que se
contemplan en el desarrollo de los LBS:
Contexto móviles,
Contexto de la Aplicación,
Contexto del usuario.
Una vez seleccionadas estas técnicas, se construirá un proceso de desarrollo el cual
integrará el proceso del desarrollo de software, el proceso de desarrollo de la usabilidad y el
proceso de desarrollo de aplicaciones móviles (tomando tres procesos de desarrollo de
Capítulo II
Página 28
aplicaciones móviles base para realizar un proceso representativo de aplicaciones móviles)
y realizar un solo proceso específico para LBS.
La figura 2.5 muestra claramente el panorama de la propuesta de solución, la cual en
recuadro de “cómputo móvil” nos muestra los artefactos a contemplar dentro del desarrollo
de nuestros LBS tomados de la propuesta de Nivala para el desarrollo de aplicaciones
móviles [Nivala, 03]. Por otra parte tenemos dos propuestas IPO mostradas en el recuadro
verde, [Nielsen 93], [Mayhew 99]. De estas propuestas se obtienen un conjunto de técnicas
las cuales se relacionan con los diferentes artefactos a desarrollar, y finalmente se realiza un
análisis y selección de las técnicas que mejor se ajusten para obtener estos artefactos.
Figura 2. 5: Tercera Propuesta de Solución
A continuación se elabora un estudio de los procesos de desarrollo de las aplicaciones
móviles, y se plantea la unificación de un proceso de desarrollo que contemple los procesos
de aplicaciones móviles (proceso obtenido), de desarrollo de software, y de usabilidad.
Una vez unificado el proceso, se incorporan las técnicas seleccionadas, acoplándolas a las
fases a la que correspondan y completando el proceso de desarrollo.
Esta propuesta de solución es en la que nos basaremos, ya que existen estudios como la
tesis doctoral de Ferré “Marco de Integración de la Usabilidad en el Proceso de Desarrollo
del Software” [Ferre, 05], que incorpora usabilidad en el desarrollo del software a través de
técnicas expuestas por la IPO con resultados satisfactorios.
Capítulo II
Página 29
2.4 Objetivo General Desarrollar un marco metodológico para la incorporación de usabilidad en el análisis,
diseño y desarrollo de servicios contextuales basados en localización (LBS), a partir de
técnicas para el desarrollo de sistemas de interacción persona ordenador (IPO) y tomando
en cuenta los perfiles de los dispositivos móviles y de los usuarios.
2.4.1 Objetivos Específicos
Estructurar un proceso de desarrollo integrado de LBS, especificando las técnicas y
actividades a desarrollar en cada etapa,
Desarrollar un manual para el desarrollo de LBS, tomando en cuenta usabilidad.
2.5 Alcances Se seleccionó un conjunto de técnicas a partir de dos propuestas de la IPO, para ser
tomadas en cuenta dentro del proceso de desarrollo de LBS,
Se seleccionaron tres metodologías para el desarrollo de aplicaciones de cómputo
móvil, analizando la similitud entre ellas para obtener sus tareas más
representativas,
Se analizaron y seleccionaron las características de los siguientes contextos dentro
de nuestro proceso de desarrollo de LBS:
Contexto móviles,
Contexto de la Aplicación,
Contexto del usuario.
Se incorporaron tres procesos de desarrollo (software, usabilidad, modelo obtenido
del proceso de desarrollo de aplicaciones móviles) en un solo proceso, para el
desarrollo de LBS,
El proceso de desarrollo integrado de LBS se basó en el estudio de dos propuestas
de diferentes autores de la IPO y tres propuestas para el desarrollo de aplicaciones
de cómputo móvil,
El estudio de las características de LBS, se realizó con base a los conceptos
propuestos por Nivala [Nivala, 03],
Se evaluó el proceso de desarrollo integrado de LBS, tomando como caso de estudio
el prototipo de un LBS funcional “Google Maps”,
Dentro del caso de estudio se consideró la realización de tres de las tareas más
representativas de un LBS: Trazado de ruta, la búsqueda de objetos en un mapa, la
búsqueda de un lugar en específico introduciendo el nombre,
El proceso de desarrollo de LBS se centró en la implementación de usabilidad en el
análisis, diseño y desarrollo de servicios contextuales basados en localización.
Capítulo II
Página 30
2.6 Limitaciones Se limitó la metodología a dispositivos basados en el sistema operativo Android,
El proceso de desarrollo es específico para LBS en exteriores y en interiores (indoor
y outdoor),
La evaluación del proceso de desarrollo integrado de LBS, se limitó a la fase de
análisis, y consistió en su capacidad para ofrecer una propuesta de mejora a las
deficiencias identificadas en un sistema existente, en este caso “Google Maps”.
CAPÍTULO III
Estado del Arte En este capítulo se muestran algunos de los trabajos más relevantes relacionados con esta
investigación
Capítulo III
Página 32
3.1 Incorporación de usabilidad en el proceso de desarrollo de
software
3.1.1 Integración de la IPO y la Ingeniería del Software: MPIu+a
En este trabajo se propone la incorporación de aspectos de usabilidad y accesibilidad dentro
del proceso de desarrollo del software. Se dice que en un desarrollo clásico estos aspectos
se ven involucrados en las últimas fases de desarrollo de software, cuando realmente se
puede hacer poco para modificar el software.
Señalan que los diseños centrados en el usuario a diferencia de los desarrollos clásicos, a
partir de diversas estrategias, involucran al usuario en las diferentes fases del desarrollo.
Consideran que la ingeniería de usabilidad debe establecer objetivos de usabilidad medibles
desde el principio del proyecto y verificar su cumplimiento conforme evoluciona el sistema
El modelo que proponen añade a la ingeniería de software los siguientes rasgos que se
pueden clasificar de la siguiente manera:
Actividades estructuradas del análisis de requerimientos, donde la usabilidad cobra
importancia vital desde el primer momento,
Actividades estructuradas específicas de soporte al diseño de la Interfaz de Usuario,
Actividades de evaluación de los objetivos de usabilidad mediante iteraciones.
Figura 3. 1: Modelo de proceso integración de usabilidad más accesibilidad [Granollers, 04].
Las principales características del modelo de proceso, son:
1. Organización conceptual. El esquema está organizado en base a una serie de módulos o
etapas que determinan la fase de desarrollo en la que nos encontramos y ubica en un nodo
concreto la actividad del conocimiento existente en IPO.
Capítulo III
Página 33
2. Tres pilares básicos. Una de las metas más importantes de este modelo de proceso es
conseguir “casar” el modelo de desarrollo de sistemas interactivos de la Ingeniería del
Software con los principios básicos de la Ingeniería de la Usabilidad y los de la
accesibilidad proporcionando una metodología que sea capaz de guiar a los equipos de
desarrollo durante el proceso de implementación de un determinado sistema interactivo
3. El Usuario. Si alguien tiene la potestad de calificar algo como “userfriendly”, es
únicamente el usuario, que es la persona que interacciona con el sistema.
4. Un método iterativo. Establecer procesos repetitivos es un aspecto natural que se da en
cualquier otro ámbito de ingeniería.
Con este trabajo pretenden proporcionar no solo una metodología útil y comprensible, sino
también definir y resolver el índice de calidad en términos de usabilidad del software, así
como desarrollar una herramienta de soporte para que los ingenieros trabajen bajo el
modelo de proceso propuesto [Granollers, 04].
3.1.2 Integrating Usability Techniques into Software Development
El objetivo de este trabajo es combinar el análisis orientado a objetos (OO) y el diseño de la
usabilidad para crear sistemas unificados. Se propone un diseño centrado en el usuario, el
cual contempla la usabilidad desde las fases más tempranas posibles, donde podría tener
mayor impacto la mejora del diseño inicial, con la finalidad de eliminar posibles retrocesos
en el desarrollo[Anderson, 01].
Se trabaja con dos equipos a cargo de un especialista en el desarrollo de software y uno de
usabilidad. El proceso de usabilidad se integra al proceso de desarrollo del software,
mediante la herramienta RUP (Rational Unified Process), como se muestra en la figura 3.2.
Figura 3. 2: Construcción de la fase
Capítulo III
Página 34
La usabilidad centra sus actividades en el estudio de usuarios finales, identificando sus
niveles de experiencia en computación, así como las tareas comunes a realizar dentro de la
aplicación, tareas que no son comunes dentro del desarrollo del software. Algunos
diagramas son representados mediante UML para que algunos analistas entiendan con
facilidad los procedimientos.
Se incluyen diversas técnicas dentro del proceso de desarrollo, como son las siguientes:
Perfeccionar el producto de software de acuerdo a los perfiles de los usuarios
asegurándose de que todo el equipo tiene una profunda comprensión de los
usuarios,
Dar prioridad a las vistas para integrar la usabilidad y los requerimientos
funcionales,
Proporcionar una interpretación completa y estructurada por parte de los ingenieros
de usabilidad,
Construir el software con un diseño centrado en el usuario y proporcionar una guía
en el resto del proceso.
3.1.3 Paper or Interactive? A Study of Prototyping Techniques for
Ubiquitous Computing Environments
Se presenta una propuesta para el desarrollo de prototipos, con una toma en cuenta de
usabilidad, en el campo de la computación ubicua.
En este trabajo tratan de determinar el nivel adecuado de la creación de prototipos fidelidad
(apariencia) y automatización (intervención de cantidad de usuarios) para diseñar con éxito
aplicaciones para computación ubicua.
Para ello diseñaron Kitchen-Net, una aplicación ubicua para la localización de elementos de
cocina. Para esta evaluación desarrollaron un prototipo en papel y uno interactivo
(ejecutable) de la aplicación llamada “Kitchen-Net”.
El prototipo en papel se utilizan bocetos y notas que representan las pantallas de Kitchen-
Net, mientras un investigador juega el papel de asistente realizando el intercambio de
pantallas, respondiendo a las preguntas orales y los eventos del usuario, con este prototipo
se incorporan importantes cambios en la aplicación de una manera rápida.
Remplazamos el prototipo de papel por una Tablet de mano, este prototipo responde a los
sucesos registrados por el asistentes, eliminando la función que realizo el investigador en el
prototipo de papel, para ello necesitaron dos semanas para poner en practica este prototipo
e incorporar los cambios importantes que son necesarios.
Los resultados obtenidos mediante estos dos prototipos fueron que el prototipo realizado en
papel tuvo pocos comentarios de mejora mientras que el prototipo implementado en la
Tablet tuvo más comentarios para el desarrollo de mejoras. Se piensa que la ejecución del
prototipo en papel no muestra una interacción real con la aplicación, este tipo de
aplicaciones ubicuas que son diseñadas para interacciones con usuarios es necesario
aplicarlos en contextos reales de trabajo para obtener mayor fidelidad de los resultados.
Los prototipos de papel nos han servido para detallar y crear de manera mas interactiva las
interfaces, nos han ayudado a disminuir costes en el rediseño de la aplicación, pero no han
funcionado para realizar una evaluación [Liu, 03].
Capítulo III
Página 35
3.1.4 Usability Engineering Methods for Software Developers
En este trabajo se resalta la importancia de tomar en cuenta la usabilidad en etapas
tempranas del desarrollo de software, destacando cinco atributos que deben tener las
aplicaciones como son el aprendizaje, el error, la memoria, la eficiencia y la satisfacción
[Holzinger, 05].
Se proponen diferentes métodos de evaluación de la usabilidad, los cuales se dividen en
métodos de inspección de usabilidad y métodos de prueba de usabilidad.
Los métodos de inspección de usabilidad son un conjunto de métodos para la detección de
problemas de usabilidad para mejorar del diseño de las interfaces. Estos métodos se basan
en normas e incluyen evaluación heurística y recorridos cognitivos.
Los métodos de prueba de usabilidad trabajan con los usuarios finales para proporcionar
información directa acerca de como se usan los sistemas, e identifica problemas específicos
de interfaz. Existen varios métodos de prueba de usabilidad como son el pensamiento en
voz alta, la observación y los cuestionarios.
En la tabla 3.1 se presenta una comparativa de los diferentes métodos clasificados en los
métodos de inspección usabilidad y los métodos de prueba de usabilidad. Tabla 3. 1: Comparativa de métodos de evaluación de usabilidad [Holzinger, 05]
No se explica si los diferentes métodos pueden ser complementados unos con otros para
tener mejores resultados.
3.1.5 Marco de Integración de la Usabilidad en el Proceso de Desarrollo
de Software.
Se presenta un análisis y comparativa de diferentes propuestas de autores pertenecientes a
la disciplina de la IPO, y se propone su incorporación en las diferentes fases del desarrollo
de software [Ferre, 05].
Capítulo III
Página 36
Se describe la forma de adoptar las técnicas de la IPO dentro del desarrollo de software, y
en particular una solución a la incorporación de usabilidad, cambiando el enfoque clásico
de la usabilidad que consiste en solo realizar evaluaciones.
La prueba de estas técnicas se aplicó en el proyecto europeo STATUS, el cual consistió en
el desarrollo de un software que incorpora estas técnicas. Fue probado por diferentes
usuarios mostrando resultados claros de usabilidad [Ferre, 05].
3.1.6 Comparativa de trabajos
En este apartado se muestra una comparativa de los trabajos encontrados relacionados con
nuestra investigación. Se identifican las tareas a realizar para la incorporación de usabilidad
en el desarrollo de software, si utilizan un diseño centrado en el usuario (DCU) y para qué
tipo de desarrollo de software se propone, tal como se muestra en la tabla 3.2.
Capítulo III
Página 37
Tabla 3. 2: Comparativa de Trabajos
Trabajos Diseño Centrado en el
Usuario (DCU) Técnicas de usabilidad Software
Convencional Aplicaciones
Móviles Análisis Diseño Evaluación
Integración de la IPO y la Ingeniería del Software: MPIu+a
X X X X
Integrating Usability Techniques into Software Development
X X X X X
Paper or Interactive? A Study of Prototyping Techniques for Ubiquitous Computing Environments
X X X
Usability Engineering Methods for Software Developers
X X X X
Marco de Integración de la Usabilidad en el Proceso de Desarrollo de Software
X X X X X
Esta investigación X X X X X
Capítulo III
Página 38
3.2 Incorporación de Usabilidad en Aplicaciones Móviles En esta sección se muestran algunos trabajos relacionados con la incorporación de
usabilidad en aplicaciones móviles. No se encontraron estudios de la IPO para aplicaciones
móviles.
3.2.1 A Qualitative Review of Empirical Mobile Usability Studies
En este trabajo se destaca la importancia de la usabilidad en las aplicaciones móviles,
debido que el mercado propone aplicaciones y servicios que se ejecutan en cualquier
momento y lugar, y esto implica la conectividad, la comunicación y los servicios de datos.
Se indica que a pesar de que existe un sinnúmero de investigaciones sobre usabilidad en el
campo de la interacción persona-ordenador (IPO), no se encuentran documentados trabajos
que tomen en cuenta la incorporación de la usabilidad en el proceso de desarrollo de
aplicaciones de computación móvil. La revisión abarca 45 estudios empíricos relacionados
con la usabilidad móvil.
Se propone para el análisis del campo de la computación móvil 4 contextos: usuario,
actividad, ambiente y producto. Para cada uno de ellos se proponen métricas específicas y
métricas comunes tal como se muestran en la figura 3.1. El cuadro de la derecha muestra
las consecuencias en las que incide la usabilidad
Figura 3.1: Contextos y métricas
3.1.2 Exploring the benefits of the combination of a software architecture
analysis and a usability evaluation of a mobile application
Se propone un método (figura 3.2) para el análisis de la arquitectura del software (SA) y
para la evaluación de la usabilidad. Incluye un método que analiza la SA de una aplicación
Capítulo III
Página 39
móvil para el diseño de la usabilidad y para validar sus resultados, en el cual se separa la
interfaz de usuario (UI) del sistema. Sin embargo, la separación de la interfaz de usuario y
el sistema, no permite explorar los aspectos necesarios de la interacción usuario-sistema
[Biel, 10].
El objetivo del método es mejorar la usabilidad de una aplicación móvil, con la
identificación de problemas de usabilidad. Para ello, se identifican una serie de factores del
contexto móvil como son: medio ambiente, usuarios, tareas, dispositivos y aplicaciones.
Figura 3.2: Metodología expuesta por Biel[Biel, 10]
El método incluye las siguientes actividades:
La fase de análisis del contexto se centra en el análisis inicial de todos los datos
disponibles y documentos descritos en el documento de marco de análisis,
incluyendo el prototipo de interfaz de usuario actual y la determinación del contexto
de uso,
La determinación de escenarios se realiza mediante el uso de un catálogo de
escenarios genéricos, donde arquitectos y analistas discuten los escenarios que son
adecuados para la aplicación. Estos escenarios describen los requerimientos de
usabilidad y las interacciones que se describieron en la primera fase,
Para la evaluación de escenarios se hace un análisis para cada escenario, con la
finalidad de determinar si las decisiones sobre el escenario en particular ayudan a
detectar los problemas de usabilidad y cómo su comprensión puede ser calificada,
En la fase de interpretación de resultados se realiza un resumen de las evaluaciones
de los escenarios y se determina un nivel de soporte de la arquitectura. El nivel de
soporte arquitectónico define el impacto de cada escenario evaluado,
En la revisión de los métodos se recapitulan las experiencias y comentarios, así
como los resultados obtenidos incorporan a los escenarios los patones de diseño.
3.1.3 Usability of Mobile Devices and Intelligently Adapting to a User’s
Needs
Este trabajo se centra en el desarrollo de aplicaciones adaptadas al contexto del usuario, y
en particular que puedan adaptarse a la información contextual que recibe en tiempo real
[Greene, 03].
Indican que el diseño de las interfaces de los usuarios representa un desafío, ya que el
mundo real en el que las aplicaciones móviles se ejecutan, presenta diversos factores de
distracción que provienen del medio ambiente, como son el movimiento de los usuarios, el
contexto social, etc.
Capítulo III
Página 40
Se sostiene que un factor importante es la experiencia del usuario, ya que esta experiencia
agiliza las búsquedas de menús, pero al realizar el desarrollo de estas interfaces debemos
comprender las prioridades del usuario y darle lo que desean en términos de visibilidad.
Dentro de este trabajo se desarrolla un sistema de inteligencia ambiental, el cual lleva el
registro del trabajo que realizan los usuarios en su vida diaria.
Se propone como solución una interfaz inteligente para aplicaciones móviles que se adapta
a las necesidades del usuario y el desarrollo de. El objetivo de la interfaz de usuario es la
adaptación del sistema al usuario y a las situaciones de uso, a partir de diferentes técnicas
de la disciplina interacción persona ordenador (IPO) y contemplando factores de usabilidad.
3.1.4 User needs for location-aware mobile services
Los servicios basados en localización pueden variar mucho de acuerdo a sus contextos de
uso incluso por parte de los mismos usuarios [Kaasinen, 03].
En este trabajo se definen los servicios sensibles al contexto como aquellos que son capaces
de extraer información del entorno para presentar los elementos más relevantes a los
usuarios de acuerdo a las tareas a realizar dentro de la aplicación. Se sostiene que estas
aplicaciones deben contar con una capacidad de adaptación a los diferentes contextos que
se les presentan.
Se realizaron estudios empíricos con usuarios de servicios basados en localización, con la
finalidad de encontrar las características de necesidades comunes de los usuarios. Se realizó
la evaluación de 13 grupos con 3 a 7 personas cada uno, para un total de 55 personas de
diferentes edades.
Una vez que realizaron las evaluaciones con los usuarios, se agruparon sus características
en 5 grupos: contenido, interacción, personalización, servicios y privacidad. De los
resultados destaca la necesidad de ofrecer más servicios en términos de cobertura
geográfica, realizando una selección de contenidos de información que se adecuen a las
necesidades de los usuarios.
Mencionan que las necesidades de los usuarios están ligadas con sus preferencias y las
diferentes situaciones que se les presentan. Los usuarios necesitan servicios que no tengan
problemas con la interacción a lo largo de la actividad de estos servicios, como son la
búsqueda de sitios, el trazado de rutas, así como el almacenamiento de información de
interés de los usuarios.
Señalan que cuando la necesidad de uso de los servicios es ocasional, los servicios deben
ser fáciles de encontrar, y deben proporcionar una visión general de todos los demás
servicios ofrecidos dentro de la misma aplicación, así como tener la mayor cobertura para
su óptimo funcionamiento independientemente de las tecnologías utilizadas.
3.1.6 Comparativa de trabajos
Las aportaciones principales tienen que ver principalmente con el diseño centrado en el
usuario (DCU); el empleo de un enfoque de usabilidad para el desarrollo o evaluación de
aplicaciones móviles; y los diferentes contextos relacionados con este tipo de sistemas. Una
comparación de estos trabajos se presenta en la tabla 3.3.
Capítulo III
Página 41
Tabla 3. 3: Comparativa de trabajos
Trabajo Desarrollo
Evaluación Diseño Centrado en el
Usuario (DCU) Contextos
Análisis Diseño Evaluación Usuario Ambiente Tarea Tecnología
A Qualitative Review of Empirical Mobile Usability Studies
X X X X X
Exploring the benefits of the combination of a software architecture analysis and a usability evaluation of a mobile application
X X X X X X X
Usability of Mobile Devices and intelligently adapting to a User’s needs
X X X X X X
User needs for location-aware mobile services
X X X X X
Esta investigación X X X X X X X
CAPÍTULO IV
Contextos Móviles En este capítulo se muestran los contextos relacionados con los servicios basados en
localización (LBS). Asimismo, se identifican sus diferentes productos y sub-productos
Capitulo IV
Página 43
4.1 Introducción
Cuando nos referimos a computación ubicua, hablamos de la forma en que la tecnología
forma parte del ambiente y es parte del entorno del usuario [Schmidt, 02]. La finalidad de la
computación ubicua, es integrar varias computadoras (dispositivos) al entorno físico,
buscando habilitar los beneficios de éstos y de la información en cualquier momento y en
cualquier lugar [Ubiquitous, 11].
Los servicios basados en localización pertenecen a la categoría de los sistemas sensibles al
contexto. Una aplicación que es sensible al contexto es aquella que obtiene información de
su contexto en tiempo real para procesarla y entregar un resultado al usuario. Algunos
campos de aplicación se pueden encontrar en servicios relacionados con viajes, compras,
entretenimiento, información de eventos, etc. [Kaasinen, 03].
Los principales problemas con la adaptación al contexto es que no puede ser fácilmente
identificado o medido. El contexto de uso móvil varía mucho, y puede incluso estar
cambiando continuamente en el curso de un servicio. Si bien la ubicación del usuario es un
elemento del contexto que en la actualidad se puede medir con más o menos precisión,
dependiendo del sistema de posicionamiento en uso [Kaasinen, 03].
Algunos autores explican que el constante cambio de dispositivos por parte de los usuarios,
les orillan a desear seguir utilizando los mismos servicios en diferentes dispositivos, incluso
a realizar tares que por momentos no están contempladas dentro de estos servicios. Aún
más, estos servicios que son sensibles al contexto, pueden cambiar dependiendo del
ambiente físico (el contexto físico puede variar mucho en términos de iluminación, ruido de
fondo, la temperatura y el clima), o de la infraestructura de telecomunicaciones (la red o el
sistema de posicionamiento), e incluso ofrecer diferentes servicios en diferentes lugares.
En este capítulo presentaremos los contextos que se tomaron en cuenta para nuestro trabajo,
así como la identificación de los productos y subproductos derivados de estos contextos.
Capitulo IV
Página 44
4.2 Contexto.
En la literatura nos ofrecen diferentes definiciones de contexto tales como la de Anind que
lo define como: “Contexto es cualquier información que puede ser usada para caracterizar
la situación de una entidad, siendo una entidad una persona, lugar, u objeto que se
considera relevante en la interacción entre un usuario y una aplicación, incluyendo también
a ellos mismos, usuario y aplicación”, [Dey, 01]. También se puede definir como toda
información que caracteriza al entorno en el cual se ejecuta una aplicación o servicio. En
este sentido, los contextos ayudaran a enriquecer a los servicios basados en localización. El
uso del término surge relacionado con el concepto de computación ubicua, en inglés
ubiquitous computing o pervasive computing.
Los sistemas conscientes del contexto, en inglés context-aware system, son sistemas
capaces de adaptarse mucho mejor y de forma automática a las condiciones de entorno, y
por tanto proporcionar un mejor servicio. Para ello, necesitan extraer o adquirir ese
contexto de forma precisa, procesarlo para obtener la información necesaria para la
aplicación, y usarlo para personalizar ésta [Telefónica, 11].
Dentro de los LBS, diferentes autores hacen una clasificación de los contextos que deben
considerarse para este tipo de servicios, como se expone en el trabajo de Biel que expone
una seria de diferentes factores de contexto a considerar dentro del desarrollo de una
aplicación móvil [Biel, 10], o el trabajo de Gurdin el cual se centra más en el contexto
móvil y las diferentes características de la capacidad de procesamiento a considerar de los
dispositivos [Gurdin, 02]. La tesis de Grill titulada “Designing interactions in mixed
interaction environments”, nos explica los elementos a considerar para el desarrollo de
aplicaciones que consideren los contextos [Grill, 09]. Por su parte Kjeldskov nos explica la
aplicación móvil desde el punto de vista más aproximado a la disciplina Interacción
Computadora-Humano, IPO, y nos muestra deficiencias de las aplicaciones móviles
[Kjeldskov, 03]. Nivala expone una serie de contextos para el desarrollo de aplicaciones
móviles [Nivala, 03]. La propuesta de Nivala es una de las más citadas ya que sus contextos
han servido como base para el desarrollo de aplicaciones tales como GiMoDig. Esta
aplicación estudia la usabilidad de los mapas en topografía a través de una interfaz que se
adapta al contexto, con la cual se realiza una prueba de campo en el parque nacional de
Nuuksio, muy conocido por el excursionismo y el acampamiento [Sarjakoski, 05]. En
nuestro trabajo de investigación trabajaremos con la propuesta de Nivala.
Capitulo IV
Página 45
4.3 Identificación de contextos
En la tabla 4.1 se muestran los contextos a considerar dentro del desarrollo de los LBS
[Nivala, 03].
Figura 4. 1: Contextos
En la tabla 4.1 se presenta el objetivo de la especificación de cada uno de estos contextos,
así como los factores que los afectan: Tabla 4. 1 Contextos móvil, aplicación y usuarios
Contextos Factores [Nivala, 2003] Objetivo
Móvil Sistema
Identificar las características
básicas propias del dispositivo
móvil que son necesarias para un
óptimo funcionamiento de los
servicios basados en localización
(LBS).
Aplicación
Ubicación
Finalidad de Uso
Tiempo
Medio Ambiente Físico
Historial de
Navegación
Identificar las particularidades
del servicio (interiores (indoor) o
exteriores (outdoor), así como la
consideración de los diferentes
factores que intervienen para
realizar una personalización del
servicio en un momento dado.
Usuario
Cultural y Social
Perfil de Usuario
Identificar las diferentes
características físicas de los
usuarios, así como las
particularidades que influyan de
una manera importante en el uso
del servicio.
Capitulo IV
Página 46
4.3.1 Contexto Móvil.
Dentro de este contexto buscamos el reconocimiento de particularidades de los dispositivos.
Factor Sistema.- Aunque Nivala y Biel lo mencionan con diferente nombre, en este factor
se identifican las características tanto de hardware como de software de un dispositivo, es
decir los requerimientos mínimos de los dispositivos móviles, para tener un óptimo
funcionamiento [Nivala, 03], [Biel, 10],
En la figura 4.2 se muestra un panorama de lo que se detecta en este contexto:
Figura 4. 2: Contexto aplicación
4.3.2 Contexto Aplicación.
De acuerdo a Nivala y Biel, el reconocimiento de estos factores ayuda a tener una mejor
personalización de la aplicación.
Factor Ubicación.- Es la especificación de la ubicación física donde se localiza un usuario
en un determinado momento, en forma de mapa, croquis o texto.
Factor Finalidad de Uso.- Al usar la aplicación en sí, es probablemente muy difícil
identificar con qué propósito el usuario ocupará el servicio para una orientación o búsqueda
de servicio. Por ello, es un factor importante identificar la intención de uso que se le dará,
para así poder mostrar la mejor información posible al usuario.
Factor Tiempo.- Dentro de este factor se exponen las diversas modalidades de indicar el
tiempo y la forma como se relaciona con otros factores para proporcionar diversos
servicios, por ejemplo por las mañanas podrían ser mostradas la cafeterías abiertas, si es día
no laborable, mostrar parques cercanos, etc.
Factor Medios Ambiente Físico.- Este es uno de los factores más importantes al realizar
el reconocimiento del ambiente que rodea al móvil, es decir, aquel que engloba las
variables relacionadas con el tiempo atmosférico (temperatura, si hace sol, si llueve),
iluminación, ruido ambiente, etc.
Historial de Navegación.- Con base en información histórica, en este factor se busca
ofrecer al usuario servicios adicionales o complementarios, por ejemplo, dentro de una ruta
trazada, agregar los restaurantes, cines, parques, etc. que se sabe son de interés del usuario.
En la figura 4.3 se muestra un panorama de lo que se detecta con este contexto, junto con
sus diferentes factores.
Capitulo IV
Página 47
Contexto
Aplicación
Figura 4. 3: Contexto Aplicación
Capitulo IV
Página 48
4.3.3 Contexto Usuario.
Dentro de este contexto es fácil confundir entre un perfil y el contexto de usuario. De
acuerdo a las aplicaciones móviles o en este caso los LBS, consideramos que existe
diferencia entre contexto de usuario y perfil de usuarios. Conociendo la definición de
ambos términos, puede considerarse que uno engloba al otro (o al revés), pero en general
puede establecerse una diferencia entre ambos:
Un perfil de un usuario contiene información sobre rasgos estables de una persona,
que en general se supone varían lentamente con el tiempo,
El contexto de un usuario, en cambio, evalúa la situación de la persona en un
momento concreto (de nuevo la característica de tiempo real es básica), [Telefónica,
11].
Una vez mencionada la diferencia entre perfil y contexto consideramos la determinación de
los siguientes factores dentro de este contexto.
Factor Cultural y Social.- La situación social parece ser muy difícil de medir, esta
característica va relacionada directamente con las preferencias y conocimientos de los
usuarios, como podríamos considerar los niveles de experiencia con, conocimientos
tecnológicos, etc., las preferencias de los usuarios pueden ir ligadas a lugares concurridos o
tranquilos.
Factor Perfil de Usuario.- Las características que deben interpretarse en el contexto de
usuario son: capacidades físicas (altura, edad, diestro o surdo), capacidad de memoria
(memoria, aprendizaje, resolución de problemas, toma de decisiones, etc.) y las diferencias
de personalidad (de género, la actitudes ante las computadoras y dispositivos móviles,
hábitos, estados emocionales, etc.) [Nivala, 03].
Dentro de la literatura encontramos una clasificación para este tipo de contextos,
[Telefónica, 11]:
Contexto individual: información contextual que concierne o describe el entorno
de una persona o entidad concreta,
Contexto de grupo: información extraída de un grupo de personas (una familia, los
pasajeros de un tren, un grupo de amigos, los asistentes a una conferencia); no se
trata de la mera agregación de los contextos individuales sino que es necesario
considerar qué propiedades de contexto propaga al grupo entero, y si la existencia
del grupo provoca la aparición de nuevas propiedades no aplicables a título
individual,
Contexto colectivo: se distingue del contexto de grupo en su agregación a gran
escala. Son contextos de aplicación a poblaciones grandes, y en ellos lo importante
es determinar qué rasgos (con el margen de error considerado) son generalizables a
las poblaciones objeto de análisis.
En la figura 4.4 se muestra un panorama de lo que se detecta con este contexto, junto con
sus diferentes factores.
Capitulo IV
Página 49
Figura 4. 4: Contexto usuario
A continuación en la tabla 4.2 los objetivos de cada uno de los factores ya explicados, y los
contextos a los que pertenecen, con la finalidad de tener una idea más clara de las
características de los productos identificados.
Contexto
Usuario
Capitulo IV
Página 50
Tabla 4. 2: Factores
Factor Contexto Objetivo
Sistema Móviles
Realiza una identificación
de características de
hardware y software
necesarios para un buen
funcionamiento del servicio
basado en localización
Ubicación Aplicación
Reconocimiento de
ubicación de los usuarios en
un lugar determinado,
mostrando su posición
exacta dentro de un interior
o exterior.
Finalidad de Uso Aplicación
Uno de los contextos más
difíciles de tener en cuenta es
el propósito del servicio, en
otras palabras, la tarea que
desea realizar el usuario con el
servicio.
Tiempo Aplicación
Identificación de la hora
para analizar la información
que pueda ser más óptima
para mostrar al usuario
dentro del servicio.
Medio Ambiente Físico Aplicación
Consiste en el
reconocimiento físico del
ambiente que rodea al
dispositivo móvil
incluyendo variantes como
ruido, iluminación, etc.
Historial de Navegación Aplicación
Consiste en mostrar los
puntos de interés del
usuarios, una vez trazada
una ruta para llegar a un
punto determinado
Cultural y Social Usuarios
Este es un contexto difícil
de identificar, con él es
posible mostrar información
de preferencia del usuario.
Perfil de Usuario Usuarios
Este factor identifica las
características físicas del
usuario por ejemplo: la
edad, capacidad de
razonamiento, diestro o
zurdo, etc.
Capitulo IV
Página 51
4.4 Identificación de productos
En esta sección mostramos la identificación de los productos de los contextos a considerar
dentro de esta investigación.
4.4.1 Contexto Móvil
Dentro de este contexto se busca tener como resultado la identificación de los
requerimientos mínimos en hardware y software de un dispositivo para un óptimo
rendimiento de los servicios que ofrece, tomando en cuenta las características ambientales
bajo las cuales debe funcionar, como son el ruido, la iluminación, el movimiento, etc.
Algunos de las características de estos requerimientos pueden ser: tipo pantalla,
conectividad por medio de bluethooth, wifi, rfid, o alguna tecnología de radiofrecuencia,
sistema operativo Windows Mobile o Android, etc. (ver figura 4.5).
Figura 4. 5: Productos de contexto móvil
4.4.2 Contexto de Aplicación
Este es uno de los contextos más importantes a analizar ya que de él se obtienen las
principales características del ambiente de trabajo, es decir, se define el tipo de servicio a
efectuar para interiores (indoor) o exteriores (outdoor). Se identifica tanto la información a
mostrar como el tipo de sistema de ubicación. Para ubicación en exteriores el sistema de
posicionamiento global (GPS) es el más utilizado, y en caso de ser para interiores, es
necesario identificar el tipo de tecnología inalámbrica para obtener la posición del
dispositivo.
Este contexto da como resultado un conjunto de servicios que se ofrecen al usuario
(dispositivo móvil), identificando si es para interiores o exteriores, y las tareas en específico
que podrá realizar con estos servicios, como son: trazado de ruta, búsqueda de dirección,
búsqueda de un restaurant, búsqueda de puntos de interés cercanos, etc., por mencionar
algunos en la figura 4.6 mostramos al producto obtenido dentro de este contexto.
Capitulo IV
Página 52
Figura 4. 6: Productos de contexto aplicación
4.4.3 Contexto Usuario
Dentro de este contexto se realiza la identificación de las particularidades de los usuarios.
La identificación del perfil de usuario y del factor social y cultural que engloba el contexto
de usuario da como resultado un perfil que describe las particularidades de un usuario, o del
grupo o grupos a considerar para el uso de nuestros servicios. En la figura 4.7 se muestra
un panorama general del producto que se obtiene.
Capitulo IV
Página 53
Figura 4. 7: Productos de contexto usuario
4.5 Identificación de Sub-Productos En base a los contextos y los productos identificados, necesitamos realizar la derivación de
subproductos, con la finalidad de tener una mayor correspondencia con las actividades que
se deben realizar para el desarrollo de los LBS.
4.5.1 Sub-productos de contexto Usuario
El subproducto identificado dentro de este contexto es el siguiente:
Identificación de contexto de usuario.- Es la especificación de las particularidades
relevantes de los usuarios a los que dirigimos el LBS. Para contar con información
relevante de los usuarios, es necesario realizar una serie de actividades con los usuarios
reales que utilizarán estos servicios, obteniendo sus particularidades físicas (perfil de
usuario) y su nivel cultural y social.
4.5.2 Sub-productos de contexo Móvil
El subproducto identificado dentro de este contexto es el siguiente:
Identificación de requerimientos de hardware/software.- Es la especificación de las
características mínimas, con las cuales debe contar el dispositivo para tener un rendimiento
óptimo de los servicios contextuales. Estas características deben superar los ambientes que
involucra el tipo de aplicación (indoor o outdoor).
4.5.3 Sub-productos de contexto de Aplicación
Los subproductos identificados dentro de este contexto son los siguientes:
Identificación del contexto físico.- Es la especificación del entorno físico donde se
ejecutarán los servicios, interiores o exteriores.
Identificación de finalidad de uso.- Es la especificación de los servicios que se ofrecen,
que básicamente consisten en 4 funcionalidades: consulta de ubicación, consulta de
Capitulo IV
Página 54
orientación, búsqueda de servicios, búsqueda de rutas, y a partir de ellos de derivan una
serie de otras funcionalidades posibles.
Especificación del nivel de usabilidad de los LBS.- Es la especificación del nivel de
usabilidad dentro de la aplicación, que permita asegurar que los servicios cumplan con el
nivel de usabilidad establecido.
Prototipo de los LBS.- Es el prototipo o maqueta de la interfaz de usuario mostrando los
servicios ofertados, así como ejemplos de la información que se mostrará dentro de las
diferentes funcionalidades de estos servicios.
Esquema de interacción de los LBS.- Este subproducto surge de las propuesta realizadas
por algunos autores, tales como Biel [Biel, 2010], quien propone realizar un esquema de
interacción de las aplicaciones con la finalidad de determinar y analizar la cantidad de
iteraciones que debe realizar un usuario para la ejecución de una tarea específica. Permite
simplificar y hacer más accesible el acceso a los servicios que ofrece el dispositivo,
elevando la satisfacción de los usuarios.
CAPÍTULO V
Selección de Técnicas IPO En este capítulo se muestra la selección de técnicas IPO, también se muestra la relación
entre técnicas y sub-productos de los contextos ya seleccionados en el capítulo anterior.
Capítulo V
Página 56
5.1 Introducción
La usabilidad es un factor de calidad tradicionalmente muy relacionado con la evaluación
de interfaces de usuario, que tiene que ver con la medida en la cual un producto puede ser
usado por usuarios específicos para conseguir objetivos específicos con efectividad,
eficiencia y satisfacción en un contexto de uso especificado.
Sin embargo, a pesar de la importancia creciente de este factor de calidad de un producto
de software, existen pocos trabajos reportados en la literatura donde la incorporen al ciclo
de desarrollo de nuevas aplicaciones. Si bien existe una variedad de metodologías de
evaluación de usabilidad y trabajos relacionados con el diseño de interfaces.
Xavier Ferre propone elevar los niveles de usabilidad de nuevas aplicaciones de software,
haciendo un análisis y selección de diversas técnicas proveniente de autores de la IPO y
expone como pueden ser incorporadas dentro de su ciclo de desarrollo.
Para efectos de nuestro trabajo de tesis, revisamos e hicimos una selección de algunas de
estas técnicas para incorporarlas al desarrollo de aplicaciones LBS, en particular para la
obtención de los productos y subproductos contextuales identificados en el capítulo
anterior.
Capítulo V
Página 57
5.2 Clasificación de técnicas dentro de las actividades de
desarrollo de los Servicios Basados en Localización (LBS) Dentro de este apartado clasificaremos las actividades necesarias en el desarrollo de los
LBS, mencionando los factores involucrados dentro de cada actividad y posibles técnicas
que sean adaptados al desarrollo de estas aplicaciones. Esta clasificación (tabla 5.1) está
basada en el trabajo expuesto por Xavier Ferre [Ferre, 05], tomando como guías a los
autores Nielsen y Mayhew. Tabla 5. 1: Clasificación de Técnicas
Clasificación de técnicas dentro de las actividades de usabilidad para los LBS
Actividad
de
Usabilidad
Actividad específica de
usabilidad
Técnica Contexto
Involucrado Mayhew Nielsen
Actividades de
Análisis
Especificación
del contexto de
uso
Análisis de
Usuarios
Cuestionarios de
perfiles de usuarios.
Características de
usuarios. Usuario
Análisis de
Tareas
Entrevistas
Contextuales. *Análisis
Comparativo
*Análisis del
Impacto Financiero
Aplicación
Diagramas de
afinidad.
Escenarios de
tareas
Restricción de
plataforma
Móviles
Especificaciones de Usabilidad
Objetivo de
Usabilidad
Objetivo de
usabilidad Móviles
Aplicación
Usuario
Actividades de
Diseño
Desarrollo del concepto del
producto
Task Sorting
Card Sorting
Diseño paralelo
Móviles
Aplicación
Usuario
Prototipado
Maqueta de baja
fidelidad.
Prototipado Móviles
Aplicación.
Maqueta de alta
fidelidad Móviles
Aplicación
Diseño de la Interacción Guías de estilo Móviles
Aplicación
Actividades de
Evaluación Evaluación de usabilidad
Retroalimentación
del usuario
Retroalimentación
del usuario
Móviles
Aplicación
Usuario
Técnicas de test
remotos
Focus group
Test Formales Análisis de Impacto
Pensar en voz alta
Laboratorios de
usabilidad
Grabación de Video
Observación
Cuestionario y
entrevista
GOMS
Cuestionarios y
Entrevistas *Técnicas que no son posibles aplicar en el dominio de los LBS de acuerdo a esta investigación.
Capítulo V
Página 58
Dentro de nuestra aplicación de LBS las técnicas que debemos resaltar son aquellas donde
destacaremos el contexto de tareas, de usuarios, y de dispositivos móviles, las cuales
involucran a nuestros diferentes contextos que debemos considera en el desarrollo, dentro
de los diferentes autores mencionados en la tesis de Xavier Ferre [Ferre, 05] , resaltamos
las técnicas de Mayhen en propuesta de “ciclo de vida de la usabilidad” y las técnicas
expuestas por Nielsen en su libro “ingeniería de usabilidad”, ya que nos muestran una serie
de tecinas que realizar dentro de las diferentes actividades del ciclo de la usabilidad.
5.3 Análisis de Propuestas Dentro de las dos propuestas seleccionadas anteriormente siguen una estructura de
actividades, que tienen en común acuerdo alguna de las técnicas por realizar dentro de las
diferentes actividades de usabilidad por desarrollar dentro de un proyecto, a continuación
presentamos una descripción de cada una de estas propuestas.
5.3.1 Análisis del Ciclo de Vida de la Usabilidad (Mayhew).
Este ciclo de vida nos muestra la autora Mayhew es una visión amplia de su ciclo de vida
de la usabilidad (figura 5.1), donde nos muestra una serie de actividades que se involucran
dentro de todo este ciclo, expone una serie de técnicas las cuales facilitan el desarrollo de
estas actividades, exponiendo y contemplando los diferentes factores que deben ser
contemplados en un sistema.
Involucra una serie de cuestiones que impactaran al sistema desde el análisis para poder
determinar un nivel de usabilidad al sistema desde el inicio de su desarrollo, dentro de este
ciclo de vida no es tan interactivo como otros mostrados y analizados en la tesis de Xavier
Ferré [Ferre. 05], pero centra alguna de sus técnicas en la etapas de actividades de diseño
que son interactivos como el desarrollo de sus maquetas alta y baja fidelidad, cumplen con
el objetivo de desarrollo de prototipos, que son la idea más clara que se le puede mostrar a
un usuario del sistema final.
Otra de las cuestiones que es importante destacar, es que dentro de este ciclo de vida es la
valoración de usabilidad dentro de las diferentes actividades para poder pasar de una
actividad a otra, esto con el fin de obtener los objetivos de usabilidad deseados, y evitar
posibles restructuraciones en pasos futuros.
5.3.2 Análisis del Ciclo de la Ingeniería de Usabilidad (Nielsen).
Dentro de las técnicas que se mencionan de Nielsen son mencionadas en su libro “Usability
Engineering”, dentro de la tesis de Xavier Ferre, menciona que no todas son detalladas tan
profundamente, incluso algunas no son mencionadas con un título, el objetivo de este
trabajo se centra en realizar una reflexión sobre la usabilidad y la utilización de una serie de
técnicas posibles a utilizar en el desarrollo de las aplicaciones, donde alguna de las técnicas
son confusas, pero dentro de la investigación de Xavier Ferre, realiza una clasificaciones de
la identificación de estas técnicas encontradas y realiza su clasificación.
5.4 Análisis de posibles técnicas aplicables a los LBS
Capítulo V
Página 59
Los LBS son aplicaciones capaces de ejecutarse en dispositivos móviles, lo cual involucra
una enfoque diferente a el desarrollo de software clásico, donde tenemos que contemplar
sus diferentes limitaciones tanto de hardware y software, su contexto físico es decir el
entorno físico en donde se ejecutara la aplicación tomando en cuenta la iluminación, el
ruido, la conectividad, etc., otro de los aspectos importantes es la finalidad de uso del
usuario al interactuar con la aplicaciones, y bien el usuarios que contempla una serie de
características diferentes, es por ello que de acuerdo a una aplicación móvil realizamos la
selección de técnicas para su análisis y posible adaptación para obtener resultados más
óptimos y poder elevar sus niveles de usabilidad dentro del desarrollo de los LBS, un
análisis profundó de estas técnicas lo mostramos en el anexo A.
5.5 Técnicas seleccionadas En resumen después del análisis de las técnicas que se muestra en el anexo A se presentan
las técnicas seleccionadas en la tabla 5.2, dentro de las propuestas de Nielsen [Nielsen 93] y
Mayhew [Mayhew 99], estas técnicas afectan a las fases dentro del desarrollo de un
aplicación como son análisis, diseño, y evaluación.
Las técnicas seleccionadas serán las contempladas dentro de nuestro proceso de desarrollo
unificado, mostrando tanto las tareas de usabilidad como las técnicas a realizar dentro de
nuestro desarrollo de servicios.
Capítulo V
Página 60
Tabla 5. 2: Técnicas seleccionadas
Actividad Fase Técnica Producto Sub-producto
Análisis
Especificación
del contexto de
Uso
Análisis de
Usuarios
*Características de
usuarios [Nielsen
93].
Perfiles de
Usuarios
Identificación de
contexto de Usuario
[Biel 10], [Nivala
03], [Gurdin 02]. **Cuestionarios de
perfiles de usuarios
Perfiles de
Usuarios
Análisis de
tareas **Restricción de
Plataforma [Mayhew
99].
Dominio de
dispositivos
Tener una selección
de requerimientos
software/Hardware
[Biel 10], [Nivala
03], [Grill 09]
*Entrevistas
contextuales
[Mayhew 99].
Indoor
Outdoor
Identificación de
contexto físico
[Biel 10], [Nivala
03], [Kjeldskov 03]
**Escenarios de
tareas [Mayhew 99].
Identificación de
finalidad de uso
[Biel 10], [Nivala
03],
**Objetivo de
Usabilidad [Mayhew
99].
Establecer los
niveles de
usabilidad de el
LBS
**Card Sorting
[Nielsen 93].
Generar un esquema
de la aplicación, en
base a las ideas de
los usuarios
**Maqueta de Baja
Fidelidad [Mayhew
99].
Generar un
prototipo del LBS.
[Biel 10],
[Kjeldskov 03]
. **Maqueta de Alta
Fidelidad [Mayhew
99].
Generar un
prototipo del LBS.
[Biel 10],
[Kjeldskov 03]
**Guías de Estilo
[Mayhew 99].
Desarrollar un
esquema de
interacción del LBS
[Biel 10]
Diseño Estructuración
de la Aplicación Diseño UML
Desarrollar el
esquema de la
aplicación
Evaluación Evaluación de la Usabilidad
*Retroalimentación
con los Usuarios
[Mayhew 99].
Evaluar los niveles
de usabilidad de los
LBS.
[Biel 10], [Nivala
03], [Kjeldskov 03] **Cuestionarios y
Entrevistas [Nielsen
93].
*Evaluación
Heurística [Nielsen
93].
Evaluar los niveles
de usabilidad con
expertos de HCI, y
el equipo de
desarrollo
Capítulo V
Página 61
Actividad Fase Técnica Producto Sub-producto
Evaluación Evaluación de la Usabilidad
**Pensar en Voz
Alta
[Nielsen 93].
Indoor
Outdoor
Identificar la
impresión de los
usuarios. *Observación
[Nielsen 93].
**Test de Usabilidad
[Nielsen 93].
Estructuración de la
prueba de
usabilidad.
**Técnicas seleccionadas
*Técnicas opcionales
CAPÍTULO VI
Construcción del Proceso de
Desarrollo En este capítulo se presenta el proceso de desarrollo de un marco metodológico que
incorpora usabilidad al desarrollo de aplicaciones LBS, mediante la integración de técnicas
para el desarrollo de sistemas y tomando en cuenta los perfiles de los dispositivos móviles y
de los usuarios. Se describe asimismo, la secuencia de las actividades a realizar en las
diferentes fases del proceso de desarrollo, así como aplicación de las técnicas
seleccionadas.
Capítulo VI
Página 63
6.1 Introducción
Una metodología en ingeniería nos ayuda a tener un mejor control de un proyecto,
segmentándolo y precisándolo en etapas claramente identificadas, con el fin de optimizar
las tareas a llevar a cabo, detectar posibles errores en etapas tempranas del desarrollo, y
optimizar los diversos recursos que se necesitan para su desarrollo. Todo lo anterior para
alcanzar objetivos bien establecidos.
En nuestro caso y por lo anteriormente definido como metodología, decidimos limitar
nuestro trabajo a una propuesta de proceso de desarrollo, la cual aunque integra algunos
elementos metodológicos, pero sin alcanzar a cubrir todos los aspectos que en rigor debe
cubrir una metodología.
En este capítulo se describen los tres procesos que fueron considerados en la propuesta de
tesis para integrar un proceso de desarrollo de aplicaciones LBS: el proceso de desarrollo
de la usabilidad, el proceso de desarrollo del software, y el de las aplicaciones móviles.
Las aplicaciones móviles, en particular las aplicaciones LBS, si bien resultan del desarrollo
de una aplicación software, tienen algunas particularidades. En este capítulo se analizarán
estas particularidades, y a partir de allí se analizarán algunas propuestas que buscan atender
aspectos de usabilidad dentro del proceso de desarrollo de aplicaciones móviles,
específicamente de LBS.
El proceso de desarrollo de LBS, como un sistema interactivo no implica solamente el
diseño de las interfaces y de la interacción, sino que se refiere al desarrollo de servicios
tomando en cuenta el entorno completo (por ejemplo, la tecnología, el ambiente de trabajo,
las partes interesadas, los objetivos, etc.) que rodea el sistema, así como el análisis de las
necesidades y expectativas de los usuarios [Humayoun, 09].
A continuación se muestra un esquema de los tres procesos de desarrollo considerados en
nuestra propuesta: de la usabilidad desde un enfoque de la interacción persona ordenador
(IPO), de la Ingeniería de software dentro del ciclo de vida clásico, y del desarrollo de
aplicaciones móviles.
Capítulo VI
Página 64
6.2 Proceso de desarrollo de la Usabilidad La usabilidad es un tema fundamental en todo tipo de aplicaciones, en particular aquellas
que implican un nivel de interacción elevado. A pesar de ello, la ingeniería del software se
ha centrando en atributos del software más relacionados con la funcionalidad del sistema,
con el rendimiento o con la fiabilidad. [Ferre, 05].
La Ingeniería de Usabilidad se puede definir como una aproximación al desarrollo de
sistemas en la que se especifican niveles cuantitativos de usabilidad, y el sistema se
construye para alcanzar dichos niveles, [Preece, 94].
En la figura 6.1 se muestra el proceso de desarrollo de la usabilidad.
Figura 6. 1: Ciclo de Vida de la Usabilidad [Ferre, 05]
Si bien identificamos existe una gran similitud a grandes rasgos con el desarrollo de
software, realizando un esquema muy general, identificamos tres fases fundamentales, tanto
en el desarrollo del software como en el de la usabilidad, estas fases son: análisis, diseño, y
evaluación.
Capítulo VI
Página 65
6.2.1 Análisis
6.2.1.1 Especificación del Contexto de Uso
Dentro de esta actividad el objetivo es comprender e identificar las características del
contexto de uso, en cuanto éstas puedan ser relevantes para la usabilidad del producto
software final.
El contexto de uso es un término muy amplio basado en el estándar ISO 13407
Proceso de Diseño Centrado en el Usuario para Sistemas Interactivos, [ISO13407, 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 tema,
El entorno en el que los usuarios van a utilizar el sistema, incluyendo el
hardware, software y materiales que se van a utilizar.
Para realizar esta actividad se realizan dos sub-actividades, las cuales son: Análisis de
Usuarios y Análisis de Tareas.
6.2.1.1.1 Análisis de Usuarios
El análisis de usuarios considera identificar los usuarios previstos, sus conocimientos,
necesidades y características, que son relevantes en su interacción con el sistema.
Las características a identificar incluyen el conocimiento del dominio, destreza,
experiencia, formación, características físicas, hábitos, preferencias y aptitudes. Para
cierto tipo de sistemas también pueden ser relevantes características como la
edad, discapacidades, daltonismo, etc. Todas estas características se estudian con el fin de
poder adaptar el sistema a desarrollar a sus futuros usuarios.
El entorno físico también es importante aunque, estrictamente hablando, no se trata de una
característica del usuario, se debe considerar elementos como los altos niveles de ruido, la
baja luminosidad la temperatura, y otras características similares referentes al lugar de
trabajo del usuario. El software se tiene que diseñar, de tal forma que supere en
la medida de lo posible estas limitaciones del entorno de uso previsto.
6.2.1.1.2 Análisis de Tareas
El Análisis de Tareas está relacionado con la e specificación de requerimientos, pero
tiene la característica clave de centrar este tipo de actividades en los objetivos
últimos del uso del sistema por parte del usuario. La diferencia entre una tarea y una
funcionalidad es que la tarea tiene significado en sí misma para el usuario, mientras que
la funcionalidad tiene sentido para el sistema software. El usuario considera
necesario o deseable realizar las tareas. Por tanto, el término tarea implica una intención
o propósito que no tiene por qué estar presente en el concepto de funcionalidad que
ofrece un sistema. Por ejemplo, una funcionalidad para generar archivos intermedios
(necesarios para el buen funcionamiento del sistema según está concebido), no
corresponde a un propósito del usuario, sino que es algo que el sistema requiere para su
ejecución. En ocasiones funcionalidad y tarea pueden coincidir.
Capítulo VI
Página 66
6.2.1.2 Especificaciones de Usabilidad
Las Especificaciones de Usabilidad son objetivos de usabilidad cuantitativos o
cualitativos, que se utilizan como guía para determinar cuándo un sistema alcanza el
nivel de usabilidad adecuado. Pueden considerarse un subconjunto de los requerimientos
no-funcionales de un sistema. Se basan en dos componentes, por un lado la eficiencia
del usuario, y por otro su satisfacción. La eficiencia se interpreta como el nivel de
eficiencia deseado del sistema más amplio que está compuesto por el usuario junto con
el sistema software, trabajando de forma conjunta para conseguir ciertos objetivos del
usuario. Es decir, la especificación de usabilidad se define sobre las tareas específicas
definidas a partir de las descripciones de tareas generales, obtenidas en las actividades de
especificación del Contexto de Uso.
6.2.2 Diseño
6.2.2.1 Desarrollo del Concepto del Producto
Los usuarios siempre desarrollan un modelo en su mente acerca de cómo funciona el
sistema, independientemente de que haya llevado a cabo una actividad explícita de
desarrollo del concepto del producto. Este modelo mental del usuario es normalmente
una idea deficiente, nos referimos a que no corresponde exactamente con la forma de
funcionamiento del sistema, con la lógica que guía los procesos que lleva a cabo para
responder a cada acción del usuario, y con la forma en la que están distribuidas las
opciones y funcionalidades en la interfaz del usuario. Lo ideal para los diseñadores del
sistema es que el usuario pudiera ser capaz de crear el modelo mental en su cabeza
rápida y fácilmente, y que se correspondiera con la imagen del sistema.
6.2.2.2 Prototipado
El estándar ISO 13407 [ISO13407, 99] 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 forma más efectiva con los usuarios, y reducen la necesidad y el coso que conlleva
rehacer un sistema ya implementado cuando los problemas se identifican tarde en el
desarrollo. Es necesario construir prototipos porque las especificaciones técnicas y los
modelos abstractos no suelen ser la mejor vía de comunicación cuando se quiere
involucrar a usuarios en el proceso de desarrollo.
6.2.2.3 Diseño de la Interacción
El Diseño de la Interacción es la actividad de los procesos IPO que está menos
definida, por un lado, indican que el diseño es una actividad compleja y que no hay
actividad que garantice el éxito y, por otro lado, aseguran que el diseño como proceso
es una de las actividades menos comprendidas.
6.2.3 Evaluación
6.2.3.1 Evaluación de Usabilidad
No importa cuánto se enfatice la realización de actividades de usabilidad en el proceso
de desarrollo, no se puede predecir con exactitud el nivel de usabilidad del sistema por
Capítulo VI
Página 67
adelantado. Por esta razón es necesario realizar actividades de e valuació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.
6.3 Proceso de desarrollo del Software
La metodología en la que nos basaremos para el desarrollo de software es la que propone
Software Engineering Body of Knowledge (SWEBOK), la cual es una certificación para el
desarrollo de software promovida por la IEEE [SWEBOK, 04].
Un panorama que presenta SWEBOK en el desarrollo de software es el que se muestra en
la ilustración 6.2.
Capítulo VI
Página 68
Figura 6. 2: Proceso de Desarrollo SWEBOK [SWEBOK, 04]
A continuación se explica a grandes rasgos lo que se realiza en cada etapa contemplada por
esta guía. Cada una de ellas contiene un serie de actividades que no se detallarán ya que no
considera necesario para efectos del presente trabajo de investigación. Solamente se tomará
como referencia la estructura en etapas como base para el desarrollo de nuestra propuesta.
6.3.1 Análisis
Elicitación de requerimientos.- Esta actividad se refiere a la recolección de los
requerimientos del software y la manera como el ingeniero de software participa de esta
actividad. Es la primera etapa en la construcción de la comprensión del problema del
software, se trata fundamentalmente de una actividad humana, y es donde las partes
Capítulo VI
Página 69
interesadas se identifican y se establecen relaciones entre el equipo de desarrollo y el
cliente. Uno de los principios fundamentales de la ingeniería de software es que haya una
buena comunicación entre los usuarios del software e ingenieros de software.
Esta actividad es también designada como "captura de requerimientos", " descubrimiento
de requerimientos", o "adquisición de requerimientos”.
Análisis de requerimientos.-Este tema tiene que ver con el proceso de análisis de los
requerimientos:
Detectar y resolver conflictos entre los requerimientos,
Descubrir los límites del software y cómo debe interactuar con su entorno,
Elaboración de los requerimientos del sistema para obtener los requerimientos del
software.
La visión tradicional de análisis de requerimientos se ha reducido a un modelado
conceptual utilizando uno de los diferentes métodos de análisis.
Especificación de requerimientos.- Para la mayoría de las profesiones de ingeniería, el
término especificación se refiere a la asignación de valores numéricos a determinados
atributos. En la ingeniería de software se refiere a la especificación del comportamiento
esperado de un sistema de software, que cual incluye valores cuantitativos pero también
cualitativos. Concretamente se refiere a la elaboración de un documento que debe ser
revisado, evaluado y aprobado. Para sistemas grandes y complejos, especialmente los que
implican una gran cantidad y variedad de componentes de software, se realizan hasta tres
diferentes tipos de documentos: definición del sistema, requerimientos del sistema, y los
requerimientos de software.
Validación de requerimientos.- Los documentos de requerimientos pueden ser objeto de
validación y los procedimientos de verificación. Los requerimientos deben ser validados
para asegurar que el ingeniero de software ha entendido los requerimientos. Es importante
verificar que un documento se ajusta a los requerimientos y estándares de la organización,
y es comprensible y coherente.
6.3.2 Diseño
Diseño de alto Nivel.- Se investiga sobre el problema, sobre los conceptos relacionados
con el conjunto de casos de uso que se esté tratando. Se debe llegar a una buena
comprensión del problema por parte del equipo de desarrollo, pero sin especificar cuál va a
ser la solución y los detalles de implementación.
Diseño de Bajo Nivel.- Se crea una solución a nivel lógico basada en el conocimiento
reunido en la fase de diseño de alto nivel. Los modelos más importantes en esta fase son el
diagrama de clases de diseño y los diagramas de interacción, que se realizan en paralelo y
que definen los elementos que forman parte del sistema que se va a construir (clases y
objetos), y cómo colaboran entre sí para realizar las funciones que se piden al sistema,
según éstas se definieron en los contratos de operaciones del sistema.
Diseño de la Interfaz.- Su objetivo es que las aplicaciones y los dispositivos en sí sean más
atractivos, además que la interacción con el usuario sea lo más fácil e intuitiva posible. En
estas actividades, en las cuales se aplican técnicas provenientes del diseño industrial y del
diseño gráfico, se evita sobre todo no afectar el funcionamiento técnico y desempeño del
dispositivo.
Capítulo VI
Página 70
6.3.3 Implementación
Codificación.- En esta actividad se toman en cuenta las siguientes consideraciones:
Técnicas adecuadas de codificación y de nomenclatura,
Manejo de condiciones de error, planificado y excepciones (entrada de datos
erróneos, por ejemplo),
Prevención de violaciones de seguridad a nivel de código,
Uso de recursos a través de mecanismos de exclusión, y disciplina en el acceso a
los recursos reutilizables en serie (incluyendo hilos o bloqueos de base de datos),
Organización del código fuente (Módulos, rutinas, clases, paquetes, y otras
estructuras),
Documentación del código.
6.3.4 Evaluación
Evaluación Unitaria.- Es la verificación del funcionamiento en forma aislada del software.
Las piezas de software son probadas por separado.
Evaluación de Integración.-Es la verificación de la interacción entre los componentes de
software. Las pruebas de integración son una actividad continua en cada etapa, en la que los
ingenieros de software deben abstraer perspectivas de menor nivel y concentrarse en las
perspectivas del nivel que se está integrando.
Evaluación de Aceptación.- Estas pruebas las realiza el cliente. Son básicamente pruebas
funcionales, sobre el sistema completo, y buscan una cobertura de la especificación de
requerimientos y del manual del usuario. Estas pruebas no se realizan durante el desarrollo,
pues sería impresentable al cliente; sino que se realizan sobre el producto terminado e
integrado o pudiera ser una versión del producto o una iteración funcional pactada
previamente con el cliente.
6.3.5 Mantenimiento
El mantenimiento de software es una parte integral del ciclo de vida del software. Las
empresas de desarrollo se esfuerzan en proporcionar un adecuado mantenimiento para darle
un mayor ciclo de vida al software, prolongando su vida útil y evitando que llegue a ser
obsoleto tempranamente.
6.4 Proceso de desarrollo de una Aplicación Móvil Las aplicaciones móviles han tenido en los últimos años un enorme crecimiento
haciéndose cada vez más rentables. Mucho de su éxito es derivado del avance tecnológico y
del ofrecimiento de nuevos y novedosos servicios. Se trata de un mercado tan desarrollado
y tan demandado que las empresas han optado por metodologías de desarrollo ya utilizadas
para el software tradicional. Lo anterior, a pesar de que el software para dispositivos
móviles debe satisfacer requerimientos y restricciones especiales.
A pesar de estas restricciones, el software producido debe contar con un alto nivel de
calidad para que pueda operar dentro de los diferentes dispositivos que existen actualmente,
y también pensar en los futuros diseños de dispositivos. Blanco nos explica que el
desarrollador de aplicaciones móviles se enfrenta, además, a un campo muy incompatible,
ya que está formado por una multitud de plataformas, como son: Symbian, Windows
Capítulo VI
Página 71
Mobile, Brew, iPhone SDK, Android, Linux o Java, por mencionar algunos. Todo esto hace
que el proceso de desarrollo para plataformas móviles sean más complejo [Blanco, 09].
6.4.1 Estructura convencional de la metodología de una aplicación móvil
El desarrollo de aplicaciones para dispositivos móviles, desde el punto de vista de la
Ingeniería del Software, aunque no difiere sustancialmente de los pasos de desarrollo de
una aplicación de software de escritorio, sí tiene sus particularidades. A continuación
mostramos la metodología de tres etapas para el desarrollo de aplicaciones móviles
propuesta por Sánchez [Sánchez, 09]:
Análisis de requerimientos. El analista debe determinar por medio de entrevistas
con los usuarios, las necesidades que tienen y los requerimientos que se le pedirán
a la aplicación. Por ejemplo, en el caso del análisis para una aplicación que se
ejecutará en un dispositivo móvil, algunos de estos requerimientos generales
pueden ser la facilidad de uso, que se pueda ejecutar en teléfonos móviles, PDAs,
notebooks, etc. que permita una conexión a una entidad mayor para obtener datos
actualizados o devolver otros, además de identificar cuáles son las tareas
mejorables mediante la implementación de la aplicación móvil.
Diseño de la aplicación. Es muy importante en este tipo de aplicaciones el crear
programas separados por cada uno de los posibles usos que se le dé a la aplicación.
De esta manera cada programa será más pequeño y se adaptará mucho mejor a las
características de los dispositivos móviles. En la fase de implementación se tendrá
que establecer un mecanismo que controle las diferentes aplicaciones.
Implementación de la aplicación. Esta etapa vendrá marcada por la elección del
lenguaje, plataforma y herramientas de desarrollo. Utilizando dicha metodología,
será posible analizar y distinguir cuales son los procesos, objetivos, roles y tareas
realmente significativos para el grupo de trabajo de la organización y a partir de
esta información, en primer lugar, qué funcionalidades debe tener la aplicación para
que aporte la ventaja de su movilidad; y en segundo lugar, de qué forma será
procesada la información con la aplicación móvil a la hora de realizar una tarea en
concreto [Sánchez, 09].
Sánchez expone esta metodología como algo muy similar al desarrollo de software clásico,
resaltando las particularidades que se deben atender para aplicaciones móviles.
Por otra parte Mobinex que es un proveedor de aplicaciones y soluciones para dispositivos
móviles, dedicada al desarrollo de sistemas para operadores móviles, proveedores de
contenido y compañías de medios, nos muestra un metodología de desarrollo de estas
aplicaciones, la cual, realizando un análisis del panorama general cumple con la
estructuración de la metodología clásica del desarrollo de software [Mobinex, 11].
La figura 6.3 muestra la estructuración de la metodología expuesta por Mobinex.
Capítulo VI
Página 72
Figura 6. 3: Metodología para Aplicaciones Móviles [Mobinex, 11].
En esta metodología se muestra una serie de fases para el desarrollo de aplicaciones
móviles y se describe qué se debe desarrollar en cada una de estas fases, así como algunas
preguntas que deberían poder contestarse dentro de cada fase.
Evaluación de Necesidades.- En esta fase se realiza la identificación de los requerimientos
de la aplicación, realizando prácticamente las actividades del análisis de la ingeniería de
software. Los requerimientos que se recomienda identificar son los siguientes:
Identificación de finalidad de uso,
Que servicios se ofrecerán dentro de la aplicación,
La distribución de los usuarios que utilizar la aplicación en tiempo real,
Identificar los escenarios de usabilidad de la aplicación (Durante el uso, el medio
ambiente ocupado, etc.),
Definir conexión / de información en línea,
Definir la compatibilidad con las diferentes plataformas con las que se contará,
Definir las especificaciones de los dispositivos que podrán utilizar la aplicación,
Definir el soporte de la resolución de pantalla que van a ser compatibles.
Guión Gráfico.- Esta fase va más relacionada con el diseño de la interfaz de la aplicación,
dentro de la cual se realizan las siguientes actividades:
Realizar un esquema de navegabilidad de la aplicación,
Identificar el tipo de información que se incluye en las páginas o ventanas de la
aplicación,
Identificar el modelo que se utilizará para la presentación de contenidos,
Tipos de botones que se mostraran en las diferentes ventanas,
Los datos estarán configurados de una manera dinámica o estática.
Capítulo VI
Página 73
Flujo Cliente/Sevidor.- Esta etapa consiste en la determinación de los servicios web que
serán utilizados dentro de la aplicación, incluyendo:
Definición de los recursos que proporcionará la datos de manera dinámica (en caso
de que así sea definido),
La firma de servicios tales como servicio web, RSS, json que se utilizarán en la
aplicación,
Definir los mensajes de error de código (Error de red basada en códigos, etc.).
Diseño.- Esta fase se relaciona más con el diseño de la aplicación de los móviles,
considerando el sello de la empresa que promoverá el servicio como son logos, estilos, etc.,
los factores a definir dentro de esta fase son las siguientes:
Identidad Gráfica del dispositivo, del proveedor de servicios, de la aplicación, etc.,
Vistas de la aplicación,
Medios de comunicación visual o audio que se utilizarán en la aplicación,
Qué tipo de dispositivo móviles se utilizarán para esta aplicación,
También las diferentes experiencias de los usuarios para diferentes plataformas
deben ser consideradas.
En esta fase, los siguientes elementos también deberán ser determinados:
El diseño de los objetos bajo los siguientes criterios como son: pantalla táctil o uso
del teclado,
Si el diseño de la aplicación requiere ser utilizado por una pantalla táctil,
Soporte para la resolución de múltiples colores dentro de las diferentes resoluciones
que llegue a soportar la aplicación.
Desarrollo en línea o fuera de línea.- En esta fase se determinan los métodos para realizar
las solicitudes de la aplicación.
Prueba.- En esta fase se realizan las pruebas necesarias a la aplicación para poder verificar
lo posibles problemas que presente la aplicación. En ella deben realizarse las siguientes
actividades:
Determinar los casos de prueba,
Identificar si la aplicación cumplió con los requerimientos establecidos,
Determinar los diferentes problemas que se han producido durante la prueba.
Proceso de aceptación.- Esta es la etapa de aceptación de la aplicación. Para ello deben
considerarse las siguientes actividades:
Verificar si la aplicación cumple con los criterios determinados, tales como
funcionalidad, visualización de la información y usabilidad,
Identificar los posibles cambios en la funcionalidad, la visualización y / o facilidad
de uso en la solicitud.
Actualizaciones regulares.- Esta etapa se relaciona directamente con el mantenimiento de
la aplicación y se determina lo siguiente:
El período de actualización de la aplicación,
Determinar el responsable de las actualizaciones.
6.4.1 Metodología de WORKPA
El proyecto europeo WorkPad proporciona una infraestructura de software y comunicación
con operadores de apoyo en situaciones de emergencia para dispositivos móviles. Cuando
Capítulo VI
Página 74
ocurre un desastre, la fase de respuesta está diseñada para proveer asistencia de emergencia
a las víctimas.
WorkPad está desarrollada bajo el estándar ISO 13407 (Proceso Centrado en el Usuario),
intentando elevar los niveles de usabilidad. Se trabaja bajo un diseño iterativo, donde los
usuarios forman parte de las diferentes etapas de desarrollo. Se utilizan diversas técnicas
para obtener la información de los usuarios tales como: cuestionarios, entrevistas,
escenarios y análisis de tareas. Esto requiere un contacto continuo con usuarios reales, no
sólo por responder a preguntas sencillas, sino también pensar en sus sugerencias e
impresiones.
Lo que rescatamos como aportación con relación a nuestro proceso de desarrollo, es cómo
realizar la actividad de elicitación de requerimientos, la cual la descomponen en tres
perspectivas diferentes: necesidades de negocio, necesidades de usuarios y necesidades de
sistema.
La forma en que realizan la recolección de datos es con la aplicación de un enfoque de
interacción de usuario basado en el estándar ISO 13407. También toman en cuenta casos de
uso, planteando los casos más representativos de la aplicación, para así tomar en cuenta la
impresión de los usuarios sobre la aplicación desde las etapas tempranas del desarrollo, e
integrar y estructurar sus necesidades más apegadas. Es bien sabido que los desarrollos
centrados en el usuario aumentan los niveles de satisfacción, ya que lo involucran en las
diferentes fases de su desarrollo [Humayoun, 09].
En la figura 6.4 se muestra la estructura de esta metodología.
Capítulo VI
Página 75
Figura 6. 4: Metodología WORKPAD [Humayoun, 09].
6.5 Construcción del proceso de desarrollo Para realizar el estructura miento de este proceso de desarrollo tomamos como base los tres
tipos de procesos expuestos anteriormente: de la usabilidad desde un enfoque de la
interacción persona ordenador (IPO), de la Ingeniería de software dentro del ciclo de vida
clásico, y del desarrollo de aplicaciones móviles.
Capítulo VI
Página 76
En la tabla 6.1 se muestran las actividades a realizar para los tres tipos de proceso y se
realiza una clasificación de las fases comunes que consideramos fundamentales: Análisis,
Diseño, Codificación, Evaluación, y Mantenimiento. La clasificación de las diferentes
actividades se realizó de acuerdo al grado de semejanza entre las actividades de los
diferentes procesos. Tabla 6. 1: Proceso de desarrollo en paralelo
Fases Usabilidad [Ferre, 05] Software [SOWEBOK, 04] Móviles
Análisis
Análisis de Usuario
Análisis de Tareas
Elicitación de Requerimientos
Elicitación de
Requerimientos
[Humayoun, 09].
Análisis de Requerimientos
Especificación de Requerimientos Especificación de
Requerimientos [Mobinex,
11], [Sánchez, 09]
Validación de Requerimientos
Objetivo de Usabilidad
Desarrollo de Concepto
del Producto
Modelado de la Aplicación
[Mobinex, 11].
Diseño de Interacción
Determinación de la
Interacción[Mobinex, 11],
[Biel, 10]
Prototipado Prototipo [Mobinex, 11],
[Biel, 10]
Diseño Desarrollo de la
Aplicación
Diseño de Alto Nivel Desarrollo de la Aplicación
[Mobinex, 11], [Biel, 10] Diseño de Bajo nivel
Diseño de Interfaz
Codificación Construcción del Software
Evaluación
Evaluar los Niveles de
Usabilidad
Pruebas Unitarias Evaluar los Resultados de
Prueba [Mobinex, 11],
[Biel, 10], [[Humayoun,
09].
Pruebas de Interacción
Pruebas de Aceptación
Mantenimiento
Mantenimiento Correctivo Mantenimiento Correctivo
[Mobinex, 11], [Biel, 10],
Mantenimiento Perfectivo Mantenimiento Perfectivo
[Mobinex, 11],
En nuestra propuesta tomamos como base el proceso de desarrollo de software para
adicionarle nociones de usabilidad y actividades específicas para el desarrollo de la
aplicación móvil con un enfoque de desarrollo de LBS. Decidimos tomar como base el
proceso de desarrollo de software debido a que es el más amplio y cubre la totalidad de
etapas de desarrollo de un proyecto de ingeniería. En la tabla 6.2 mostramos la fusión de los
tres procesos, realizando la unificación de acuerdo a las semejanzas de las actividades de
los diferentes procesos:
Además, mostramos la estructuración de las fases y actividades a seguir para el desarrollo
de LBS.
Una vez detectadas las tareas a realizar dentro de cada fase realizamos la estructuración de
nuestro proceso de desarrollo, mostrando el momento de la aplicación de nuestras técnicas
de IPO ya seleccionadas.
Capítulo VI
Página 77
Tabla 6. 2: Construcción del proceso de desarrollo
Fase Actividad Proceso de Desarrollo de
Procedencia
Análisis
Elicitación de Requerimientos Móviles, Software
Análisis de Usuarios Usabilidad
Análisis de Tareas Usabilidad
Análisis de Requerimientos Móviles, Software
Objetivo de Usabilidad Usabilidad
Especificación de Requerimientos Móviles, Software
Validación de Requerimientos Software
Desarrollo del Concepto del
Producto
Usabilidad
Modelado de la Aplicación Móviles
Diseño de la Interacción Usabilidad, Móviles
Prototipado Usabilidad, Móviles
Diseño
Diseño de Alto Nivel Software
Diseño de Bajo Nivel Software
Diseño de la Interfaz Software
Codificación Construcción del software Software
Evaluación
Pruebas Unitarias Software
Pruebas de Integración Software
Pruebas de Aceptación Software
Evaluar Niveles de Usabilidad Usabilidad
Validación de Resultados Móviles
Mantenimiento Mantenimiento Correctivo Software, Móviles
Mantenimiento Perfectivo Software, Móviles
Tomando el enfoque de la metodología WorkPad, dividimos la fase de análisis en tres
secciones las cuales serán nombradas como: 1. recolección y validación de requerimientos,
2. Desarrollo del concepto del producto, 3. Validación de requerimientos y construcción de
conceptos visuales, las fases posteriores no serán seccionadas y nuestro proceso de
desarrollo queda estructurado como se muestra en las figuras 6.5, 6.6 y 6.7.
Capítulo VI
Página 78
Figura 6. 5: Fase de Análisis
Capítulo VI
Página 79
Figura 6. 6: Fase de Diseño y Codificación
Capítulo VI
Página 80
Figura 6. 7: Fase de Evaluación y mantenimiento
CAPÍTULO VII
Caso de Estudio y
Evaluación del Proceso de
Desarrollo En este capítulo se presenta un caso de estudio en el cual se aplica el proceso de desarrollo
propuesto, y se efectúa una evaluación de los resultados obtenidos.
Capítulo VII
Página 82
7.1 Introducción Esta etapa de evaluación tiene como objetivo determinar el nivel de mejoramiento del
atributo usabilidad en una aplicación comercial LBS, a partir de la aplicación del proceso
de desarrollo propuesto en este trabajo de tesis. Este proceso de desarrollo integra técnicas
de la usabilidad desde un enfoque de la interacción persona ordenador (IPO), de la
Ingeniería de software dentro del ciclo de vida clásico, y del desarrollo de aplicaciones
móviles para LBS.
Para realizar la evaluación se plantearon principalmente dos alternativas: 1) realizar la
evaluación de nuestra propuesta en el desarrollo de una nueva aplicación LBS, o 2) en la
mejora de una aplicación LBS ya existente.
Dadas la restricción en el tiempo disponible para implementar el proceso de desarrollo en
un nuevo caso, que se estima requeriría aproximadamente 5 meses, así como la restricción
técnica, al no contar con todas las competencias necesarias in situ para realizar todo el ciclo
de desarrollo de una nueva aplicación, se optó por la alternativa 2.
Consideramos la alternativa 2 viable para evaluar la capacidad de nuestro proceso de
desarrollo para incorporar aspectos de usabilidad, ya que si bien en un proyecto nuevo se
aplican las fases del proceso en el orden análisis-diseño-codificación-evaluación-
mantenimiento, en un proyecto existente es posible aplicar el orden evaluación-análisis-
diseño-codificación-evaluación-mantenimiento. Es decir, partir de la fase de evaluación
para revisar un producto existente en vista de su mejora. Una vez obtenidos los resultados
de la fase de evaluación se pasa a la fase de análisis para establecer los requerimientos de
mejora y así continuar con las siguientes fases diseño-codificación-evaluación-
mantenimiento.
Reconocemos que en el caso de un proyecto existente de mejora, ciertas fases de nuestro
proceso de desarrollo podrían tener algunos ajustes respecto a un proyecto nuevo, pero de
acuerdo a los resultados que se presentan al final de este capítulo, es en la etapa de análisis
que se asegura la incorporación de usabilidad en los dos casos.
Es por ello que la evaluación de nuestro trabajo se limita a evaluar la fase de análisis a
través de un comparativo entre el nivel de usabilidad de la aplicación en su estado actual y
el nivel de usabilidad que se propone en el proyecto de mejora.
Para el caso de estudio se seleccionó una aplicación comercial que consiste en un servicio
de localización denominado “Google Maps”, ya que en la actualidad es uno de los servicios
de localización más utilizados y conocidos actualmente y utilizamos un teléfono móvil htc
widefire con sistema operativo Android versión 2.2.
El proyecto lo denominamos: Proyecto de mejora de una aplicación LBS ya existente,
donde la mejora se refiere exclusivamente a la incorporación de usabilidad en esta
aplicación.
Capítulo VII
Página 83
A continuación, punto 7.2, se describen muy brevemente las fases de evaluación y análisis
de nuestro proceso de desarrollo.
Evaluación: Consiste en realizar la evaluación de la aplicación con el fin de determinar los
problemas de usabilidad. En el caso de un proyecto existente, de esta etapa solamente se
aplican las actividades correspondientes a pruebas de usabilidad. En nuestro caso de estudio
nos limitaremos a algunas de las tareas más representativas de esta aplicación, y se
determinarán los escenarios donde se realizaran estas pruebas.
Análisis: Esta fase se divide en las siguientes secciones: 1.Recolección y validación de
requerimientos, 2.Desarrollo del concepto del producto, 3.Validación de requerimientos y
construcción de conceptos visuales.
1. Recolección y validación de requerimientos: Incluye principalmente tareas específicas de
usabilidad como son análisis de usuarios y análisis de tareas, determinando los perfiles de
los usuarios y el contexto de uso en el cual se desempeña la aplicación. A continuación,
aplicando algunas técnicas clásicas de software (entrevistas, reuniones, cuestionarios, lluvia
de ideas, etc.) se realizará un análisis de requerimientos y que conjuntamente con los
resultados de la etapa anterior de evaluación permitirán obtener los objetivos de usabilidad.
2. Desarrollo del concepto del producto: Una vez determinados los objetivos de usabilidad
desarrollamos un esquema de la distribución de información que tienen los usuarios de la
aplicación. En esta sección nos apoyamos en la técnica expuesta por Nielsen llamada card
sorting.
3. Validación de requerimientos y construcción de conceptos visuales: En la sección
realizamos la especificación de los requerimientos obtenidos en la sección uno de esta fase,
se establecen las restricciones de la plataforma para la cual se desarrollará la aplicación, y
una vez especificados los requerimientos, se realiza se validación. Finalmente, se elabora
una maqueta de la interfaz así como un mapa de interacción.
En nuestro caso de estudio al término de esta fase se obtiene maqueta de baja fidelidad de
la aplicación, mostrando los rasgos básicos de la interfaz así como de la navegación de
usuarios.
Finalmente, en el punto 7.3 se presenta la evaluación del proceso de desarrollo, en cual
toma como criterios la percepción visual y el tiempo que ocupa un usuario para ejecutar
con éxito un conjunto de tareas previamente especificadas.
De los resultados de este punto se obtiene una valoración acerca de la incorporación de
usabilidad en el desarrollo de servicios contextuales basados en localización (LBS)
utilizando el proceso de desarrollo propuesto.
Capítulo VII
Página 84
7.2 Proyecto de mejora de una aplicación LBS ya existente La figura 7.1 muestra un esquema general del proyecto, donde las fases y actividades
provienen de nuestra propuesta de proceso de desarrollo de aplicaciones LBS.
A continuación se muestran y explican las actividades a realizar en las dos fases,
explicando la finalidad de las técnicas y los resultados que se espera obtener con la
aplicación de cada una de ellas.
Figura 7. 1 Fases del caso de estudio
7.2.1 Fase de Evaluación
En la ilustración 7.2 tenemos una descripción de las actividades a realizar en la fase de
evaluación del proceso de desarrollo de LBS. Al caso de estudio solamente es aplicada la
sección correspondiente a evaluación de usabilidad y se describen cada una de las
actividades que comprende.
Capítulo VII
Página 85
Figura 7. 2: Fase de evaluación
7.2.1.1 Pruebas de Usabilidad
Tabla 7. 1: Plantilla de Pruebas de Usabilidad
Datos generales de la evaluación
Nombre de la Aplicación Google Maps para Android
Descripción
Es un servidor de aplicaciones de mapas en la Web. Ofrece
imágenes de mapas desplazables, así como
fotos satelitales del mundo entero e incluso la ruta entre diferentes
ubicaciones o imágenes a pie de calle (Street View). Desde el 6 de
octubre del 2005, Google Maps es parte de Google Local.
Objetivo de la evaluación Detectar problemas de usabilidad por medio de la evaluación, para
realizar mejoras sobre esta aplicación.
Técnicas de evaluación Observación y retroalimentación con los usuarios (cuestionarios)
7.2.1.1.1 Prototipo de la Prueba
El escenario donde se realizará la prueba será en la ciudad, en los ambientes reales donde se
utiliza este tipo de servicio, teniendo como tareas principales las siguientes:
Prueba de
usabilidad
Capítulo VII
Página 86
Identificar un punto de interés en el mapa por medio de la visualización de objetos
auxiliándose de los botones del zoom.
Ubicación
Botones Zoom
Punto de interés
a identificar
La tarea es identificar “oficinas IMSS Clínica 20” como se muestra en la figura 7.3.
Realizar un trazado de ruta desde la ubicación de los usuarios hasta el punto de
interés seleccionado.
Trazado de Ruta
La tarea consiste en realizar una trazado de ruta al punto de interés ya ubicado en el mapa el
cual es “oficinas IMSS Clínica 20” desde nuestra ubicación, como se muestra en la figura
7.4.
Realizar una búsqueda de lugar, ayudándose de la funcionalidad de búsqueda
introduciendo el nombre del lugar.
Figura 7. 3: Punto de identificación
Figura 7. 4: Trazado de ruta
Capítulo VII
Página 87
Figura 7. 5: Búsqueda por texto
La tarea consiste en introducir el nombre “Jardín Borda” realizando la búsqueda automática
de un punto de interés, como se muestra en la figura 7.5.
La selección de usuarios para esta prueba se realizó escogiendo usuarios aleatoriamente, ya
que este tipo de servicios no está dirigido a una comunidad en específico, sino para
cualquier tipo de usuario. Fueron seis los usuarios seleccionados, tres estudiantes usuarios
de y tres trabajadores usuarios. Tabla 7. 2: Cronograma de Actividades
Mes Octubre
Día
Actividad 5 6 7 8 9 10 11
Prueba de equipo y conexión
Realización de la prueba
Análisis de videos
Análisis de resultados
Redacción de informe
7.2.1.1.2 Realización de la Prueba
7.2.1.1.2.1 Prueba de Observación Tabla 7. 3: Plantilla técnica de observación
**Técnica Observación
Fase Evaluación
Actividad Evaluación de Usabilidad
Sub-Actividad Test de Usabilidad
Descripción
Con esta técnica identificamos las deficiencias de usabilidad por medio de
la interacción de los usuarios con el sistema, grabándolos al realizar una
serie de tareas ya definidas, y realizando el llenado de platillas en el
momento de esta grabación.
Capítulo VII
Página 88
Para realizar esta prueba es necesaria la utilización de una cámara, un dispositivo móvil, y
dos personas. Una se ocupará de la cámara para grabar la interacción de los usuarios con la
aplicación y con el dispositivo, y la otra realiza el llenado de las siguientes plantillas. Los
videos de estas pruebas se encuentran en el CD adjunto al documento de tesis, en la carpeta
usuario. Tabla 7. 4: Plantilla de observación usuario 1 (video 1)
Tarea Tareas
realizadas
Tiempo
(MM:SS) Observaciones #01
Identificación de
punto de interés 00:56
Problemas con la manipulación del mapa.
Trazado de ruta
01:13
Los títulos de las funcionalidades no fueron muy
claros para realizar esta tarea, el usuario expresa
que es complicado.
Búsqueda de
punto de interés 00:53
Problemas con el dispositivo para quitar el
teclado de pantalla. El usuario tras tener la
primera experiencia con el trazado de búsqueda,
aprendió intuitivamente a introducir el nombre de
un lugar manualmente.
Tabla 7. 5: Plantilla de observación usuario 2 (video 2)
Tarea Tareas
realizadas
Tiempo
(MM:SS) Observaciones #02
Identificación de
punto de interés 01:30
El usuario no pone atención en los objetos que se
le presentan en el mapa.
Trazado de ruta
01:25 El usuario no encontró las funcionalidades de
trazado de ruta.
Búsqueda de punto
de interés 00:25
El usuario después de estar un rato con la
aplicación identificó la funcionabilidad de
búsqueda.
Tabla 7. 6: Plantilla de observación usuario 3 (video 3)
Tarea Tareas
realizadas
Tiempo
(MM:SS) Observaciones #02
Identificación de
punto de interés 01:37
El usuario no identificaba los lugares marcados en
el mapa como hospitales palacios, paradas de
camión, escuelas, estacionamientos, etc.
Trazado de ruta
02:39 El usuario no encuentra las funcionalidades
Búsqueda de punto
de interés 00:00
El usuario declinó realizar esta tarea al no
encontrar las funcionalidades.
Capítulo VII
Página 89
Tabla 7. 7: Plantilla de observación usuario 4 (video 4)
Tarea Tareas
realizadas
Tiempo
(MM:SS) Observaciones #04
Identificación de
punto de interés 00:06
El usuario detectó rápidamente los objetos
sobresalientes que marca el mapa.
Trazado de ruta
00:54
El usuario tardó en identificar las funcionalidades,
y lo logró por medio de palabras claves como el
titulo de la funcionalidad “instrucciones”.
Búsqueda de punto
de interés 00:23
El usuario tras tener la primera experiencia con el
trazado de búsqueda, aprendió intuitivamente
cómo introducir un lugar manualmente para la
búsqueda.
Tabla 7. 8: Plantilla de observación usuario 5 (video 5)
Tarea Tareas
realizadas
Tiempo
(MM:SS) Observaciones #05
Identificación de
punto de interés 00:29
El usuario por medio de su ubicación y los objetos
del mapa pudo identificar el punto de interés
Trazado de ruta
01:29 El usuario no diferenció el trazado de ruta a pie, en
coche, o en ruta.
Búsqueda de punto
de interés 00:29
El usuario aprendió el uso de la aplicación
rápidamente y logro la localización del Jardín
Borda.
Tabla 7. 9: Plantilla de observación usuario 6 (video 6)
Tarea Tareas
realizadas
Tiempo
(MM:SS) Observaciones #06
Identificación de
punto de interés 00:05
El usuario identificó los lugares rápidamente por
los objetos resaltantes en el mapa.
Trazado de ruta
00:20 El usuario identificó las funcionalidades
rápidamente por medio de los títulos.
Búsqueda de punto
de interés 00:37
El usuario tuvo problemas con la interacción de
texto con la aplicación.
Estas plantillas fueron llenadas simultáneamente cuando se realizaba la grabación de los
usuarios realizando este tipo de tareas. Los videos se quedan guardados como archivos y
fueron revisados de nuevo con más detenimiento tratando de seguir encontrando problemas
de usabilidad.
Fórmula para obtener el porcentaje de eficacia en uso:
((Tareas satisfactorias) x (100)) / Total de tareas = % de eficacia de uso
Capítulo VII
Página 90
La tabla 7.10 muestra los porcentajes de eficiencia de las tareas realizadas por los usuarios y
resaltamos el trazado de ruta ya que tenemos un porcentaje de 67% en su eficacia, el cual
consideramos bajo. Tabla 7. 10: Porcentajes de eficacia
Tarea % Eficacia de uso % Ineficacia de uso
Identificación de punto de
interés 83% 17%
Trazado de ruta 67% 33%
Búsqueda de punto de interés 83% 17%
7.2.1.1.2.2 Prueba retroalimentación con los usuarios (Cuestionario).
Tabla 7. 11: Plantilla retroalimentación con los usuarios
Técnica Retroalimentación con los usuarios (Cuestionario)
Fase Evaluación
Actividad Evaluación de Usabilidad
Sub-Actividad Test de Usabilidad
Descripción
Con esta técnica identificamos las deficiencias de usabilidad por medio de
la experiencia vivida del usuario en su interacción con la aplicación. Se
identifica la satisfacción subjetiva que tiene el usuario sobre la aplicación.
Esta prueba la realizamos aplicando un cuestionario a los usuarios de la experiencia vivida
con la aplicación, el cuestionario se muestra a continuación. El cuestionario se realizó
tomando como parámetros en las opciones múltiples (satisfacción, indiferencia o
insatisfacción dependiendo de la respuesta).
Cuestionario
1.- ¿Qué edad tienes?______ Sexo: (F) (M) Ocupación: ________
2.- ¿Es la primera vez que utilizas este tipo de aplicaciones?
a) Si b) No
Si67%
No33%
Figura 7. 6: Grafica de satisfacción en la utilización
Capítulo VII
Página 91
3.- ¿Se te dificultó identificar el punto de interés con los objetos del mapa (oficinas del
IMSS Clínica 20)?
a) Si (Insatisfecho) b) Un poco (Indiferente) c) No (Satisfecho)
Si50%
Un poco17%
No33%
Figura 7. 7: Grafica de satisfacción de dificultad en la identificación de puntos
4.- ¿Se te dificultó realizar los trazados de ruta?
a) Si (Insatisfecho) b) Un poco (Indiferente) c) No (Satisfecho)
Si29%
Un poco57%
No14%
Figura 7. 8: Grafica de satisfacción en el trazado de ruta
Capítulo VII
Página 92
5.- ¿Se te dificultó visualizar los lugares en el mapa?
a) Si (Insatisfecho) b) Un poco (Indiferente) c) No (Satisfecho)
Si16%
Un poco17%
No67%
Figura 7. 9: Grafica de satisfacción de dificultad en la observación de objetos en el mapa
6.- ¿Es claro identificar el modo de llegar al lugar ya sea caminando, en coche, o en ruta?
a) Si (Satisfecho) b) Un poco (Indiferente) c) No (Insatisfecho)
Si83%
Un poco17%
Figura 7. 10: Grafica de satisfacción de identificación de las funcionalidades
Capítulo VII
Página 93
7.- ¿Crees que la información mostrada en la aplicación es la adecuada para orientarte?
a) Si (Satisfecho) b) Un poco (Indiferente) c) No (Insatisfecho)
Si100%
Figura 7. 11: Grafica de satisfacción dela información en el mapa
8.- ¿Se te dificultó la selección de objetos dentro del mapa o la entrada de texto dentro del
dispositivo?
a) Si (Insatisfecho) b) Un poco (Indiferente) c) No (Satisfecho)
Figura 7. 12: Grafica de satisfacción de interacción con la aplicación
9.- ¿Te sentiste desesperado por no encontrar las funciones dentro de la aplicación?
a) Si (Insatisfecho) b) Un poco (Indiferente) c) No
(Satisfecho)
Figura 7.13: Grafica de satisfacción de localización de las funcionalidades
Capítulo VII
Página 94
10.- ¿El tiempo utilizado para realizar las tareas indicadas fue adecuado?
a) Si (Satisfecho) b) Un poco (Indiferente) c) No
(Insatisfecho)
Figura 7.14: Grafica de satisfacción del tiempo utilizado
11.- ¿En general consideras buena la aplicación?
a) Si (Satisfecho) b) Un poco (Indiferente) c) No
(Insatisfecho)
Figura 7.15: Grafica de satisfacción de la aplicación en lo general
12.- ¿Qué es lo que más se te dificultó hacer dentro de la aplicación?
De las preguntas contestadas, fue la visualización de objetos en el mapa.
A partir de nuestro cuestionario sacamos nuestra tabla de satisfacción de usuarios, la cual se
muestra a continuación, y nos dará un idea más de los problemas en los que nos debemos
de concentrar.
Capítulo VII
Página 95
Tabla 7. 12: Satisfacción
Indicador Satisfacción Indiferencia Insatisfacción
Búsqueda de objetos
en el mapa 33% 17% 50%
Identificación de
funcionalidades 14% 57% 29%
Visualización de
objetos 67% 17% 16%
Diferenciar
funcionalidades de
trazado de ruta
83% 0% 17%
Información mostrada 100% 0% 0%
Interacción con el
mapa 67% 17% 16%
Estrés del manejo de
la aplicación por no
encontrar
funcionalidades
15% 23% 62%
Tiempo requerido para
realizar las tareas 83% 0% 17%
Evaluación general 50% 50% 0%
A partir de nuestra tabla de satisfacción realizamos la identificación de problemas críticos y
no críticos (tabla 7.13). Tabla 7. 13: Clasificación de problemas encontrados
Problemas críticos Problemas no críticos
-No logran diferenciar los objetos dentro del
mapa que están marcados.
-No mostrar tan claramente las funcionalidades
que existen dentro de la aplicación.
-Identificación las diferentes funcionalidades.
-Problemas de interacción con el dispositivo.
-Manipulación del mapa en el dispositivo.
Un problema crítico es aquel que hace imposible la conclusión de la tarea por el usuario.
Un Problema no crítico es aquel donde un mejor diseño evita que el usuario tenga
problemas o ineficiencia para concluir la tarea.
Capítulo VII
Página 96
7.2.1.1.3 Informe de la Prueba
Proyecto:
Mejora de una aplicación LBS ya existente
Descripción:
Es un proyecto el cual busca encontrar las deficiencias de usabilidad Google Maps en
plataformas Android, realizando la aplicación de una serie de técnicas de interacción
persona ordenador (IPO) que fueron seleccionadas para aplicaciones LBS. Como es
conocido Google Maps es un servicio basado en localización.
Actividades
Evaluación de la aplicación Google Maps en dispositivos móviles con plataforma
Android.
Aplicación de la técnica de observación.
Aplicación de la técnica de retroalimentación con los usuarios.
Descripción de las Actividades
Preparación de la prueba.- Se realizó la preparación de la prueba escogiendo una
serie de tareas a desarrollar dentro de la aplicación y se creó el prototipo de la
prueba.
Planificación.- Se realizó la planificación de la prueba de equipo y la evaluación en
un cronograma de actividades.
Pruebas de equipo.- Se realizó la prueba de conexiones y del equipo en el lugar
donde se llevarían a cabo las pruebas.
Realización de la prueba.
Observación.- se pidió a un conjunto de usuarios seleccionados aleatoriamente
entre la gente del centro de Cuernavaca, Morelos, México, que realicen una serie
de actividades dentro del dispositivo con plataforma Android, observando las
deficiencias de usabilidad, y realizando el llenado de plantillas de evaluación.
Retroalimentación con los usuarios (cuestionarios).- Se les pidió a los
mismos usuarios evaluados en la observación que conteste una serie de
preguntas de un cuestionario de opción múltiple.
Análisis de la prueba.- Se realizó el análisis de los resultados de la prueba,
analizando los videos y obteniendo los resultados estadísticos de las respuestas de
los usuarios dentro del cuestionario.
Resultados de la evaluación de la aplicación:
Problemas críticos:
o No se logran diferenciar los objetos dentro del mapa que están marcados.
o No se muestran claramente las funcionalidades que se ofrecen dentro de la
aplicación.
Capítulo VII
Página 97
Problemas no críticos
o Problemas de identificación de las diferentes funcionalidades.
o Problemas de interacción con el dispositivo.
o Problemas de manipulación del mapa en el dispositivo.
Resultados de porcentajes de satisfacción de alerta: Tabla 7. 14: Problemas de satisfacción
Indicador Satisfacción Indiferencia Insatisfacción
Búsqueda de objetos
en el mapa 33% 17% 50%
Estrés del manejo de
la aplicación por no
encontrar
funcionalidades
15% 23% 62%
Identificación de
funcionalidades 14% 57% 29%
Resultados de eficacia en uso de alerta: Tabla 7. 15: Problemas de eficacia
Tarea % Eficiencia en uso %Ineficiencia en uso
Trazado de ruta 67% 33%
Fecha de inicio: 5/10/11
Fecha de finalización: 11/10/11
Capítulo VII
Página 98
7.2.2 Fase de Análisis
Sección 1
7.2.2.1 Análisis de Usuarios
7.2.2.1.1 Identificación de perfiles
La identificación de perfiles la basamos en los criterios de conocimiento de los usuarios,
como son el conocimiento tecnológico y el conocimiento de LBS en móviles, también
considerando su edad y sexo.
Una tabla de perfiles que consideraremos de este caso de estudios se muestra en la tabla
7.16, la cual muestra los diferentes criterios a considerar dentro de nuestro servicio basado
en localización.
Para la identificación del perfil al que corresponde cada participante, considerado como
usuarios en nuestro caso, se aplicó la técnica del cuestionarios de perfil de usuario
propuesta por Mayhew [Mayhew, 99].
A continuación se muestra una plantilla descriptiva de la técnica aplicada. Tabla 7. 16: Plantilla del cuestionario de Perfil de Usuario
Técnica Cuestionario de Perfil de Usuario de Mayhew
Fase Análisis
Actividad Elicitación de Requerimientos
Sub-Actividad Análisis de Usuarios
Descripción
Con esta técnica identificamos las características más sobresalientes de
nuestros usuarios LBS. Dentro estas características, nos enfocamos en
aquellas que afecten la interacción de nuestro LBS.
Las características a identificar son las capacidades visuales, las
capacidades auditivas, el nivel de experiencia que tienen los usuarios con
los dispositivos móviles, el nivel de experiencia que tiene los usuarios con
el uso de los diferentes LBS, sus capacidades de concentración en los
diferentes ambientes de uso, las preferencias por los diferentes medios de
entrada de datos en los dispositivos.
Esta técnica es realizada a través de cuestionarios.
El enfoque de nuestras características se detectar se muestra a continuación en la tabla 7.17
Capítulo VII
Página 99
Tabla 7. 17: Criterios para identificación del Perfil de Usuario
Criterio Descripción
Identificar la ocupación Con el fin de tener una idea más central y conocimiento de las
actividades rutinarias de nuestros usuarios.
Detectar el nivel
educativo promedio
La identificación del nivel educativo promedio de nuestros usuarios,
ayuda a tener en cuenta un nivel de razonamiento dentro de nuestro
LBS, así como el tipo de mensajes a mostrar, y la información a
desplegar.
Tener referencia del sexo La proporción en el sexo de nuestros usuarios.
Rango de edad Esta característica ayuda a considerar los rangos de edad de los
usuarios de LBS. Considerando que los síntomas neurológicos en
personas de edad avanzada son muy comunes, así como la
disminución de las funciones cognitivas o intelectuales, incluyendo
alteraciones de memoria, deterioro de la movilidad, pérdida de
percepción sensorial (visual o auditiva) y desequilibrio del sistema
nervioso autónomo [1].
Detección de problemas
visuales
La identificación de problemas visuales la consideramos de suma
importancia ya que al trabajar directamente con dispositivos móviles,
es muy común el interactuar con pantallas pequeñas, lo cual incide
directamente con esta característica.
Experiencia con
dispositivos móviles
Esta característica ayuda a tener una mejor perspectiva del tipo de
usuario que utilizara los servicios LBS, identificando la facilidad que
tiene el usuario con el manejo de un dispositivo móvil.
Experiencia con servicios
basados en localización
(LBS)
La identificación de esta experiencia nos ayuda a considerar el
conocimiento que tienen nuestros usuarios sobre los LBS, la
identificación de funcionalidades que ofrecer.
Detección de tarea(s)
común(es) dentro de un
(LBS)
Esta característica ayuda a identificar la forma de operar de nuestros
usuarios con un LBS, así como las tareas más comunes por las que
utilizan este tipo de servicios.
Características de
dispositivo móvil
utilizados
Identificamos las características de los dispositivos móviles más
utilizados por nuestros usuarios.
Capacidades de
concentración de los
usuarios
Identificaremos los niveles de concentración de nuestros usuarios,
considerando los diferentes contextos físicos a los que se pueden
enfrentar con el desarrollo de nuestro LBS.
Detección de uso de
medios de entrada del
dispositivo
De acuerdo a los diferentes dispositivos móviles que existen,
identificamos el nivel de experiencia con los diferentes medios de
entrada como pueden ser teclados o pantallas táctiles.
Detección de preferencias
de usuario
La identificación de esta técnica nos proporciona una idea de las
preferencias de nuestros usuarios.
Detección de problemas
con el dispositivo
Nos ayudará a identificar las complicaciones técnicas que tienen
nuestros usuarios en su interacción con el dispositivo móvil. [1] http://www.uiaccess.com/JustAsk/es/users_eg.html#ref2 De acuerdo a las características a detectar mostramos el cuestionario (tabla 7.18), con el
enfoque de las mismas características a detectar.
Capítulo VII
Página 100
Tabla 7. 18: Cuestionario para obtener el Perfil de Usuario
Cuestionario Enfoque
1. ¿Cuál es tu nombre?
R:
Información general
2. ¿Cuál es tu ocupación?
R:
Identificar la ocupación
de nuestros usuarios
3. ¿Cuál es tu nivel educativo?
Primaria Secundaria Preparatoria o Equivalente
Licenciatura Maestría Doctorado
Otro____________
Detectar el nivel
educativo promedio de los
usuarios
4. Sexo: Masculino Femenino Tener referencia del
porcentaje de sexo de
nuestros usuarios
5. ¿Qué edad tienes? R:__________________________________ Rango de edad de
nuestros usuarios
6. ¿Tienes problemas de vista? Sí No Detección de problemas
visuales
7. ¿Usas lentes?
Sí
No
8. ¿Cuándo los ocupas?
Ver de lejos y cerca Ver de cerca
Ver de lejos
Detección de problemas
visuales
9. ¿Utilizas dispositivo o
dispositivos móviles?
No utilizo
Notebooks
Tablet
(Móvil/Celular)
PDA
Otro
_____________
10. ¿Desde hace cuánto tiempo
aproximadamente?
R:
Experiencia con
dispositivos móviles
11. ¿Se te facilita la visualización de
algún o algunos colores dentro de los
dispositivos móviles?
Sí No
12. ¿Qué colores?
Detección de problemas
visuales y preferencias de
nuestros usuarios.
13. ¿Has utilizado algún servicio como Google Maps, un GPS, o algún
tipo de aplicación por el estilo, que te da una referencia acerca de
donde te localizas? Sí No
Experiencia con servicios
basados en localización
(LBS)
14. ¿Cuántas veces has utilizado estos servicios?
Una vez Más de una vez
Muchas veces
Experiencia con servicios
basados en localización
(LBS)
15. ¿Qué tan frecuente has utilizado estos servicios?
Una vez al día Una vez a la semana
Cada 15 días Una vez al mes
Experiencia con servicios
basados en localización
(LBS)
16. ¿Comúnmente para que lo has utilizado)?
Búsqueda Guiado Orientación
Otro______________________
Detección de tarea(s)
comunes dentro de un
(LBS)
Capítulo VII
Página 101
17. ¿Te cuesta trabajo tener un nivel de concentración en lugares
ruidosos?
Si Casi siempre En ocasiones No
No
Capacidades de
concentración de los
usuarios
18. ¿Te cuesta trabajo tener un nivel de concentración en lugares
donde existen movimientos de cosas como automóviles, personas,
cuando vas en el metro, autobús, etc.?
Si Casi siempre En ocasiones
No
Capacidades de
concentración de los
usuarios
19. ¿Cuántas horas al día ocupas tu dispositivo móvil?
1hr 2hr 3Hr 4hr Mas
¿Cuantas?_______________
Experiencia con
dispositivos móviles
20. ¿Qué tarea o tareas comúnmente realizas al utilizar tu dispositivo
móvil?
Llamadas SMS Navegación por
Internet Redes sociales
Mail Consulta de mapas (GPS)
Otros_____________________________
Detección de tarea(s)
común al utilizar el móvil
20. ¿Prefieres el uso de menús o botones dentro de las diferentes
aplicaciones que utilizas?
Preferencia del usuario
con las interacciones
En la tabla 7.19 mostramos el resultado de los cuestionarios aplicados, y en ella utilizamos
un “x” para indicar a qué tipo de perfil corresponden los usuarios que se presentaron en
nuestra evaluación, el perfil 4 no es un perfil a contemplar dentro de la aplicación, pero es
posible que nos ayude a aportar más ideas de mejora de la aplicación ya que son usuarios
que desconocen totalmente este tipo de aplicaciones.
Capítulo VII
Página 102
7.2.2.1.1 Tabla de Usuario a Analizar
Con conocimiento X Sin conocimiento
Tabla 7. 19: Perfiles de Usuario identificados
Usuario Ideal Usuario con habilidad Móvil Usuario con habilidad Tecnológica Usuario sin habilidades en el dominio
Tipo de
Usuario Perfil 1 Perfil 2 Perfil 3 Perfil 4
Criterio
Tecnológic
o
Móvil
(LBS)
Tecnológic
o
Móvil
(LBS)
Tecnológic
o
Móvil
(LBS)
Tecnológico Móvil
(LBS)
X X X X
Mayor
(38 -
adelante)
Medio (30 -
38)
xx
Joven
(hasta 30) xx x x
Capítulo VII
Página 103
7.2.2.2 Análisis de Tareas
En esta sección realizaremos los casos de uso más representativos de la aplicación.
7.2.2.2.1 Diagramas de casos de uso
Móvil
CU0: Sistema de
Guía Usabie*
*
Figura 7. 16: Diagrama de caso de uso “Diagrama de caso de uso principal”
Móvil
CU1.1: Ubicación
Servidor google maps
«extends»
*
*
CU1.2: Búsqueda
CU1.3: Trazado de
ruta
«extends»
«extends»***
*
Figura 7. 17: Diagrama de caso de uso “Sistema de Integración de usabilidad”
Móvil
CU1.3.1: Trazado
de ruta en mapa«extends»
*
*
Servidor google maps
CU 1.3.2:
Intrucciones de trazado de ruta
-Fin1
* -Fin2
*
«extends»
Figura 7. 18: Diagrama de caso de uso "Trazado de ruta"
Capítulo VII
Página 104
7.2.2.2.2 Plantillas de casos de Uso del Sistema
Tabla 7. 20: RF-01 Ubicación
RF-01 Ubicación
Versión Versión 1.0
Objetivos asociados OBJ - 01 Determina Ubicación
Requerimientos asociados IRQ – 01 Información sobre Ubicación
Descripción El sistema deberá comportarse tal como se describe en el
siguiente caso de uso cuando se decida saber su ubicación.
Precondición Conexión a internet
Secuencia normal Paso Acción
1 El usuario realiza la petición de saber su
ubicación.
2 El sistema envía su latitud y longitud al
servidor en Google.
3 El sistema despliega el mapa con la posición
del usuario.
Postcondición Despliegue en pantalla de la posición del usuario
Excepciones Paso Acción
1 No mostrar la ubicación no existe conexión a
internet Importancia Alta Estabilidad Alta Comentarios Ninguno
Tabla 7. 21: RF-02 Búsqueda
RF-01 Búsqueda
Versión Versión 1.0
Objetivos asociados OBJ - 01 Determinar Ubicación
Requerimientos asociados IRQ – 02 Búsqueda
Descripción El sistema deberá comportarse tal como se describe en el
siguiente caso de uso, cuando se decida realizar una
búsqueda.
Precondición Conexión a internet y tener activado GPS
Secuencia normal Paso Acción
1 El usuario realiza el ingreso del nombre de una
calle, negocio, etc.
2 El sistema envía en una cadena de caracteres
su latitud y longitud al servidor en Google.
3 El sistema muestra la ubicación elegida en
pantalla.
Capítulo VII
Página 105
Postcondición Despliegue en pantalla lo encontrado en relación a la
búsqueda
Excepciones Paso Acción
1 No mostrar os resultados de la búsqueda no
existe conexión a internet Importancia Alta Estabilidad Alta Comentarios No trata casos fallidos
Tabla 7. 22: RF-03 Trazar ruta
RF-01 Trazar ruta
Versión Versión 1.0
Objetivos asociados OBJ - 01 Determinar Ubicación
Requerimientos asociados IRQ – 02 Trazado de ruta
Descripción El sistema deberá comportarse tal como se describe en el
siguiente caso de uso cuando se decida trazar una ruta para
llegar a un punto de interés.
Precondición Conexión a internet y tener activado GPS
Secuencia normal Paso Acción
1 El usuario indicara el punto de interés al que
desea llegar.
2 El sistema enviará la ubicación actual de
usuario, y la ubicación del lugar a donde desea
llegar.
3 El sistema mostrara las opciones del tipo de
trazado de ruta que el usuario elija
4 En caso que el usuario elija solo trazado de
ruta solo mostrara el mapa trazando la ruta de
llegada al lugar donde el usuario desea llegar.
5 En caso de que el usuario elija el trazado por
medio de instrucciones, se mostrar las
indicaciones para llegar al lugar deseado.
Postcondición Despliegue en pantalla lo encontrado en relación a la ruta a
trazar.
Excepciones Paso Acción
1 No mostrar la ruta si no existe conexión a
internet Importancia Alta Estabilidad Alta Comentarios Ninguno
Capítulo VII
Página 106
7.2.2.3 Técnicas clásicas de elicitación de requerimientos (reuniones)
En nuestro caso, a partir de reuniones del equipo de desarrollo, concentramos la
información relativa a los requerimientos derivados del análisis de usuarios y del análisis de
las tareas presentadas en 7.2.2.1 y 7.2.2.2 y cuyos resultados básicamente inciden en la
atención de las siguientes problemáticas:
Elevar la eficacia del LBS de Google Maps.
Mejorar la usabilidad de Google Maps.
7.2.2.4 Técnicas clásicas de análisis de requerimientos
Esta técnica consiste en identificar y clasificar los diferentes requerimientos tanto
funcionales como no funcionales, resolviendo también los posibles conflictos entre los
mismos requerimientos detectados. Para ello se elabora un documento, el cual explica el
estado actual del sistema y la nueva propuesta de solución, este documento se muestra en el
anexo B.
7.2.2.5 Especificación de usabilidad
Para el establecimiento de objetivos de usabilidad tomamos como base los resultados
obtenidos por nuestra fase de evaluación, como son los problemas críticos y no críticos y
tomamos aquellos que se relacionan directamente con la aplicación.
Objetivos de usabilidad:
Mejorar la visualización de las funcionalidades dentro de la aplicación.
Mejorar la eficiencia en uso del trazado de ruta.
Reducir los niveles de insatisfacción en la búsqueda de objetos en el mapa.
Sección 2
7.2.2.6 Card Sorting
La finalidad de esta técnica consiste en obtener el modelo mental más común que existe en
de nuestros usuarios acerca del uso de la aplicación.
Esta técnica se aplicó con un conjunto de tarjetas, de las cuales seis de ellas contienen los
títulos donde se agruparán las demás tarjetas (indicaciones, latitud, navegación, páginas de
sitios, capas).
Estas tarjetas son repartidas y son los usuarios quienes colocan las tarjetas que se les dan en
el título que crean corresponde con una tarea LBS previamente definida.
Se genera posteriormente una matriz de frecuencia con la información obtenida, tabla 7.23.
Capítulo VII
Página 107
Tabla 7. 23: Matriz de frecuencia de modelos mentales de los usuarios
Tarjetas Indicaciones Latitud
(Amigos) Ubicación
Navegación (guiado)
Páginas de Sitios
Capas
Información de negocios, lugares, etc.
8
Recomendación de lugares 8
Como llegar caminando 6 2
Como llegar en coche 6 2
Como llegar en Servicio Publico 6 2
Búsqueda de lugar de interés 4 4
Trazado en mapa 5 3
Instrucciones escritas de llegada
5 3
Trafico 8
Vista Satelital 8
Street view 6 2
Localización de amigos 8
Guiado caminando
8
Guiado en coche 8
Guiado en Servicio Publico
8
Capítulo VII
Página 108
El modelo mental más común de los usuarios se muestra en la figura 7.19.
Sección 3
Sección 3
7.2.2.7 DSR
Este documento contiene la descripción de los diferentes requerimientos identificados en
las secciones 1 y 2. Se elaboran casos de uso, plantillas, la descripción de requerimientos
funcionales y no funcionales. El anexo E contiene este documento.
7.2.2.8 Guía de Estilo
Las guías de estilo por momentos son confundidas con guías de usabilidad, las guías solo
contiene cuestiones básicas de la interfaz que se utilizará en los proyectos. Se definen los
logotipos de las empresas proveedoras de las los aplicaciones y de servicios; colores
fundamentales que predominaran dentro de la aplicación; iconografía, etc. La guía de estilo
se muestra en el anexo D.
Figura 7. 19: Arquitectura de Información
Capítulo VII
Página 109
7.2.2.9 Diagramas de interacción del usuario
7.2.2.9.1 Diagramas de secuencia
Movil
Inicia Google Maps
Google Maps Usable
Despliega mapa y ubicación del movil
Servidor Google Maps
Envia solicitud
Envia información de solicitudProcesa solicitud
Figura 7. 20: Diagrama de secuencia "Mi ubicación"
Móvil Google Maps Usable
Inicia Navegacin
Activa GPS
Evia punto de destino y origen y opcion
Despliega informcacion que necesita
Realiza el guiado por voz
Servidor Google Maps
Envia solicitud
Procesa solicitud
Envia información de solicitud
Figura 7. 21: Diagrama de secuencia "Navegación"
Capítulo VII
Página 110
Móvil Google Maps Usable Servidor Google Maps
Inicia función indicaciones
Solicita el destino
Obtiene origen y destino
Envia solicitud
Procesa solicitud
Envia información de solicitud
Despliega informcaión
Figura 7. 22: Diagrama de secuencia "Indicaciones"
Móvil Google Maps Usable Servidor Google Maps
Inicia funcion de Latitud
Despliega Amigos
Selecciona Amigo
Envía solicitud
Despliega información
Envia respuesta
Procesa Solicitud
Figura 7. 23: Diagrama de secuencia "Latitud"
Capítulo VII
Página 111
Móvil Google Maps Usable Servidor Google Maps
Selecciona mis sitios
Despliega los sitios
Selecciona sitio
Envía solicitud
Despliega información
Despliega información
Procesa Solicitud
Figura 7. 24: Diagrama de secuencia "Páginas de Sitios"
Móvil Google Maps Usable Servidor Google Maps
Selecciona Capas
Despliega los opciones
Selecciona trafico, vista satelite, ruta
Envía solicitud
Despliega información
Despliega información
Procesa Solicitud
Figura 7. 25: Diagrama de secuencia "Capas"
Capítulo VII
Página 112
Móvil Google Maps Usable Servido Google Maps
Inicia búsqueda
Solicita Información
Proporciona datos
Envia solicitud con datos
Procesa solucitud
Envia solicitud procesada
Muestra Información
Figura 7. 26: Diagrama de secuencia "Búsqueda"
7.2.2.10 Maqueta de Baja Fidelidad
La maqueta de baja fidelidad es un diseño en papel, a colores y escala natural que permite
modelar los diseños de interfaz. La ventaja principal es el bajo costo y la facilidad con la
que se elaboran y actualizan los diseños para una diversidad de funciones y características
de despliegue de imágenes de diversos dispositivos móviles.
Por maqueta de alta fidelidad se entiende el modelado de los diseños de interfaz
programando y desarrollando funciones directamente sobre los dispositivos móviles y
plataformas para los cuales se destinan las aplicaciones.
Figura 7. 27: Inicio de la aplicación
La figura 7.27 muestra los iconos de inicio de la aplicación. Como se observa, latitud,
navegación, y sitios, están separados Google Maps. Son funcionalidades que se muestran al
Capítulo VII
Página 113
inicio de la aplicación en la maqueta de baja fidelidad. Otras funciones están en el icono
que se nombra Maps.
La funcionalidad “mi ubicación” de nuestra maqueta de baja fidelidad se muestra en la
figura 7.28, y es la primera instancia de interfaz que se desarrolla de la aplicación.
La figura 7.29 muestra el bosquejo de la funcionalidad “buscar”, mostrando la pantalla de
navegación y lo que se muestra el usuario al momento de seleccionar buscar dentro de
nuestro menú mostrado en la parte superior de la pantalla.
La figura 7.30 nos muestra el bosquejo de la interfaz de nuestra funcionalidad “latitud”, la
cual consiste en un servicio que nos ofrece Google Maps de tener la ubicación de nuestros
amigos registrados en las cuentas de Gmail.
Figura 7. 28: Mi ubicación
Figura 7. 29: Buscar
Capítulo VII
Página 114
La figura 7.31 muestra el bosquejo de la funcionalidad “indicaciones”. En esta
funcionalidad Google Maps ofrece las indicaciones acerca de como poder llegar ya sea
caminando, en auto, o en servicio público a un lugar especificado.
La figura 7.31 muestra el bosquejo de la funcionalidad “indicaciones”. En esta
funcionalidad Google Maps ofrece las indicaciones acerca de como poder llegar ya sea
caminando, en auto, o en servicio público a un lugar especificado.
La figura 7.32 muestra el bosquejo de la interfaz “Más”, que se refiere a más opciones que
se tendrán dentro del menú. En ella englobamos una funcionalidad que está directamente en
el menú de Google Maps que es “Capas”.
Figura 7. 30: Latitud
Figura 7. 31: Indicaciones
Capítulo VII
Página 115
La figura 7.33 muestra un bosquejo de la interfaz de la selección de la opción “capas” que
se encuentra dentro de la opción “Más” en el menú.
La propuesta para la solución de visualización de objetos dentro de la aplicación se propone
utilizar edificios y objetos en 3D para una mejor percepción de lugares a resaltar para los
usuarios, la figura 7.34 muestra la interfaz de esta propuesta de solución.
Figura 7. 32: Más
Figura 7. 33: Capas
Capítulo VII
Página 116
7.3 Resultados de la evaluación del proceso de desarrollo Los resultados obtenidos mediante el caso de estudio se muestran en esta sección. Se
muestra una tabla comparativa (tabla 7.24) entre nuestro proceso de desarrollo integrado y
un proceso de desarrollo común para el desarrollo de LBS. Tabla 7. 24: Comparación de procesos de desarrollo
Atributos LBS LBS LBS con usabilidad
integrada
Perfil de Usuario Alto Alto
Contexto de Usuario Bajo Alto
Requerimientos Funcionales Alto Alto
Requerimientos no Funcionales Medio Alto
Establecimiento de Objetivos de
Usabilidad --- Alto
Construcción de arquitectura de
información centrado en el usuario Bajo Alto
Diseño de Interacción Medio Alto
Diseño de guía de estilo Medio Alto
Bosquejos de interfaz en papel --- Alto
Selección de tecnología de
posicionamiento Alto Alto
Modelado de LBS Alto Alto
Diseño de la interfaz Alto Alto
Prototipo Alto Alto
Codificación Alto Alto
Pruebas de software Alto Alto
Pruebas de Usabilidad --- Alto
Figura 7. 34: Objetos dentro del mapa
Capítulo VII
Página 117
Corrección de errores Alto Alto
Establecimiento de mantenimientos Alto Alto
Periodo de tiempo Bajo Alto
Creación de diseños a partir de los
usuarios Bajo Alto
Evaluaciones constantes de equipo
de desarrollo Alto Alto
Evaluaciones constantes de
usuarios Bajo Alto
Tiempo Requerido Bajo Alto
7.3.1 Resultados de la evaluación de la maqueta de baja fidelidad
La evaluación de nuestra propuesta de solución al problema de mejora de la usabilidad, se
orientó a atender las limitaciones de usabilidad detectadas en las fases de Evaluación y
Análisis de nuestro proceso de desarrollo.
Para ello, se realizo una evaluación de nuestro prototipo elaborado en una maqueta de baja
fidelidad, en la cual se hizo un análisis de las acciones y el tiempo requerido por un usuario
para completar un conjunto de tareas previamente definidas [Unicen, 12].
La evaluación se realizó mostrando los prototipos presentados en papel a cuatro usuarios y
realizando preguntas acerca de las interfaces y con la percepción e identificación de
funcionalidades dentro de los diferentes prototipos presentados en papel. A continuación se
muestran los ejercicios realizados.
7.3.1.1 Evaluación de Google Maps en su estado actual
1. Realiza la identificación de las oficinas del IMSS dentro de la siguiente imagen.
Tiempo___________ Figura 7.3: Evaluación Google Maps, ejercicio 1
Capítulo VII
Página 118
2. Identifica donde está representada “tu ubicación” en la siguiente pantalla.
Tiempo__________ Figura 7.4: Evaluación Google Maps, ejercicio 2
3. Identifica dónde se puede encontrar el Menú “funcionalidades” en la siguiente
imagen.
Tiempo_______________ Figura 7.5: Evaluación Google Maps, ejercicio 3
Capítulo VII
Página 119
4. Una vez identificadas las funcionalidades, identifica la funcionalidad
“indicaciones”, la cual te explica la ruta para llegar a un determinado lugar.
Tiempo______________ Figura 7.6: Evaluación Google Maps, ejercicio 4
5. Selecciona un lugar (objeto) de la siguiente pantalla.
Tiempo_________________ Figura 7.7: Evaluación Google Maps, ejercicio 5
Capítulo VII
Página 120
7.3.1.2 Evaluación de Google Maps mejorado en usabilidad
1. Realiza la identificación de las oficinas de la Catedral de Cuernavaca de la siguiente
imagen.
Tiempo________________
2. Identifica dónde esta representada “tu ubicación” en la siguiente pantalla.
Tiempo_____________ Figura 7.9: Evaluación Google Maps mejorado en usabilidad, ejercicio 2
Figura 7.8: Evaluación Google Maps mejorado en usabilidad, ejercicio 1
Capítulo VII
Página 121
3. Identifica dónde se encuentra el Menú “funcionalidades” en la siguiente imagen.
Tiempo______________
Figura 7.10: Evaluación Google Maps mejorado en usabilidad, ejercicio 3
4. Una vez identificadas las funcionalidades, identifica la funcionalidad
“indicaciones”, la cual te explica la ruta para llegar a un determinado lugar.
Tiempo_________ Figura 7.11: Evaluación Google Maps mejorado en usabilidad, ejercicio 4
5. Selecciona un lugar (objeto) de la siguiente pantalla.
Tiempo_______________
Figura 7.12: Evaluación google maps usable ejercicio 5
Capítulo VII
Página 122
7.3.1.3 Tablas de tiempos obtenidos con los diferentes usuarios
Usuario 1: Tabla 7. 25: Evaluación usuario 1
Criterios Acción Google Maps actual
Google Maps
mejorado
Tiempo (MM:SS) Tiempo (MM:SS)
Percepción
Visual
Reconocimiento de
lugares dentro del mapa 00:12 00:10
Identificación de
Ubicación 00:05 00:02
Identificación del menú
de funcionalidades 00:20 00:05
Acciones
Mentales
Elegir funcionalidad
que proporciona
indicaciones de llegada
a un lugar
00:02 00:002
Selección de objetos 00:13 00:10
Usuario 2: Tabla 7. 26: Evaluación usuario 2
Criterios Acción
Google Maps actual Google Maps
mejorado
Tiempo (MM:SS) Tiempo (MM:SS)
Percepción
Visual
Reconocimiento de
lugares dentro del mapa 00:16 00:12
Identificación de
Ubicación 00:04 00:01
Identificación del menú
de funcionalidades 00:25 00:03
Acciones
Mentales
Elegir funcionalidad
que proporciona
indicaciones de llegada
a un lugar
00:01 00:01
Selección de objetos 00:18 00:15
Usuario 3: Tabla 7. 27: Evaluación usuario 3
Criterios Acción
Google Maps actual Google Maps
mejorado
Tiempo (MM:SS) Tiempo (MM:SS)
Percepción
Visual
Reconocimiento de
lugares dentro del mapa 00:14 00:13
Identificación de 00:06 00:03
Capítulo VII
Página 123
Ubicación
Identificación del menú
de funcionalidades 00:30 00:05
Acciones
Mentales
Elegir funcionalidad
que proporciona
indicaciones de llegada
a un lugar
00:02 00:02
Selección de objetos 00:20 00:13
Usuario 4: Tabla 7. 28: Evaluación usuario 4
Criterios Acción
Google Maps actual Google Maps
mejorado
Tiempo (MM:SS) Tiempo (MM:SS)
Percepción
Visual
Reconocimiento de
lugares dentro del mapa 00:12 00:12
Identificación de
Ubicación 00:05 00:02
Identificación del menú
de funcionalidades
00:23 00:03
Acciones
Mentales
Elegir funcionalidad
que proporciona
indicaciones de llegada
a un lugar
00:02 00:02
Selección de objetos 00:19 00:13
7.3.1.4 Tabla de tiempos promedio Tabla 7. 29: Promedio de tiempo
Criterios Acción
Google Maps actual Google Maps
mejorado
Tiempo (S) Tiempo (S)
Percepción
Visual
Reconocimiento de
lugares dentro del mapa 13.5 11.7
Identificación de
Ubicación 5 2
Identificación del menú
de funcionalidades 24.5 3.5
Acciones
Mentales
Elegir funcionalidad
que proporciona
indicaciones de llegada
a un lugar
1.75 1.75
Selección de objetos 17.5 12.5
Capítulo VII
Página 124
A partir de la mejora en tiempo para atender las tareas en las cuales se identifican
problemas de usabilidad y comparando los resultados obtenidos en este punto 7.3,
concluimos que los objetivos de usabilidad en nuestra fase de análisis están cubiertos al
mejorar los tiempos de respuesta para atender las tareas seleccionadas.
Desde luego que la evaluación del proceso de desarrollo de LBS basada únicamente en las
fases de Evaluación y Análisis, tiene limitaciones debidas al espectro de las tareas
seleccionadas, a los perfiles de los usuarios seleccionados y al contexto prevaleciente en la
aplicación de las evaluaciones.
Sin embargo, la solución propuesta, derivada de los hallazgos obtenidos en las etapas de
evaluación y análisis, también corresponde con las recomendaciones que se pueden
encontrar en la literatura de usabilidad. Asimismo, consideramos que siempre son
perfectibles las mejoras y que una vez elaboradas nuevas versiones de las aplicaciones es
deseable aplicar nuevamente el proceso de desarrollo en vista de nuevas mejoras.
CAPÍTULO VIII
Conclusiones En este capítulo se muestran las conclusiones de nuestra investigación, así como posibles
trabajos futuros por desarrollar.
Capítulo VIII
Página 126
8.1 Conclusiones La usabilidad dentro del desarrollo de software cada vez adquiere mayor importancia como
un factor de calidad. Dentro de la literatura especializada encontramos una variedad de
estudios de usabilidad, donde la principal problemática es que en su integración dentro del
ciclo clásico de desarrollo del software, pierde parte de su finalidad de facilitar y hacer
agradable a los usuarios la ejecución de sus tareas. Además de la variedad de esquemas de
uso e interacción de los usuarios con los sistemas de cómputo y comunicaciones que
muchas veces no son contemplados por los ingenieros de software.
Usabilidad no es un término que tenga pocos años de investigación. Existen diversos
estudios que analizan la usabilidad desde diferentes enfoques: usabilidad en la arquitectura
de software, usabilidad en el proceso de desarrollo del software y quizás la más conocida
dentro de la literatura, usabilidad en la interfaz del usuario.
La mayor parte de estos estudios de usabilidad tienen un enfoque de evaluación de software
y diferentes métricas propuestas tanto por estándares como por diferentes autores
pertenecientes a la disciplina IPO. Este enfoque de evaluación trata precisamente de evaluar
el software en su etapa de implementación o funcional, y tiene como consecuencia altos
costos de rediseño o restructuración de las diferentes aplicaciones software.
Tratando de encontrar una solución a esta problemática, se han propuesto diferentes
enfoques de desarrollo del software tratando de incorporar los factores de usabilidad desde
etapas tempranas. Es por ejemplo el caso de los diseños centrados en el usuario (DCU).
Por otra parte en los últimos años se ha notado una notable evolución de los dispositivos
móviles, presentando desafíos tanto tecnológicos como de desarrollo de aplicaciones que se
adapten a este tipo de dispositivos.
En esta investigación nos interesamos específicamente en los servicios basados en
localización, que ha surgido con la convergencia de diferentes tecnologías como son los
sistemas de información geográfica (GIS), el internet y los dispositivos móviles.
Las aplicaciones que se están desarrollando para este tipo de aplicaciones móviles
demandan un mayor nivel de usabilidad, y un desarrollo más detallado y analítico de sus
aplicaciones ya que estas aplicaciones están expuestas a diferentes contextos de uso como
es el ambiente, el tipo de usuario, el propósito de las tareas, las capacidades de los
dispositivos, etc. Estos contextos hacen que las aplicaciones móviles difieran del desarrollo
del software para escritorio por llamarlo de alguna, manera.
Tratando de desarrollar servicios que contemplen y superen los diferentes ambientes que se
le presentan dentro de los contextos en los cuales se ve involucrado el uso de los servicios
basados en localización, se propone un proceso de desarrollo, desde la perspectiva del
diseño centrado en el usuario con la finalidad de mejorar los niveles de usabilidad en este
tipo de servicios.
Nuestro proceso de desarrollo toma en cuenta la columna vertebral del desarrollo de
software, y se manifiesta a través de un proceso claro, entendible, y flexible, que adapta e
integra la usabilidad dentro de este mismo proceso, considerando las especificidades de las
tareas de desarrollo de las aplicaciones móviles, los perfiles de usuario y las características
de los dispositivos móviles.
Capítulo VIII
Página 127
8.1 Trabajos Futuros En este apartado mostramos los posibles estudios futuros que se podrían realizar
relacionados con esta investigación.
Extensión del proceso de desarrollo.-Este trabajo consistiría en realizar el análisis
de las demás técnicas propuestas por los diferentes autores de la IPO, ya que nuestro
proceso de desarrollo está basado solo en dos propuestas de la literatura IPO como
son la de Nielsen y Mayhew. Sería deseable analizar otras técnicas para
complementar el proceso de desarrollo, extendiéndolo y garantizando mayores
niveles de usabilidad,
Evaluación de todo el proceso de desarrollo.-Se podría realizar la validación
completa de nuestro proceso de desarrollo, ya que por cuestiones de tiempo,
solamente fue evaluada la parte de análisis, la cual es la parte que mayormente
incide en la usabilidad. Se podría realizar el desarrollo completo de una aplicación y
adicionalmente a evaluar la mejora en usabilidad, evaluar la consistencia,
coherencia y completez de cada una de sus fases y actividades,
Relación métrica componente de software.- En la literatura existen diversas
métricas propuestas en diferentes modelos de usabilidad y estándares. Sería
interesante realizar una investigación bajo un estudio empírico que pudiera
demostrar cómo están ligadas las diferentes métricas con los componentes de
software. Esto proporcionaría un amplio panorama acerca de cómo estructurar el
software, así como de seleccionar los componentes que aumenten la usabilidad,
Visión de Servicios basados en localización.- La realidad aumentada se considera
que permite mejorar la experiencia del usuario en los servicios basados en
localización. Por ejemplo, proporciona una visión imaginaria sobre el escenario real
en el que se encuentra para seguir una línea del trazado de ruta o para destacar el
logotipo o nombre del negocio o restaurant que busca dentro de un mapa. Sería
deseable desarrollar métodos y técnicas específicos para este tipo de desarrollos que
garanticen una mayor usabilidad.
Referencias bibliográficas
Referencias bibliográficas
Página 129
[Abran, 03] A. Abran, A. Khelifi, W. Suryn et al., “Consolidating the ISO
Usability Models,” in Proceedings of 11th International Software
Quality Management Conference, Glasgow, Scotland, UK, 2003.
[Anderson, 01] Anderson, J.; Fleek, F.; Garrity, K.; Drake, F.: “Integrating
Usability Techniques into Software Development”. IEEE
Software. Vol. 18, No. 1. pp. 46- 53, 2001
[ASS, 2011] Assa Abloy Future Lab, Rastreo basado en localización,
recuperado en http://www.assaabloyfuturelab.com/es/site/Le-
futurlab/Noticias/News/20102/News/Location-based-tracker-ES/,
consultado el 28/02/2011
[Biel, 10] Biel, B. & Grill, T, & Gruhn, V. “Exploring the benefits of the
combination of a software architecture analysis and a usability
evaluation of a mobile application”, The Journal of Systems and
Software 83, University of Duisburg-Essen, Germany, 2010.
[Blanco, 09] Blanco P., Metodología de desarrollo ágil para sistemas móviles
Introducción al desarrollo con Android y iPhone, Tesis Doctoral,
Universidad Politécnica de Madrid (UPM), 2009.
[Broadbent, 97] J Broadbent, Marti P.: “Location Aware Mobile Interactive
Guides: usability issues”. In Proceedings of the Fourth
International Conference on Hypermedia and Interactivity in
Museums (IHCIM97), Paris, 1997
[Coursaris, 06] Coursaris, C. K. and Kim, D. J. "A Qualitative Review of
Empirical Mobile Usability Studies." Twelfth Americas
Conference on Information Systems, Acapulco, Mexico 2006
[Dey, 01] Dey, A., “Understanding and Using Context”. Personal and
Ubiquitous Computing 5, publicación, ACM, Atlanta, GA, USA
2001.
[Diaper, 89] Diaper D. “The discipline of human-computer interaction”,
Interacting with computers, núm. 1, vol. 1, Butterworth-
Heinemann Ltd., Guildford, Reino Unido, 1989
[ESRI, 02]. ESRI, “What are Location Services? – From GIS Pespective”,
disponible en <
http://lbs360.directionsmag.com/LBSArticles/ESRI.What%20are
%20LS%20Whitepaper.pdf > consultado el 04/03/2011
[Ferre, 05] Xavier Ferré, Marco de Integración de la Usabilidad en el
Proceso de Desarrollo del Software, Tesis Doctoral, UPM, 2005.
Referencias bibliográficas
Página 130
[Formica, 08] Formica, A.,” Location based Services(LBS)”, Punto de
encuentro Galileo para industrias, disponible en
< http://www.galileoic.org/la/files/LBS%20LOCALIZAR-T.pdf
> consultado el 27/02/2011
[Greene, 03] Greene S. and Finnegan J. “Usability of mobile devices and
intelligently adapting to a user’s needs”, In Proceedings of the
1st international symposium on Information and communication
technologies, paginas 175–180, Dublin, Ireland, 2003.
[Granollers, 04] T. Granollers, "Integración de la IPO y la Ingeniería del
Software: MPIu+a" in Llenguatges Sistemes Informàtics,
Doctorade. Lleida: Lleida, 2004
[Grill 2009] Grill, T., 2009. “Designing interactions in mixed interaction
environments”. Tesis Doctoral. Johannes Kepler University Linz,
Altenbergerstr. 69, 4030 Linz (December). Disponible
http://www.tomgrill.info/show.php?name=PhD.
[Gurdin, 02] Grudin, J., Pruitt, J.,”Participatory design and product
development: an infrastructure for engagement”. In: Proceedings
of PDA, 2002.
[Holzinger, 05] Holzinger, “Usability Engineering Methods for Software
Developers”, Communications of the ACM 48(1), 71–74,2005
[Humayoun, 09] Humayoun S.,Catarci T.,de Leoni M.,Marrella A.,Mecella M.,
Bortenschlager M., “Steinmann: Designing Mobile Systems in
Highly Dynamic Scenarios. The WORKPAD Methodology”.
Journal on "Knowledge, Technology & Policy", Vol. 22 No. 1,
Springer, 2009.
[IEEE, 90]
IEEE, "IEEE Standard Glossary of Software Engineering
Terminology" St. 610.121990
[IEEE, 04] IEEE 1471-2000 Recommended Practice for Architectural
Description for Software-Intensive Systems-Desciption, 2004.
[Imielinski, 96] Tomasz Imielinski, Henry F. Korth, “Mobile Computing”,
Springer, ISBN: 0792396979, 1996
[ISO 9241-11, 98]
ISO, "ISO 9241-11 “Ergonomic requirements for office work
with visual display terminals” (VDTs), First edition 1998-03-15
", 1998.
Referencias bibliográficas
Página 131
[ISO13407, 99] ISO, ISO 13407. “Human-Centred Design Processes for
Interactive Systems”. ISO, Geneva (Switzerland), 1999.
[Jacaboson, 00] Jacaboson, I., Booch, G., Rumbaugh J., “El Proceso Unificado
de Desarrollo de Software”, Addison Wesley 2000.
[Kaasinen, 03]
Kaasinen, E., “User needs for location-aware mobile services”,
publicación, Springer, Pers Ubiquit Comput 70–79, London,
2003
[Kjeldskov, 03] Kjeldskov J. and Graham C. “A Review of MobileHCI Research
Methods”. 5th conferencia internacional de Mobile HCI, Udine,
Italy. LNCS, Springer-Verlag, pp. 317-335, 2003.
[Kjeldskov, 05] Kjeldskov J., Graham C., Pedell S., Vetere F., Howard
S., Balbo R., Davies J., “Evaluating the usability of a mobile
guide: The influence of location, participants and resources”,
Behaviour and Information Technology, 2005.
[Kozaczynski, 98] Wojtek Kozaczynski, SSA, Alan W. Brown, Kurt C. Wallnau
“The Current State of CBSE”, Journal IEEE Software, Vol 15
Issues 5, CA, USA, 1998
[Liu, 03] Liu L. and Khooshabeh P., "Paper or Interactive? A Study of
Prototyping Techniques for Ubiquitous Computing
Environments" presented at Human Factors in Computing
Systems, Ft. Lauderdale, Florida, USA., 2003
[Manchon, 03] Manchon E., “¿Qué es la Interacción Persona-Ordenador?
(Human Computer-Interaction) Definición:”, alzado.org, 2003,
disponible en
http://www.usabilitynet.org/trump/methods/integration/assurance
.htm
[Mayhew, 99] D.J. Mayhew. The Usability Engineering Lifecycle. Morgan
Kaufmann, San Francisco (CA), USA, 1999.
[Mobinex, 2011] Mobinex, Mobile Application Development Methodology V3,
disponible en:
http://developer.smartface.biz/documents/Application_Developm
ent_Methodology.pdf, recuperado en 07 de marzo de 2011
[Montilva, 03] Jonás A. Montilva C., Nelson Arapé y Juan Andrés Colmenares.
“Desarrollo Basado en Componentes”, p 3.200, Málaga, 2003
[Nielsen, 93] J. Nielsen, Usability Engineering: Academic Press, 1993.
Referencias bibliográficas
Página 132
[Nivala, 03] Nivala, A-M. and Sarjakoski, L.T,”Need for Context-Aware
Topographic Maps in Mobile Devices. In Virrantaus”,
Conference on Geographical Information Science, June 4-6,
Espoo, Finland, pp. 15-29. Disponible en:
http://www.scangis.org/scangis2003/papers/.
[Paulk, 93] Paulk, M., “Capability Maturity Model for Software, Software
Engineering Institute”, Carnegie Mellon University, Pittsburgh,
PA, 1993.
[Pressman, 97] Pressman, R, Ingeniería del Software: Un enfoque práctico,
McGraw Hill 1997
[Preece, 94] J. Preece, Y. Rogers, H. Sharp, D. Benyon, S. Holland, T. Carey.
“Human-Computer Interaction”, Addison Wesley, 1994.
[Sanchez, 09] Y Sánchez, Y Gómez, D. Pantoja, “Proposal Methodology For
Development Of Mobile Applications Using The Framework
Plaser”,VII Congreso Internacional de Informática en la Salud,
Cuba, 2009.
[Sarjakoski, 05] Sarjakoski, L.T. and A.M. Nivala. “Adaptation to Context A
Way to Improve the Usability of Mobile Maps”, Mobile Services
Theories, Methods and Implementations, Springer, NY, pp.
107123, 2005.
[Satyanarayanan, 96] M. Satyanarayanan, "Fundamental Challenges in Mobile
Computing", Proc. 15th ACM Symp. Principles of Dist. Comp.,
Philadelphia, PA, 1996
[Schiller, 04] Schiller, Jochen , Part 1 “LBS Applications”, Location-Based
Services, publicado en 2004 por Morgan Kaufman, disponible
en:
<http://books.google.es/books?hl=es&lr=&id=wj19b5wVfXAC
&oi=fnd&pg=PP1&dq=Location-
Based+Services+Jochen+Schiller&ots=lbLj5wqeIk&sig=CmPEf
MDUqFCcnD-DHr92FJQXTg4#v=onepage&q&f=false >.
[Seco, 08] Seco, Fernando, “Tema 3.3: Sistemas de localización en
interiores basados en radiofrecuencia”, curso, Instituto de
Automática Industrial – CSIC, Universidad de Alcalá, 2008,
disponible en: <
http://www.iai.csic.es/lopsi/static/publicaciones/docencia/Apunte
s%20RF-LPS.pdf > consultado el 05/03/2011
Referencias bibliográficas
Página 133
[Sommerville, 02] Sommerville, I., Ingeniería de Software, Pearson Educación, 02.
[SOWEBOK, 04] IEEE Computer Society Professional Practices Committee.
"Guide to the Software Engineering Body of Knowledge - 2004
Version". IEEE Computer Society, Los Alamitos (CA), USA,
2004.
[Steiniger, 06] Steiniger S., Neun M., Alistair E.,“Foundations of Location
Based Services”, Departamento de Geografía, Universidad de
Zurich, Suiza. 2006
[Szyperski,98] Clemens Szyperski, “Component Software Component Software
Beyond Object – Oriented Programming”. P 20 - 22. 1998.
[Telefonica, 11] Telefonica, El contexto y su uso, disponible en <
http://www.lacofa.es/index.php/tecnologias/el-contexto-y-su-
contexto >. Consultado el 19 febrero 2011
[Ubiquitous, 11] UbiquitosComputing,”What Is Ubiquitous Computing?”,
disponible en < http://www.rcet.org/ubicomp/what.htm >,
consultado el 14/02/2011
[Unicen, 12] Unicen “Métodos de Evaluación”, disponible en
<http://eisc.univalle.edu.co/cursos/web/material/750093M/80/me
todos_evaluacion.pdf> consultado el 03/01/12
[wikiLBSpro, 11] LBSPro, Servicios Basados en Localización, recuperado en <
http://wiki.lbspro.com/index.php?title=LBS>, consultado el
26/02/2011
Anexo A
Análisis de Técnicas IPO En este anexo se muestra un análisis de las técnicas IPO más utilizadas aplicables al
desarrollo de aplicaciones LBS.
Anexo A
Página 135
A.1 Análisis de Técnicas Tabla A.4: Análisis de técnicas
Técnica Análisis Contexto Producto
Nivel de Aceptación
Características de
los Usuarios
[Nielsen 93].
Si bien sabemos en cualquier sistema es
importante tener en cuenta las diferentes
características de los usuarios, la técnica
que describe Nielsen en su trabajo de
ingeniería de usabilidad se adapta a lo que
buscamos, ya que dentro de nuestra
aplicación es importante considerar las
características particulares de los usuarios
como son los que el menciona: experiencia
de trabajo, nivel educativo, edad,
experiencia previa con ordenadores, y
conocer su contexto de trabajo y social, son
cuestiones que son necesarias identificar en
nuestra aplicación, ya que con ello
podremos optimizar tanto los niveles de
presentación de la información, como las
posibles funcionalidades ofrecidas a el
usuario.
Usuario
Perfil de
Usuario.
Cuestionarios de
Perfiles de
Usuarios
[Mayhew 99].
Esta técnica nos ayuda a identificar las
características de los usuarios, la cual
podría ser aplicada dentro de los LBS, ya
que recopila la información necesaria del
usuario, que se necesita en un LBS.
Usuario Perfil de
Usuario
Entrevistas
Contextuales
[Mayhew 99].
En esta técnica se identifica el medio de
trabajo, en nuestro caso de los LBS, lo
traduciremos a nuestro medio físico, ya que
a diferencia de una aplicación de escritorio
nuestro contexto juega un papel de suma
importancia hablando del medio físico que
rodea al móvil.
Aplicación *Outdoor
*Indoor
Anexo A
Página 136
Técnica
Análisis
Contexto
Producto
Nivel de Aceptación
Diagramas de
Afinidad
[Mayhew 99].
Si bien es necesario que dentro nuestra
aplicación de los LBS sea necearía la
identificación del contexto es decir el
entorno en que será ejecutado, como
sabemos los diferentes ambienten en
cualquier momento puede ser drásticamente
diferente, tanto en aplicaciones interiores
(indoor) o exteriores (outdoor). Por ello se
considera esta técnica para el desarrollo de
un LBS, ya que dentro de ella se realiza un
reconocimiento de ambiente de trabajo, lo
que podríamos traducir a el contexto físico
en donde se encuentre el móvil, con el
reconocimiento de este contexto podremos
tener una mayor aprovechamiento tanto del
hardware como del software, ofreciendo al
usuario una mayor eficiencia en uso.
Aplicación *Outdoor
*Indoor
Escenarios de
Tareas
[Mayhew 99].
Se identifican las tareas más
representativas de una aplicación, con estos
realizamos una representación del trabajo
en la vida real, en estas se presentan
instancias de casos de uso.
Aplicación *Outdoor
*Indoor
*Análisis
Competitivo
[Nielsen 93].
Esta técnica consiste en analizar los
productos existentes, y realizar un análisis
heurístico de estos productos, en relación
con las guías de usabilidad existentes, por lo
cual para los LBS, no es aplicable ya que no
existe un prototipo ideal especifico de
usabilidad para los LBS.
*Análisis de
Impacto
Financiero
[Nielsen 93].
Esta técnica no es aplicable dentro de
nuestros LBS, ya que no se desarrolla una
aplicación empresarial, donde se pueda
expresar, las recuperaciones financieras del
servicio.
Restricción de
Plataforma
[Mayhew 99].
Esta técnica se utiliza para identificar las
características relevantes de las plataformas
tanto en el hardware y software sobre las
que funcionara el sistema, en nuestro caso
es de una importancia identificar las
características mínimas del dispositivo para
un correcto funcionamiento del LBS.
Móvil
Dominio
especifico
de
móviles
Anexo A
Página 137
Técnica Análisis Contexto Producto
Nivel de Aceptación
Objetivo de
Usabilidad
[Nielsen 93].
Esta técnica establece la identificación de
usabilidad desde los inicios de un proyecto
en relación a un determinado patrón de
usabilidad, lo cual dentro de nuestro
objetivo por alcanzar niveles de usabilidad
elevados es una técnica útil para el
desarrollo de los LBS, ya que haciendo un
análisis de los desarrollo hemos observado
que es importante trazar este objetivo de
usabilidad desde el comienzo del desarrollo
de una aplicación, para poder tener nuestros
parámetros de optimización con respecto a
la usabilidad.
Usuario
Aplicación
Móvil
Perfil de
Usuario
*Outdoor
*Indoor
Dominio
especifico
de
móviles
Objetivo de
Usabilidad
[Mayhew 99].
Esta técnica también realiza un
establecimiento de niveles de usabilidad
desde los inicios de el desarrollo de una
aplicación, pero en la se realiza una
calcificación de objetivos tanto cualitativos
como cuantitativos, y menciona 3 tipos
como son objetivos de rendimiento,
objetivos de satisfacción y objetivos de
preferencias, con esta clasificación es
posible adaptarse a las diferentes interfaces
del servicio, y medir el nivel de rendimiento
del usuario con los LBS.
Usuario
Aplicación
Móvil
Perfil de
Usuario
*Outdoor
*Indoor
Dominio
especifico
de
móviles
Diseño Paralelo
[Nielsen 93].
Esta técnica consiste en realizar un diseño
preliminar del sistema, donde se diversifica
a los diseñadores o diseñador se centre en
problemas de diseño detectados.
Aplicación
*Outdoor
*Indoor
Task-Sorting
[Mayhew 99].
Esta técnica consiste en dar a un grupo de
usuarios unas tarjetas, las cuales contienen
información que se proporcionara a los
usuarios información la aplicación, donde el
usuario realizara una reagrupación de las
tarjetas, y proporcionara un nombre al
grupo de cada una de las tarjetas, con el fin
de tener una esquema de modelo conceptual
de información que se mostrará.
Aplicación
*Outdoor
*Indoor
Anexo A
Página 138
Técnica Análisis Contexto Producto Nivel de
Aceptación
Card Sorting
[Nielsen 93].
Esta técnica, consiste en trabajar con un
grupos de usuarios, y en unas tarjetas
pongan las ideas del el sistema como se
estructurara, esto con la finalidad de tener
un estructura más sólida de la distribución
de la información, esto sería de mucha
ayuda dentro de los LBS, pues ayudaría a
optimizar la información necearía que el
usuario le gustaría visualizar.
Aplicación
*Outdoor
*Indoor
Maqueta de Baja
Fidelidad
[Mayhew 99].
Esta técnica presenta al usuario una idea de
la información que se mostrara en la
aplicación, así como las funcionalidades
que se presentaran, este diseño se presenta
en papel, esto sería de ayuda en los LBS ya
que con ello podríamos detectar si la
visualización del sistema e información que
se mostrara cumple con las expectativas
tanto del usuario como desarrolladores.
Aplicación
*Outdoor
*Indoor
Maqueta de Alta
Fidelidad
[Mayhew 99].
Esta técnica realiza un estructura miento de
la interfaz al usuario, visualizando la
información y funcionalidades de la
aplicación, este prototipo se realiza ya en
una ejecución de máquina, aun sin
funcionalidades pero con un esquema más
claro de la navegación, dentro de nuestros
LBS, es una técnica aplicable, ya que se
observaría un esquema más concreto de
interacción entre el usuario y el servicio.
Aplicación
Móvil
*Outdoor
*Indoor
Dominio
especifico
de
móviles
Prototipado
[Nielsen 93].
En esta técnica nos da la libertad de hacerlo
sobre una ejecución de la aplicación o sobre
un prototipo de papel, donde solo se
muestre los aspectos del sistemas de
interacción, en cualquiera de los dos casos,
solo se muestra la interfaz del sistema, su
navegabilidad pero con reducidas
funcionalidades solo un esquema general de
la aplicación, estos prototipos se realizan en
base a escenarios, por lo que respecta a los
LBS, es aplicables el prototipado ya que
ayudarían a realizar mejoras ya sea en una
navegabilidad, funcionalidad o esquema de
la información visualizada que el usuario
detectara en este punto.
Aplicación
Móvil
*Outdoor
*Indoor
Dominio
especifico
de
móviles
Anexo A
Página 139
Técnica Análisis Contexto Producto Nivel de
Aceptación
Guías de Estilo
[Mayhew 99].
En esta técnica se desarrollan modelos
como son diseños de pantallas, con el
objetivo de tener una mayor consistencia en
usabilidad, se maneja en varios subniveles
como son: Plataforma, Organización, o
producto en particular, esto ayudaría a los
LBS a tanto en pantalla de interfaz como en
plataforma, para tener esquema más claro y
concreto de lo requerido dentro de los
niveles de usabilidad.
Aplicación
Móvil
*Outdoor
*Indoor
Dominio
especifico
de
móviles
Retroalimentació
n con los
Usuarios
[Nielsen 93].
Esta técnica consiste en que el usuarios
pueden realizar sus comentarios de mejora
de la aplicación, por diferentes medios que
existan como son correo, grupos de noticias,
etc. Dentro de los LBS es una técnica
aplicable siempre y que se tenga un equipo
de soporte técnico capaz de resolver los
diferentes cometarios de los usuarios.
Usuario
Aplicación
Móvil
Perfil de
Usuario
*Outdoor
*Indoor
Dominio
especifico
de
móviles
Retroalimentació
n con los
Usuarios
[Mayhew 99].
En esta técnica, se propone analizar las
dificultades observadas por los diferentes
usuarios, dentro de ella realiza una
clasificación de cómo se podrían realizar
esta técnica, uno de los métodos para
aplicar esta técnica son los estudios de uso,
por lo que en los LBS, seria de suma
importancia realizar un estudio con los
usuarios para detectar los problemas de
usabilidad encontrados y poder realizar las
correcciones.
Usuario
Aplicación
Móvil
Perfil de
Usuario
*Outdoor
*Indoor
Dominio
especifico
de
móviles
Evaluación
Heurística
[Nielsen 93].
En esta técnica se involucran tanto
desarrolladores del producto como los
especialistas en usabilidad, realizando un
análisis de la interfaz del sistema. Por lo
que en el desarrollo de un LBS, sería una
técnica aplicable, ya que con ellos se podría
tener un ahorro de tiempo para la
evaluación del servicio, y detectar
problemas en etapas tempranas y oportunas
para sus posibles modificaciones, el
inconveniente de esta técnica es que no
siempre se cuenta con los especialistas en
usabilidad.
Aplicación
Móvil
*Outdoor
*Indoor
Dominio
especifico
de
móviles
Anexo A
Página 140
Técnica Análisis Contexto Producto Nivel de
Aceptación
Test Formales de
Usabilidad
[Mayhew 99].
En esta técnica se realiza una evaluación
con los usuarios, en la propuesta de
Mayhew se presentan diferentes pruebas
formales, que nos ayudan a obtener esta
serie de resultados de la mejor manera
posible, esta técnica es aplicable a los LBS,
ya que con ella se detectarían problemas en
casos reales y se podría lograr una mejor
personalización del servicio.
Usuario
Aplicación
Móvil
Perfil de
Usuario
*Outdoor
*Indoor
Dominio
especifico
de
móviles
Pensar en Voz
Alta
[Nielsen 93].
En esta técnica consiste en tener a un
usuario interactuando con el sistema y
pensando en voz alta las ideas que va
teniendo sobre el sistema, para poder tener
una mejor visión dé la impresión que tiene
el usuario, esta técnica es aplicable a los
servicios contextuales ya que con ella
tendremos una mejor idea, dé la impresión
del usuario.
Usuario
Aplicación
Móvil
Perfil de
Usuario
*Outdoor
*Indoor
Dominio
especifico
de
móviles
Técnicas de Test
Remoto
[Mayhew 99].
Esta técnica nos ofrece diferentes maneras
de realizar la evaluación de usabilidad
desde el entorno de trabajo del usuario, esto
con la finalidad de estar trabajando con el
sistema en su contexto natural y tener una
mejor idea del problema, esta técnica no es
aplicable a los LBS, ya que algunos
métodos mencionados dentro de la misma
técnica no tienen factibilidad por las
limitaciones que presentan los dispositivos
móviles tanto en software y hardware.
Usuario
Aplicación
Móvil
Perfil de
Usuario
*Outdoor
*Indoor
Dominio
especifico
de
móviles
Test de
Usabilidad
[Nielsen 93].
En esta técnica se nos presenta un esquema
muy general de los pasos que debe contener
una prueba de usabilidad, dentro de la cual
la consideramos optima dentro de los LBS,
ya que contiene una estructura detallada,
pero dentro de ella sería necesario realizar
la definición de el tipo de prueba ya que la
estructura que nos muestra técnica contiene
una serie de pasos como lo son:
Preparación, introducción, el propio test, y
elaboración del informe del test, la cual nos
serviría como estructura de prueba dentro
de los LBS.
Usuario
Aplicación
Móvil
Perfil de
Usuario
*Outdoor
*Indoor
Dominio
especifico
de
móviles
Anexo A
Página 141
Técnica Análisis Contexto Producto Nivel de
Aceptación
Laboratorio de
Usabilidad
[Nielsen 93].
Esta técnica consiste en realizar las pruebas
de usabilidad dentro de un laboratorios
especializado para ello, teniendo espejos y
cámaras de video para observar y grabar al
usuario en cada acción que realice dentro de
una interacción con la aplicación, esta
técnica no la vemos aplicable a los LBS, ya
que no es común contar con un laboratorios
de usabilidad.
Grabación en
vídeo
[Nielsen 93].
Esta técnica consiste en realizar grabaciones
de video con usuarios, detectando los
problemas de usabilidad en los diferentes
usuarios grabados, para así poder ser
analizados los videos y ser rectificados con
el grupo de desarrolladores y especialista de
usabilidad, por lo que vemos la técnica
aplicable a los LBS, ya que demostraría
claramente las deficiencias del servicio en
condiciones reales de uso.
Usuario
Aplicación
Móvil
Perfil de
Usuario
*Outdoor
*Indoor
Dominio
especifico
de
móviles
Observación
[Nielsen 93].
Dentro de esta técnica, se realiza visitando a
un usuario dentro de su lugar de trabajo,
realizando notas de lo que realiza y
posiblemente realizar una grabación, el
observador no debe interferir en las
acciones del usuario, para así poder detectar
los problemas de usabilidad una vez
analizadas las notas y los videos según sea
el caso, esta técnica es aplicable a los LBS,
ya que sería de comodidad solo observar
cómo se realiza la interacción entre el
servicio y un usuario.
Usuario
Aplicación
Móvil
Perfil de
Usuario
*Outdoor
*Indoor
Dominio
especifico
de
móviles
Cuestionarios y
Entrevistas
[Nielsen 93].
Dentro de esta técnica se busca encontrar la
satisfacción subjetiva de los usuarios,
realizando una serie de cuestionarios ya sea
por vía correo electrónico o una entrevista,
esta técnica es aplicable a los LBS, y la cual
nos podría ayudar a detectar los posibles
problemas o deficiencias de la aplicación
dentro de los LBS.
Usuario
Aplicación
Móvil
Perfil de
Usuario
*Outdoor
*Indoor
Dominio
especifico
de
móviles
Anexo A
Página 142
Técnica Análisis Contexto Producto Nivel de
Aceptación
Focus Groups
[Nielsen 93].
En esta técnica se realiza reunir un grupo de
usuarios reducido, donde en cada grupo
existe un moderador atendiendo sus ideas, y
explicando un tema de interés, este con el
fin de identificar temas relevante que
puedan ayudar a la aplicación, esta técnica
no es aplicable a los LBS, ya que por el
diseño de nuestro LBS, no es una aplicación
tan amplia, dentro de estas evaluaciones se
busca realizar mejoras ha funcionalidades y
visualizaciones de información.
Registro del Uso
Real
[Nielsen 93].
Esta técnica puede ser considerada como
suplementaria a las pruebas de usabilidad,
ya que consiste en que una computadora
recogiendo datos estadísticos después del
lanzamiento del producto, esta técnica es
aplicable dentro de los LBS, pues
podríamos revisar los datos generados en
estadísticas de las pruebas realizadas en el
campo, realizando unas pruebas más
formales y completas.
Usuario
Aplicación
Móvil
Perfil de
Usuario
*Outdoor
*Indoor
Dominio
especifico
de
móviles
GOMS
[Nielsen 93].
Esta técnica, tiene como objetivo verificar
las metas y subtemas trazadas tanto para los
usuarios como los desarrolladores, aunque
por otra parte estas técnicas solo consideran
la utilidad del sistema y dentro de las
debilidades de GOMS, no considera los
factores que pudieran afectar al usuarios
como cansancio, alrededores sociales u
organizacionales, por lo que dentro de
nuestros servicios es importante la
consideración de estos factores.
Nomenclatura de nivel de aceptación
Aceptada Alternativa No
aceptada
En la tabla A.1, se muestra la relación entre los subproductos de los LBS y las técnicas
analizadas de la IPO, mostrando la menar de cómo obtener los diferentes subproductos
mediante las diferentes técnicas IPO.
La tabla A.2 muestra la relación entre sub-productos de los LBS t las diferentes técnicas
analizadas de la literatura IPO.
Anexo A
Página 143
A.2 Relación de sub-productos LBS y técnicas de usabilidad Tabla A.5: Relación de sub-productos y técnicas IPO
LBS (Servicios Basados en Localización) Usabilidad
Contexto Factores Product
o
Sub-
Productos Descripción del Sub-
Producto
Fase de
Usabilidad
Actividad
específica de
Usabilidad
Técnica de HCI Descripción de la
Técnica
Usuario
Perfiles
de
Usuario
Cultural
y Social
Perfiles
de
Usuarios
Identificació
n de
contexto de
Usuario
[Biel 10],
[Nivala 03],
[Gurdin 02].
Realizar la identificación de
perfiles de acuerdo a las
características comunes de
un grupo de usuarios
identificado, para ayudar a la
personalización de los
servicios
Actividad
des de
Análisis
Espe
cific
ació
n del
cont
exto
de
Uso
Análisis
de
Usuarios
**Características
de usuarios
[Nielsen 93].
Identificación de las
características físicas y
capacidades de los
usuarios.
Cuestionarios de
perfiles de
usuarios [Mayhew
99].
Identificación de las
características y
capacidades de los
usuarios atreves de
cuestionarios a
usuarios potenciales de
la aplicación.
Aplicación
Ubicació
n
Finalidad
de Uso
Tiempo
Ambient
e Físico
Indoor
Outdoor
Identificació
n de
contexto
físico
[Biel 10],
[Nivala 03],
[Kjeldskov
03]
Identificar los elementos
necesarios que intervendrán
en el ambiente real del
servicio que se desea
desarrollar, ya que los
ambientes tanto en interiores
como exteriores es diferente.
Análisis
de tareas
**Entrevistas
contextuales
[Mayhew 99].
Realizar entrevistas,
para la identificación
del ambiente de trabajo
de una aplicación.
Diagramas de
afinidad
[Mayhew 99].
De la información
recolectada de las
entrevistas
contextuales, la cual
ayudara a realizar
ambientes más
apegados el ambiente
de trabajo.
Anexo A
Página 144
LBS (Servicios Basados en Localización) Usabilidad
Contexto Factores Product
o
Sub-
Productos Descripción del Sub-
Producto
Fase de
Usabilidad
Actividad
específica de
Usabilidad
Técnica de HCI Descripción de la
Técnica
Aplicación
Ubicació
n
Finalidad
de Uso
Tiempo
Ambient
e Físico
Indoor
Outdoor
Identificació
n de
finalidad de
uso
[Biel 10],
[Nivala 03],
Identificar los casos claves
que pueden realizarse dentro
del LBS, ya separa
orientación, búsqueda de
servicios, búsqueda de rutas,
etc.
Actividad
des de
Análisis
Espe
cific
ació
n del
cont
exto
de
Uso
Análisis
de tareas
**Escenarios de
tareas
[Mayhew 99].
Identificar las tareas
más representativas de
la aplicación, son
instancias de casos de
uso.
Establecer
los niveles
de
usabilidad
de los LBS
Establece los niveles de
usabilidad esperados dentro
de los LBS, teniendo una
referencia de los objetivos
que de desean alcanzar
Especificación
de Usabilidad
Objetivo de
Usabilidad
[Nielsen 93].
Se establecen los
niveles de usabilidad
desde el principio del
proyecto.
**Objetivo de
Usabilidad
[Mayhew 99].
Se establecen los
niveles de usabilidad
desde el principio del
proyecto, pero realiza
una clasificación de
objetivos tanto
cualitativos como
cuantitativos.
Generar un
prototipo del
LBS. [Biel
10],
[Kjeldskov
03]
Generar un esquema más
aproximado a la realidad de
la aplicación, que pueda
mostrar al usuario una idea
más profunda del LBS.
Actividades
de Diseño
Desarrollo del
concepto del
producto
Diseño Paralelo
[Nielsen 93].
Se realiza un prototipo
en paralelo de la
aplicación, pidiendo a
diseñadores que se
centren en partes
específicas de
usabilidad.
Anexo A
Página 145
LBS (Servicios Basados en Localización) Usabilidad
Contexto Factores Product
o
Sub-
Productos Descripción del Sub-
Producto
Fase de
Usabilidad
Actividad
específica de
Usabilidad
Técnica de HCI Descripción de la
Técnica
Aplicación
Ubicació
n
Finalidad
de Uso
Tiempo
Ambient
e Físico
Indoor
Outdoor
Generar un
prototipo
del LBS.
[Biel 10],
[Kjeldskov
03]
.
Generar un prototipo en base a
la idea que tienen los usuarios
de los LBS, realizando un
despliegue de información
más óptima de acuerdo las
necesidades expuestas por
ellos
Actividades
de Diseño
Desarrollo del
concepto del
producto
**Card Sorting
[Nielsen 93].
Se les pide a un grupo
de usuarios que
escriban sus ideas de la
aplicación en tarjetas y
posteriormente las
reagrupen asignándoles
un nombre con la
finalidad de conocer el
esquema que tiene en
mente el usuario.
Task-Sorting
[Mayhew 99].
Se proporciona a un
grupo de usuarios
tarjetas con
información del diseño
de la aplicación y se les
pide que las reagrupen
para tener una idea
clara de lo que tiene el
usuario en mente.
Generar un prototipo en papel,
el cual da una idea más clara
al usuario de la distribución de
la Información al usuario
Prototipado
**Maqueta de
Baja Fidelidad
[Mayhew 99].
Se realiza un esquema
de la aplicación en
papel, en el cual esta
reducido de
funcionalidades pero
muestra un breve
esquema de
navegabilidad.
Anexo A
Página 146
LBS (Servicios Basados en Localización) Usabilidad
Contexto Factores Product
o
Sub-
Productos Descripción del Sub-
Producto
Fase de
Usabilidad
Actividad
específica de
Usabilidad
Técnica de HCI Descripción de la
Técnica
Aplicación
Ubicació
n
Finalidad
de Uso
Tiempo
Ambient
e Físico
Indoor
Outdoor
Generar un
prototipo
del LBS.
[Biel 10],
[Kjeldskov
03]
Generar un prototipo,
ejecutable, donde el usuario
tiene una idea más clara de la
navegabilidad de los LBS y
contiene reducidas
funcionalidades, y el usuario
no trabaja con información
real.
Actividades
de Diseño
Prototipado
**Maqueta de
Alta Fidelidad
[Mayhew 99].
Se realiza un prototipo
más completo pero ya
es ejecutable dentro de
un ordenador, aun sin
funcionalidades pero
representa un esquema
más amplio de la
aplicación.
Prototipado
[Nielsen 93].
También realiza un
prototipo más amplio
puede ser en papel o
ejecutable y lo hace en
base en escenarios.
Desarrollar
un
esquema
de
interacción
del LBS
[Biel 10]
Se genera un esquema general
de el LBS, donde se muestra
la interacción del usuario con
los LBS, posiblemente
generar un mapa de
navegabilidad
Diseño de la
Interacción
**Guías de Estilo
[Mayhew 99].
Esta técnica realiza un
modelado tanto del
diseño como son
pantallas y
organizacional el cual
nos dará una mejor
visión de lo que se
busca y la distribución
de la información.
Evaluar los
niveles de
usabilidad
de los
LBS.
[Biel 10],
[Nivala
03],
[Kjeldskov
03]
Realizar una evaluación con
un grupo de usuarios, donde
identifican las deficiencias de
los LBS. Actividades
de
evaluación
Evaluación de la
Usabilidad
Retroalimentación
con los Usuarios
[Nielsen 93].
Consiste en que los
usuarios realizan sus
comentarios y
observaciones de la
aplicación por medio
de correo electrónico, a
un muro de noticias.
Anexo A
Página 147
LBS (Servicios Basados en Localización) Usabilidad
Contexto Factores Product
o
Sub-
Productos Descripción del Sub-
Producto
Fase de
Usabilidad
Actividad
específica de
Usabilidad
Técnica de HCI Descripción de la
Técnica
Aplicación
Ubicació
n
Finalidad
de Uso
Tiempo
Ambient
e Físico
Indoor
Outdoor
Evaluar los
niveles de
usabilidad
de los
LBS.
[Biel 10],
[Nivala
03],
[Kjeldskov
03]
Realizar una evaluación con
un grupo de usuarios, donde
identifican las deficiencias de
los LBS.
Actividades
de
evaluación
Evaluación de
la Usabilidad
**Retroalimentació
n con los Usuarios
[Mayhew 99].
Esta técnica consiste en
trabajar con un grupo
de usuarios las cuales
ayudan a detectar
problemas o mejores de
la aplicación,
presentando una serie
de métodos más
completos.
Realizar un análisis, de la
estructura de los LBS, y su
interfaz, con especialistas de
usabilidad y desarrolladores.
*Evaluación
Heurística
[Nielsen 93].
Consiste en hacer una
evaluación de la
aplicación desde etapas
tempranas podría ser
desde un prototipo,
donde el grupo de
especialistas de
usabilidad y el grupo
de desarrolladores se
reúnen para realizar
esta evaluación
Realizar pruebas reales con
usuarios, y en ambientes
reales, que reflejen el nivel de
usabilidad que presentan los
LBS. Test Formales de
Usabilidad
[Mayhew 99].
En esta técnica se
propone realizar las
pruebas reales con
usuarios, como medir
tiempos, pensar en voz
alta, hacer pruebas con
el diseño.
Anexo A
Página 148
LBS (Servicios Basados en Localización) Usabilidad
Contexto Factores Product
o
Sub-
Productos Descripción del Producto
Fase de
Usabilida
d
Actividad
específica de
Usabilidad
Técnica de HCI Descripción de la
Técnica
Aplicación
Ubicació
n
Finalidad
de Uso
Tiempo
Ambient
e Físico
Indoor
Outdoor
Evaluar los
niveles de
usabilidad
de los LBS
[Biel 10],
[Nivala
03],
[Kjeldskov
03]
Detectar la impresión que
tiene los usuarios del LBS, así
como identificar si la
información es la necesaria y
está bien distribuida.
Actividad
es de
evaluació
n
Evaluación de la
Usabilidad
**Pensar en Voz
Alta
[Nielsen 93].
Esta técnica consiste en
tener a un usuario
interactuando con el
sistema pensando en
voz alta, con el fin de
tener más claro las
ideas y pensamientos
de los usuarios en
relación a la aplicación.
Realizar un estructura miento
y planificación de la prueba de
usabilidad que se realizara en
el LBS, determinando las
tareas en que se relazaran las
pruebas
**Test de
Usabilidad
[Nielsen 93].
En esta técnica se nos
expresa un esquema
muy general de lo que
se debe realizar en una
prueba de usabilidad
son una serie de pases
como: Preparación,
introducción, el propio
test, y elaboración del
informe del test.
Identificar los problemas
reales de los usuarios con los
LBS, en ambientes reales.
Grabación en
vídeo
[Nielsen 93].
Consiste en grabar a
diferentes usuarios con
la interacción del
sistema, para
posteriormente ser
analizados los videos y
detectar posibles
problemas coincidentes
en alguna etapa de la
interacción.
Anexo A
Página 149
LBS (Servicios Basados en Localización) Usabilidad
Contexto Factores Product
o
Sub-
Productos Descripción del Producto Fase de
Usabilidad
Actividad
específica de
Usabilidad
Técnica de HCI Descripción de la
Técnica
Aplicación
Ubicació
n
Finalidad
de Uso
Tiempo
Ambient
e Físico
Indoor
Outdoor
Evaluar los
niveles de
usabilidad de
los LBS
Identificar los problemas
reales de los usuarios con
los LBS, en ambientes
reales.
Actividades
de
evaluación
Evaluación de la
Usabilidad
*Observación
[Nielsen 93].
En esta técnica consiste
en que se observe al
usuario en su ambiente
natural de trabajo y la
interacción del sistema,
realizando notas y si es
posible grabando para
detectar posible
problemas con la
aplicación.
Realizar una evaluación
con un grupo de usuarios,
donde identifican las
deficiencias de los LBS.
*Cuestionarios y
Entrevistas
[Nielsen 93].
Esta técnica consiste en
la realizar una serie de
cuestionarios y
entrevistas a los
usuarios para detectar
problemas dentro de la
aplicación
Tener un control
estadístico de las pruebas
que se llevan a cabo en
ambientes reales, y reflejen
los niveles de usabilidad
alcanzados.
*Registro del Uso
Real
[Nielsen 93].
Consiste que una
computadora lleva los
datos estadísticos del
uso real de la
aplicación, es
considerada como
suplementaria a las
pruebas de usabilidad.
Móvil Sistema
Dominio
de
móviles
Tener una
selección de
requerimientos
software/Hard
ware
[Biel 10],
[Nivala 03],
[Grill 09]
Identificar las
características
hardware/software de un
dispositivo móvil Actividad
des de
Análisis
Especificación
del contexto de
Uso
**Restricción de
Plataforma
[Mayhew 99].
Identifica las
características
relevantes tanto
software/hardware para
un correcto
funcionamiento de la
aplicación.
Anexo A
Página 150
A.3 Comparativa de Técnicas En este apartado se muestra la comparación de técnicas que existen para los diversos
subproductos, realizando una comparativa entre ellas y realizando a la elección de las
mismas para los diversos subproductos.
A.3.1 Análisis de Usuarios
Dentro de los servicios basados en localización, es de suma importancia hacer un análisis
de los usuarios, realizando una reagrupación de características comunes, y generar perfiles,
para una mejor personalización del servicio, de acuerdo a las características mismas de los
usuarios, la tabla A.7 muestra la comparativa de las técnicas de Nielsen y Mayhew. Tabla A.6: Análisis de Usuarios
Nielsen Mayhew
*Características de los Usuarios.- Identificación de
las características físicas y capacidades de los
usuarios.
Cuestionarios de perfiles de usuarios.-
Identificación de las características y capacidades de
los usuarios atreves de cuestionarios a usuarios
potenciales de la aplicación.
Ventajas
Identificación de características de los
usuarios,
Menor demanda de tiempo en identificación
de características.
Ventajas
Identificación de características de los
usuarios,
Identificación de características más precisa
al colaborar directamente con usuarios.
Desventajas
Menor precisión de las características de los
usuarios.
Desventajas
Mayor tiempo de identificación de las
características.
**Técnica con seleccionada
Dentro de estas dos técnicas, se considera con mayor adaptación a los sistemas basados en
localización (LBS) a la propuesta por J. Nielsen, ya que por nuestro tipo de aplicación, no
tenemos usuarios tan específicos, pues estos servicios son ofrecidos a cualquier tipo de
usuario, sin importar que pertenezca una empresa o una cultura, es por ello que la
generalización de características de los usuarios es muy útil en este tipo de servicios.
A.3.2 Análisis de Contexto de Uso
En los LBS es importante identificar el medio en el que presentaran la información, es decir
identificar si serán interiores o exteriores, lo cual será de sume importancia identificar el
ambiente físico que se involucra alrededor del dispositivo, ya que se deberán tomar
consideraciones para cierto tipo de ambientes, la tabla A.8 muestra la comparativa entre las
técnicas para análisis de tareas.
Anexo A
Página 151
Tabla A.7: Análisis de Tareas
Mayhew Mayhew Mayhew
**Entrevistas contextuales.-
Realizar entrevistas, para la
identificación del ambiente de
trabajo de una aplicación.
Diagramas de afinidad.- Realiza
una identificación de los
ambientes de trabajo de los
usuarios de las entrevistas
contextuales, y que un observador
analiza a los usuarios en su
ambiente natural de trabajo para
complementar la información.
**Escenarios de tareas.-
Identificar las tareas más
representativas de la aplicación,
son instancias de casos de uso.
Ventajas
Identificación más
precisa del ambiente de
trabajo por medio de
entrevistas con los
usuarios,
Identificación de casos de
uso más precisas,
Identificación de las
acciones y decisiones
claves de los usuarios.
Ventajas
La información del
ambiente de trabajo es
más precisa,
Recopilación de la
información desde la
observación del usuario
dentro del ambiente de
trabajo.
Ventajas
Identificación de los
casos claves de la
aplicación,
Menor demanda de
tiempo en la
identificación de los
escenarios.
Desventajas
Demanda de tiempo para
realizar las entrevistas,
Generar reuniones entre
usuarios y
desarrolladores.
Desventajas
Es necesarios realizar las
entrevistas contextuales,
Genera reuniones entre
los observadores para
analizar sus notas.
Desventajas
Menor porcentaje de
precisión en la
identificaron de los casos
claves,
Recopilación de
información de
entrevistas contextuales. *Técnica seleccionada
Dentro de las 3 técnicas aportadas en la propuesta de Mayhew, optamos por Escenarios de
tareas, ya que dentro de los LBS, no son aplicaciones tan extensas, y es fácil identificar las
tareas básicas y más representativas de estos servicios, y el reconocimiento de ambientes de
los mismos, dependiendo el enfoque que se le da al servicio (outdoor o indoor) por lo que
proponemos que esta técnicas la más adecuada, tomando en cuenta que la identificación de
los escenarios de tares parte de la información recopilada de las entrevistas contextuales, es
por ello que son estas dos técnicas la seleccionadas.
A.3.3 Especificación de Usabilidad
Ya que nuestro objetivo es aumentar nuestros noveles de usabilidad, debemos establecer los
niveles que se desean alcanzar desde un principio, para ello necesitaremos tener un objetivo
claro de usabilidad, la tabla A.9 muestra la comparativa de las técnicas de Nielsen y
Mayhew.
Anexo A
Página 152
Tabla A.8: Especificación de Usabilidad
Nielsen Mayhew
Objetivo de Usabilidad.- Se establecen los niveles
de usabilidad desde el principio del proyecto.
**Objetivo de Usabilidad.- Se establecen los
niveles de usabilidad desde el principio del proyecto,
pero realiza una clasificación de objetivos tanto
cualitativos como cuantitativos.
Ventajas
Establece los niveles de usabilidad
esperados para la aplicación,
Especifica varios niveles de rendimiento de
usabilidad.
Ventajas
Establece los niveles de usabilidad
esperados para la aplicación,
Clasifica los objetivos en cualitativos y
cuantitativos.
Desventajas
Se establece el nivel de usabilidad de una
manera muy general.
Desventajas
Mayor demanda de tiempo en la
clasificación de los objetivos de usabilidad. *Técnica con seleccionada
De acuerdo a las dos técnicas comparadas nos inclinamos por la de Mayhew, ya que dentro
de su clasificación se nos hace más óptima y adecuada dentro de los LBS, ya que la
clasificación que nos presenta en dividir los objetivos cuantitativos y cualitativos, ayudaría
a tener una idea más clara, con su clasificación podríamos observar directamente los
objetivos cumplidos, detectando los elementos que cumplen con los objetivos de
usabilidad.
A.3.4 Concepto del producto
Una de las cuestiones que debemos realizar como parte de los procesos de diseño centrado
en el usuario, es tomar en cuenta la idea que tiene el usuario del LBS, ya que con ello
podemos tener un idea más clara de la distribución de la información, las técnicas para este
concepto se presentan en la tabla A.10. Tabla A.9: Desarrollo del concepto del producto
Nielsen Nielsen Mayhew
Diseño Paralelo.- Se realiza un
prototipo en paralelo de la
aplicación, pidiendo a diseñadores
que se centren en partes
específicas de usabilidad.
**Card Sorting .- Se les pide a
un grupo de usuarios que escriban
sus ideas de la aplicación en
tarjetas y posteriormente las
reagrupen asignándoles un
nombre con la finalidad de
conocer el esquema que tiene en
mente el usuario.
Task-Sorting.- Se proporciona a
un grupo de usuarios tarjetas con
información del diseño de la
aplicación y se les pide que las
reagrupen para tener una idea
clara de lo que tiene el usuario en
mente.
Ventajas
No es necesario acabar la
etapa de análisis para
empezar un prototipo de
la aplicación,
Es posible realizar
mejoras sobre el mismo
diseño,
Se empieza a trabajar con
el diseño y la interacción
del usuarios a tempranas
etapas .
Ventajas
Se tiene una idea más
clara de la idea que tiene
el usuario de la
aplicación,
Se realiza la clasificación
de información d acuerdo
a la percepción que tiene
el usuario de la
información,
Se tiene la idea clara de
los usuarios.
Ventajas
Se tiene una idea más
clara de la idea que tiene
el usuario de la
aplicación,
Se realiza la clasificación
de información d acuerdo
a la percepción que tiene
el usuario de la
información.
Anexo A
Página 153
Desventajas
No se tiene una ida tan
clara de la percepción del
usuario.
Desventajas
Requiere de mayor
tiempo al realizar la
recopilación con el
usuario,
Es necesario la
colaboración de usuarios
para realizar esta técnica.
Desventajas
Requiere de mayor
tiempo al realizar la
recopilación con el
usuario,
Es necesario la
colaboración de usuarios
para realizar esta técnica. *Técnica con seleccionada
Dentro de los LBS, es de gran ayuda mostrar una idea más clara y concreta como un
prototipo para un mejor entendimiento de visualización de la información que se mitrará
dentro de este servicio, es por ello que la técnica de Nielsen “Card Sorting”, es la que
proponemos como más óptima, ya que se tendría una mejor idea del panorama de los
usuarios sobre los servicios y ayudaran en gran parte a hacer una mejor distribución de la
información sobre el servicio.
A.3.5 Prototipado
Dentro de cualquier aplicación es de mucha ayuda tener un concepto claro de lo que se
desarrollara, tanto para el grupo de desarrollo como para los usuarios, en nuestro caso es de
mucha utilidad, ya que mostrar un idea clara de lo que se desarrollara ayudara a tener una
idea más sólida de los servicios basados en localización, la tabla A.11 muestra la
comparativa de técnicas para el prototipado. Tabla A.10: Prototipado
Nielsen Mayhew Mayhew
Prototipado.- También realiza un
prototipo más amplio puede ser en
papel o ejecutable y lo hace en
base en escenarios.
**Maqueta de Alta Fidelidad.- Se
realiza un prototipo más completo
pero ya es ejecutable dentro de un
ordenador, aun sin
funcionalidades pero representa
un esquema más amplio de la
aplicación.
**Maqueta de Baja Fidelidad.- Se
realiza un esquema de la
aplicación en papel, en el cual esta
reducido de funcionalidades pero
muestra un breve esquema de
navegabilidad.
Ventajas
Realiza prototipos en
base a escenarios, es
decir tareas que se
pueden realizar dentro de
la aplicación,
Muestra una idea básica
que tendrá el usuario con
la aplicación,
El prototipo puede ser
echo a papel o en
ejecución, reduciendo las
funcionalidades.
Ventajas
Se realiza en forma
ejecutable con reducidas
funcionalidades,
Muestra una idea básica
que tendrá el usuario con
la aplicación.
Ventajas
Pueden realizarse más
fácilmente
modificaciones dentro
del producto,
Muestra una idea básica
que tendrá el usuario con
la aplicación.
Desventajas
El usuario no interactúa
con datos reales.
Desventajas
Es necesario tener una
implementación de este
prototipo para su
interacción.
Desventajas
El usuario no tiene una
aproximación tan cercana
a lo que será la
interacción con la
aplicación. *Técnica con seleccionada
Anexo A
Página 154
Dentro de los LBS, tomamos la propuesta de Mayhew, tomando sus dos ideas básicas para
el desarrollo del prototipo, en donde realiza una segmentación, la cual nos ayudara a tener
una idea clara del prototipo a desarrollar con su “Maqueta de baja fidelidad”, la cual se
desarrollara el esquema de un LBS de acuerdo a lo analizado, y con ello empezar el
prototipo ejecutable en la “Maqueta de alta fidelidad”, esto con el fin de detectar posibles
mejoras o correcciones en etapas tempranas del producto.
A.3.6 Diseño de la interacción
En esta parte se realiza una visión más amplia de las intenciones que se deben realizar para
realizar una determinada tarea, la tabla 12 muestra la técnica para el diseño de interacción. Tabla A.11: Diseño de la Interacción
Mayhew
**Guías de Estilo.- Esta técnica realiza un modelado tanto del diseño como son pantallas y organizacional el
cual nos dará una mejor visión de lo que se busca y la distribución de la información.
Ventajas:
Realiza un modelo de la aplicación, considerando estándares de los diseños de las pantallas,
Refleja la consistencia de la ingeniería de usabilidad de la aplicación.
Desventajas
**Técnica con seleccionada
Esta técnica se adecua para la creación más clara de la interacción de los servicios basados
en localización, realizando una formalización tanto de pantallas y estándares, la tabla A.13
muestra la comparativa de técnicas para la evaluación de usabilidad.
Anexo A
Página 155
Tabla A.12: Evaluación de Usabilidad
Nielsen Mayhew Nielsen Mayhew Nielsen Nielsen Nielsen Nielsen Nielsen Nielsen Retroalimentación
con los Usuarios.-
Consiste en que los
usuarios realizan
sus comentarios y
observaciones de la
aplicación por
medio de correo
electrónico, a un
muro de noticias.
**Retroalimentación
con los Usuarios.-
Esta técnica consiste
en trabajar con un
grupo de usuarios las
cuales ayudan a
detectar problemas o
mejores de la
aplicación,
presentando una serie
de métodos más
completos.
Evaluación
Heurística.-
Consiste en
hacer una
evaluación de
la aplicación
desde etapas
tempranas
podría ser
desde un
prototipo,
donde el grupo
de
especialistas
de usabilidad y
el grupo de
desarrolladores
se reúnen para
realizar esta
evaluación
Test
Formales
de
Usabilidad.-
En esta
técnica se
propone
realizar las
pruebas
reales con
usuarios,
como medir
tiempos,
pensar en
voz alta,
hacer
pruebas con
el diseño.
**Pensar en
Voz Alta.-
Esta técnica
consiste en
tener a un
usuario
interactuando
con el
sistema
pensando en
voz alta, con
el fin de
tener más
claro las
ideas y
pensamientos
de los
usuarios en
relación a la
aplicación.
**Test de
Usabilidad.-
En esta
técnica se nos
expresa un
esquema muy
general de lo
que se debe
realizar en
una prueba de
usabilidad
con los sig.
pasos:
Preparación,
introducción,
el propio test,
y elaboración
del informe
del test.
Grabación en
vídeo.-
Consiste en
grabar a
diferentes
usuarios con la
interacción del
sistema, para
posteriormente
ser analizados
los videos y
detectar
posibles
problemas
coincidentes
en alguna
etapa de la
interacción.
*Observación.- En esta técnica
consiste en que
se observe al
usuario en su
ambiente
natural de
trabajo y la
interacción del
sistema,
realizando
notas y si es
posible
grabando para
detectar posible
problemas con
la aplicación.
**Cuestionarios
y Entrevistas.-
Esta técnica
consiste en la
realizar una serie
de cuestionarios
y entrevistas a
los usuarios para
detectar
problemas
dentro de la
aplicación
Registro del
Uso Real.- Consiste que
una
computadora
lleva los datos
estadísticos del
uso real de la
aplicación, es
considerada
como
suplementaria a
las pruebas de
usabilidad.
Ventajas:
-Los usuarios son
los que detectan los
problemas de
usabilidad.
Ventajas:
-Los usuarios son los
que detectan los
problemas de
usabilidad,
-Propone diversas
maneras de realizar
esta técnica.
Ventajas
-Se detectan
problemas de
usabilidad
desde las
etapas
tempranas,
-No es
necesario tener
una versión
funcional.
Ventajas
-Realiza la
evaluación
con
usuarios,
-Es evaluado
en su
ambiente
natural de
trabajo.
Ventajas
-Se obtiene
una idea más
clara de lo
que percibe
el usuario,
-Es fácil
percibir que
es lo que
necesita el
usuario.
Ventajas
-Contiene una
metodología
que nos
ayuda a tener
una
formalidad de
los
resultados,
-Son pruebas
en ambientes
reales y con
usuarios.
Ventajas
-Se evalúa
directamente
la interacción
del usuario
con la
aplicación,
-Es evaluado
en tiempo real
y en su
ambiente de
trabajo.
Ventajas
- Se evalúa
directamente la
interacción del
usuario con la
aplicación,
-Es evaluado en
tiempo real y en
su ambiente de
trabajo.
Ventajas
-Los usuarios
son los que
detectan los
problemas de
usabilidad.
Ventajas
-Es una técnica
que se
considera
complementaria
la evaluación.
Los datos
estadísticos son
una buena
referencia de
los resultados.
Anexo A
Página 156
Desventajas
-No siempre los
usuarios
describirán el
problema
claramente.
Desventajas
-No siempre los
usuarios describirán
el problema
claramente.
Desventajas
-No siempre se
cuenta con un
grupo de
especialistas
en usabilidad
Desventaja
-Es
necesario
tener una
versión
funcional
para llevarla
acabo
Desventajas
-Es posible
no entender
algunos
pensamientos
del usuario.
Desventajas
-No siempre
se cuenta con
el tiempo
para la
estructuración
de esta
prueba
Desventajas
-Es necesario
un versión
funcional
Desventajas
-El observador
debe estar lo
suficientemente
preparado para
realizar la
evaluación
Desventajas
-Por momentos
es difícil
coincidir con los
usuarios para
realizar este tipo
de técnica
Desventajas
-Es difícil por
momentos
llevar el control
estadístico y
realizar la
evaluación de
usabilidad en
grandes
poblaciones.
**Técnica con seleccionada
Dentro de nuestros LBS, es importante saber lo que nuestros usuarios perciben en el uso de la aplicación, ya que como sabemos los
servicios pueden ser utilizados por cualquier tipo de usuario, es por ello que con una selección de usuarios, se reflejaran los defectos
que se tienen en ellos, así como también es importante detectar las primeras impresiones que tienen los usuarios de la aplicación ya que
al tener como objetivo la usabilidad, debemos tener aplicaciones intuitivas, es por ello que las técnicas más apropiadas para nuestros
servicios dentro de nuestra etapa de evaluación de usabilidad son las siguientes:
Test de usabilidad [Nielsen].- esta técnica e seleccionada con el fin de obtener la estructuración de la evaluación, ya que nos muestra
una serie de pasos a seguir para poder realizar una evaluación, la cual la tomamos como estructura de nuestra evaluación.
Pensar en voz alta [Nielsen].- Esta técnica es tomada con el fin de identificar la primera impresión del usuario, y la forma de percibir
la información mostrada dentro de los servicios.
Cuestionarios y entrevistas [Nielsen].-Esta técnica es seleccionada, con el fin de tomar una muestra de nuestros usuarios, de
preferencia con los mismos niveles de experiencia en manejo dispositivos, y nos proporcionen información sobre posibles correcciones
o mejoras de los servicios.
Retroalimentación con los Usuarios [Mayhew].-Esta técnica nos presenta una serie de alternativas, con las cuales podemos realizar
una muestra de usuarios, para poder identificar las mejoras y correcciones sobre los servicios.
Anexo A
Página 157
A.3.7 Restricción de plataforma
Debido a el ambiente de nuestra aplicación es muy importante delimitar las características
tanto software como hardware, ya que el mercado de dispositivos móviles evoluciona de
una manera muy rápida, es por ello que es necesario establecer las características mínimas
de los dispositivos, la tabla A.14 muestra la técnica para la restricción de plataforma. Tabla A.13: Restricción de plataforma
Mayhew
**Restricción de Plataforma.- Identifica las características relevantes tanto software/hardware para un
correcto funcionamiento de la aplicación.
Ventajas:
Identifica las características del software y hardware que son necesarias para un óptimo
funcionamiento,
Ayuda a tener un referencia de los equipos óptimos donde se puede ejecutar la aplicación.
Desventajas
Posible inversión de tiempo posibles pruebas con diferentes dispositivos
**Técnica con seleccionada
Dentro de los LBS, es una parte importante delimitar las características mínimas de un
dispositivo móvil, donde se pueda ejecutar el LBS, ya que como sabes existe una gran
diversidad de dispositivos, y día a día siguen surgiendo nuevos dispositivos, los usuarios
buscan tener los mismos servicios sobre la evolución de los dispositivos, es por ello que la
técnica presentada con el nombre de “Restricción de plataforma” nos ayudara a determinar
las características mínimas de hardware/software para poder ejecutar nuestros servicios de
manera óptima.
Anexo B
Análisis de Requerimientos Este anexo muestra el documento de análisis de requerimientos de nuestro caso de estudio,
así como la propuesta de solución a desarrollar.
Anexo B
Página 159
B.1 Introducción. Este proyecto se realizará como caso de estudio de nuestro proceso de desarrollo, tratando
de demostrar el incremento de los niveles de usabilidad en un servicio basado en
localización (LBS). Nos centraremos en un LBS, de los más conocidos y comúnmente más
utilizados como es Google Maps.
El presente documento describe el análisis de requerimientos para la elaboración de un
diseño Google Maps mas usable Por las limitaciones de tiempo que presenta este proyecto
solo se llegará hasta la fase de diseño de nuestro proceso de desarrollo. Se realizará una
descripción del sistema actual de Google Maps y los objetivos que se pretenden alcanzar
con el sistema propuesto.
Para una mejor comprensión del sistema la información, se presentarán los requerimientos
funcionales y no funcionales, la situación actual del sistema y la nueva propuesta de
sistema. Este documento tiene como objetivo mostrar los requerimientos del sistema y la
propuesta de solución.
B.2 Descripción
El sistema Google Maps para Android Usable (GMAU) es una aplicación para dispositivos
móviles, es un servidor de aplicaciones de mapas en la Web, este proyecto realizará la
incorporación de usabilidad en diferentes funcionalidades que lo requieran.
B.3 Descripción del Sistema Actual
Los servicios basados en localización (LBS) son en la actualidad más utilizados, una de las
aplicaciones más conocidas en este campo es el Google Maps, el cual muestra una serie de
funcionalidades con el fin de proporcionar información de una geoposición o localización
de un usuario (móvil).
El servidor de mapas está disponible para diferentes plataformas como son BlackBerry,
Windows Mobile, Nokia y Android. Este último según las páginas oficiales de esta
aplicación cuenta con la mayor compatibilidad de las funcionalidades que se ofrecen.
B.4 Clasificación de Requerimientos
Requerimientos Funcionales Requerimientos no funcionales
Navegación,
Como llegar,
Latitud,
Capas,
Páginas de sitio,
Mi ubicación.
Mejorar la interfaz de visualización de
las funcionalidades,
El sistema debe tener una alta
disponibilidad para su consulta,
El sistema debe ser diseñado en
componentes para tener la propiedad de
mantenerlo.
B.5 Propuesta de desarrollo
Nuestra propuesta de desarrollo se centrara únicamente en mejorar los aspectos de
usabilidad de Google Maps utilizado bajo la plataforma Android.
Anexo B
Página 160
B.6 Alcances y Limitaciones
El proyecto puede volverse muy amplio debido a que solo se llegará a la fase de diseño de
nuestra aplicación usable. Los dispositivos celulares que se utilizarán son dispositivos que
soporten el sistema operativo Android y que tengan conectividad a internet.
Se limitará a algunos dispositivos celulares, no para todas las marcas y modelos.
El proyecto trata de demostrar el aumento de los niveles de usabilidad utilizando el
proceso de desarrollo propuesto,
Solo se desarrollará un diseño de la aplicación usable incorporando los factores de
usabilidad en las deficiencias encontradas,
No se evaluará el diseño propuesto en este proyecto, ya que no se llegará a la fase de
codificación.
Anexo C
Documento de
Especificación de
Requerimientos Este anexo muestra el documento de especificación de requerimientos basado en el
estándar IEEE 830.
Anexo C
Página 162
Ficha del documento
Fecha Revisión Autor Descripción.
24/10/11 1 Nazir O. Molina Coronel
Versión 1.0 .- Creación del
documento DSR de Google
Maps Usable para Android
basado en el estándar IEEE 830
Anexo C
Página 163
C.1 Introducción Los servicios basados en localización (LBS) día a día toman más importancia con la
revolución de los dispositivos móviles, diferentes proveedores con el fin de abarcar un
mayor mercado ofrecen servicios de este tipo, uno de los más representativos servicios de
este tipo es el sistema de posicionamiento global (GPS), analizando la innovación de estos
servicios ofrecidos se detectan ciertas carencias en este tipo de servicios relacionadas con el
término de usabilidad.
Tomando en cuenta que el término usabilidad se deriva de la interacción persona ordenador
(IPO), partiendo como una disciplina independiente a la ingeniería de software (IS) y
siendo que por momentos los desarrolladores y diseñadores dan por hecho que las
aplicaciones cumplen con las cuestiones de usabilidad sin consultar directamente a los
usuarios correspondientes de las aplicaciones, en el momento de liberación de estos
servicios encontramos deficiencias de interacción y cuestiones de eficiencia en uso.
Como una solución propuesta realizamos la creación de un proceso de desarrollo le cual
contempla diferentes técnicas de usabilidad dentro del mismo proceso procedentes de la
IPO, y para realizar su demostración se realiza este proyecto.
Este proyecto parte como prueba del proceso de desarrollo de integración de usabilidad
para servicios contextuales basados en localización, para ello tomamos como referencia uno
de (LBS) más conocidos y utilizados como es el Google Maps, este proyecto se desarrolló
bajo un proceso centrado en el usuario (DCU), el software se mejorara en cuestiones de
usabilidad, tomando como prototipo el LBS funcional en este momento.
C.1.1 Propósito
El propósito de este proyecto es realizar un diseño con la incorporación de usabilidad
a Google Maps utilizado bajo el sistema operativo móvil Android.
0BJ-01 Servicio Basado en Localización
Autores Ing. Nazir Ossiel Molina Coronel
Descripción El sistema deberá proporcionar la información
necesaria para la orientación del usuario.
Estabilidad Alta
Comentarios Ninguno
Propósito del documento.- El presente documento describe el análisis de
requerimientos hecho para la elaboración de un Google Maps usable para
Android, mencionando la información recopilada durante las reuniones de
elicitación, descripción del sistema actual y los objetivos que se pretenden
alcanzar con el sistema propuesto.
Anexo C
Página 164
Audiencia a quien va dirigido.- Este documentó va dirigido para los
desarrolladores y diseñadores de la aplicación, con el fin de entender las
funcionalidades de la aplicación, así como los objetivos de la misma.
C.1.2 Alcance
Perfiles de Usuario.- Se realizara la identificación de los perfiles de los usuarios de
la aplicación.
Especificación de Usabilidad.- Se establecerán los objetivos de usabilidad de la
aplicación, analizando los resultados obtenidos en la valuación de la aplicación para
detectar los principales problemas en los que nos enfocaremos.
Concepto del producto.- Se desarrollara un concepto del producto mediante las
ideas que tengan los usuarios sobre esta aplicación.
Diagrama de Interacción.- Se realizara un diagrama de interacción el cual
especificara el número de interacciones debe tener el usuario para concretar una
tarea.
Maqueta de baja fidelidad.- Se desarrollara una idea en papel de la interfaz de
usuario, antes de comenzar con el diseño de la interfaz.
Modelado de la aplicación.- Se modelara la aplicación en objetos del mundo real
para tener una idea más clara de la aplicación.
Diseño de Interfaz.- Se desarrollara una interfaz de la aplicación.
C.1.3 Personal involucrado
Nombre Nazir O. Molina coronel
Rol Evaluador, Analista y Diseñador
Categoría profesional Ing. En Sistemas computacionales
Responsabilidades Fases de: Evaluación, Análisis y Diseño
Información de
contacto
1.4 Definiciones, acrónimos y abreviaturas
IU.- Ingeniería de Usabilidad.
LBS.- Servicios Basados en Localización.
DCU.- Diseño Centrado en el Usuario
Google Maps.- Es un servidor de aplicaciones de mapas en la Web. Ofrece imágenes de mapas
desplazables, así como fotos satelitales del mundo entero e incluso la ruta entre diferentes ubicaciones
o imágenes a pie de calle Street View.
C.1.5 Resumen
Este documento muestra los diagramas de casos de uso de los requerimientos
funcionales, las plantillas de secuencia de los requerimientos funcionales y la
descripción de los requerimientos no funcionales, y de los usuarios que son
contemplados para este tipo de aplicación, este documento representa el documento
Anexo C
Página 165
de especificación de requerimientos (DSR) de la aplicación de Google Maps usable
para Android.
Este documento está dividido en tres secciones las cual la primera nos da una
introducción a la aplicación y descripción de las perspectivas del producto.
La segunda sección nos realiza una descripción general de la aplicación a realizar
teniendo un panorama más amplio del producto y de los usuarios.
La tercera sección nos realiza una descripción detallada de los requerimientos de la
aplicación usable a realizar, mostrando los casos de uso, plantillas de requerimientos
y la descripción de los requerimientos no funcionales a realizar.
C.2 Descripción general
C.2.1 Perspectiva del producto
Este proyecto se lleva acabo como un proyecto independiente el cual tiene como
objetivo demostrar la incorporación de usabilidad como parte de la prueba de un
proceso de desarrollo para LBS.
El LBS prototipo que se tomó para la demostración de esta incorporación es Google
Maps ya que es uno de los LBS más conocidos y utilizados actualmente.
C.2.2 Funcionalidad del producto
La aplicación proporcionara al usuario (móvil) información necesaria de su
ubicación, así como también proporcionara la información necesaria para llegar a
puntos de interés del usuario, mostrara los mapas para proporcionarle rutas de llegada
a sus puntos de interés, así como las diferentes opciones de llegada como son en
coche en servicio (bus) o caminando, también podrá realizar búsquedas específicas
de lugares.
C.2.3 Características de los usuarios Tabla C.14: Perfil de usuario 1
Tipo de usuario Perfil 1
Formación Experiencia con dispositivos Móviles y conocimientos
tecnológicos
Habilidades Capacidad de concentración en lugares que presentan
movimiento y son ruidosos
Actividades Estudiantes, Trabajadores Tabla C.15: Perfil de usuario 2
Tipo de usuario Perfil 2
Formación Experiencia en dispositivos Móviles
Habilidades Capacidad de concentración en lugares que presentan
movimiento y son ruidosos
Actividades Estudiantes, Trabajadores
Anexo C
Página 166
Tipo de usuario Perfil 3
Formación Conocimiento tecnológico
Habilidades Capacidad de concentración en lugares que presentan
movimiento y son ruidosos
Actividades Estudiantes, Trabajadores
C.2.4 Restricciones
La mayor restricción a considerar son las capacidades hardware/software de los
dispositivos móviles en las cuales se utilizaran las aplicaciones LBS, en nuestro caso
serán todos aquellos dispositivos que sean capaces de soportar un sistema operativo
Android versión 2.2.1 y una conexión a internet. Nos apegaremos a nuestro proceso
de desarrollo creado para los LBS.
El desarrollo de esta aplicación solo contempla la parte del cliente de Google Maps,
en específico los dispositivos móviles con sistema operativo Android versión 2.2.1.
C.2.5 Evolución previsible del sistema
El sistema una vez desarrollado e implementado podría realizarse la evaluación del
mismo, con el fin de identificar si los objetivos de usabilidad establecidos han sido
cumplidos, e identificar las posibles mejoras del software.
C.3 Requerimientos específicos
Tabla C.16: Requerimiento 1
Número de requisito 01
Nombre de requisito Navegación
Tipo Requisito Restricción
Fuente del requisito Aplicación
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional
Tabla C.17: Requerimiento 2
Número de requisito 02
Nombre de requisito Como llegar
Tipo Requisito Restricción
Fuente del requisito Aplicación
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional
Tabla C.18: Requerimiento 3
Número de requisito 03
Nombre de requisito Latitud
Tipo Requisito Restricción
Fuente del requisito Aplicación
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional
Anexo C
Página 167
Tabla C.19: Requerimiento 4
Número de requisito 04
Nombre de requisito Capas
Tipo Requisito Restricción
Fuente del requisito Aplicación
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional
Tabla C.20: Requerimiento 5
Número de requisito 05
Nombre de requisito Páginas de sitios
Tipo Requisito Restricción
Fuente del requisito Aplicación
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional
Tabla C.21: Requerimiento 6
Número de requisito 06
Nombre de requisito Mi Ubicación
Tipo Requisito Restricción
Fuente del requisito Aplicación
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional
C.3.1 Requerimientos comunes de los interfaces
Las interfaces presentadas deben ser intuitivas, presentando a los usuarios una
comprensión de la interacción con el dispositivo, deberán ser introducidos los
nombres de los puntos de interés para el usuario, así como la indicación por medio de
la interacción con los puntos de interés para el mismo puedan ser seleccionados y
proporcionar las funcionalidades debidas a cada punto de interés seleccionado o
introducido.
C.3.1.1 Interfaces de usuario
La interfaz de usuario se basara en la idea que tiene el usuario del sistema, de
la cual nos apoyaremos de la sección “2 concepto del producto” del usuario,
presentando interfaces las cuales serán evaluadas por los mismo usuario, como
son la maqueta de baja fidelidad que se desarrollará en el diseño de la
interacción.
Las interfaces estarán basadas principalmente en las interfaces de Google
Maps, considerando colores y mapas.
C.3.1.2 Interfaces de hardware
La interfaz de la aplicación será por medio de pantallas táctiles (touch screen)
para la manipulación de los mapas, botones de acción, selección de objetos y la
interacción con el teclado que aparecerá en forma de panel dentro de las
funcionalidades del dispositivo.
Anexo C
Página 168
C.3.1.3 Interfaces de comunicación
Comunicación con redes WiFi por medio de la tarjeta inalámbrica del
dispositivo, para tener una comunicación con la aplicación Google Maps por
medio de solicitudes HTTP.
C.3.2 Requerimientos funcionales
El software recibirá la solicitud del usuario la cual será enviada por el dispositivo
móvil al servidor de Google Maps, enviando información de la solicitud como su
ubicación (coordenadas de latitud/longitud), partiendo de ella para proporcionar la
información debida.
El servidor recibirá la petición con las coordenadas pertinentes para proporcionar la
información debida dentro de los sistemas de información geográfica (GIS) para
proporcionar los datos solicitados en caso de tener información sobre dichas
coordenadas.
Los principales parámetros que se deberán proporcionar son las coordenadas latitud/longitud.
C.3.2.1 Diagramas de caso de uso
Móvil
C.U.0 Google Maps
Servidor Google Maps
«extends»
Figura C.13 Diagrama de caso de uso principal
Movil
C.U.1 Navegación
C.U.2 Indicaciones
C.U.3 Latitud
C.U.4 Capas
C.U.5 Páginas de
sitios
C.U.6 Mi Ubicación
Servidor Google Maps
«extends»
«extends»
«extends»
«extends»
«extends»«extends»
Figura C.14: Diagrama de selección de funcionalidad
Anexo C
Página 169
Móvil
Servidor Google Maps
C.U.1.1 En coche
C.U.1.2 Servicio
Publico
C.U.1.3 Caminando
*
*
«extends»
«extends»
«extends»
Figura C.15 Diagrama de caso de uso navegación
Móvil Servidor Google Maps
C.U.2.1 En coche
C.U.2.2 Servicio
Publico
C.U.2.3 Caminando
*
*
«extends»
«extends»
«extends»
Figura C.16 Diagrama caso de uso como llegar
C.3.3 Requerimientos no funcionales
C.3.3.1 Disponibilidad
La disponibilidad debe tener un 100% de disponibilidad ya que en cualquier
momento podría ser consultado su servicio de localización para cualquier tarea
a realizar por el usuario.
C.3.3.2 Mantenibilidad
Esta es una propiedad la cual debe contar nuestra aplicación, tomando en
cuenta periodos de evaluación para su posible mejora y mantenimiento de
nuestra aplicación, en nuestro caso propondríamos tener dos evaluaciones por
año identificando las posibles mejores y mantenimiento del software a realizar.
Las tareas de mantenimiento serán realizadas por los analistas, diseñadores y
desarrolladores a partir de los resultados obtenidos por las diferentes
evaluaciones, centrándose en los porcentajes de eficiencia en uso, así como
problemas de interacción que puedan ser encontrados.
C.3.3.3 Fiabilidad
Este dependerá del servidor Google Maps el cual se realizan las solicitudes,
este proyecto solo contemplamos la parte clientes (móvil) de la aplicación.
Anexo D
Guía de Estilo Este anexo muestra la guía de estilo que deberá llevar la aplicación LBS usable que se
generara, determinando colores y estilos dentro de las interfaces.
Anexo D
Página 171
D.1 Audiencia a quien va dirigido Este documento está destinado a los desarrolladores de la aplicación móvil Google Maps
usable.
D.1.2 Conocimientos previos
Para un completo entendimiento del documento, el lector deberá tener conocimientos
previos sobre las siguientes tecnologías:
• Desarrollo en la plataforma Android,
• API de Google Maps.
D.1.3 Arquitectura de la Información
La arquitectura de información en la cual nos basaremos son los modelos mentales
obtenidos mediante nuestra técnica Card Sorting, que nos da una idea más clara del modelo
mental de información que tienen los usuarios de la aplicación.
D.1.4 Estilos de la Interfaz
-Las interfaces deberán ser lo suficientemente intuitivas para que los usuarios sean capaces
de percibir la manipulación del mapa por los usuarios en las pantallas touch screen.
Figura D.1: Manipulación de mapa
-Los colores en los que nos basaremos serán los colores comunes utilizados en los mapas
de Google Maps como son: naranja, azul, amarillo, verde, negro, gris.
Anexo D
Página 172
Figura D.2: Google Maps
-Las funcionalidades de los usuarios deberán ser mostradas sobre pantalla, ya que los
usuarios al están acostumbrados al manejo de menús y botones.
Figura D.3. Menú
-Los iconos a manejar dentro de la aplicación serán edificios en 3d como propuesta de
solución de los iconos que no son identificados por los usuarios.
H
Figura D.4: Objetos dentro del mapa
Anexo D
Página 173
- La ubicación del usuario será representada por medio de un usuario en 3d dándole una
intuición más precisa de donde está localizado.
Figura D.5: Indicador de Ubicación
- Existirá un mensaje de perdida de conexión ya que si se queda sin conexión la aplicación
solo manda un mensaje de cargando.