INSTITUTO TECNOLOGICO

DE CERRO AZUL
OCTAVO SEMESTRE
ING. SISTEMAS COMPUTACIONALES

MATERIA:
TECNOLOGIAS MOVILES

CATEDRATICO:
ING. NOE FRANCISCO CRUZ REYES

TRABAJO:
UNIDAD 3.-APLICACIONES
MOVILES ACTUALES

PRESENTA:
GASPAR REYESMARIA DEL CARMEN
10500339

0
 INDICE

Pag.

UNIDAD 3.- APLICACIONES MOVILES ACTUALES 2

3.1 FUNDAMENTOS DE DISEÑO DE SISTEMAS INTERACTIVOS 3

3.2 LINEAMIENTOS DE INTERFACES E INTERACCION PARA APLICACIONES EN

IOS Y ANDROID 13

3.3 MODELADO DE APLICACIONES CON DISEÑO CENTRADO EN EL USUARIO 15

3.4 APLICACIONES DE ALTA Y BAJA FIDELIDAD PARA DISPOSITIVOS MOVILES 21

3.5 EVALUACION DE APLICACIONES PARA

DISPOSITIVOS MOVILES 27

1
 UNIDAD 3.- APLICACIONES MOVILES
ACTUALES
Las tecnologías móviles y su continuo avance están propiciando una nueva
generación de aplicaciones, estas son las denominadas “aplicaciones móviles”. Se
considera aplicación móvil, a aquel software desarrollado para dispositivos
móviles. Móvil se refiere a poder acceder desde cualquier lugar y momento a los
datos, las aplicaciones y los dispositivos. Este tipo de aplicaciones se desarrollan
teniendo en cuenta las limitaciones de los propios dispositivos, como por ejemplo
el bajo poder de cómputo, la escasa capacidad de almacenamiento, ancho de
banda limitado, etc. Los dispositivos móviles son suficientemente livianos como
para ser transportados por personas y disponen de la capacidad de batería
adecuada para funcionar de forma autónoma. Algunos de estos dispositivos se
pueden observar en la Fig. 4. Estos dispositivos están dominados por diferentes
plataformas tecnológicas, incluyendo diferentes sistemas operativos. Cada uno
tiene sus particularidades en cuanto al manejo por parte del usuario, como así
también al momento de desarrollar una aplicación. Los sistemas operativos para
móviles son mucho más simples que los de una computadora y están más
orientados a la conectividad inalámbrica.

Existen dos categorías en las que se pueden clasificar las aplicaciones móviles
[17]: aplicaciones nativas y aplicaciones Web.

2
Aplicaciones nativas: Las aplicaciones nativas son desarrolladas
específicamente para un tipo de dispositivo y su sistema operativo, se basan en la
instalación de código ejecutable en el dispositivo del usuario. Estas tienen la
ventaja de acceder a las funciones del dispositivo, como por ejemplo:
almacenamiento, GPS (sistema de posicionamiento global), SMS (servicio de
mensajes cortos), mails, etc. Existen repositorios de los cuales se pueden
descargar e instalar este tipo de aplicaciones, según el sistema operativo. El
principal inconveniente de estas aplicaciones es que se deben desarrollar para
cada plataforma y por lo tanto incrementa el tiempo de desarrollo, costo y
esfuerzo.

Aplicaciones Web: Las aplicaciones móviles de este tipo se encuentran

ejecutándose en servidores, estas incluyen páginas web optimizadas para ser
visualizadas en dispositivos móviles y se pueden desarrollar en HTML, Java
Script, CSS, etc. Por definición, estas aplicaciones serán accedidas utilizando
algún navegador web. La ventaja que tiene desarrollar aplicaciones móviles Web
es que son fáciles de implementar y de integrar con aplicaciones existentes,
además de necesitar menos requerimientos del hardware de los dispositivos
móviles. El problema que tienen es que no pueden acceder a las funcionalidades
propias del dispositivo. Por ejemplo, una aplicación web no puede emplear la
cámara de un Smartphone, en el caso que la tuviera, para capturar imágenes o
realizar una filmación.

3.1 FUNDAMENTOS DE DISEÑO DE SISTEMAS

INTERACTIVOS

A mediados de los años ochenta se observa un cambio en la forma de concebir el

diseño, pasando de ser visto como un proceso lineal a la idea actual de ciclo en la
que se centra la idea en el carácter iterativo del proceso y en las necesidades y
capacidades de los usuarios. Dentro del ciclo de diseño se enmarca el concepto
de usabilidad, es decir, a como el usuario puede usar el sistema que está siendo
diseñado. Para ello es necesario llegar al concepto de evaluación de la usabilidad:
deben existir unas especificaciones de usabilidad la opinión del usuario debe
tenerse en cuenta el diseño debe ser poco costoso

Corresponde a los expertos en ingeniería de la usabilidad definir como se evalúan

las especificaciones, como recoger la opinión del usuario y tenerla en cuenta
dentro del ciclo de diseño, y finalmente como concretar el número mínimo de

3
prototipos a partir del cual, la iteración del ciclo se considera ya suficiente para dar
por finalizado el diseño.

Como ejemplo de marco metodológico se dispone del Modelo de Proceso de la

Ingeniería de la Usabilidad y la Accesibilidad MPIu+a desarrollado por Toni
Granollers que recoge cada una de las fases del ciclo (poner aquí el nombre)
(Granollers et.al., 2005). Y para la medida de la usabilidad es necesario contar con
la aportación de los estudios experimentales llevados a cabo en los laboratorios de
usabilidad.

Jerarquía de necesidades. (ej: diseño de un programa V+ para robot RX-90

de Stáubli)

Este concepto proviene de la jerarquía de necesidades de Maslow (Maslow,

1991). Maslow aplica esta jerarquía en aspectos de motivación y personalidad. La
propuesta original puede aplicarse al diseño, modificando ligeramente algunas de
las ideas que intervienen inicialmente. El principio de la jerarquía de las
necesidades especifica que un diseño debe satisfacer un conjunto de necesidades
de forma ordenada.

La jerarquía de necesidades se expresa en forma de pirámide de 5 niveles. La

idea elemental es que un diseño debe satisfacer las necesidades básicas (niveles
inferiores) antes de intentar conseguir necesidades más elevadas (niveles
superiores). A continuación se detalla cada nivel tomando como ejemplo de diseño
la creación de un programa de control de los movimientos y tareas de un robot
industrial.

4
Funcionalidad. El diseño creado debe permitir que la máquina o el artefacto
funcione. Cuando se programa un robot industrial, dicha máquina debe funcionar
en el sentido de realizar tareas básicas. En el ejemplo del robot: posicionarse en el
espacio, coger una pieza, desplazarse en el espacio, y dejar la pieza. Tareas que
vienen dadas por la propia definición de lo que es un robot industrial.

Fiabilidad. El aspecto se refiere a la obtención de resultados estables y

consistentes. En el ejemplo del robot, se trata de que el robot coja eficazmente la
pieza, sin problemas de adherencia, y no pierda la pieza a lo largo del
desplazamiento. El agarre debe efectuarse sin dañar la pieza. Si no se pueden
garantizar estos aspectos, el robot no puede aplicarse en el entorno industrial con
éxito.

Utilidad. El concepto se refiere a la facilidad en el uso de un diseño. En el ejemplo

