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






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. 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. 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

http://mail.elsevier-alerts.com/go.asp?/bESJ001/mTX33K2F/q4FCLK2F/uPBGM0U6/xUMUNK2F/cutf%2D8


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


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


Identificación de


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.


Tarea Tareas

realizadas

Tiempo


Identificación de


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


Tarea Tareas

realizadas

Tiempo


Identificación de


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.


Tarea Tareas

realizadas

Tiempo


Identificación de


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.


Tarea Tareas

realizadas

Tiempo


Identificación de


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?


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?


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?


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.


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.

http://www.uiaccess.com/JustAsk/es/users_eg.html#ref2

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


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


11. ¿Se te facilita la visualización de

algún o algunos colores dentro de los

dispositivos móviles?

Sí No

12. ¿Qué colores?


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



(LBS)

14. ¿Cuántas veces has utilizado estos servicios?

Una vez Más de una vez

Muchas veces



(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



(LBS)

16. ¿Comúnmente para que lo has utilizado)?

Búsqueda Guiado Orientación

Otro______________________


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


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


usuarios

19. ¿Cuántas horas al día ocupas tu dispositivo móvil?

1hr 2hr 3Hr 4hr Mas

¿Cuantas?_______________

Experiencia con


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_____________________________


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


Objetivos asociados OBJ - 01 Determinar Ubicación

Requerimientos asociados IRQ – 02 Búsqueda


siguiente caso de uso, cuando se decida realizar una

búsqueda.

Precondición Conexión a internet y tener activado GPS


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


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


Objetivos asociados OBJ - 01 Determinar Ubicación

Requerimientos asociados IRQ – 02 Trazado de ruta


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


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.


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


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"


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


Selecciona mis sitios

Despliega los sitios

Selecciona sitio

Envía solicitud



Procesa Solicitud

Figura 7. 24: Diagrama de secuencia "Páginas de Sitios"


Selecciona Capas

Despliega los opciones

Selecciona trafico, vista satelite, ruta

Envía solicitud



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


Criterios Acción

Google Maps actual Google Maps

mejorado


Percepción

Visual

Reconocimiento de


Identificación de




Acciones

Mentales


que proporciona


a un lugar

00:01 00:01



Criterios Acción


mejorado


Percepción

Visual

Reconocimiento de


Identificación de 00:06 00:03

Capítulo VII

Página 123

Ubicación



Acciones

Mentales


que proporciona


a un lugar

00:02 00:02



Criterios Acción


mejorado


Percepción

Visual

Reconocimiento de


Identificación de



de funcionalidades

00:23 00:03

Acciones

Mentales


que proporciona


a un lugar

00:02 00:02


7.3.1.4 Tabla de tiempos promedio Tabla 7. 29: Promedio de tiempo

Criterios Acción


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


de funcionalidades 24.5 3.5

Acciones

Mentales


que proporciona


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


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.


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.

http://www.galileoic.org/la/files/LBS%20LOCALIZAR-T.pdf

http://www.tomgrill.info/show.php?name=PhD


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.

http://www.usabilitynet.org/trump/methods/integration/assurance.htm

http://www.usabilitynet.org/trump/methods/integration/assurance.htm

http://developer.smartface.biz/documents/Application_Development_Methodology.pdf

http://developer.smartface.biz/documents/Application_Development_Methodology.pdf


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

http://www.scangis.org/scangis2003/papers/

http://books.google.es/books?hl=es&lr=&id=wj19b5wVfXAC&oi=fnd&pg=PP1&dq=Location-Based+Services+Jochen+Schiller&ots=lbLj5wqeIk&sig=CmPEfMDUqFCcnD-DHr92FJQXTg4#v=onepage&q&f=false




http://www.iai.csic.es/lopsi/static/publicaciones/docencia/Apuntes%20RF-LPS.pdf

http://www.iai.csic.es/lopsi/static/publicaciones/docencia/Apuntes%20RF-LPS.pdf


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

http://www.lacofa.es/index.php/tecnologias/el-contexto-y-su-contexto

http://www.lacofa.es/index.php/tecnologias/el-contexto-y-su-contexto

http://www.rcet.org/ubicomp/what.htm

http://eisc.univalle.edu.co/cursos/web/material/750093M/80/metodos_evaluacion.pdf

http://eisc.univalle.edu.co/cursos/web/material/750093M/80/metodos_evaluacion.pdf

http://wiki.lbspro.com/index.php?title=LBS

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


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.


*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.


*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


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


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


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


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


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].


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



o

Sub-


Producto

Fase de

Usabilidad

Actividad

específica de

Usabilidad


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



o

Sub-


Producto

Fase de

Usabilidad

Actividad

específica de

Usabilidad


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



o

Sub-


Producto

Fase de

Usabilidad

Actividad

específica de

Usabilidad


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



o

Sub-


Producto

Fase de

Usabilidad

Actividad

específica de

Usabilidad


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



o

Sub-

Productos Descripción del Producto

Fase de

Usabilida

d

Actividad

específica de

Usabilidad


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].


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



o

Sub-

Productos Descripción del Producto Fase de

Usabilidad

Actividad

específica de

Usabilidad


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].


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,


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,



la aplicación.

Ventajas

Pueden realizarse más

fácilmente

modificaciones dentro

del producto,



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


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.


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


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

[email protected]

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


Formación Experiencia en dispositivos Móviles



Actividades Estudiantes, Trabajadores

Anexo C

Página 166


Formación Conocimiento tecnológico



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



Nombre de requisito Como llegar






Nombre de requisito Latitud




Anexo C

Página 167



Nombre de requisito Capas






Nombre de requisito Páginas de sitios






Nombre de requisito Mi Ubicación




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


«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


«extends»

«extends»

«extends»

«extends»

«extends»«extends»

Figura C.14: Diagrama de selección de funcionalidad

Anexo C

Página 169

Móvil


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.

TESIS DE MAESTRÍA EN CIENCIAS - CENIDET...Los LBS surgen de la convergencia de diferentes...

Documents

Transcript of TESIS DE MAESTRÍA EN CIENCIAS - CENIDET...Los LBS surgen de la convergencia de diferentes...