del robot, se trata de que el programa creado sea flexible para permitir cambios y
aceptar nuevas instrucciones que mejoren el programa básico a medida que se
requieran: incluir instrucciones sobre la precisión de los movimientos, la velocidad
del movimiento, el tipo de trayectoria a seguir en el espacio.

Competencia. Se trata de otorgar a los usuarios la posibilidad de hacer las cosas

mejor. Un experto en ingeniería robótica, puede obtener el programa de robot
generado por el diseñador e introducir mejoras. Este detalles es útil cuando el

5
robot se programa en un entorno industrial repleto de otras máquinas, y cuando
hay que prever la interacción entre las tareas del robot y del operario. Dichos
cambios se realizan a lo largo de diversas fases en la puesta en marcha del robot,
por lo que es necesario dicha necesidad.

Creatividad. Una vez satisfechas todas las necesidades anteriores, los usuarios
pueden interactuar con el diseño de un modo innovador. En el ejemplo del robot,
el experto en ingeniería robótica puede mejorar los tiempos de ciclo para mejorar
la productividad del robot en su tarea industrial, y contribuir así a la mejora del
rendimiento del sistema productivo.

En qué se diferencia el diseño de aplicaciones móviles:

 Los usuarios de dispositivos móviles pueden conectarse desde una gran

variedad de redes, tecnologías y ubicaciones: 3G, 4G, Redes Wi-Fi, desde casa,
la Universidad, la Oficina, etc.
 Existe una amplia variedad de dispositivos móviles, con diferentes
capacidades y tamaños de pantalla, desde tabletas, teléfonos inteligentes
(Smartphones) o teléfonos “semi-inteligentes” (teléfonos inteligentes sin pantalla
táctil).
 Amplia variedad de fabricantes y sistemas operativos, iOS (iPhone de
Apple), Android, Blackberry, Windows Phone, entre otros, cada uno con sus
propios estándares de diseño de interfaz y programación.
 Los dispositivos poseen funcionalidades específicas como: Sensores de
proximidad, localización, orientación de pantalla vertical u horizontal que deben
tomarse en cuenta.
 Los dispositivos tienen carga de batería limitada. Si se hace un uso
inadecuado de ciertas funciones, esta se puede consumir rápidamente en perjuicio
para el usuario.
 Necesidad de acomodar diferentes paradigmas de diseño por plataforma,
por ejemplo botones circulares en iOS vs. Botones cuadrados en Android.
 La interacción con la pantalla táctil es totalmente diferente a la interacción
con teclado y mouse, incluyendo tocar la pantalla, arrastrar, presionar, entre otras
posibilidades.
 Mercado saturado, sin un producto líder (múltiples marcas y sistemas
operativos), que evoluciona rápidamente. Cualquier cosa que se construya hoy
será obsoleta en un año. 

Como diseñar aplicaciones para móviles

Mayor estudio del contexto en el que se desenvuelve el usuario

6
 El contexto de un usuario móvil es muy distinto al de los usuarios de PC’s
fijos, por ejemplo es muy lógico pensar que una app de mapas o sobre el clima
sea consultada mientras se está en la calle, con mucho ruido y atento a no
golpearte contra una farola.
 Tener en cuenta contextos como éste está dentro del trabajo que ha de
realizar el experto en usabilidad. 
 Los contextos varían mucho, los Teléfonos inteligentes pueden ser usados
mientras andas en la calle, o en un taxi, o en el subterráneo, mientras que las
tablets son más usadas en la sala de tu casa o sentado en un café.
 Si han de abarcarse múltiples dispositivos, deben desarrollarse
funcionalidades específicas al contexto de cada uno.
 En el peor de los casos se requerirá una versión por cada tipo, marca,
tamaño y sistema operativo del dispositivo.

Requiere de especialistas en Diseño para móviles

Quienes desempeñen roles de diseño de aplicaciones móviles deben:

 Preferiblemente tener experiencia en diseño web y diseño centrado en el

usuario.
 Estar formados en interfaz hombre máquina para dispositivos móviles.
 Entender los principios de diseño para móviles, esto es un punto de alto
riesgo. Por ejemplo, si desarrollas una aplicación para iOS que no cumpla con los
“Lineamientos para interfaz humana” de Apple, tu aplicación podría no ser
aprobada para ingresar al App Store (por lo que no podrías distribuirla ni a clientes
internos ni externos).
 Conocer las limitaciones de las plataformas para las cuales están
diseñando, para con esa base diseñar la forma de capturar y mostrar la
información.
 Ahora más que nunca los proyectos requerirán de un experto en usabilidad
móvil, no sirve un experto en usabilidad web, debe tener conocimientos y
experiencia específicos en dispositivos móviles.

Elementos de Diseño y Usabilidad

 El diseño es tan importante como la funcionalidad. No importa qué tan

buena o práctica sea una aplicación, si a los usuarios no les gusta como se ve, no
la utilizarán.
 Por el punto anterior, queremos que la aplicación sea atractiva visualmente,
pero es igual de importante desarrollar la usabilidad teniendo en cuenta el
contexto, es decir, donde y cuando se va a usar.
 El usuario no contará con ratón o puntero para interactuar con la aplicación.

7
 La aplicación podría utilizarse en movimiento, mientras se camina, se habla
o se está concentrado en otra cosa.
 Tener en cuenta contextos como éste está dentro del trabajo que ha de
realizar el experto en usabilidad. 

Cambios en la Metodología de Diseño

 Debe hacerse con métodos más iterativo y más visuales, los documentos
extensos que describen funcionalidad gráfica ya no funcionan aquí.
 Utilizar métodos tradicionales resultará en múltiples revisiones y cambios al
documento, aplicación, resultando en esfuerzo desperdiciado.
 En lugar de especificaciones detalladas, es mejor utilizar un wireframe de
baja fidelidad para capturar el look and feel y validarlo con el cliente.
 Existen herramientas con ayudas visuales para wireframes en las cuales
estos se pueden crear y modificar rápidamente en un proceso iterativo, trabajando
de la mano con el cliente.
 Luego de aprobar los wireframes, es hora de crear la interfaz gráfica, lo que
implica trabajo conjunto con el departamento de mercadeo para usar los
lineamientos de diseño de acuerdo a la marca. 
 Si tu empresa no ha hecho aplicaciones móviles antes, estos lineamientos
podrían no estar disponibles.
 Algunos puntos a definir:
o Diseño del icono de la aplicación en la tienda app.
o Posicionamiento de los logos en el espacio limitado.
o Disponibilidad de recursos para crear las imágenes (iconos, botones,
fondos de pantalla). Para esto se requiere diseño artístico.
o Efectividad del diseño.

Desarrollo de Software Tradicional o Desarrollo Ágil? 

Lo primero que debemos seleccionar al iniciar un proyecto de desarrollo de un App

para móviles es la metodología de desarrollo de software a utilizar. 

Si aplicáramos un desarrollo en cascada (tradicional), deberíamos seguir

religiosamente estos pasos: primero obtener los requerimientos, y firmarlos, luego
escribir los documentos de diseño funcional y técnico, construir la aplicación,
hacer pruebas unitarias, pasara por el proceso de QA y luego la salida (Reléase). 

Sin embargo, el enfoque tradicional tiene un problema para proyectos de

aplicaciones móviles, y es que depende en gran medida que las especificaciones
de diseño sea lo que el usuario realmente quiere para tener éxito, ¿Quién define
estas especificaciones?, como no podemos entrevistar a todos los miles de
usuarios potenciales de nuestro App, tenemos que recurrir a un grupo de expertos
8
en producto quienes tendrán que interpretar los deseos de este usuario.  

¿Qué sucedería si diseñamos las 40 funcionalidades (features) de nuestro App?,

desarrollamos el App y al lanzar el producto nos damos cuenta que esto no era lo
que el usuario final quería. 

En lugar del enfoque tradicional, podríamos optar por lanzar un “mínimo producto
viable”, con algunas pocas funcionalidades, y luego utilizar la retroalimentación de
nuestros clientes para incorporarlo en el resto de las 40 funcionalidades, este
enfoque “ágil” nos permite tener mayor seguridad que estamos invirtiendo el
esfuerzo en el producto que el cliente realmente quiere y necesita. 

De hecho, la mayoría de la comunidad en la web coincide que el desarrollo para

móviles se adapta mejor a métodos de desarrollo ágil de software, aunque
existe una minoría de proyectos en el área empresarial (por ejemplo extensiones
del ERP de la empresa) en el cual se aplican métodos predictivos tradicionales. 

Desarrollo de aplicaciones nativas 

Cada uno de los principales fabricantes de teléfonos móviles y tabletas (Apple,

Android, Blackberry) dispone de su propio sistema operativo, por ejemplo Apple
cuenta con el iOS y los dispositivos Android utilizan ese sistema operativo. 

Desarrollar aplicaciones nativas implica utilizar las herramientas que proporcionan

estos sistemas operativos, por ejemplo Android se basa en Java y iOS en Objetive
C, estos son los lenguajes de programación en el cual deben ser desarrolladas las
aplicaciones. Estas aplicaciones residen en el dispositivo, y pueden interactuar
con componentes de servidor. 

Debe definirse un proceso de construcción para cada tecnología o sistema

operativo involucrado en el proyecto, por ejemplo, si se tiene un proyecto de
desarrollo de un App que se va a distribuir en Apple iPhone (iOS), teléfonos
Android (iOS) y BlackBerry, el proceso de construcción se debe diagramar de la
siguiente forma: 

9
 Imagen obtenida de: Mobile Effect

Si a esto añadimos dispositivos adicionales como Tablets Apple o Android, u otros

dispositivos como el Windows Phone, o dispositivos Windows 8, pues como
veremos tendríamos que abrir un proceso de construcción distinto para cada
dispositivo, con diferentes conocimientos y habilidades requeridos de los
desarrolladores de software que intervendrían en el proceso. El proyecto puede
crecer en tamaño y complejidad rápidamente.

¿Cómo manejar esta complejidad?, pues existen varias alternativas: 

 Construir aplicaciones para un solo sistema operativo, construiremos un

equipo de desarrollo y capacidades de la organización cohesionados, pero
podemos perder clientes potenciales en otros sistemas, ¿Qué ocurrirá si
desarrollamos sólo para Android y nos piden un App para Apple?, ¿diríamos que
no?, en eso debemos pensar.
 Construir aplicaciones en un solo sistema operativo, luego cuando
tengamos la retroalimentación del cliente, desplegar en otros sistemas operativos.
Esto nos permite reducir la complejidad de nuestro desarrollo inicial, sobre todo
cuando es un nuevo producto que está definiendo un nuevo mercado. 
 Construir en tres o cuatro sistemas operativos, pero debemos tener en
cuenta la complejidad del proyecto, por ejemplo si vamos a construir para tablets y
smartphones en los sistemas Apple, Android y Blackberry, podríamos necesitar
entre 3 y 6 equipos de desarrollo, lo cual puede ser más complejo de gestionar. 

Desarrollar en HTML5 (para el Browser Web) 

Para minimizar el impacto de desarrollar aplicaciones nativas, algunas compañías

han considerado el HTML5 o un enfoque híbrido entre aplicaciones cliente
servidor. Esto es, desarrollar la aplicación del lado de servidor, en la tecnología
que se seleccione (por ejemplo Java, PHP o .NET), utilizando componentes para
hacer la interfaz gráfica más amigable, y que se acceda a estas aplicaciones por
medio del browser web que se puede instalar en cada dispositivo móvil. 

Sin embargo, es necesario recordar que igualmente, es necesario producir código

diferente para acomodar las diferentes plataformas (iOS, Android, Blackberry, etc.)
y si estamos desarrollando una aplicación con funcionalidades gráficas
avanzadas, terminaremos en un escenario similar al de las aplicaciones nativas. 

Adicionalmente, se debe lidiar con el hecho que HTML5 es un estándar que aún
está en constante evolución, lo cual ha resultado en muchas variantes en los
browsers, para lo cual en un proyecto como este se necesitaría una versión de
aplicación para cada uno. 
10
¿Cual enfoque es el adecuado?

Desarrollar aplicaciones nativas o basadas en el browser pueden ser ambos

enfoques válidos, todo dependerá de las necesidades del producto que estemos
desarrollando y de los objetivos que necesitemos lograr, por ejemplo, necesitamos
velocidad o vistosidad gráfica, facilidad para aplicar cambios, aplicaciones
empresariales u orientadas a cliente final, es decir, deben considerarse todas las
variables al tomar una decisión.

Al desarrollar aplicaciones para móviles (teléfonos o Tabletas), deben

considerarse los siguientes casos de prueba adicionales.

1.- Pruebas de Diseño de Interfaz de Usuario

Adicional a las pruebas que forman parte de un proyecto de software (Unitarias,

Funcionales, Integrales, Desempeño, Aceptación de usuario, entre otros), debe
agregarse pruebas de diseño de interfaz de usuario. Esto es particularmente
importante en aplicaciones para el iPhone (Apple), pues el no adherirse a los
lineamientos de Diseño exigidos por Apple podría ocasionar que la aplicación no
sea aceptada en la tienda (el único medio posible para distribuir estas aplicaciones
al público).

2.- Escenarios de prueba específicos de cada sistema operativo

Es necesario agregar casos específicos en cada sistema operativo incluido (iOS,

Android, Blackberry, etc). Existen funcionalidades que se comportan de distinta
manera en un iOS que de un Android. Los casos de prueba deben tomar en
cuenta esto.

3.- Pruebas de Interrupción

Los escenarios de prueba deben incluir las llamadas “pruebas de interrupción”, por
ejemplo:

 Usuario recibe llamada o mensaje de texto justo en el momento de la

ejecución de un proceso de la aplicación.
 Que sucede si la App utiliza geolocalización y pierde cobertura (de la red de
telecomunicaciones) en el medio de un proceso.

4.- Uso de emuladores

 Podría estarse tentado a utilizar solamente simuladores de dispositivos

(emuladores) para ahorrar tiempo de prueba y costos, sin embargo, no es
recomendable, pues es seguro que se tendrán problemas en producción.
11
 Los emuladores son herramientas muy útiles, sin embargo, la realidad
demuestra que las aplicaciones tienen distinto comportamiento en el dispositivo
real que en el emulador.
 Algunas pruebas, como por ejemplo pruebas de funcionalidades de
localización del dispositivo (funcionalidad en la cual el dispositivo identifica la
localización y por ejemplo muestra una lista de comercios o direcciones cercanas),
pruebas desempeño en distintas redes de telecomunicaciones, entre otras,
simplemente no se pueden hacer en el emulador.

5.- Pruebas en dispositivos móviles reales

 Si bien es imprescindible probar en dispositivos reales, no es posible probar

toda la gama de dispositivos y configuraciones que existen.
 Cuales dispositivos y cuantos dependerá de la tolerancia que tenga la
compañía de presentar problemas en producción, si la tolerancia es baja (no
toleramos errores) entonces las pruebas deberán ser más extensas e incluir más
dispositivos.
 La adquisición de estos dispositivos debe considerarse en el presupuesto
del programa o proyecto para el desarrollo de las aplicaciones móviles. Todos los
años salen al mercado nuevos dispositivos, por lo cual deberán realizarse
compras permanentemente.
 Otra opción es recurrir a nuestros mismos clientes, es decir podemos lanzar
un Beta o iniciativa de Crodwsourcing y buscar el apoyo de nuestros clientes
pioneros (los llamados Early Adopters), quienes están motivados adquirir y probar
la última tecnología, inclusive cuando esta presenta fallas. La ventaja de esta
opción es que se obtiene mayor volumen de pruebas.

6.- Pruebas y modificaciones de código en múltiples ramas

 Si se está desarrollando la aplicación para múltiples dispositivos en

múltiples sistemas operativos, debe tomarse en cuenta que, al resolver defectos,
deberá manejarse el mantenimiento de cada rama y versión de la aplicación.
 Esto implica un equipo de desarrollo más grande y costos mayores
de reparación de cada defecto, es por ello que garantizar la calidad desde el inicio
es particularmente importante en aplicaciones móviles .

12
3.2 LINEAMIENTOS DE INTERFACES E
INTERACCION PARA APLICACIONES EN IOS Y
ANDROID
iOS es el sistema operativo desarrollado por Apple y que se utiliza en sus
diferentes dispositivos que en este momento son iPhone, iPod touch y iPad. Su
participación de mercado en México en cuanto a smartphones es del 20% y 72%
respecto a tabletas.

Su fortaleza principal está en que la experiencia de usuario es muy consistente de

un dispositivo a otro ya que el número de modelos con los que cuenta Apple es
muy limitado además de que la gran mayoría de sus usuarios actualiza
constantemente su sistema operativo.

El iPad especialmente es un dispositivo muy versátil para el ámbito de negocios ya

que tiene las siguientes ventajas:

 Larga duración de batería

 Se activa inmediatamente 

 Su gran pantalla permite una interacción prolongada más cómoda

 Son dispositivos sencillos de utilizar

Las aplicaciones que desarrollamos para iOS pueden publicarse de manera

masiva en la App Store o pueden distribuirse de manera restringida a través del
programa que ofrece Apple llamado “iOS Enterprise Program“.

Este último es conveniente por si se desea llevar a cabo un desarrollo de uso

interno exclusivo (aplicaciones para la fuerza de ventas de la empresa, para llevar
a cabo procesos internos, para visualizar reportes ejecutivos, etc…)

La constancia y confiabilidad de los equipos Apple permite desarrollar aplicaciones

más atractivas y con una interfaz gráfica más personalizada.

Si desea que su aplicación sea publicada en la App Store, nosotros los hacemos
posible, ya que al desarrollar su app, nos apegamos a los diferentes lineamientos
que marca Apple y seguimos siempre las mejores prácticas de programación y de
control de calidad.

13
Android es la plataforma móvil más utilizada en México, con un 62% de
participación de mercado entre los teléfonos inteligentes. Lo que significa que en
México hay entre 25 y 30 millones de usuarios de este sistema operativo.

Estos datos sin duda hablan de que existe una gran oportunidad de negocio.

Desarrollar para Android a nivel profesional como lo hacemos nosotros no es

sencillo ya que existe un fenómeno conocido como “fragmentación“.

La fragmentación quiere decir que existen muchas diferentes marcas que utilizan
Android. Estas marcas a su vez ofrecen muchos diferentes modelos (hay más de
10 mil modelos en el mercado) con diferentes características cada uno. Algunas
de ellas son:

 Resolución de pantalla

 Procesador

 Memoria RAM

 Versión de Android

Desarrollar una aplicación compatible con la mayoría de estos dispositivos es un

reto interesante y que nosotros enfrentamos todos los días.

La manera en la que trabajamos con la plataforma Android es la siguiente:

 Primero identificaremos el mercado (por perfil psicosociodemográfico o

nivel socioeconómico) al que va dirigido tu aplicación; de esta manera
podemos identificar las marcas y modelos que más probablemente estará
utilizando la mayoría de tus usuarios

 Definimos una experiencia de usuario que sea consistente para las marcas
y modelos a las que nos enfocaremos

 Desarrollamos tu aplicación siguiendo los estándares más altos de diseño,

experiencia de usuario, programación y seguridad, cuidando que el
resultado sea una app estable y que consuma solo los recursos mínimos
necesarios del usuario (plan de datos y batería)

Durante el desarrollo y una vez terminado el mismo, realizamos pruebas de

calidad asegurándonos que tu app corra de manera correcta en la mayoría de
dispositivos Android del mercado y específicamente en aquellos modelos que
utilizará la mayoría de tus usuarios.

14
Nosotros contamos con decenas de dispositivos de pruebas para tu tranquilidad
y personal muy capacitado con varios años de experiencia, lo que garantiza
que su inversión está segura con nosotros.

3.3 MODELADO DE APLICACIONES CON DISEÑO

CENTRADO EN EL USUARIO
El diseño centrado en el usuario (DCU) es un proceso de desarrollo de software
en el que la usabilidad se considera como el objetivo a lo largo del proceso
completo de desarrollo. Las actividades de DCU deben empezar en la fase más
temprana del desarrollo del sistema, o sea, desde que se inicia la etapa de
conceptualización. En las siguientes secciones se describen los elementos
básicos del DCU, los modelos de diseño de la interacción, los pasos para realizar
un DCU, y el proceso para identificar usuarios, necesidades y requerimientos.

ELEMENTOS BÁSICOS DEL DCU

 Participación activa de los usuarios en el proceso de desarrollo
 Equipos de DCU con diversidad de habilidades

Beneficios que aporta la Usabilidad:

 Incremento de las ventas
 Mejora de la comunicación
 Reducción de los costes de desarrollo
 Detección inicial de errores
 Tiempo de desarrollo menores
 Menos costes de mantenimiento y soporte

PASOS PARA REALIZAR UN DCU

Son cinco los pasos para realizar DCU:
 Planificación del proceso de DCU: integración del DCU en todas las fases
del ciclo de vida del sistema; determinación de riesgos posibles derivados
de una usabilidad pobre; desarrollo de procedimientos para comunicación y
retroalimentación para otras actividades del proceso de desarrollo
relacionadas con el DCU; definición de hitos en las tareas del DCU;
acuerdos acerca de tiempo; definición de responsabilidades y control de
cambios.
 Comprensión y especificación del contexto de uso: identificación de
usuarios; características, necesidades y objetivos de los usuarios y otros

15
 afectados (stakeholders) por el sistema; hardware, software y materiales
necesarios mientras se usa el sistema; características y restricciones del
ambiente físico, social, organizacional, cultural y técnico.
 Especificación de los requerimientos de los usuarios: requerimientos
derivados de las necesidades de los usuarios y el contexto de uso;
requerimientos y objetivos de usabilidad derivados de las características del
usuario; solución de posibles conflictos entre distintos requerimientos.
 Producción de soluciones de diseño: diseño de las tareas del usuario;
interfaz de usuario e interacción humano-sistema para alcanzar los
requerimientos; cambios en las soluciones de acuerdo con los resultados
de las evaluaciones.
 Evaluación del diseño: participación de evaluadores y usuarios; definición
de pruebas que brinden retroalimentación para mejorar la solución de
diseño; evaluación de prototipos de parte de los usuarios, preferiblemente
con la ejecución de tareas concretas que representen sus necesidades.
Tal como se puede observar en la Figura 1, el DCU es un proceso iterativo
que inicia con la planificación. Cada iteración comprende la ejecución de cuatro
pasos, al final de los cuales, con base en los resultados de la evaluación, se
determina si el diseño del sistema sirve para satisfacer los requerimientos. La
respuesta a la pregunta de si el sistema satisface los requerimientos que se
plantea al final de cada ciclo servirá para determinar cuál es el aspecto a dar
prioridad para la siguiente iteración.

Figura 1. Proceso de diseño centrado en el usuario

16
IDENTIFICACIÓN DE USUARIOS Y NECESIDADES
La etapa de comprensión y especificación del contexto de uso del DCU
incluye la identificación de los usuarios, otros afectados y sus necesidades. Este
aspecto es fundamental puesto que el sistema debe estar adaptado a las
habilidades físicas, sensoriales y cognitivas de los usuarios, sus personalidades y
diferencias culturales.
Para identificar a los usuarios y otros afectados, es conveniente tomar en
cuenta aspectos técnicos, sociales, organizacionales y humanos. La primera
pregunta que debemos plantearnos es quiénes son todos los afectados por el
éxito o el fracaso del sistema, usualmente llamados stakeholders, del sistema. No
todos los afectados por un sistema lo son en la misma forma, pero es importante
identificarlos a todos pues entre ellos pueden existir conflictos de intereses.
Podemos clasificar los stakeholders en cuatro categorías:
 Primarios: los que directamente interactuarán con el sistema, a quienes
usualmente llamaremos usuarios.
 Secundarios: los que reciben la salida y proveen la entrada al sistema sin
interactuar con el sistema. Indirectamente son usuarios del sistema.
 Terciarios: los que no se involucran con el sistema pero se ven afectados
por su éxito o fracaso.
 Facilitadores: los que tienen a su cargo el desarrollo y la puesta en
producción del sistema.
Supongamos que estamos pensando en crear un sistema de dispositivos
móviles que permitirá a los residentes de una zona reportar malas prácticas
ambientales, tales como botaderos ilegales de basura o vertederos de aguas
contaminadas a ríos. En este caso, los stakeholders por categoría serían los
siguientes
 Primarios: los que van a utilizar directamente el sistema, o sea, los
residentes con el teléfono móvil dispuestos a denunciar las malas prácticas;
funcionarios en el gobierno local que recibirán las denuncias y las
canalizarán a las autoridades competentes.
 Secundarios: los encargados de la recolección de basura y las autoridades
sanitarias competentes; las autoridades del gobierno local
 Terciarios: los que son responsables de las malas prácticas ambientales,
tales como las empresas que generen la contaminación y las personas que
tiren la basura en los tiraderos; los residentes de la zona
 Facilitadores: el equipo de desarrollo del sistema, el personal del
departamento de tecnologías de información del gobierno local
En este ejemplo es fácil ver que existen conflictos de interés entre los
distintos stakeholders, pues mientras unos lucharán contra las malas prácticas,
otros intentarán perpetuarlas.

17
 En particular, para los stakeholders primarios, usuarios del sistema, se
debe determinar sus características, tales como su formación, experiencia previa
en el uso de computadoras, actitud ante estas, grupo etario, limitaciones
cognitivas y físicas y motivación para usar el sistema. Esto ayudará a crear un
sistema que brinde una experiencia de uso positiva.
Para que los desarrolladores tengan siempre presente que están creando un
sistema que va a afectar a personas, pueden crear personas, personajes ficticios
que sintetizan las características de un grupo de usuarios potenciales específicos.
Al ponerle un rostro humano a un usuario, a los diseñadores se les facilita pensar
en lo que un ser humano real puede necesitar. Además, se evita el error de que el
desarrollador se ponga a sí mismo como referencia. Las personas no
corresponden a personajes idealizados, sino realistas, en el sentido de que una
persona posee tanto habilidades como limitaciones específicas, pero además
realiza sus tareas en un contexto, tiene objetivos y preocupaciones, actitudes y
comportamientos. La descripción de una persona puede abarcar una o dos
páginas. Se pueden crear varias personas para representar distintos grupos de
usuarios.

Los desarrolladores del sistema deben cubrir las necesidades de tantos

stakeholders como sea posible, aunque, debido a los conflictos, habrá que
establecer prioridades. Usualmente estas se asignan con base en el grupo al que
pertenecen los stakeholders. En términos generales, las necesidades de los
primarios son las de mayor prioridad. Sin embargo, hay excepciones, como en
equipos médicos de soporte vital, para los que las necesidades del paciente, un
stakeholder secundario, son las más importantes pues su vida depende del
sistema.
Una vez identificados todos los stakeholders, se procede a identificar sus
necesidades. Para ello, se pueden utilizar varias estrategias, tales como:
inmersión en el ambiente real de los usuarios, observación de las personas
cuando realizan sus tareas, grupos focales y entrevistas a las personas mientras
trabajan. Sin embargo, con estas estrategias no se puede cubrir todo el rango de
stakeholders cuando se desarrollan aplicaciones web o para dispositivos móviles,
cuyos usuarios pueden estar distribuidos por todo el mundo. En estos casos,
todavía es posible recurrir a encuestas en línea, aunque se sabe que la tasa de
respuesta es muy baja.
Para hacer más concretas las necesidades, las transformamos en tareas.
Una tarea es una unidad significativa de trabajo que debe ser realizada en un
determinado tiempo, caracterizada por qué hacen los usuarios, cuáles artefactos
(objetos físicos) usan y cómo lo hacen. La ejecución con éxito de una tarea implica
que el usuario ha conseguido un objetivo. Si ya existe una forma de realizar la
tarea, el diseñador responderá las preguntas con base en observación y
entrevistas. Si no, será necesario imaginar cómo se podría llevar a cabo la tarea,
con el uso de algunas técnicas de prototipado que se verán posteriormente.

18
 Una tarea describe un trabajo completo, no es una lista de lo que el sistema
debería hacer, sino que se enlaza todo lo que el usuario quiere hacer. Por
ejemplo, supongamos que estamos desarrollando una aplicación web de
supermercado en línea. Una tarea en este contexto es realizar la compra mensual
de comestibles y productos de limpieza. Esta tarea, a su vez, puede dividirse en
subtareas, tales como: revisar la despensa para determinar cuáles productos se
han agotado, identificar los eventos sociales que pueden causar que se requieran
cantidades extraordinarias de algunos productos (por ejemplo, una fiesta familiar),
revisar la lista de productos que están en oferta, hacer la lista de productos a
comprar, determinar el monto de dinero disponible para gastar, seleccionar los
productos a comprar entre los disponibles en el supermercado, revisar la lista de
productos seleccionados y pagar. Como se puede notar en este ejemplo, no todas
las subtareas se realizan con el sistema, pero es importante comprender todo el
contexto dentro del que se desarrolla la tarea.

PROTOTIPADO
Un prototipo es un medio para probar una idea, refinarla, evaluar su
factibilidad técnica y económica, promocionarla y gestionar fondos para su
comercialización. Los prototipos son comunes en industrias como la
automovilística o la aviación. En particular, en el campo de la IHC, un prototipo es
una herramienta que simula o en la que se han implementado partes del sistema
que estamos implementando. Existe un amplio rango de prototipos, que incluyen,
por ejemplo, una pieza de madera con la que se simula la interacción, un
documento estático, una serie de dibujos, una historieta (storyboard) sobre cómo
se desarrolla la interacción, un video en la que se ve cómo interactuará el usuario
con el sistema, o bien una pieza de software con funcionalidad limitada, con la que
un usuario podría o no interactuar.
Los prototipos se utilizan principalmente en la fase de identificación de
requerimientos y son especialmente útiles cuando existe incertidumbre acerca de
las necesidades de los usuarios. Sirven como un medio de comunicación que
facilita el entendimiento entre diseñadores y usuarios. Por esta misma razón,
permiten a los diseñadores establecer un lenguaje común con los usuarios y
recibir retroalimentación de estos, fundamental en un proceso de DCU. Algunas de
las técnicas de prototipado tienen un costo muy bajo, con lo cual se puede pensar
en distintas opciones de diseño. Por esta razón, los prototipos dan espacio a la
reflexión sobre el diseño de la interacción. Además, pueden utilizarse para probar
un concepto o un modelo de interacción antes de invertir mucho tiempo y dinero.
Dependiendo del tamaño del sistema, puede no ser posible crear prototipos
de todas las tareas que se deben realizar. En este caso, se debe ser selectivo
acerca de cuáles partes del sistema prototipar. Por eso, se debe establecer
criterios de selección, tal como elegir las tareas más complejas o que impongan
mayor carga cognitiva sobre los usuarios o bien aquellas que son de uso más
frecuente. En el primer caso, se espera bajar la carga cognitiva y en el segundo
lograr un alto nivel de eficiencia en tiempo.
19
 Existen tres estrategias para la decidir los criterios de selección de qué
prototipar: vertical, horizontal y diagonal. En un prototipo vertical, se implementan
de manera completa pocas de las funcionalidades del sistema. Ofrece la ventaja
de mostrar una sección limitada pero completa del sistema. Si se trata de un
prototipo ejecutable, se puede probar dicha sección como si estuviera en
producción. Por el contrario, un prototipo horizontal muestra toda la funcionalidad
del sistema, aunque no es funcional. Por tanto, no se puede realizar una prueba
real. Por último, un prototipo diagonal comienza como un prototipo horizontal hasta
un cierto nivel y después, una sección del sistema se desarrolla con más
profundidad. En la Figura X se muestran los conceptos de prototipo horizontal y
vertical.

CARACTERÍSTICAS DE UN PROTOTIPO
Un prototipo es un producto intermedio del proceso de DCU. Sus
características dependen del propósito para el que fue creado y del grado de
avance en el proceso de desarrollo. Sin embargo, algunas son comunes para
todos los prototipos, tales como que deben:
 Ser construidos en poco tiempo
 Ser oportunos, o sea, estar listos temprano en el proceso para que ayude a
clarificar ideas
 Ser fácilmente modificables
 Mostrar cómo será la interacción entre usuarios y sistema
 Ayudar a crear un lenguaje común entre usuarios y desarrolladores
 Sugerir en vez de confirmar, para que sirvan para refinar el diseño

20
3.4 APLICACIONES DE ALTA Y BAJA FIDELIDAD
PARA DISPOSITIVOS MOVILES
Existen dos grandes clases de prototipos: los de baja y los de alta fidelidad. Los
primeros se caracterizan por no parecer un producto final. Por lo general, los
prototipos de baja fidelidad se construyen en poco tiempo, son de bajo costo por
no tener que invertir mucho tiempo en su elaboración y se modifican fácilmente.
Los usuarios no siempre comprenden cuánto esfuerzo se ha realizado para la
construcción de un prototipo. Si se les presenta uno que parece muy elaborado, se
sentirán intimidados para opinar y cambiarlo, pues pensarán que ya se ha
invertido mucho tiempo en su elaboración. Por tanto, el prototipo no servirá para
cumplir su cometido. Es por esta razón que los prototipos de baja fidelidad son
importantes.
Los prototipos de baja fidelidad ejemplifican cómo se implementarán
algunos aspectos generales del sistema, sin detallar cómo será la interfaz. Son
apropiados en las etapas más tempranas del ciclo de vida, pues ayudan a
identificar los requerimientos y a crear, conjuntamente con el usuario, el modelo
conceptual del sistema, o sea, un acuerdo común sobre cómo funcionará el
sistema. Además, debido a su bajo costo, es posible crear varias opciones de
diseño, con lo cual son aptos para evaluar múltiples conceptos de interacción.
Dado que los prototipos de baja fidelidad no son ejecutables, para simular
la interacción con el sistema, el usuario debe contar con la guía y la asistencia del
diseñador. La vida de los prototipos de baja fidelidad termina cuando los
requerimientos ya están establecidos.
Los prototipos de alta fidelidad se parecen más a un producto final, con el
que incluso puede simularse cierta interacción. Por esta razón, se corre el riesgo
de que los usuarios crean que ya es un producto terminado y listo para ser usado.
Para no crear falsas expectativas, es importante aclarar que no es así. Otro riesgo
es que los usuarios piensen que no se puede cambiar el diseño o no se atrevan
a cuestionar al diseñador. Un prototipo de alta fidelidad refleja detalles precisos de
cómo será la interfaz y la interacción con el sistema.
Un prototipo de alta fidelidad interactivo puede ser utilizado por un usuario
sin la ayuda del diseñador. Además, puede servir como instrumento para el
mercadeo de un producto. Por su nivel de detalle, puede servir como un insumo
para la etapa de codificación del sistema.

TÉCNICAS DE PROTOTIPADO
Existen varias técnicas de prototipado. Algunas de ellas hacen énfasis en la
presentación o apariencia de la interfaz, mientras que otras lo hacen en la
interacción. Sin embargo, todas son útiles, en mayor o menor medida, de acuerdo
con la complejidad del sistema y la incertidumbre que exista respecto a los

21
requerimiento. Algunas de las técnicas generan prototipos de baja fidelidad y las
otras, de alta fidelidad.
Las técnicas de prototipado son: bocetos, storyboards, prototipos de papel,
maquetas, maquetas digitales, storyboards navegacionales, vídeos y prototipos de
software. Cada una de ellas será explicada a continuación.
Los bocetos o sketches sirven para representar las primeras ideas sobre un
sistema. Son los que se utilizan en la primera iteración del DCU. Sirven para crear
las primeras impresiones del espacio del trabajo. Se realizan muy rápidamente, lo
que permite generar varias opciones de bocetos en muy poco tiempo. Se pueden
crear incluso con la presencia de usuarios.
Una maqueta digital es una representación de alta fidelidad que está entre
el prototipo de papel y la versión final de la interfaz. Su creación requiere el uso de
herramientas de software, de las cuales existen algunas especializadas para este
propósito. En una maqueta digital se incluyen detalles como colores, botones y
controles utilizados para ingreso y despliegue de datos en pantalla. Dado su alto
grado de detalle, los usuarios tienden a pensar que no se pueden modificar.
Un prototipo de software es una implementación ejecutable que reproduce
la funcionalidad de un sistema. Puede ser horizontal o vertical, dependiendo del
objetivo que se desee alcanzar. Por lo general, se implementan después de varias
iteraciones en el proceso de DCU, en el momento en que ya se han aclarado en
gran medida los requerimientos y se necesita saber cómo realmente se verá y
funcionará el sistema. Aunque los prototipos se desarrollan con la idea de ser
desechados al cumplir su objetivo, la apariencia de sistema terminado y el mayor
costo de elaboración hacen muchas veces que un prototipo de software deje de
ser desechable y se convierta en un prototipo evolutivo.
Un storyboard navegacional consta de una serie de dibujos que muestran cómo
será la navegación en el sistema. Un prototipo de este tipo es muy útil para
identificar si se está respetando el patrón de navegación que se había adoptado
previamente, o para verificar que acceder a cada opción del sistema no requiere
más de un número predeterminado de clics. Se puede utilizar esta técnica con las
pantallas que constituyen un prototipo de papel o uno de software.
Un storyboard navegacional puede servir para mostrar un escenario
particular de uso del sistema, que comprende solo una parte del prototipo creado
(ver Figura X), o bien para mostrar cómo es la navegación entre todas las
pantallas del prototipo (ver Figura Y).

22
Figura X. Storyboard navegacional que muestra uso de un escenario particular

Figura Y. Storyboard navegacional que comprende un prototipo completo

Tabla 1. Comparación entre las técnicas de prototipado
Técnica Propósito Costo Tiempo Fidelidad
Boceto Representar las Muy bajo Muy rápido Baja
23
 primeras ideas de un
sistema
Storyboard Mostrar cómo se usará Muy bajo Rápido Baja
un sistema para
alcanzar una tarea
Prototipo de Berificar si un usuario Muy bajo Rápido Baja
papel es capaz de realizar
sus tareas con la
interfaz propuesta
Maqueta Evaluar una parte Relativamente No tan Baja
física del sistema bajo rápido
Maqueta Presentar apariencia Bajo No tan Alta
digital del sistema rápido
Prototipo de Presentar apariencia Medio Lento Alta
software final del sistema y su
funcionamiento
Storyboard Mostrar cómo será la Bajo Rápido Bajo o
navegacional navegación alta
Vídeo Crear escenarios de Alto Muy alto Alta
futuro

HERRAMIENTAS DE PROTOTIPADO
Para la construcción de prototipo de baja fidelidad, los materiales y las
herramientas utilizados son sencillos y comunes: papel, cartulina, fichas, notas
post-it, tijeras y lápices. Cuando se trabaja en el diseño de un sistema para
dispositivos móviles, es conveniente utilizar caparazones de estos que permitan
tener una idea de las dimensiones que deberán tener los elementos de la interfaz.
Las maquetas digitales se pueden construir con herramientas de software
especializadas para la construcción de este tipo de prototipo. Estas herramientas
ofrecen plantillas para distintos dispositivos, como tabletas y teléfonos móviles. La
Figura X muestra la ventana principal de una herramienta especializada llamada
Pencil. A la izquierda se ve la columna con las colecciones de formas y controles
que se pueden utilizar. Una ventaja de que una aplicación cuente con formas y
controles predeterminados es que se facilita al diseñador apegarse al estándar de
una determinada plataforma. De esta manera, un usuario rápidamente se sentirá
familiarizado con el prototipo que ve si previamente ha tenido experiencia con la
plataforma.

24
Figura X. Ventana de la herramienta de prototipado Pencil
Para la creación de prototipos de software, existen aplicaciones
especializadas que ofrecen una serie de características que aceleran el desarrollo
de prototipos y permiten iterar muy rápidamente. Al seleccionar una aplicación
para crear prototipos, es importante considerar algunas características que hagan
agilicen la creación, tales como:
 Disponibilidad de plantillas para diferentes plataformas
 Capacidad para crear tanto prototipos de software como storyboards
 Disponibilidad de imágenes predefinidas para la creación de storyboards
 Posibilidad de integrar las pantallas del prototipo en un storyboard
 Capacidad para agregar anotaciones que sirvan para describir el prototipo
 Opción de ejecutar los prototipos
La Figura X muestra un ejemplo de una herramienta de software
especializada en la creación de prototipos. A la derecha se pueden observar
imágenes predefinidas que facilitan la creación de storyboards.

25
Figura X. Ejemplo de aplicación especializada en creación de prototipos
También se pueden utilizar herramientas de software no especializadas en
la creación de prototipos. Algunas de estas son aplicaciones para desarrollos
multimedios y lenguajes de programación. Algunas características que hacen de
una herramienta no especializada un buen candidato para crear prototipos como
son que:
 Permita implementar fácilmente interfaces gráficas
 Ofrezca funcionalidad para implementar eventos asociados a las
actividades realizadas con el ratón, el teclado e incluso táctiles.
 Cuente con opciones para navegación.
 Cuente con un lenguaje de programación que permita implementar la
funcionalidad requerida.
 Genere programas ejecutables para la plataforma en la que se desarrollará
el sistema.

26
3.5 EVALUACION DE APLICACIONES PARA
DISPOSITIVOS MOVILES

Las aplicaciones o productos de software cuando son lanzados al mercado se

espera que tengan cierto grado de aceptación entre los usuarios, ese grado va a
depender de las características particulares que cada usuario considere
importantes. Desde el punto de vista de la Ingeniería de Software (SE: Software
Engineering), una de las principales características que tiene que tener una
aplicación para ser exitosa entre los usuarios es que sea de calidad. Resulta
relevante para los desarrolladores de software poder medir esa calidad o realizar
pruebas de calidad a las aplicaciones construidas, pero para poder medir se
necesita saber qué es lo que hay que medir y cómo.

La calidad del software es el grado que el software posee de una combinación

deseada de atributos, esta combinación de atributos deberá ser claramente
especificada. Definir calidad de software para un sistema es equivalente a definir
una lista de atributos de calidad del software requeridos para ese sistema [1].
Utilizando esta definición se puede afirmar que lo que hay que medir más
puntualmente son ciertos atributos del software relacionados a la calidad. Dentro
de estos atributos uno de los considerados más importantes es la usabilidad, que
indica la facilidad con la que un usuario puede usar una aplicación de software.
Por lo tanto resulta de interés poder obtener una medida del grado de usabilidad
que tiene una aplicación. Debido a que en los últimos años el uso de dispositivos
móviles (teléfonos móviles, reproductores de audio portátil, asistentes personales
digitales, navegadores gps, tablets, cámaras digitales, etc.) se ha incrementado de
manera considerable, es importante disponer de metodologías y herramientas que
permitan realizar estudios de usabilidad específicos para aplicaciones
desarrolladas para estos tipos de dispositivos (aplicaciones móviles). Las
aplicaciones móviles son aquellas que fueron desarrolladas para ejecutarse en
dispositivos móviles. El término móvil se refiere a poder acceder a los datos, las
aplicaciones y los dispositivos desde cualquier lugar. Para desarrollar software de
este tipo se tiene que tener en cuenta ciertas restricciones que tiene el hardware
de estos dispositivos, como por ejemplo que son de dimensiones reducidas, tienen
bajo poder de cómputo, escasa capacidad de almacenamiento, ancho de banda
limitado, etc. Algunos ejemplos de aplicaciones móviles son: mapas y navegación,
búsqueda, juegos, mensajería, aplicaciones empresariales.

Los métodos y métricas actualmente utilizados para medir usabilidad fueron

creados para aplicaciones de escritorio, sin embargo estos pueden no ser

27
directamente adecuados o apropiados a entornos móviles [2]. Uno de los desafíos
consiste en identificar las variables adicionales relacionadas al ambiente de uso
(contexto móvil) que pueden impactar en la usabilidad de una aplicación móvil.

USABILIDAD

La usabilidad en general tiene que ver con la forma en que se usa algún elemento
(herramienta, dispositivo electrónico, etc.), es la facilidad con que se usa y si
permite hacer lo que se necesita. Particularmente la usabilidad de una aplicación
de software se refiere a la facilidad con que los usuarios pueden utilizar la misma
para alcanzar un objetivo concreto. Este nivel de usabilidad no puede medirse o
ser evaluado directamente, debido a que depende de diferentes factores.
Formalmente, la definición más utilizada o reconocida de usabilidad es la que se
expone en la norma ISO 9241-113, en la cual usabilidad se describe como el
grado con el que un producto puede ser usado por usuarios específicos para
alcanzar objetivos específicos con efectividad, eficiencia y satisfacción, en un
contexto de uso especifico [3]. La norma define como especificar y medir la
usabilidad de productos y aquellos factores que tienen un efecto en la misma;
también destaca que la usabilidad en terminales con pantalla de visualización es
dependiente del contexto de uso y que el nivel de usabilidad alcanzado dependerá
de las circunstancias específicas en las que se utiliza el producto. El contexto de
uso lo forman los usuarios, las tareas a realizar, el equipamiento (hardware,
software y materiales), así como también los entornos físicos y sociales que
pueden influir en la facilidad de uso de un producto.

En la norma mencionada anteriormente los atributos considerados son los

siguientes [4]:

Efectividad: Está relacionada con la precisión y completitud con la que los usuarios
utilizan la aplicación para alcanzar objetivos específicos. La calidad de la solución
y la tasa de errores son indicadores de efectividad.

Eficiencia: Es la relación entre efectividad y el esfuerzo o los recursos empleados

para lograr esta. Indicadores de eficiencia incluyen el tiempo de finalización de
tareas y tiempo de aprendizaje. A menor cantidad de esfuerzo o recursos, mayor
eficiencia.

Satisfacción: Es el grado con que el usuario se siente satisfecho, con actitudes

positivas, al utilizar la aplicación para alcanzar objetivos específicos. La
satisfacción es un atributo subjetivo, puede ser medido utilizando escalas de
calificación de actitud. Para poder especificar o medir la usabilidad, es necesario
descomponer los atributos y el contexto de uso en componentes medibles y
verificables. Las relaciones que existen entre el usuario, el producto, los atributos,
28
el contexto de uso y los objetivos que se quieren lograr se pueden observar en el
framework de usabilidad propuesto en la norma citada

Los siguientes son algunos de los atributos utilizados para medir el grado de
usabilidad de una aplicación de software:

Facilidad de Aprendizaje: La facilidad con la que los usuarios alcanzan objetivos

específicos la primera vez que utilizan la aplicación. La primer experiencia que
tiene los usuarios con un nuevo sistema es la de aprender a usarlo.

Memorabilidad: La facilidad para memorizar la forma de utilizar la aplicación y

alcanzar objetivos específicos, y la facilidad con que vuelven a utilizar la
aplicación después de un tiempo. La curva de aprendizaje debe ser
29
significativamente menor para un usuario que ya utilizó el sistema, que para uno
que es la primera vez que lo va a utilizar.

Errores: Los errores que comete el usuario al utilizar la aplicación y la gravedad de

los mismos. La aplicación debe producir la menor cantidad de errores posibles.
Si se producen, es importante que se den a conocer al usuario de forma rápida y
clara, además de ofrecer algún mecanismo para recuperarse de ese error.
Contenido: Aspectos relacionados a la distribución del contenido y de los formatos
utilizados para mostrar información al usuario.

Accesibilidad: Consideraciones tenidas en cuenta por posibles limitaciones físicas,

visuales, auditivas o de otra índole de los usuarios.

Seguridad: Capacidad para alcanzar niveles aceptables de riesgo. Disponibilidad

de mecanismos que controlan y protegen la aplicación y los datos almacenados.

Portabilidad: Capacidad de la aplicación de ser transferida de un entorno a otro

(diferentes plataformas).

Contexto: Relacionado a los factores o variables del entorno de uso de la

aplicación.

A la vez, los atributos de usabilidad, pueden ser clasificados en objetivos y

subjetivos . Los atributos objetivos pueden ser medidos a través de la interacción
del usuario con la aplicación, no dependen de la percepción del usuario; en
cambio los subjetivos están relacionados con el factor humano, se refiere a la
actitud del usuario hacia el uso de la aplicación, está vinculado a las emociones y
por lo tanto son más difíciles de medir y cuantificar.

Métricas de Usabilidad

Debido a que los atributos de una aplicación son conceptos abstractos, estos no
pueden ser directamente medidos. Para medirlos se les asocian distintas
métricas, por ejemplo, el atributo eficiencia puede ser evaluado mediante la
métrica que calcula el tiempo empleado por un usuario en terminar una tarea
específica. Una métrica (medida) es un valor numérico o nominal asignado a
características o atributos de un objeto computado a partir de un conjunto de datos
observables y consistentes con la intuición [8]. Una métrica debe cumplir con
ciertas características:

Debe tener características matemáticas deseables.Cuando una métrica representa

una característica que aumenta cuando se presentan rasgos positivos o que
disminuye al encontrar rasgos indeseables, el valor de la métrica debe aumentar o
disminuir en el mismo sentido.Cada métrica debe validarse empíricamente en una
30
amplia variedad de contextos antes de publicarse o aplicarse en la toma de
decisiones.

Una de las clasificaciones para las métricas, es dividirlas en estáticas y dinámicas

[9]. Las métricas estáticas son utilizadas para medir las características estáticas
de una aplicación, como el tamaño del código o la complejidad del mismo. Las
dinámicas permiten medir el comportamiento de la aplicación, se calculan con la
aplicación en ejecución. Cabe aclarar que las métricas no representan un fin por sí
mismas, estas revelan datos e información sobre la experiencia personal del
usuario cuando hace uso de una aplicación. La información obtenida de las
métricas nos ayuda a realizar un mejor análisis y tomar decisiones más acertadas
con respecto a la usabilidad de una aplicación. La Tabla 1 muestra atributos de
usabilidad y las métricas comúnmente asociadas a los mismos para poder
cuantificarlos.

31
Los modelos de usabilidad esencialmente están formados por la aplicación que se
va a evaluar y la interacción que el usuario tiene con esta para alcanzar sus
objetivos. La aplicación tiene definidos atributos, y métricas asociadas para medir
dichos atributos. Estos componentes se encuentran definidos dentro de un cierto
contexto de uso (Fig. 2).

32