Propuesta para Trabajo de Grado - …pegasus.javeriana.edu.co/.../entregables/Memoria_Alejan… · Web viewThe boom of mobile technologies and entrepreneurship around the world

CIS1330IS02Estrategia de Comercio Móvil integrando Técnicas de Recompensas Extrínsecas y Servi-

cios Basados en Localización

ALEJANDRO ARDILA SCHICKLER

PONTIFICIA UNIVERSIDAD JAVERIANAFACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SISTEMASBOGOTÁ, D.C.

2013-03

Pontificia Universidad Javeriana Memoria de Trabajo de Grado – APLICACIÓN PRÁCTICA

CIS1330IS02Estrategia de Comercio Móvil integrando Técnicas de Recompensas Extrínsecas y

Servicios Basados en Localización

Autor:

Alejandro Ardila Schickler

MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO DE LOS REQUISITOS PARA OPTAR AL TITULO DE INGENIERO DE

SISTEMAS

Director

Ingeniero Javier Francisco López Parra

Página web del Trabajo de Grado

http://pegasus.javeriana.edu.co/~ CIS1330IS02

Página iPreparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008

http://pegasus.javeriana.edu.co/~

Ingeniería de Sistemas ISTAR – CIS1330IS02


CARRERA DE INGENIERIA DE SISTEMASBOGOTÁ, D.C.Noviembre, 2013


CARRERA DE INGENIERIA DE SISTEMAS

Rector Magnífico

Joaquín Emilio Sánchez García S.J.

Decano Académico Facultad de Ingeniería

Ingeniero Jorge Luis Sánchez Téllez

Decano del Medio Universitario Facultad de Ingeniería

Padre Sergio Bernal Restrepo S.J.

Director de la Carrera de Ingeniería de Sistemas

Ingeniero Germán Alberto Chavarro Flórez

Director Departamento de Ingeniería de Sistemas

Ingeniero Rafael Andrés González Rivera

Página ii


Página iiiPreparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008


La aprobación del presente trabajo de grado se realiza por medio de co-rreo electrónico enviado por el director del trabajo de grado.

Página iv


Artículo 23 de la Resolución No. 1 de Junio de 1946

“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que se vean en ellos el anhelo de buscar la verdad y la Justicia”

Página vPreparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008


AGRADECIMIENTOS

-“Si no puedes tolerar llegar a cero, no deberías tratar de alcanzar el infinito.”-

Muchas personas han hecho posible que me mantuviera activo y con deseos de aprender du-

rante toda mi experiencia universitaria. En primera estancia, quiero agradecer a mi familia.

Todo su esfuerzo, ánimo y dedicación continua me motivaron a lo largo de la carrera para

esmerarme en mi trabajo. No lo hubiera podido hacer sin ustedes!

Igualmente, doy gracias a la Pontificia Universidad Javeriana por brindarme una excelente

educación y todo el apoyo que necesité durante el trabajo de grado. En especial quiero agra-

decerle al Ingeniero Hernando Hurtado por estar pendiente de mi proceso y por su inmediatez

en el préstamo de materiales de laboratorio. Si no es por usted, probablemente las pruebas no

hubieran sido tan buenas.

Siempre le voy a estar agradecido a mis amigos y personas que estuvieron conmigo en las

buenas y en las malas, causando en mí, un profundo sentimiento de curiosidad hacia el desa-

rrollo de software y la Ingeniería en general.

En especial, quiero agradecer a mi madre Johana Schickler por su inmenso amor hacia la vida

y su dedicación apremiante a sus seres queridos. Eres muy especial para mí y te dedico todo

este esfuerzo y el que está por venir.

Página vi


Contenido

TABLA DE ILUSTRACIONES..........................................................................................X

ÍNDICE DE TABLAS......................................................................................................XI

INTRODUCCIÓN.....................................................................................................14

I - DESCRIPCION GENERAL DEL TRABAJO DE GRADO............................16

1. OPORTUNIDAD, PROBLEMÁTICA, ANTECEDENTES..........................................161.1 Descripción del contexto.........................................................................................161.1. 1.2. Formulación del problema que se resolvió....................................................171.2. 1.3 Justificación......................................................................................................171.3. 1.4 Impacto Esperado.............................................................................................19

2. DESCRIPCIÓN DEL PROYECTO..........................................................................191.4. 2.1. Visión global....................................................................................................192.2. Objetivo general......................................................................................................202.3. Restricciones...........................................................................................................202.4. Fases Metodológicas o Conjunto de Objetivos Específicos...................................202.5. Método que se propuso para satisfacer cada fase metodológica...........................21

II - MARCO TEÓRICO............................................................................................24

1. MARCO CONTEXTUAL......................................................................................241.1. Language Quality Game (LQG) [10].....................................................................241.2. Foursquare [11]......................................................................................................25

2. MARCO CONCEPTUAL......................................................................................272.1. Comercio Móvil [13]..............................................................................................272.2. Business Model Canvas [9]...................................................................................292.3. Gamification...........................................................................................................312.4. Servicios Basados en Localización.........................................................................372.5. Metodología de Desarrollo Ágil.............................................................................40

III – DESARROLLO DEL TRABAJO....................................................................43

1. CONCEPTUALIZACIÓN.......................................................................................44

2. ANÁLISIS..........................................................................................................452.1. Rama de Administración de Empresas...................................................................472.2. Rama Ingeniería de Software..................................................................................48

Página viiPreparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008


3. DISEÑO.............................................................................................................493.1. Cliente Móvil...........................................................................................................493.2. Servidor Web...........................................................................................................50

4. IMPLEMENTACIÓN............................................................................................504.1. Manejo de Versiones...............................................................................................514.2. Plugin de Google Cloud Endpoints........................................................................524.3. Puesta en marcha....................................................................................................52

5. VALIDACIÓN.....................................................................................................53

IV - RESULTADOS Y REFLEXIÓN SOBRE LOS MISMOS.............................55

1. IDEA DE NEGOCIO.............................................................................................55

2. BUSINESS MODEL CANVAS..............................................................................562.1. Segmento de Clientes..............................................................................................562.2. Propuestas de Valor................................................................................................572.3. Canales de Distribución.........................................................................................572.4. Relación con los Usuarios......................................................................................582.5. Fuentes de Ingreso..................................................................................................592.6. Recursos Clave........................................................................................................592.7. Actividades Clave....................................................................................................592.8. Socios Clave............................................................................................................592.9. Estructura de Costos...............................................................................................60

3. FRAMEWORK DE GAMIFICATION......................................................................613.1. Objetivos de negocio...............................................................................................613.2. Tipos de Personas usando la Aplicación................................................................623.3. Comportamientos Clave Identificados....................................................................62

4. ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE....................................644.1. Requerimientos Funcionales...................................................................................644.2. Requerimientos no Funcionales..............................................................................664.3. Casos de Uso...........................................................................................................67

5. ARQUITECTURA DEL SISTEMA..........................................................................695.1. Modelo Funcional...................................................................................................705.2. Modelo de Despliegue.............................................................................................71

6. IMPLEMENTACIÓN DEL SISTEMA......................................................................736.1. Tomar Foto.............................................................................................................736.2. Ver evento...............................................................................................................746.3. Crear Evento...........................................................................................................756.4. Invitar Amigo..........................................................................................................76

7. RECOLECCIÓN DE DATOS Y VALIDACIÓN........................................................767.1. Selección de la Zona de Estudio.............................................................................777.2. Lectura de la Ubicación del Usuario......................................................................787.3. Análisis de los Resultados Documentados..............................................................81

Página viii


V – CONCLUSIONES, RECOMENDACIONES Y TRABAJOS FUTUROS....83

1. CONCLUSIONES.................................................................................................83

2. RECOMENDACIONES.........................................................................................85

3. TRABAJOS FUTUROS.........................................................................................85

VI - REFERENCIAS Y BIBLIOGRAFÍA..............................................................86

REFERENCIAS...............................................................................................................86

VII - ANEXOS............................................................................................................90

ANEXO 1. GLOSARIO....................................................................................................90

ANEXO 2. POST-MORTEM............................................................................................91Metodología propuesta vs. Metodología realmente utilizada...........................................91Actividades propuestas vs. Actividades realizadas............................................................91Efectividad en la estimación de tiempos del proyecto.......................................................91Costo estimado vs. Costo real del proyecto.......................................................................91Efectividad en la estimación y mitigación de los riesgos del proyecto.............................92

Página ixPreparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008


Tabla de Ilustraciones

Ilustración 1 - Dependencias del Comercio Móvil...................................................................15

Ilustración 2 - Fases metodológicas del proyecto....................................................................20

Ilustración 3 - Proceso de Desarrollo del Trabajo de Grado....................................................21

Ilustración 4 - Interfaz Gráfica del LQG..................................................................................24

Ilustración 5 – Definicion de Sistemas Inter-organizacionales del Comercio en Internet [15]..................................................................................................................................................26

Ilustración 6 - La Pirámide de los elementos de Gamification................................................31

Ilustración 7- Ejemplo de Sistemas de Retroalimentación en “Monopoly®”..........................32

Ilustración 8 - Flujo de desarrollo de un sistema con entregas incrementales (Sommerville, 2005).........................................................................................................................................40

Ilustración 9 - Principales Ramas de Investigación.................................................................43

Ilustración 10- Descripción Global de la Estrategia de Comercio Móvil................................45

Ilustración 11 - Casos de Uso del Sistema...............................................................................67

Ilustración 12 - Apreciación Global de la Arquitectura del Sistema propuesto.......................68

Ilustración 13 - Diagrama de Componentes.............................................................................69

Ilustración 14 - Diagrama de Despliegue.................................................................................71

Ilustración 15 - Flujo del CU Tomar Foto................................................................................72

Ilustración 16 - Flujo del CU Ver Evento................................................................................73

Ilustración 17 - Flujo del CU Crear Evento.............................................................................74

Ilustración 18 - Proceso de Recolección de Datos y Validación..............................................75

Ilustración 19 - Interfaz de Pruebas..........................................................................................76

Ilustración 20 - Dimensiones que atacó la estrategia de Comercio Móvil propuesta..............82

Página x


Índice de Tablas

Tabla 1 - Aplicaciones de Comercio Inalámbrico [16]............................................................28

Tabla 2 - Entregables por Fase Metodológica..........................................................................43

Tabla 4 – Formato de Validación de Confiabilidad.................................................................54

Tabla 5 - Propuestas de Valor..................................................................................................57

Tabla 6 - Canales de Distribución............................................................................................58

Tabla 7 - Comportamientos Clave...........................................................................................62

Tabla 8 - Requerimientos Funcionales.....................................................................................66

Tabla 9 - Requerimientos No Funcionales...............................................................................67

Tabla 10 - Convenciones utilizadas en los resultados de Confiabilidad del Proyecto.............79

Tabla 11 - Resultados de las Pruebas de Validación................................................................80

Tabla 12 - Resultados de Precisión de Métodos de Ubicación................................................81

Página xiPreparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008


ABSTRACT

The boom of mobile technologies and entrepreneurship around the world is changing the way

we build software. Therefore, it is important for the Software Engineer that works in this

environment, to understand the business idea and adapt it nimbly to a functional product. This

paper suggests, describes and implements a mobile commerce strategy that helps restructure

the process of creating a business model with characteristics of a startup company. The paper

also emphasizes in keeping balance between running a business with the implementation and

maintenance of software development itself.

RESUMEN

El gran auge de las tecnologías móviles y el emprendimiento empresarial alrededor del mun-

do está cambiando la forma de construir software. Por eso, es importante para el Ingeniero de

Sistemas que trabaje en este ambiente, comprender la idea de negocio y adaptarla un producto

funcional ágilmente. El presente trabajo propone, describe e implementa una estrategia de

comercio móvil que ayuda a agilizar el proceso de creación de un Modelo de Negocio con

características de una Empresa de Base Tecnológica. Asimismo, se hizo énfasis en mantener

el equilibrio entre la administración de una empresa con la implementación y mantenimiento

del software a implementar.

Página xii


RESUMEN EJECUTIVO

Actualmente, alrededor del mundo se está creando una cultura de emprendimiento tecnológi-

co que está brindando ingresos e innovación importantes al país. En el contexto Colombiano,

el Ministerio de Tecnologías de la Información y las Comunicaciones (MinTIC) está hacien-

do una fuerte apuesta en generar valor local por medio de desarrollos tecnológicos. Sin em-

bargo la poca experiencia e interdisciplinariedad que tiene el campo del emprendimiento

tecnológico conlleva a que existan pocas empresas de base tecnológica Colombianas que

posean un modelo de negocio sostenible y un mínimo producto viable aceptables.

El objetivo principal que resolvió el proyecto fue proponer una Estrategia de Comercio Móvil

tipo Negocio a Consumidor que facilitara al Ingeniero de Sistemas a crear una Empresa de

Base Tecnológica a partir de la construcción de un Modelo de Negocio sostenible y la ade -

cuada administración e implementación de Ingeniería de Software. También se consideraron

factores que ayudaron a estructurar la idea de negocio y darle posicionamiento en el mercado

del Software Móvil. Como valor agregado, se utilizaron técnicas de Gamification para hacer

la propuesta más atractiva y metodologías de desarrollo ágil para implementar un primer

prototipo funcional.

Para asegurar el cumplimiento del objetivo general se especificaron 7 objetivos específicos.

Estos fueron al mismo tiempo, el hilo conductor del proyecto:

Identificar fuentes de información que permitan hacer una buena práctica investigati-

va del proyecto.

Establecer características de la estrategia que contengan dinamismos, mecanismos y

componentes

Traducir la propuesta y la necesidad identificada en requerimientos de ingeniería de

software.

Traducir los requerimientos de software en una representación de componentes,

interfaces y datos.

Proponer una arquitectura sostenible tanto para el software como para las reglas de

negocio de la estrategia.

Página xiiiPreparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008


Desarrollar un prototipo funcional que represente los requerimientos planteados.

Validar la aplicación y evaluar la confiabilidad del sistema.

Previo al desarrollo del trabajo, se decidió incluir una fase de contextualización y conceptua-

lización del problema para que la ejecución del trabajo fuese coherente y respaldada de inves-

tigaciones pasadas. El proyecto entró en contexto al investigar empresas que hayan adoptado

técnicas de gamification exitosamente. Se investigaron los casos específicos de Microsoft con

su Language Quality Game y a la empresa de comercio móvil Foursquare. Se consultaron

diferentes fuentes bibliográficas incluyendo artículos científicos, libros, blogs y tutoriales

para tener conceptos claros acerca de lo que se iba a proponer. Las principales ramas de in-

vestigación fueron Gamification, Servicios Basados en Localización, Metodologías de Desa-

rrollo de Software y Comercio Móvil.

Durante el desarrollo del trabajo, se propuso una estrategia de Comercio Móvil que atacara 4

dimensiones que aportaran creación de valor y ventaja competitiva en una empresa. Las di-

mensiones fueron clasificadas en Factores Vinculantes y Factores Posicionales los cuales

permitieron, respectivamente, observar la estrategia desde perspectivas organizacionales y de

proposición de valor a sus clientes. Como resultado, la estrategia propuesta desarrolló por

medio de las metodologías ágiles, un Modelo de Negocio utilizando el Business Model Can-

vas y reforzó sus propuestas de valor agregándole dinámicas, mecánicas y componentes pro-

venientes de un análisis motivacional usando técnicas de Gamification. Luego, se extrajeron

los requerimientos utilizando plantillas certificadas por la Pontificia Universidad Javeriana y

se procedió a hacer el proceso de Ingeniería de Software.

En el proceso de Ingeniería de Software, se diseñó e implementó un primer prototipo funcio -

nal para hacer una prueba de concepto de la estrategia de comercio móvil. Se evaluaron dis -

tintas arquitecturas y aproximaciones de diseño para lograr cumplir los objetivos propuestos.

Finalmente se optó por utilizar las tecnologías que ofrece la Plataforma como Servicio de

Google App Engine y la Infraestructura como Servicio de Amazon Web Services. La integra-

ción de estos dos servicios permitió que se pudiera aislar las fotos de las bases de datos, ha-

ciendo el proceso transaccional más óptimo.

Página xiv


El prototipo aprovechó las bondades de su hardware incorporado para hacer un sistema basa-

do en localización que permitiera tomar fotos georeferenciadas en un evento. Para que el

software fuera controlable y mantenible se utilizó la metodología ágil de desarrollo orientada

a características.

El Modelo de Negocio tenía como una de sus restricciones clave el tener que tomar una foto

dentro de una zona específica. De esta manera, si el usuario se encuentra fuera de la zona de

aceptación, no se le permite tomar fotos. Para que el producto tuviera consistencia con el

Modelo de Negocio se hicieron pruebas de confiabilidad que permitieron evaluar la restric-

ción clave utilizando diferentes métodos de ubicación incorporados en el dispositivo móvil

(GPS, WiFi y 3G). Analizando las pruebas de confiabilidad, se concluyó que el producto aún

no puede ser confiable cuando los usuarios se encuentran en un evento cubierto utilizando 3G

como único método de localización.

Concluyendo el trabajo se lograron acatar todos los objetivos específicos abordando temas de

Liderazgo Tecnológico, Infraestreucutra Estretégica, Infraestrucutra Organizacional, Servicio

ofrecido y Mercado. Esto logró crear una estrategia de comercio móvil íntegra y completa.

Página xvPreparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008


INTRODUCCIÓN

Dentro del gran fenómeno de la Web 2.0, startups como Google, Facebook, Twitter, FourS-

quare o LinkedIn, etc. muestran grandes triunfos en el mundo de las Empresas de Base Tec-

nológica (EBT). Una característica de este tipo de empresas, es que sus modelos de negocio

son poco convencionales porque dependen rotundamente del contenido y tráfico de sus usua-

rios. Por consiguiente, para darle sostenibilidad al plan de negocios de una EBT, hay que

contemplar su posible exhibición a las economías de escala (o los denominados “grandes

mercados”) [1] [2]. Afortunadamente, para este tipo de empresas, el acceso a sus aplicaciones

está incrementando por el uso de las emergentes tecnologías móviles alrededor del mundo.

Los usuarios ya no dependen de una estación de trabajo para hacer consultas electrónicas

porque con los dispositivos móviles los resultados son más inmediatos y asequibles.

Sin embargo, el cambio de paradigma (de lo estacionario a lo móvil) no es del todo sencillo.

Es importante para el Ingeniero de Sistemas, entender la idea de negocio, desglosarla en com-

ponentes programables y adaptarla al contexto de lo móvil lo más rápido posible. Por eso es

necesaria una estrategia orientada a la Ingeniería de Software que migre una idea de negocio

de su concepción a su implementación.

El presente documento fue elaborado por Alejandro Ardila Schickler y dirigido por Javier

Francisco López Parra durante el periodo 2013-03. Este se inmiscuyó en el paradigma del

emprendimiento móvil, mostrando la evolución y desarrollo de una estrategia de comercio

móvil (m-Commerce) utilizando como herramientas principales técnicas de Gamification y

Sistemas Basados en Localización (LBS). Los principales capítulos del documento son:

Capítulo I: Descripción General del Trabajo de Grado

Se describe y justifica el desarrollo del Trabajo de Grado en General. Esto incluye la delinea-

ción del contexto, la formulación del problema que se resolvió y la descripción del proyecto

propuesto (incluyendo consideraciones, restricciones, entregas y metodologías de desarrollo

del mismo).

Página 16


Capítulo II: Marco Teórico

Orienta y pone en contexto al lector con toda la información pertinente al Trabajo de Grado.

En primer lugar está el Marco Contextual el cual explica, haciendo uso de antecedentes y

casos de estudio, el estado actual de las metodologías y principales ramas de investigación

propuestas. Luego, en el Marco Conceptual, se especifica más a fondo cada uno de los con-

ceptos que se requieren para entender el desarrollo del proyecto.

Capítulo III: Desarrollo del Trabajo

Especifica el aporte que brindó el cumplimiento de cada uno de los objetivos específicos del

proyecto. Dicho aporte se resume la investigación, razón de ser y desarrollo de las fases me-

todológicas del Trabajo de Grado.

Capítulo IV: Resultados y Reflexión sobre los mismos

Despliega los resultados obtenidos en las pruebas de validación del proyecto. Ofrece un análi-

sis sobre los mismos de tal manera que se pueda comprobar la viabilidad y fiabilidad del sis-

tema construido a lo largo de la experiencia.

Capítulo V: Conclusiones, Recomendaciones y Trabajos Futuros

Se exponen las conclusiones finales del trabajo, haciendo un análisis transversal de todas las

componentes que conformaron el presente Trabajo de Grado. Adicionalmente, con el propósi-

to de aclarar inconvenientes, consideraciones y comentarios generados durante el proceso de

elaboración se radican recomendaciones a tener en cuenta. También se proponen trabajos

futuros que pueden darle continuidad al presente trabajo.

Capítulo VI: Referencias y Bibliografía

Hace constancia de la investigación y respaldo que hubo en el presente trabajo.

Capítulo VII: Anexos

Finalmente, los anexos hacen referencia explícita a todos los documentos que se generaron

durante la ejecución del proyecto. Estos incluyen un glosario y un post-mortem.

Página 17

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


I - DESCRIPCION GENERAL DEL TRABAJO DE GRADO

Oportunidad, Problemática, AntecedentesDescripción del contexto

La emergente tendencia de los dispositivos móviles se está convirtiendo en una tendencia de

consumo masivo a nivel mundial. Se estima que para el 2016 el 80% de la población estadou-

nidense utilizará los dispositivos móviles para su quehacer diario [3]. Asimismo, existen ci-

fras muestran que entre Octubre de 2010 a Octubre de 2010 la tasa de apertura en disposit ivos

móviles ha incrementado un 300% [4]. Con estas cifras, es evidente deducir que investigar en

formas de comercio móvil se ha vuelto una necesidad para la industria del software.

Paralelo a estos acontecimientos, en Colombia están existiendo bastantes iniciativas por parte

del Gobierno e Instituciones Privadas que promueven el emprendimiento empresarial tecno-

lógico orientado a soluciones móviles [5]. No obstante, el mercado de aplicaciones móviles

Colombianas aún se encuentra en etapa temprana, lo cual origina una oportunidad de investi-

gación y desarrollo en el campo del comercio móvil.

Ilustración 1 - Dependencias del Comercio Móvil

Página 18

Comercio Móvil

Comercio Electrónico

Negocio a Consumidor

Otros

Dispositivos Móviles

Localización

Interacción


La Ilustración 1 resume las dependencias que existen en el comercio móvil. Cabe resaltar que

el comercio móvil hereda los objetivos y bases conceptuales de su antecesor, el comercio

electrónico. Sin embargo, este debe ser optimizado para que funcione en dispositivos móvi-

les, lo cual implica tener consideraciones en la localización del cliente y de su interacción con

el dispositivo (sus factores diferenciales). En resumidas cuentas, el presente trabajo de grado

propone una estrategia de comercio móvil que, fuera de mostrar la migración simple de una

idea de negocio a la elaboración de un prototipo funcional, ataque estos factores diferenciales

utilizando Sistemas Basados en Localización (LBS) y técnicas de Gamification (interacción).

Formulación del problema que se resolvió

Considerando las recientes iniciativas de invertir en Emprendimiento Tecnológico Nacional

por parte de entidades privadas y del Ministerio de Tecnologías de la Información y las Co-

municaciones (MinTIC) de Colombia, se elaboró el análisis, diseño y creación de un software

que parte de una idea de negocio. Los entregables y el ejecutable del prototipo funcional ad-

juntos a este documento, describen la forma en la que se resolvió la concepción de las estrate-

gia utilizando técnicas de motivación (con Gamification), LBS y de Desarrollo Ágil en Inge-

niería de Software. L pregunta generadora que circundó el desarrollo del Trabajo de Grado

fue:

¿Cómo diseñar una estrategia de comercio móvil que satisfaga las necesidades y motivacio-

nes de su público objetivo?

Justificación

Hay tres razones principales para esta iniciativa:

A. Justificación Institucional: A nivel institucional, hay dos justificaciones.

a. Nivel académico : Según el Acuerdo No 0066 del Consejo Directivo Univer-

sitario 22 de abril de 1992 de la Pontificia Universidad Javeriana [3] este

proyecto coincide con la misión de contribuir conocimiento a la solución de

“la deficiencia y la lentitud en el desarrollo científico y tecnológico.”

b. Nivel gubernamental : Según el Plan nacional de Desarrollo [4], uno des sus

principales objetivos es el Crecimiento Sostenible y la Competitividad:

Página 19



“Más que desarrollar estrategias para generar innovación en el aparato

productivo, se requiere impregnar una cultura de innovación y emprendi-

miento en todas las esferas del Estado incluyendo, por supuesto, el sector

empresarial, las universidades, y la sociedad civil.”

Viendo que el gobierno Colombiano y el Ministerio de Tecnologías de la

Información y Comunicaciones (MinTIC) han tomado reciéntemente iniciati-

vas de promover la innovación y emprendimiento empresarial, se cree que

también se puede aportar al gobierno a cumplir sus objetivos de creación de

empresa de base tecnológica. Fuera de impulsar al crecimiento del emprendi-

miento, ayuda a que el país tenga desarrollos tecnológicos substancialmente

importantes y por ende más inversión en este.

B. Justificación Profesional: La emergente tecnología móvil, aún es un camino dentro

de las ciencias de la computación que sigue en constante crecimiento. El boom de los

dispositivos móviles ha hecho que desarrollar aplicaciones para celular sea un reto

para el Ingeniero de Sistemas. Aunque ya existan aplicaciones similares, el trabajo de

grado pretende darle valor agregado a la aplicación práctica incorporando técnicas

que permitan descubrir el nivel de “enganche” que se le pueda dar a un usuario final.

El campo de Gamification es una oportunidad para el Ingeniero logre asociar concep-

tos de ingeniería de software con metodologías emergentes.

C. Justificación Personal: Dentro del marco personal, es retador desarrollar el trabajo

de grado. Fuera de la investigación requerida, se va a necesitar de:

a. Habilidades de Desarrollo Móvil: es sumamente importante capacitarse utili-

zando tecnologías backend como Plataformas como Servicio e Infraestructu-

ra como servicio y conocimientos de desarrollo móvil en plataforma Android

(Java).

b. Creatividad: Aunque Gamification tenga una serie técnicas y frameworks

definidos, el contexto de la estrategia es único a cada necesidad de negocio.

Página 20


De esta manera, el proceso creativo es indispensable para el buen desarrollo

de la aplicación.

Impacto Esperado

Para cuando culmine el proyecto, se espera:

Aumentar Cobertura de los Beneficiarios: El prototipo que se implemente logrará hacer las

operaciones básicas de un EMS junto a su interacción social y almacenamiento de memorias

del evento. Por parte del usuario sin interés económico, este se beneficiará porque encontrará

la experiencia divertida y útil para organizar sus memorias de eventos. En el caso de las em-

presas, se podrá generar comunidades que tengan intereses en común para así promocionar

eventos de diversas índoles a un público específico.

Impacto Social: Se pretende que esta aplicación sea un caso de éxito y que tenga repercusión

social en el país.

Impacto Tecnológico: Vale la pena aclarar que no se intenta hacer una aplicación multimi-

llonaria sino demostrar el reto que tiene hacer una aplicación útil en el contexto de la compu-

tación móvil.

Descripción del Proyecto4.1. Visión global

El presente proyecto muestra la elaboración de una estrategia de comercio móvil de una idea

de negocio y un primer prototipo funcional que retrate las herramientas que se utilizaron para

llevar a cabo la estrategia.

La estrategia se respaldó con técnicas de Gamification que permitieron deducir dinámicas,

mecánicas y componentes útiles para generar atracción e interacción del cliente con la aplica-

ción. En compensación, el prototipo se dividió en dos partes: la aplicación móvil, y un servi-

dor web. La aplicación móvil se encargó de utilizar los sensores GPS y la cámara integrada

de un dispositivo móvil para darle vida a la idea de negocio generada en la estrategia. Por otra

Página 21



parte, el servidor web maneja la concurrencia y distribuye la carga del sistema logrando certi -

ficar atomicidad en transacciones.

4.2. Objetivo general

Proponer una estrategia de comercio móvil tipo Negocio a Consumidor que utilice Servicios

Basados en Localización (LBS) orientada a técnicas de Recompensas Extrínsecas en el con-

texto Colombiano.

5. Restricciones

Dada la naturaleza y alcance del presente Trabajo de Grado, se tuvieron en cuenta restriccio -

nes que permitieron mitigar riesgos y tomar decisiones durante la experiencia. Las restriccio-

nes con más trascendencia en el desarrollo del proyecto son:

Todas las fases metodológicas en el presente trabajo de grado se tendrán que cumplir

entre el 21 de Julio de 2013 al 19 de Noviembre de 2013 (4 meses aproximadamen-

te).

La construcción del software móvil se hará únicamente para dispositivos móviles con

sistema operativo Android 4.0 o superior.

Los datos que se almacenen en el servidor no pueden superar la capacidad gratuita

que establecen los proveedores de servicios en la nube utilizados [6] [7].

Los dispositivos móviles en los que se hicieron las pruebas tienen que ser recursos

universitarios o personales.

6. Fases Metodológicas o Conjunto de Objetivos Específicos

El proyecto se dividió en 5 fases metodológicas. Cada una fue clasificada con el propósito de

que fueran temáticas distintas y, en lo posible, independientes una de la otra.

Página 22


Ilustración 2 - Fases metodológicas del proyecto

Cada una de las fases enunciadas en la Ilustración 2 contiene de 1 a 2 objetivos específicos

cumplidos en el proceso de desarrollo del Trabajo de Grado.

7. Método que se propuso para satisfacer cada fase metodológicaPara satisfacer cada fase metodológica se propuso el siguiente proceso utilizando notación

BPMN [8].

Página 23

Identificar fuentes de información que permitan hacer una buena práctica investigativa del proyecto.Conceptualización

Establecer características de la estrategia que contenga dinamismos, mecanismos y componentes de Gamifiction.Traducir la propuesta y la necesidad identificada en requerimientos de ingeniería de software.

Análisis

Traducir los requerimientos de software en una representación de componentes, interfaces y datos.Proponer una arquitectura sostenible tanto para el software como para las reglas de negocio de la estrategia.

Diseño

Desarrollar un prototipo funcional que represente los requerimientos planteados.Implementación

Validar la aplicación y evaluar la confiabilidad del sistema.Validación



Ilustración 3 - Proceso de Desarrollo del Trabajo de Grado

Conceptualización

El método utilizado es basado en estudio exploratorio recurriendo a varios medios de acceso.

Se hizo una búsqueda de referencias utilizando herramientas tecnológicas y cuando hubo

textos extensos se recurrió a documentarlos en forma de resumen.

Página 24


Análisis

Extrae una idea de negocio principal utilizando el Business Canvas Model [9] y después este

lo somete a un análisis con técnicas de gamification. De esta forma se retroalimenta la idea de

negocio para que encajara con las dinámicas y mecánicas extraídas de estas técnicas. Luego,

a partir de la idea de negocio refinada, se extraen los principales requerimientos funcionales y

no funcionales de la aplicación.

Diseño

Se plantea una arquitectura inicial del sistema que después es interpretada por su diagrama de

clases. El diseño del modelo funcional y de despliegue se hace en paralelo y se buscan los

principales componentes, nodos y clases del sistema a implementar. Puede haber casos en los

que la arquitectura se puede reconsiderar.

Implementación

La implementación del prototipo consiste en ir modificando en paralelo tanto la aplicación

móvil como la aplicación servidor. En dado caso de que se implementen clases y componen-

tes que no fueron considerados en la arquitectura inicial del sistema, esta se vuelve a diseñar.

La implementación es probada en máquinas locales para depurar errores de aplicación y lue-

go es desplegada en sus respectivos nodos para depurar errores de conexión y configuración.

Validación

Se diseñan pruebas de aceptación del producto y se hace la recolección de datos en una zona

previamente elegida. Luego los resultados se someten a un análisis para ser, finalmente, con-

cluidos.

Página 25



II - MARCO TEÓRICO

Marco Contextual

En la presente sección se realiza una presentación resumida de los principales casos de éxito

de algunas aplicaciones que han incorporad Gamification dentro de su estrategia de negocio

para mantener motivado a su público objetivo. Los testimonios expuestos a continuación,

provienen de empresas de gran impacto en el mundo tecnológico en los últimos años. Se pre-

tende contextualizar el presente documento asimilando las estrategias que utilizaron.

1.1. Language Quality Game (LQG) [10]

El presente caso de éxito involucra a Ross Smith, Director de Pruebas del Departamento de

Software Testing (Pruebas de Software) en Microsoft Corporation®. Su equipo a cargo, por

la inmensa popularidad mundial de Microsoft, obtenía grandes cantidades de bugs lingüísti -

cos en sus diferentes versiones a lo largo del globo. Hablando en términos de productividad

empresarial y Retorno de Inversión (ROI), la alta tasa de errores lingüísticos que manejaba el

Departamento, hacía que no fuera una tarea sencilla reducir los costos de una forma efectiva.

Es por eso que decidieron diseñar el Language Quality Game [10] mostrado en la Ilustración

4 el cuál permitía a través de técnicas de juegos, mezclar comportamientos de ciudadanía

organizacional con productividad y gestión de calidad. Aprovecharon la oportunidad de tener

trabajadores con diferentes lenguas nativas y diseñaron un software interactivo con Gamifi -

cation que accediera a todo su recurso humano para detectar errores lingüísticos en su so-

ftware propietario.

Página 26


Ilustración 4 - Interfaz Gráfica del LQG [10]

La implementación del juego fue bastante sencilla. Consistió en utilizar una base de datos

con imágenes extraídas automáticamente del código fuente en fase prueba del equipo de

desarrollo en Microsoft. Las imágenes son expuestas al usuario (el jugador) y se enriquecen

incluyendo metadatos acerca del lenguaje utilizado. Las imágenes son agrupadas en grupos

de 25 para darle un sentimiento de completitud al jugador. De esta forma, el jugador puede

utilizar el mouse para indicar el error que se encuentra dentro de la imagen e indicar por

medio de botones si se encuentra un “bug lingüístico” en la imagen o no.

Oportunamente, la estrategia de Ross Smith fue todo un éxito teniendo un 100% de partici-

pación de 900 empleados y detectando 170 bugs del sistema para todos los 36 lenguajes que

maneja la compañía [10]. El LQG logró integrar las habilidades computacionales de su pú-

blico objetivo en un juego productivo que dio resultados que no serían posibles o efectivos

en términos de costo si se implementaran con procesos de negocio tradicional.

1.2. Foursquare [11]

Foursquare es una aplicación de networking social basada en localización. Fue creada en el

2009 por Denis Crowley y Naveen Selvadurai y actualmente está valorizada por más de 800

Página 27



millones de dólares con más de 20 millones de usuarios registrados en todo el mundo [12]. La

aplicación consiste en proveer a sus usuarios información acerca de los diferentes sitios que

se encuentran alrededor de él. El usuario puede hacer check-in en un lugar aledaño utilizando

su teléfono móvil, mensajes de texto o el portal web. Cada check-in le otorga al jugador pun-

tos y en casos muy específicos medallas por su buena fidelidad con el lugar. La aplicación

logra afianzar la relación entre la empresa y el cliente motivando al usuario a interactuar y

descubrir sus lugares de ocio favoritos. El enriquecimiento de las estadísticas que proveen los

usuarios a las empresas es de gran utilidad para medir la actividad y compromiso del cliente

promedio.

La aplicación utiliza sistemas de información basados en localización para hacer búsquedas

acorde a la posición actual del usuario. Además utiliza componentes sociales y de juegos para

preservar el compromiso del usuario con la aplicación. La mecánica principal de Foursquare

consiste en coleccionar alcaldías, puntos y medallas. Las alcaldías son un título otorgado por

establecimiento el cual muestra a todos sus acudientes quién es el usuario que más ha hecho

check-in en el establecimiento. Los puntos son otorgados cada vez que un usuario hace che-

ck-ins en sitios específicos y las medallas se dan en casos especiales para felicitar al jugador.

Por ejemplo, cuando un usuario ha hecho más de 100 check-ins o cuando cambia de ciudad.

Cada uno de los componentes y mecánicas de juego son una forma de retroalimentar (de for-

ma sencilla) al usuario de la actividad que ha hecho a lo largo de la experiencia. Además

permite comparase con otros jugadores que de alguna forma son relevantes para el usuario

(como amigos o alcaldes).

Foursquare ha sido una de las empresas de mayor trascendencia en el mundo tecnológico.

Aprovecha las bondades de ubicuidad que brinda los dispositivos móviles para aumentar el

mundo de sus usuarios con una interfaz divertida que además de prometer gratificación del

cliente, manifiesta una utilidad para que una empresa monitoree la actividad de su estableci-

miento en tiempo real.

Página 28


Marco Conceptual 2.1. Comercio Móvil [13]

El comercio móvil es una nueva derivación del comercio electrónico que involucra a los dis-

positivos móviles dentro de las consideraciones de un negocio rentable. Según el Estudio de

Skiba et al. [14], el comercio móvil (o m-commerce) se define como

“el uso de dispositivos móviles para comunicar, informar, tramitar y usar texto y datos a

través de una conexión a redes públicas o privadas”.

El comercio móvil es una evolución del comercio electrónico que explota las aplicaciones y

servicios para convertirlos en modelos de negocio asequibles para dispositivos móviles con

acceso a internet. Aunque el modelo de negocio del comercio móvil difiere en algunos aspec-

tos del modelo de negocio tradicional del comercio electrónico, existen algunos conceptos

claves que aún aplican para el desarrollo de este.

2.1.1. Sistemas Inter-organizacionales

Dentro del comercio en internet, existen 4 sistemas inter-organizacionales:

Ilustración 5 – Definicion de Sistemas Inter-organizacionales del Comercio en Internet

[15]

Página 29

B2CLa empresa atiende las necesidades del cliente

minorista

B2BLa empresa cubre las necesidades de otros

negocios

C2BSuple las necesidades de

otros negocios a través de sus clientes.

C2CLa empresa facilita la

comunicación y comercio entre clientes minoristas.



La Ilustración 5 define a grandes rasgos la característica principal de los diferentes sistemas

inter-organizacionales. Al momento de escoger uno de estos, se orienta la Idea de Negocio y

se logran identifican las fuentes de ingresos que va a tener el Modelo de Negocio

Tabla 1 - Aplicaciones de Comercio Inalámbrico [16]

La Tabla 1 describe en términos generales los tipos de aplicaciones que se pueden crear se-

gún su sistema inter-organizacional y su tipo de empresa. Como los sistemas C2B son poco

conocidos y difíciles de implementar, la Tabla 1 los obvia dentro de su clasificación. En el

presente trabajo de grado se creó una aplicación que comercializa contenido basado en nece-

sidades (needs based content).

2.1.2. Ventajas del Comercio Móvil [16]

El comercio móvil incrementa la cantidad de usuarios conectados a una plataforma o servicio.

Las principales ventajas que provee son:

Es enfocado a las economías de escala, lo cual asegura que los servicios pueden ser

comprados a precios asequibles a todo tipo de empresa o cliente.

Página 30


Provee perfiles de consumo. Por lo general los dispositivos móviles tienen un único

dueño. Esto permite que la información suministrada ayude a detectar los perfiles de

consumo de un usuario lo cual es bueno para marketing dirigido.

Aprovecha la localización variable del cliente para brindar experiencias aumentadas

y conscientes de ubicación (location aware).

Business Model Canvas [9]

El Business Model Canvas (BMC) es una reciente metodología ágil de administración de

negocios que permite describir los 9 pilares de un modelo de negocio.

I. Segmentación de Clientes

Identificando el nicho del mercado que quiere atacar el modelo de negocio, se tiene

que tener un entendimiento general de las necesidades, comportamientos y demás

atributos de los tipos de cliente que van a consumir están involucrados. que quiere

alcanzar el modelo de negocio. Esto incluye entendimiento del perfil de usuarios que

van a utilizar el producto o servicio.

II. Propuestas de Valor

Resuelve los problemas o necesidades identificadas por cada segmento del cliente.

Debe existir por lo menos una propuesta de valor por segmento ya que estas son los

identificadores de una empresa. Una empresa que contenga los mismos segmentos de

clientes pero diferentes propuestas de valor de otra empresa, puede ser el factor deci-

sivo para que un cliente decida optar por cambiar de empresa.

III. Canales de Distribución

Describe la comunicación entre los segmentos de clientes y las propuestas de valor.

Estos incluyen métodos de distribución y comunicación. Estos incluyen posiciona-

miento, soporte y producto.

IV. Relación con los Usuarios

Página 31



Aunque ya se tenga la forma en la que se va a comunicar la propuesta de valor con un

segmento del mercado, se necesitan describir el tipo de relaciones que los clientes

van a tener con la empresa. Estos pueden variar desde auto servicio a procesos auto-

matizados.

V. Fuentes de Ingresos

Describe cómo se generan las fuentes de ingresos de la empresa. Esto debe conside-

rar el valor que un cliente está dispuesto a pagar. A grosso modo, lo ideal es generar

fuentes de ingresos por cada segmento de clientes, sin embargo en modelos de nego-

cios freemium, puede no existir dicha relación.

VI. Recursos Clave

Enuncia los diferentes activos que se deben tener en la empresa para que el modelo

de negocio sea implementado. Cada recurso clave puede ayudar a generar una o más

propuestas de valor. Los recursos pueden ser físicos, intelectuales financieros o hu-

manos.

VII. Actividades Clave

Especifica las actividades más importantes donde se cree, itere e innove la idea de

negocio a lo largo del tiempo. Cada actividad ayuda a generar propuestas de valor e

innovación empresarial.

VIII. Socios Clave

Establece cuáles son las empresas con las que se pueden hacer alianzas estratégicas,

modelos de inversión o tercerización de servicio e infraestructura.

IX. Estructura de Costos

Las propuestas de valor, los canales de distribución, el manejo de relaciones con los

clientes y las fuentes ingresos son directamente dependientes de la estructura de cos-

tos. En mayoría de los casos cuando las actividades, recursos y socios clave son defi -

nidos es más fácil estructurar los costos de la empresa.

Página 32


El BMC tiene una didáctica poco convencional que simplifica y agiliza el proceso de crea-

ción de modelo de negocio a partir de un lienzo y notas adjuntas a este. Las notas tienen un

código de color para poder diferenciar la relación entre las diferentes componentes en el lien-

zo.

2.3. Gamification

La naciente teoría de Gamification sustenta que empleando técnicas de diseño de juegos a

una aplicación o proceso, se puede crear compromiso implícito por parte del usuario y ade-

más proveer datos relevantes que ayuden a la interacción hombre máquina. Gamification

trabaja además, con técnicas de psicología como la Teoría de la Autodeterminación [17] para

distinguir los tipos de motivación que puede tener un usuario (o jugador) y cómo estos pue-

den aportar al compromiso con una actividad.

La PhD y Consultora de Diseño de Juegos Jane McGonigal [18] en su New York Bestseller,

“Reality Is Broken” estudia la forma en la que las dinámicas de juego ayudan a fomentar

motivación en sus jugadores, para así convertirse, en seres más auto sostenibles y felices. La

estructura de un juego ofrece los objetivos, reglas y sistemas de retroalimentación, suficien-

temente enriquecidos, para motivar a sus usuarios a ejercer una actividad específica.

“Comparado a los juegos, la realidad es demasiado sencilla. Los juegos nos retan

con obstáculos voluntarios y nos ayudan a potencializar nuestras fortalezas persona-

les” [19]

Viendo los beneficios que brindan las técnicas de motivación de los juegos a sus jugadores,

se plantea que dichas técnicas pueden aplicarse a contextos colaborativos (Web 2.0) que

como propósito sea dirigirlas a contextos ajenos a los juegos. Por ejemplo, la optimización de

un proceso, la educación y aprendizaje, el desarrollo sostenible, el marketing, etc. De esta

forma, nace el Gamification.

“Gamification” es una corriente nueva, y por eso es que aún, no se encuentra una definición

oficial de la palabra. Sin embargo, se cree que Kevin Werbach logra encapsular una defini -

ción precisa y completa:

Página 33



Gamification es “El uso de elementos de juego y técnicas de diseño de juegos en contex-

tos ajenosa los juegos”. [20]

2.3.1. Conceptos Básicos

La Ilustración 6, muestra la “Pirámide de los Elementos de Gamification”. Esta logra clasifi-

car y poner en jerarquía los elementos principales que giran en torno a una estrategia de Ga-

mification. La Pirámide denota 3 elementos: dinámicas, mecánicas y componentes. Cabe

resaltar, que aunque haya muchas ramificaciones por cada elemento, la idea no es incluirlos

todos, sino escoger aquellos que encajen en los comportamientos que se quieran motivar en la

estrategia.

Ilustración 6 - La Pirámide de los elementos de Gamification

Dinámicas

Son aquellas que crean la forma de interacción con el usuario. Hay gran cantidad de dinámi-

cas; entre ellas sobresalen el reconocimiento, el liderazgo, la organización, etc. [21]. Una

dinámica puede ser, por ejemplo, restricciones de tiempo para hacer un reto más difícil o

incentivar el compañerismo permitiendo que las personas compartan contenido en la aplica-

ción. Una característica importante de las dinámicas es que describen el comportamiento de

Página 34

Dinámicas

Mecánicas

Componentes


las mecánicas de una manera secuencial y cíclica. Para ilustrar los comportamientos cíclicos

se utilizan “sistemas de retroalimentación”.

Ilustración 7- Ejemplo de Sistemas de Retroalimentación en “Monopoly®” [17]

En la Ilustración 7, se muestra un sistema de retroalimentación en el famoso juego de Mono-

polio®. Es inevitable observar que el nivel de abstracción de este mapa mental muestra diná-

micamente la interacción de los escenarios adscritos a los casos de uso del juego. Se intentará

aplicar este concepto al desarrollo de la aplicación.

Mecánicas

Son todas aquellas acciones, comportamientos y mecanismos de control que son otorgados al

usuario dentro del contexto de la aplicación. Un ejemplo pueden ser las mecánicas de las

cartas, que son revolver y repartir, las cuales aporta al elemento dinámico de “bluffing”. Su

principal característica es que describe los componentes particulares del juego a nivel de

representación de datos y algoritmos a utilizar. De esta manera, en términos de Ingeniería de

Software se cree que hay una conexión entre las mecánicas de juego y la definición de casos

de uso y modelación de datos.

Componentes

Son instanciaciones de las mecánicas y dinámicas de la estrategia de Gamification. Estas

pueden ser las cartas, los dados, los puntos otorgados, etc. Muchos autores como Kevin Wer-

bach y Gabe Zichermann especifican los principales componentes para gamificar un sistema.

Como son tantos y hay tantas subclasificaciónes se va a remitir a las definiciones de los deno-

minados PBLs o Puntos, Medallas y Podios (Points, Badges & Leaderboars).

Página 35



Puntos (Points)

Utilizados para motivar a las personas a hacer una acción por medio de la colecta de estos. Su

forma simple de retroalimentación, le dice al jugador qué tan bien está haciendo la tarea. En

dado caso de que la tarea sea muy larga o se desea que haya una repetición de esta, se utilizan

niveles para darle un sentido de completitud a la sub-actividad. Una forma ilustrativa de re-

presentar los niveles es por barras de progresión. Los sistemas de puntos, además de motivar

a un jugador, logran ser herramientas de medición supremamente efectivas para los diseñado-

res de la estrategia.

Medallas (Badges)

Es una representación visual de un logro en la estrategia gamificada. Un sistema de medallas

bien diseñado debe proveer una meta definida, un sentido de identificación con los otros que

la han obtenido y que sean capaces de producir emociones positivas cuando se ganen. Estos,

en un segundo plano, son una clase de marcador visual de la reputación del usuario. Por ende

es una forma de incentivar el sentimiento de “ser reconocido”.

Podios (Leaderboards)

La lista de los mejores es una de las componentes de juego que más causa problemas. Pueden

ser muy desmotivantes ya que el jugador al ver que no está dentro de los primeros de la lista

no está seguro de seguir haciendo la tarea sabiendo que ya nunca va a ser el mejor. Algunos

estudios han revelado que incorporar la lista a un ambiente de negocio empeora el desempe-

ño.

2.3.2. Creación de Estrategia de Gamification

Como se dijo antes, el Gamification es una técnica tan emergente, que aún no se tienen esta -

blecidas metodologías oficiales para certificar éxito, administración y control sobre la estrate-

gia. Sin embargo, investigadores como Kevin Werbach y Dan Hunter en su libro “For the

Win” [22] establecen un framework para guiar al ejecutor de la estrategia por una serie de

pasos clave a considerar. Por más de que el framework logre explicar efectivamente los pasos

a seguir, la técnica no logra sobrepasar el umbral de la ambigüedad (hablando en términos

ingenieriles). De esta manera, basándose en dicho framework, se definirán los pasos a seguir.

Página 36


Luego, por cada paso, se harán propuestas metodológicas que intenten romper la brecha de

tergiversación que hay en la Estrategia de Gamification desarrollada.

Paso 1: Definir Objetivos de Negocio

Para empezar, se deben definir las metas principales del negocio o estrategia que se va a im-

plementar. Las metas no pueden ser ambiguas y tienen que ser dirigidas exclusivamente a

mejorar el desempeño del proceso que se quiere hacer, como por ejemplo, incrementar la

retención de clientes, crear lealtad de marca, o mejorar la productividad de un empleado.

Aunque el Gamification sea efectivo, puede generar resultados que no necesariamente ayuden

de la manera que se esperaba. Es por esto que, para prevenir esto, hay que hacer una lista de

todos los objetivos potenciales. Después, se vuelve a repasar la lista para simplificar los obje-

tivos, de tal manera que sólo se describan los fines y no los medios del sistema.

Paso 2: Delinear comportamientos clave

Teniendo definidos los objetivos, se identifican los comportamientos clave que aporten al

acatamiento de estos. El Gamification corre en algoritmos y software; es por eso que, fuera de

describir los comportamientos clave, se debe encontrar una forma que se puedan medir. Unos

ejemplos de métricas pueden ser los mismos componentes de juego, como los puntos y meda-

llas obtenidas. Sin embargo, también se pueden derivar medidas exclusivas para los diseñado-

res de la estrategia, como el nivel de compromiso1, o el porcentaje de mujeres que están utili-

zando la aplicación.

Paso 3: Describir a los Jugadores

No todos los usuarios son iguales. Esto, en Gamification, abre las puertas a identificar dife-

rentes escenarios que motiven a los usuarios. Si se logra hacer una segmentación efectiva de

los jugadores más dinámicas se podrán crear. Richard Bartle, PhD. en inteligencia artificial

crea el test de Bartle para la psicología de un jugador. Este asegura factorizar el nivel de

compromiso de un usuario. Por más de que estandarice a los jugadores, no quiere decir que se

1 Más conocido como DAU/MAU que establece la proporción de Usuarios Diarios Activos y Usuarios Mensuales Activos. Esto muestra la probabilidad de que un usuario esté comprometido con la experiencia [46]

Página 37



tenga que seguir este esqueleto al pie de la letra. Por eso, es importante describir a cada tipo

de jugador lo más preciso que se pueda.

A cada segmento de jugadores encontrado se le necesita encontrar una historia y describirla.

¿Cuáles son sus esperanzas y miedos? , ¿Sus talentos?, ¿Sus hobbies? Tener un número redu-

cido de jugadores en la experiencia quiere decir que se entiende más a las personas y que el

sistema va a ser atractivo para diferentes tipos de audiencias.

Por último, hay que establecer el Ciclo de Vida del Jugador. Explica cómo se le van a dar

oportunidades al jugador a medida que va adentrándose más en la estrategia. Esto le quita

monotonía a la experiencia y guía al jugador a un nivel de experticia. Las fases que común-

mente se utilizan son la de novatos, regulares y expertos. Los novatos por lo general necesitan

acompañamiento en la experiencia mientras aprenden cómo funciona la mecánica del juego.

Los jugadores regulares ya saben cómo funciona el juego y se encuentran dentro de la expe-

riencia. Estos son los más importantes ya que necesitan sentirse motivados para continuar en

“el juego”. Es por eso que se necesita brindar al jugador con novedades para que siga hacien-

do actividades en la aplicación.

Paso 4: Definir Ciclos de Actividad

Es de vital importancia aclarar que un juego no es siempre lineal (o por lo menos los buenos

juegos). Tomemos como ejemplo a alguien que publica una foto en Facebook, y un usuario

comenta sobre la foto, dándole la opción al “jugador” de poder responder a este comentario y

por ende quedarse en ciclos de actividad a partir de la primera acción que se hizo.

Hay dos tipos de ciclos que se pueden desarrollar. Los Bucles de Compromiso y las Escale-

ras de Progresión. Los Bucles de Compromiso describen, a un nivel micro, lo que deben

hacer cada uno de los jugadores, por qué lo hacen y lo que hace el sistema en respuesta a esa

acción. El elemento clave dentro de este proceso (y lo que cierra el ciclo) es el llamado a la

acción o “trigger”. Es lo que hace a los juegos unos motivadores tan efectivos. Por el otro

lado, las Escaleras de Progresión tienen un papel más macro. Reflejan el cambio de la expe-

riencia de juego a lo largo del tiempo. El primer componente de la escalera de progresión es

“onboarding” lo cual significa que el jugador tiene una clase de guía en el juego para que

Página 38


vaya entendiendo la mecánica de este mismo. También existen los periodos de descanso que

ayudan a los jugadores a notar variabilidad dentro de la experiencia.

Paso 5: Verificar que la Estrategia sea Divertida

Antes de empezar a implementar la estrategia con elementos de juego y demás características

hay que preguntarse: ¿Es la experiencia divertida? ¿Los jugadores participan en el juego vo-

luntariamente? En dado caso de que la experiencia tenga recompensas tangibles como des-

cuentos o puntos redimibles en bienes virtuales, es de gran ayuda verificar el nivel de com-

promiso del usuario quitándolos de la experiencia ya hacer las mismas preguntas menciona-

das anteriormente.

Paso 6: Desplegar herramientas adecuadas para el Trabajo

En este paso se tienen que extraer de los demás pasos, a manera de lista, las mecánicas y

componentes adecuados que permitan que la experiencia esté Gamificada. Werbach aconseja

que los ciclos de actividad determinados en el paso 4, son un perfecto esqueleto para empe-

zar a construir el sistema.

2.4. Servicios Basados en Localización2.4.1. Propósito & Definición

El término “Servicios Basados en Localización” o LBS denota la integración entre localiza-

ción geogreferenciada y la noción de servicio. La cantidad de aplicaciones que cubren el

espectro de los LBS son inumerables. Entre estas se encuentran los servicios en seguridad

perimetral, de optimización de rutas, marketing móvil y control de tráfico. Es claro ver cómo

un sistema que utilice geolocalización puede ayudar a tener una experiencia mucho más real e

interactiva con el usuario. Con la emergente tecnología móvil, los LBS tienen gran aceptación

dentro del desarrollo de software para dispositivos con GPS y otras tecnologías como Blue-

tooth o Wi-Fi. Haoshen Huang, resalta el impacto de incorporar los Servicios Basados en

Localización con el pensamiento colectivo de la Web 2.0.

“La Web 2.0 le permite a los usuarios hacer más que sólo extraer información. Los usuarios

están comprometidos a contribuir sus datos.” [23]

Página 39



Cuando se incorpora el pensamiento colaborativo de la Web 2.0 con tecnologías basadas en

localización, se pueden obtener datos compartidos por la comunidad a ritmos acelerados.

En el caso de la aplicación a desarrollar, es importante denotar los conceptos básicos que un

LBS brinda. Como es una aplicación de interacción social y contiene mecanismos parecidos a

las técnicas de marketing dirigido, se va a analizar los diferentes servicios de retroalimenta-

ción de los LBS y se decidirá para qué son útiles en el contexto del presente Trabajo de Gra -

do.

2.4.2. Servicios Push

Los servicios push proveen información a la terminal móvil de una manera autónoma. Es

decir, el usuario no tiene que solicitar el envío de información para que esta llegue al disposi -

tivo móvil. Dicho servicio es útil para notificar información que puede ser relevante, pero

desconocida, para el usuario. No obstante, por su manejo asincrónico y orientado a eventos,

se debe tener en cuenta las diferentes técnicas de comunicación entre el dispositivo y el LBS

para este servicio.

Push por cambio de zona

Los eventos serán disparados cada vez que haya una fluctuación en ubicación del dispositivo

móvil. Es muy útil para aplicaciones que sólo necesiten proveer nuevos datos cuando la zona

del celular ha cambiado. Por ejemplo, está el marketing basado en localización que .Las fluc-

tuaciones de ubicación pueden ser predeterminadas por el programa o, en experiencias más

enriquecidas, por el usuario. Por lo general, la determinación de cambios de zona se puede

dar por el código postal en el que se encuentra y, en casos más especializados por rangos de

coordenadas geográficas.

Push por marcas de tiempo

Los eventos serán disparados cada vez que se cumpla un intervalo de tiempo determinado. Es

útil para aplicaciones que necesitan constante retroalimentación de la posición del usuario

para enviar información relevante. Por ejemplo, detección de tráfico y optimización de rutas

vulnerables al cambio. Aunque el servicio sea más preciso, a nivel micro puede sufrir de uso

Página 40


de batería del dispositivo y, a nivel macro, es capaz de sufrir de problemas de latencia y pro-

cesamiento.

Además de estas técnicas de comunicación, para que un servicio push funcione efectivamen-

te, el sistema debe tener en cuenta las preferencias y gustos del usuario previamente diligen-

ciadas. En dado caso de que se implementen buenos algoritmos de búsqueda y de deducción

basada en agentes, esta puede ser una buena opción para marketing dirigido.

Dadas las condiciones del tiempo de desarrollo y complejidad algorítmica, implementar algo-

ritmos para hacer servicios push se sale del alcance del Trabajo de Grado. De todas formas,

se buscarán alternativas que logren, en su mayor parte emular los beneficios de este tipo de

servicio.

2.4.3. Servicios Pull

Los servicios pull proveen información a la terminal móvil cuando el usuario la solicite. Si -

gue una metodología de comunicación similar a la de peticiones web en Internet, solo que, en

vez de digitar una url se escribe una dirección o palabra clave que ayude a encontrar objetos

geográficos. Los servicios pull tienen 2 derivaciones:

Pull orientado a servicios funcionales

Los servicios funcionales son aquellos que ofrecen un servicio inmediato dependiendo de la

localización. Por ejemplo, pedir un taxi con sólo oprimir un botón. Para este tipo de servicios

es importante contar con bases de datos previas y, posiblemente, con servicios push sencillos

en el módulo de servicio al cliente.

Pull orientado a servicios de información

Los servicios de información son aquellos que brindan información relevante y cercana a lo

que el usuario está buscando. Por ejemplo encontrar las primeras 20 tiendas de ropa más cer-

canas a la posición actual. Este tipo de servicios deben poseer una base de datos previa para

que funcione efectivamente.

Página 41



Los servicios pull son más asequibles dentro de la implementación de la aplicación. Como va

a ser orientada a la búsqueda de eventos, cae en el contexto de los servicios pull orientados a

los servicios de información.

2.4.4. Integración de Dispositivos Móviles con el GPS

El Global Positioning System o GPS por su comunicación basada en señales de radio, tiene la

desventaja de que solo puede ser utilizado en exteriores. Existen canales de comunicación y

sensores alternativos como el Bluetooh, el Wi-Fi o el GSM que pueden asistir al GPS a cum-

plir su tarea cuando se está en interiores. Es por esta asistencia que nace el concepto de Assis-

ted-GPS (A-GPS) [24] para brindar servicios de posicionamiento a través de redes inalámbri-

cas.

Google Inc®, aprovechando las ventajas de los A-GPS lanza Google Maps®, su propio LBS

con acceso web que permite a tecnologías emergentes como la móvil visualizar de una mane-

ra interactiva, información relevante referente a una actividad. De esta manera, es fácil para

los desarrolladores acceder a un LBS web e incorporarlo a sus aplicaciones.

2.5. Metodología de Desarrollo Ágil

Dado el alcance que tiene el trabajo de grado, se resaltará la metodología que más se acomo-

de a las necesidades de este. Los criterios de selección que se tuvieron en cuenta fueron:

Tiempo de Entrega

Entregas tempranas de funcionalidades del sistema

Priorización de Requerimientos

Como resultado, para el proceso de software del presente trabajo decidió optar por un enfo-

que de entregas incrementales y un método ágil de desarrollo de orientado a características.

2.5.1. Enfoque de Entregas Incrementales

Ian Sommerville aclara que “En un proceso de desarrollo incremental, los clientes identifi-

can, a grandes rasgos, los servicios que proporcionará el sistema. Identifican qué servicios

son más importantes y cuáles menos.” [25] La priorización de los servicios permite que se

Página 42


pueda dividir el software en pequeñas entregas dependiendo de la prioridad de los requeri -

mientos para así hacer prototipos funcionales de fácil integración entre incrementos.

Ilustración 8 - Flujo de desarrollo de un sistema con entregas incrementales [25]

El enfoque brinda además la ventaja de amortiguar el continuo cambio de los requerimientos

a lo largo del tiempo y, gracias a su priorización, ayuda a que no se propaguen errores entre

entregas debido a su integración con incrementos posteriores. Sommerville denota que utili-

zar este enfoque también brinda algunas desventajas, entre ellas, el poco control que se puede

tener sobre entregas muy grandes. Sin embargo, como el Trabajo de Grado sólo se va a enfo -

car en entregas pequeñas, no se considera dicha desventaja.

2.5.2. Desarrollo orientado a Características [26]

El desarrollo orientado a características es una metodología ágil de desarrollo que se concen-

tra en hacer iteraciones cortas que entregan funcionalidades tangibles. El proceso de imple-

mentación de esta tecnología consta de 5 pasos. Cada uno de estos pasos considera incorporar

a diferentes miembros del equipo. En aras de que en el presenta trabajo de grado la imple-

mentación sólo es efectuada por una persona se obviaron algunas especificaciones de trabajo

en equipo:

I. Construir la apreciación global

Para este paso ya se debe tener un contexto general y los requerimientos específicos

del sistema. Se divide el dominio del sistema en diferentes áreas o equipos para em-

pezar a construir el sistema.

II. Hacer lista de características

Página 43



A partir del modelo, los requerimientos y la apreciación global se construye una lista

con las características principales del sistema.

III. Planeación por característica

Se elabora un plan de alto nivel para coordinar a todos los miembros del equipo y

delimitar tiempos.

IV. Diseñar por características

Se diseña el software iterativamente a medida que vayan surgiendo nuevas caracterís-

ticas y/o especificaciones más formales.

V. Construir por característica

Se construye el software iterativamente a medida que vayan surgiendo nuevas carac-

terísticas y/o especificaciones más formales

Página 44


III – DESARROLLO DEL TRABAJO

En el proyecto se definió que cada fase metodológica se considera como completa cuando

esta se materializa en un entregable. De esta forma, los entregables por cada fase son:

Tabla 2 - Entregables por Fase Metodológica

En el Seminario de Investigación ofrecido por el Departamento de Ingeniería de Sistemas se

estableció una Metodología de Desarrollo y Gestión de Riesgos del Proyecto. Este fue un pre

requisito para aprobar la primera parte del Trabajo de Grado. Luego, se realizó una recolec-

ción de referencias bibliográficas y se hizo un inventario de la información relevante para

entregar en un Marco teórico. El siguiente desarrollo resumirá cada una de las fases del pro-

yecto. Estas incluirán la información relevante al contexto y visión general del proyecto. Para

más profundización en cada una de las entregas se invita al lector a leer los documentos

anexos.

Página 45

ENTREGABLEFASE

Marco TeóricoConceptualización

Estrategia de m-Commerce.Especificación de Requerimientos de Software(SRS).Análisis

Documento de Arquitectura de Software (SAD)Diseño

Código ejecutable del prototipo funcional (APK)Implementación

Test de Precisión del dispositivo móvilValidación



1. Conceptualización

Previo al desarrollo del trabajo, se decidió incluir una fase de contextualización y conceptua-

lización del problema para que la ejecución del trabajo fuese coherente y respaldada de inves-

tigaciones pasadas. El Marco Teórico ubicado en el Capítulo 2 del presente documento, resu-

mió dicha fase recolectando referencias bibliográficas e inventariando la recolección de datos

relevantes para el contexto del problema. Las principales ramas que se investigaron fueron:

Ilustración 9 - Principales Ramas de Investigación

Para darle rigurosidad al trabajo de grado, se mantuvieron estándares de calidad que evitaron

la parcialidad de la información recogida. Los estándares se definieron teniendo en cuenta la

forma de acceso al material y sus certificaciones de calidad. En resumen, el trabajo de grado

utilizó 3 formas de acceso para recolectar las referencias bibliográficas:

I. ARTÍCULOS CIENTÍFICOS: Los textos extraídos de internet fueron, en su mayo-

ría, artículos científicos. Los principales bancos de información que se utilizaron

fueron IEEE, ACM, Scopus y casos prácticos de reconocidas empresas como

Microsoft, IBM, entre otros.

Página 46

GamificationServicios

Basados en Localización

Metodologías de Desarrollo de Software

Desarrollo en Android

Desarrollo en Google

Appengine

Comercio Móvil


II. LIBROS: Se aceptaron libros que tuvieran una exhaustiva investigación teórica en

Gamification e Ingeniería de Software. Además también se utilizaron libros técnicos

que agilizaron la curva de aprendizaje en programación de dispositivos Android.

III. BLOGS Y TUTORIALES: En la fase de implementación, se recurrieron a blogs y

tutoriales de expertos en programación en dispositivos Android y Google Appengine.

Los portales más utilizados fueron Stack Overflow, Vogella, Google Groups y Actio-

nbar Sherlock.

Los datos recolectados, al provenir de diferentes fuentes, tenían que ser inventariados utili-

zando herramientas que clasificaran y almacenaran la información. Las 2 principales herra-

mientas tecnológicas utilizadas fueron Zotero y Evernote. Zotero fue implementado para

averiguar los textos en internet y Evernote para mantener un registro de los blogs y tutoriales.

Estas herramientas, al ser meramente tecnológicas, se salen del alcance de los libros por lo

que estos fueron resumidos.

El Marco Teórico resultante puede ser consultado en la Sección II de este documento y las

referencias bibliográficas en el Capítulo IV. Como el propósito principal del entregable es

contextualizar y conceptualizar al lector, no se incluyeron las ramas de investigación que

conciernen al desarrollo del prototipo.

2. Análisis

Durante la fase de análisis se propuso la estrategia de comercio móvil. Para que la estrategia

tenga una propuesta de valor y sea íntegra en todos sus procesos, ésta debe atacar distintas

dimensiones comerciales.

Página 47



Ilustración 10 - Dimensiones que atacó la estrategia de Comercio Móvil propuesta

La Ilustración 10 muestra las dimensiones que atacó la estrategia de comercio móvil pro-

puesta. Las dimensiones fueron clasificadas en Factores Vinculantes y Factores Posicionales.

Los Factores vinculantes son los pilares de la estrategia que interpretaron la idea de negocio

antes de abordar cuestiones funcionales. Por otra parte, los Factores Posicionales equilibraron

la tecnicidad de los Vinculantes generando propuestas de valor, definiendo el mercado objeti-

vo y segmentando a los clientes.

2.1. Factores Vinculantes

Para que la estrategia de comercio móvil sea exitosa, esta debe preparar el terreno antes de

que se comience a implementar el producto. Es por eso que los factores vinculantes permiten

tejer los pilares de la estrategia para que haya coordinación y liderazgo entre todas sus partes.

Por lo general es de vital importancia considerar aspectos de Aprendizaje Organizacional y

Formalización de Procesos Empresariales. Sin embargo como la estrategia que se desarrolló

Página 48


sólo involucra a una persona, se incorporaron factores de Liderazgo Tecnológico e Infraes-

tructura.

I. Liderazgo Tecnológico

Se debe incorporar un buen proceso de Ingeniería de Software para que haya una

adaptación temprana de la idea con la tecnología disponible. Entre más ágiles y con-

trolables sean estos procesos, la empresa será líder en el desarrollo e innovación tec-

nológica de su producto.

II. Infraestructura

La infraestructura de una empresa con énfasis en comercio móvil no solamente se

puede ver en términos de activos físicos como lo es la infraestructura tecnológica.

También se tienen que considera los aspectos estratégicos y organizacionales de esta.

3. Factores Posicionales

Los factores posicionales equilibran a los Factores Vinculantes de tal manera que demuestran

la propuesta de valor que se le quiere transmitir al público objetivo de la estrategia de comer-

cio móvil. Se consideró que los factores posicionales más importantes dentro de una estrate-

gia de negocio son el servicio y el mercado.

I. Servicio

El servicio que presta la empresa se va a ver reflejado en el producto final que ofrece

y la forma en cómo transmite las propuestas de valor a su público objetivo. Por más

de que los factores vinculantes den una estabilidad organizacional, este factor posi -

cional va a ser el que va a dar ventaja competitiva en el nicho de mercado atacado.

II. Mercado

Sin un debido análisis del mercado es muy difícil entender el propósito general de la

empresa y el problema que está intentando resolver. Dentro de la estrategia de comer-

cio móvil es muy importante determinar los segmentos del mercado con los que se

trabaja, sus intereses y comportamientos clave. Entre más se entienda al mercado

Página 49



objetivo, es más probable que la empresa gane posición en el mundo de las aplicacio-

nes móviles.

Diseño

La arquitectura del sistema permite unificar la extracción de requerimientos funcionales y no

funcionales en dos soluciones: el modelo funcional y el modelo de despliegue. El modelo

funcional es útil para identificar tanto los componentes programables del sistema como los

subsistemas mientras que el modelo de despliegue se preocupó más por clasificar en nodos la

ubicación del sistema. Adicionalmente, para lograr describir los modelos con un nivel de

especificidad aceptable, se acudió al flujo de tareas para crear una arquitectura lógica de Peter

Eeles [27]. Este parte de una apreciación global de la arquitectura y de ahí se bifurca sus acti-

vidades en esbozos de elementos funcionales y de despliegue del proyecto.

Se hizo el diseño del Sistema a través de diagramas de clase para el Cliente Móvil y el Servi-

dor Web. Como es descrito en el capítulo 4, el servidor de fotos que provee Amazon Web

Services sirve sólo para persistencia no se hizo lógica interna en este. En la presente subsec-

ción se describen los diferentes paquetes que fueron diseñados para el correcto funcionamien-

to del sistema.

III.1. Cliente Móvil

A continuación se presentan los paquetes principales que fueron desarrollados dentro de la aplicación móvil:

SPI: Contiene los modelos de datos del sistema y la especificación de los métodos de la API

para tener una comunicación directa con Google Appengine. Las clases son empaquetadas

por cada entidad y son generadas por el plugin de Google Appengine para el IDE Eclipse.

Activity: Las Actividades es una componente de la aplicación que provee una pantalla en la

cual un usuario interactuará con ella mantienen la comunicación entre la vista y la lógica de

la aplicación. Las aplicaciones en Android usualmente están compuestas de diferentes activi-

dades relacionadas entre sí.

Página 50


Adapter: Los adaptadores definidos en el proyecto ayudaron a controlar los datos suministra-

dos por el back-end en forma de lista. Se combinaron con memoria caché para que su proce-

samiento fuera optimizado.

Util: El paquete de utilidades contiene métodos, variables y constantes de uso general para

toda la aplicación. Dentro de las clases de utilidad que se encuentean en el proyecto, están

aquellas que controlan la comunicación con Amazon Web Services, transformación de fechas

y deducción de distancias según la localización del usuario, entre otras.

III.2. Servidor Web

A continuación se presentan los paquetes principales que fueron desarrollados dentro del servidor web:

Model: Alberga las entidades de negocio utilizando el conocido framework de Java Empresa-

rial JPA.

Endpoint: Definen las métodos que van a ser utilizados por el API del sistema.

Util: Contiene constantes de configuración y acceso a la unidad de persistencia del servidor

de aplicaciones. Como se está utilizando el Framework de JPA, el administrador de persisten-

cia por defecto se define por una factoría de EntityManager.

Para más información sobre las clases utilizadas y su diseño se puede acudir a la documenta-

ción anexa.

La especificación de la Arquitectura del prototipo implementado permite visualizar desde

diferentes vistas, la forma en la que se pensó el sistema y sus dependencias con otras tecnolo-

gías.

Implementación

Durante la fase de implementación del sistema se tuvieron que reconsiderar varias arquitectu-

ras que brindaran una solución aceptable para el contexto del problema. En primera estancia

se trabajó únicamente con Google Appengine; incluso para el almacenamiento de fotos. Sin

Página 51



embargo por problemas de comunicación con el servidor de BLOBS se decidió utilizar la API

de Amazon Web Services S3.

Durante el proceso de implementación se controlaron todos los imprevistos que implicaban

riesgo en el desarrollo del producto. En primera instancia, para evitar problemas de compati-

bilidad, se recurrió a ejecutar el código de la aplicación móvil y del servidor web en emulado-

res. Así se pudieron depurar muchos errores internos que no tenían que ver con la conexión

entre el cliente y el servidor. Después de conseguir una versión estable se desplegaron los

componentes de software en sus respectivos nodos (ver el Modelo de Despliegue).

La presente sección muestra las herramientas que se utilizaron para administrar y mantener la

construcción del software a niveles óptimos.

IV.1. Manejo de Versiones

Para manejar las versiones del software implementado se utilizó Git como herramienta princi-

pal. Git permite llevar de una manera organizada, el historial de cambios que se hicieron a un

archivo dentro del computador. Además también puede dividir las versiones en ramas para no

perjudicar implementaciones que se han hecho anteriormente.

Como metodología, por cada característica que se fuera a implementar en el sistema se hacían

3 ramificaciones:

En desarrollo

En pruebas

En producción

De esta forma, cuando una característica era desarrollada, su código se transfería a la ramifi-

cación de pruebas. Luego, la ramificación de pruebas se encargó de poner a prueba la caracte-

rística que se utilizando JUnit tanto para la aplicación móvil como para el servidor. Al pasar

la pruebas de software, el código era pasado a producción y desplegado adecuadamente para

ver

Página 52


IV.2. Plugin de Google Cloud Endpoints

El plugin de Cloud Endpoints permite por medio de la herramienta de desarrollo Eclipse ge-

nerar los modelos de datos ligeros para el cliente. De esta forma se evita toda la extenuante

configuración para comunicar a un dispositivo móvil con un servidor.

V. Puesta en marcha

Para hacer las pruebas de software se utilizaron dispositivos con las siguientes características:

LG Nexus 4

Memoria Almacenamiento: 16GB

Memoria RAM: 2GB

Procesador: CPU Qualcom Snapdragon™ S4 Pro

Sistema Operativo: 4.2 (Jelly Bean).

Samsung Galaxy Note II


Memoria RAM: 2GB

Procesador: Quadcore 1.6 GHz Cortex-A9

Sistema Operativo: 4.1.2. (Jelly Bean).

Samsung Nexus S


Memoria RAM: 512MB

Procesador: ARM Cortex-A8 1GHz

Sistema Operativo: 4.2. (Jelly Bean).

Página 53



Validación

La validación permitió determinar si los requerimientos especificados fueron acarreados exi-

tosamente. Esto teniendo en cuenta Atributos de Calidad de Software (QA) y que se cumplie-

ran los Objetivos de Negocio del BMC. En el presente trabajo de grado se propuso retroali-

mentar al BMC con técnicas de Gamification. Estos aspectos se tuvieron en cuenta durante el

Análisis de Requerimientos & Casos de Uso. De esta forma los requerimientos no solo fueron

vistos solamente en términos de lo que necesita el sistema sino también en lo que es “atracti-

vo” (o motivante) para el usuario.

Aunque la estrategia de Gamification haya encontrado medidas para validar el nivel de com-

promiso del usuario, estas no pudieron ser aprobadas adecuadamente en la última fase de

desarrollo del proyecto. Al parecer, muchas de las medidas de la estrategia, por más que se

consideren de corto plazo en el contexto de una EBT, excedieron los tiempos de prueba pla-

neados en el cronograma de desarrollo del proyecto. Por ejemplo, para medir el nivel de com-

promiso en aplicaciones con características de Gamification, se utiliza un cálculo denomina-

do DAU/MAU. Esto es el cociente entre el promedio de usuarios que estuvieron activos por

día (DAU) y el promedio de usuarios que estuvieron activos en el mes (MAU). El hecho de

que se tuviera que esperar un mes para tener precisión en la medida, hizo que se descartara

para la validación del sistema. Sin embargo, se sugiere que está validación debe ser hecha en

dado caso de que se pretenda darle continuación al proyecto.

En contraprestación al imprevisto, se decidió validar QA que se asemejaran, lo mejor posible,

a medidas de compromiso de la aplicación. Gracias a que se tercerizó el mantenimiento y

disponibilidad de los servidores, se solventó la validación únicamente a la confiabilidad

(Reliability) de la aplicación. En el caso específico del sistema a que se implementó, la con-

fiabilidad depende rotundamente en asegurar que un usuario se encuentre ubicado en un

evento para tomar una foto. De esta forma, la precisión del método de ubicación debe ser lo

suficientemente precisa para no presentar inconsistencias en la experiencia de usuario.

Como los eventos pueden llevarse a cabo tanto en lugares cerrados como abiertos, se hicieron

pruebas para validar la precisión de métodos de ubicación incorporados en el dispositivo

móvil para estos entornos. Los métodos de ubicación más usados en un dispositivo móvil son

Página 54


los Sensores GPS, Ubicación por WiFi y Ubicación por 3G. Cada uno de estos métodos (res-

pectivamente) es menos preciso que el otro, lo cual implicó llevar a cabo un análisis para

validar la confiabilidad del sistema.

Se hizo un formato para que las pruebas de validación incorporaran todos los posibles casos

en los que un usuario puede tomar una foto en un evento. Este formato se utilizó con datos

reales que están desarrollas en el capítulo 4 del presente documento:

Tabla 3 – Formato de Validación de Confiabilidad

Como se puede ver en la Tabla 3, por cada punto que se registre en el dispositivo móvil se va

a evaluar su precisión con cada método de ubicación. Se tomó un total de 6 puntos, con cada

dispositivo móvil y la interfaz de configuración del Sistema Operativo Android 4.0 (Jelly-

bean) permitió que se pudieran utilizar los 3 métodos de ubicación.

En el siguiente capítulo en la Sección 7 se hizo un despliegue más detallado de la informa -

ción recolectada a lo largo de la experiencia. Incluyendo un análisis y criterio de escogencia

de los puntos.

Página 55



IV - RESULTADOS Y REFLEXIÓN SOBRE LOS MISMOS

La estrategia de comercio móvil desarrollada a lo largo del proyecto, se divide dos ramas

principales: Administración de Empresas e Ingeniería de software. A continuación se presen-

ta un mapa mental resultante que ilustra a nivel global la descripción de la estrategia de co-

mercio móvil.

Ilustración 11- Descripción Global de la Estrategia de Comercio Móvil

Página 56


Las dos ramas de la estrategia las une el Análisis de Requerimientos & Casos de uso del sis-

tema. El análisis de requerimientos permitió extraer la información más relevante de la Rama

de Administración de Empresas y encapsularla en tareas específicas. Luego, las tareas fueron

clasificadas en Casos de Uso y profundizadas en Requerimientos Funcionales y No Funciona-

les del sistema. Dada la restricción de tiempo del proyectó se necesitó priorizar los requeri -

mientos más relevantes para incorporar en el primer prototipo funcional. Las prioridades de

los requerimientos fueron minuciosamente analizadas teniendo en cuenta el tiempo de ejecu-

ción estimado del requerimiento y su necesidad de implementación para que cumpliera con la

idea de negocio. Para probar los requerimientos se tuvo en cuenta los siguientes aspectos:

Importancia: Se debe establecer si el requerimiento es importante y esencial para el

sistema. En el caso del presente trabajo de grado, el nivel de importancia radica en la

urgencia de producir el requerimiento y su cantidad de dependencias con otros.

Penalización (Penalty): Son requerimientos que por más de que aporten a la expe-

riencia de usuario, pueden ser omitidos y el sistema seguirá cumpliendo su cometido.

Costo: Incluye la complejidad del requerimiento, su implementación y documenta-

ción. También ayuda a deducir las formas en las que se puede omitir la duplicación

de código.

Tiempo: Por lo general se deduce el número de horas dedicadas a resolver el requeri-

miento. El tiempo además influye en la infraestructura de la arquitectura del sistema,

la experiencia del desarrollador y la forma de hacer tareas en paralelo.

Riesgo: El riesgo técnico de un requerimiento puede ser un factor que puede causar

gran impacto en el desarrollo del sistema. Tener en cuenta la valoración de riesgo de

un requerimiento hace que éste tenga una prioridad más alta.

Página 57



Rama de Administración de Empresas

La rama de Administración de empresas tiene como propósito principal descomponer e ilus-

trar una idea de negocio en componentes generales de administración de negocios. Para lo-

grar dicho objetivo la rama consta tres módulos clave: el BMC, la idea de negocio a proponer

y el desarrollo del framework de Gamification. Cada uno de estos trabajan en conjunto para

enriquecer la estrategia de comercio móvil en cuatro factores vinculantes: La tecnología, el

servicio que provee, el mercado que ataca y la infraestructura que la conforma.

En primera estancia se parte definiendo la idea de negocio a desarrollar. Se enuncia el objeti-

vo principal de esta y los factores diferenciales de la empresa. Después se define un tamaño y

segmento del mercado al que se le quiere ofrecer el producto o servicio. Con esta informa -

ción, se utiliza la metodología del BMC para generar mecanismos administrativos que asegu-

ren viabilidad y mejor entendimiento del modelo de negocio de la empresa a construir. Te-

niendo un espectro más amplio del problema a resolver, se enriquece el modelo de negocio

utilizando técnicas de Gamification. Estas se enfocaron en generar comportamientos clave en

sus clientes para que se mantengan activos dentro de la aplicación. De esta forma se aclararon

las dinámicas, mecánicas y componentes de retroalimentación que fortalecieron las relaciones

con el cliente y dan valor agregado a la experiencia en general.

Rama Ingeniería de Software

Después de haber hecho un inventario de los principales requerimientos del sistema estos

pueden ser diseñados interpretando sus requerimientos funcionales y no funcionales en un

modelo funcional y un modelo de despliegue. Luego, utilizando metodologías ágiles de desa-

rrollo se procede a construir un primer prototipo funcional que muestre la interacción del

usuario con los principales casos de uso del sistema.

El registro masivo de usuarios y la interacción de estos con la plataforma, es una meta de alta

prioridad para una Empresa de Base Tecnológica. Sin embargo, existen muchas aplicaciones

en el mercado que por más de que tengan una utilidad y desempeño excelentes, no logran

trasmitir mecánicas sencillas que brinden facilidad de uso y “enganche” al usuario. Por eso

Página 58


mismo, es importante considerar dentro de la construcción de software la incorporación de

mecánicas y dinámicas que mejoren la experiencia de usuario.

Las técnicas de Gamification ayudan a definir los comportamientos que se quieren generar en

sus usuarios y por medio de sus mecánicas y dinámicas los motiva a cumplir sus tareas. Se

utilizó el Framework de las 6 D’s de Kevin Werbach [22] para extraer efectivamente los obje-

tivos de negocio, tipo de personas que usarán la aplicación y sus respectivos comportamien-

tos que se quisieron incentivar.

Los comportamientos después fueron traducidos a mecánicas y dinámicas a ser aplicadas

dentro de la aplicación. Con las mecánicas y dinámicas definidas, es más fácil entender en

términos de pasos las componentes programables a desarrollar.

Cada uno de los entregables contribuyeron al Sistema Prototipo construido. Los resultados

más relevantes son expresados en este capítulo. Se desarrollaron los diferentes módulos de la

Ilustración 10 que dieron retroalimentación al cliente y también al proceso de Ingeniería de

Software.

Idea de negocio

Con el motivo de apoyar la idea de negocio se desarrolló una aplicación móvil que crea y

administrar eventos de cualquier tipo. El creador del evento puede enviar invitaciones a las

personas que considere pertinentes para el evento. Se debe acordar fecha y lugar para que la

aplicación funcione ya que esta registrará en tiempo real, por medio de georeferenciación, a

los acudientes que hagan check-in en el lugar de encuentro, a la hora establecida. El usuario,

al hacer el check-in, podrá entonces empezar a contribuir en la formación de un álbum comu-

nitario de fotos del evento. La visibilidad de este álbum depende de dos factores: (a) el estado

del evento y (b) la privacidad del evento.

a. El estado del evento: Cuando un evento todavía se encuentra en curso, los invitados

al evento, independientemente de que se encuentren dentro de este o no, podrán ver

las fotos contribuidas al álbum en tiempo real. Sin embargo, cuando el evento culmi-

ne, únicamente los que atendieron al evento podrán tener futuro acceso a estas me-

morias.

Página 59



b. Privacidad del evento: Existen dos tipos de eventos, los privados y los públicos. En

ambos eventos hay una lista predefinida de invitados. Sin embargo, en los eventos

públicos cualquier persona puede buscar y adscribirse a un evento sin necesidad de

recibir una invitación. La mecánica de visualización también depende del estado del

evento, sólo que en los eventos públicos, cualquier usuario podrá visualizar las fotos.

Para que la aplicación encaje en un modelo de negocio, se quiere mantener un control sobre

la privacidad de los eventos. Es por eso que únicamente los usuarios que deseen sacar un

beneficio económico de la plataforma pueden crear eventos públicos.

La elaboración del prototipo final del Trabajo de Grado se limitó a que las mecánicas de

manejo de fotos se cumplan únicamente para los eventos privados.

Business Model Canvas

Se utilizó el Business Model Canvas (BMC) para crear un Modelo de Negocio sostenible de

una manera rápida y efectiva. Se hizo el BMC digital en la página web Canvanizer [28] y se

describió cada uno de sus pilares. En esta sección se presentan los aspectos más importantes

que se obtuvieron durante el proceso de creación de los 9 pilares del BMC. El BMC está dis-

ponible para su consulta en el Anexo 1.

4.1. Segmento de Clientes

La Idea de Negocio modela a 2 segmentos de clientes: Los Usuarios con Dispositivos Móvi-

les y los Promotores de Eventos. Como el sistema inter-organizacional del Modelo de Nego-

cio es B2C orientado al Contenido basado en Necesidades los segmentos de clientes identifi-

cados hacen parte de mercados bilaterales [29]. Esto quiere decir que el sistema a implemen-

tar ofrece interacción entre todos sus clientes para brindar propuestas de valor interdepen-

dientes.

Los Usuarios con Dispositivos Móviles van a tener el beneficio de poder acceder y contribuir

a la aplicación sin ningún costo. Esto es una estrategia común en este tipo de mercados ya

que genera economías de escala, generando como consecuencia que los otros 2 segmentos de

Página 60


clientes se sientan atraídos a invertir dinero en la plataforma. Es por eso que es indispensable

dentro del primer prototipo funcional que se desarrollen características orientadas a este tipo

de usuarios antes que los demás.

Los promotores de Eventos son aquellos que crean Eventos Públicos con el ánimo de que sus

acudientes aporten con contenido visual de lo ocurrido en el evento. Les interesa que quede

un registro de la actividad del evento para mostrar el desempeño de este y crear por ende

publicidad social.

4.2. Propuestas de Valor

Se lograron identificar 2 propuestas de valor, una para cada segmento de cliente. La Tabla 3

los muestra a continuación:

SEGMENTO DE CLIENTE PROPUESTA DE VALOR

Usuarios con Dispositivos Móviles Crear álbumes de fotos comunitarios entre todos los acudientes a un evento.

Promotores de Eventos Compartir y Promocionar Eventos al público en general.

Tabla 4 - Propuestas de Valor

El crear álbumes comunitarios entre todos los acudientes a un evento hace que los usuarios se

sientan en control de personalizar la experiencia de un evento, contribuyendo su “percepción”

del evento con sus fotos. Además, este mecanismo brinda conveniencia y usabilidad para los

usuarios de dispositivos móviles, ya que pueden tomar fotos y ser fotografiados al mismo

tiempo sin necesidad de recurrir a engorrosas situaciones de tener que tomar una foto varias

veces.

El compartir y promocionar eventos al público en general es una herramienta que facilita la

forma de hacer branding y posicionamiento electrónico con sus clientes. Uno de los factores

que hace que esta propuesta de valor sea interesante es que el posicionamiento lo crean los

Página 61



mismos usuarios que atendieron al evento, propagando sus fotos a amigos, relativos e intere-

sados en la empresa que está promocionando el evento.

4.3. Canales de Distribución

Se logró identificar 2 canales de distribución directos y uno indirecto. Por lo general los cana-

les de distribución directos son productos o servicios de las que la empresa es dueña o res-

ponsable. Por otra parte los canales de distribución indirectos en este caso se tercerizan

para brindar un mejor servicio al cliente. Los canales de distribución resultantes se aprecian

en la Tabla 5.

CANALES DE DISTRIBUCIÓN

INDIRECTOS DIRECTOS

Tiendas de Aplicaciones (Mobile Stores) Anuncios de Eventos públicos

Pagos por Internet

Tabla 5 - Canales de Distribución

Para lograr posicionamiento, en primera estancia se acuden a las tiendas de aplicaciones mó-

viles para promocionar la aplicación a los usuarios y los pagos por internet para poder hacer

los pagos de las empresas promotoras de eventos a la plataforma. Por otra parte la aplicación

va a proveer anuncios de eventos públicos para que todos los interesados puedan encontrar

fácilmente eventos cercanos que satisfagan sus gustos y necesidades.

4.4. Relación con los Usuarios

El Modelo de Negocio decidió establecer relación con sus usuarios a través de Efectos de Red

Directos, Co-creación de contenidos y Creación de Comunidades.

Los efectos de red directos permiten relacional el uso de la aplicación con el incremento en

valor para los segmentos de cliente. Entre más se utilice la aplicación y se suban más conteni -

dos, la aplicación crecerá su valor inherente y por ende creará economías de escala.

Página 62


La Co-creación de contenidos es un mecanismo social que permite que los usuarios con dis-

positivos móviles sientan la necesidad de contribuir con sus fotos para pertenecer a una co-

munidad que comparte los mismos intereses. Esto es beneficioso tanto para los promotores de

eventos como para los usuarios con dispositivos móviles ya que es un método poco costoso

de atracción de clientes y satisfacción personal. La creación de comunidades es un efecto

residual dentro de la estrategia del negocio. Genera economías de escala y hace que los seg-

mentos de cliente se sientan identificados con alguna empresa o razón social.

4.5. Fuentes de Ingreso

Para tener un modelo de negocio autosostenible se necesita planear las fuentes de ingreso

principales que va a tener. Las fuentes de ingreso van a provenir únicamente de los Promoto-

res de Eventos. Las formas de cobro por el servicio se van a dar por Uso y por Publicidad.

Cada vez que un Promotor de Eventos quiera crear un Evento a este se le va a cobrar un esti -

mado dependiendo de la cantidad de invitados y el campo de visibilidad del evento. Entre

más paguen, más invitados pueden soportar y su visibilidad por usuarios se expande más

metros a la redonda. Sin embargo, en dado caso de que los promotores prefieran promocionar

sus eventos días antes de que estos estén en curso también lo pueden hacer por medio de pu-

blicidad.

4.6. Recursos Clave

La empresa depende exclusivamente de su Recurso Humano. Este es una combinación entre

Ingenieros de Software y expertos en Marketing Digital.

4.7. Actividades Clave

Para que las propuestas de valor sean generadas e innovadas constantemente las actividades

clave en el Modelo de Negocios son la Construcción de Software y la creación de estrategias

de Mercadeo. La construcción del software incluye aprendizaje organizacional y manteni-

miento de la plataforma. Entre más servicios tenga la plataforma, generará más valor agrega-

do y ventaja competitiva. Por otra parte que existan estrategias para asimilar el gran mercado

que ataca la empresa ayuda a administrar mejor el negocio, teniendo en cuenta proyecciones

tanto financieras como publicitarias.

Página 63



4.8. Socios Clave

Es necesario incorporar Socios Clave dentro del Modelo de negocio para optimizar el soporte

de las economías de escala, tercerizar servicios y reducir riesgos e incertidumbre. Se dedujo

que los mejores socios que cubrieran todas las necesidades de la empresa son:

La infraestructura de la Plataforma como Servicio (PaaS) de Google Appengine pro-

vee la potencia y optimización de los servidores de Google para almacenar y cons-

truir el back-end de la aplicación. Además, de forma indirecta, se cubren costos de

mantenimiento, disponibilidad y ubicuidad.

De igual manera, la Infraestructura como Servicio (IaaS) de Amazon Web Services y

sus Servicio de Almacenamiento Simple (S3) ayuda a transferir archivos binarios de

gran tamaño de forma distribuida y transparente. El S3 cuenta con un SDK exclusivo

para plataformas de desarrollo móvil lo cual facilita su uso e integración con el pro-

ducto a construir.

Es de vital importancia contar con el apoyo de socios capitalistas que hagan inversio-

nes iniciales en la plataforma para sostener el Modelo de Negocio mientras se crea el

mínimo producto viable.

Para contribuir al emprendimiento Colombiano y tercerizar el servicio de pagos por

internet se va a recurrir a Pagos Online.

4.9. Estructura de Costos

La estructura de costos del Modelo de Negocio busca atacar a las economías de escala. Esto

tiene como ventaja que al tener muchos usuarios el costo por unidad disminuye sustancial-

mente. Los principales costos que se presentan en la empresa son:

Costos de Web Hosting

Costos de Mercadeo

Costos de Desarrollo (nómina)

Página 64


Costos de infraestructura tecnológica.

5. Framework de GamificationV.1. Objetivos de negocio

Para que la idea de negocio fuera escalable, se pensaron los objetivos principales con una

visión empresarial orientada a las economías de escala (característica principal de una EBT).

Los objetivos de negocio necesarios para el prototipo funcional son ilustrados en la Tabla:

Objetivo Justificación

Tener varios usuarios registrados al portal El sostenimiento de una EBT radica en la canti-

dad de usuarios que utilicen el servicio ofrecido.

Que haya más usuarios registrados comprueba

que el modelo de negocio sea viable.

Generar contribución de contenido por los usua-

rios.

Una de las mediciones más importantes para una

EBT son la cantidad de solicitudes por unidad de

tiempo. De esta manera, es importante que el

usuario interactúe con la plataforma lo más fre-

cuente posible.

Tener la mayor cantidad de eventos creados si-

multáneamente.

La razón de ser de la idea gira en torno a los

eventos, por lo que es importante que se creen

muchos eventos.

Tabla 6 - Objetivos de Negocio

Por más de que los objetivos de negocio no pudieron ser del todo comprobados, estos fueron

de gran ayuda para entender cómo iba a ser la interacción y visualización de la aplicación

móvil con su back-end.

Página 65



V.2. Tipos de Personas usando la Aplicación

Por más de que siempre se trate con un solo público objetivo, las técnicas de Gamification

contemplan la posibilidad de clasificar los comportamientos clave del cliente en diferentes

“personalidades”. Así se entendió más las motivaciones de los usuarios y cuáles son los com-

portamientos clave que estos describen. Se lograron extraer 3 comportamientos clave:

Tomar una foto

Crear un Evento

Check-in a un Evento

Para ver la documentación pertinente, la descripción de las “personalidades” la pueden en-

contrar en el Anexo 4.

V.3. Comportamientos Clave Identificados

La Tabla 7 resume los comportamientos clave que se quieren generar en sus Usuarios con

Dispositivos Móviles.

COMPORTAMIENTO CLAVE MÉTRICA

Tomar una Foto Fotos Mensuales/Eventos Mensuales

Crear un Evento Eventos Creados mes

Check-in a un Evento Promedio de eventos asistidos por persona al mes

Tabla 7 - Comportamientos Clave

Las métricas creadas por cada comportamiento clave van a permitir a mediano y largo plazo

evaluar el nivel de compromiso y motivación que está teniendo el usuario con la plataforma.

Posteriormente se evaluó cada comportamiento clave y por medio de los bucles de compro-

miso se logró extraer las dinámicas, mecánicas y componentes a incorporar en la aplicación.

5.3.1. Tomar una Foto

I. Dinámica

Página 66


Para que un usuario se sienta motivado a tomar una foto es necesario que tenga

una retroalimentación visual de la actividad que está ocurriendo en el evento.

Esta tiene que mostrar cualidades de compañerismo y dar noción de temporali-

dad.

II. MecánicaEl usuario va a ser capaz de ver las fotos tomadas por todos sus compañeros en el

evento. Estas son desplegadas en forma de lista y organizadas por orden cronoló-

gico, así el usuario verá la última foto que se tomó de primero.

III. ComponentePara ilustrar la mecánica se utilizaron 2 componentes. Avatares y medidas de

tiempo. Los avatares son los nombres de usuario, así se puede identificar a la

persona que tomó la foto. Las medidas de tiempo muestran hace cuánto fue toma-

da la foto. De esta manera se genera una necesidad de completitud por parte del

usuario.

5.3.2. Crear un Evento

I. DinámicaLa motivación para crear un evento surge de la necesidad de reunir a personas

que compartan un mismo interés. Es por eso que es indispensable incorporar

elementos sociales a la experiencia. Es importante también mostrar los eventos

que se han creado y que son relevantes para el usuario para que este entre en

contexto.

II. MecánicaSe debe poder invitar a un amigo de una manera sencilla y además como se espe-

ra que un usuario tenga varios eventos al mismo tiempo, estos se deben poder

visualizar de una manera dinámica y rápida. Esto se logró con animaciones de

mapa y una lista en la que el usuario puede escoger para ubicar el mapa en el

evento seleccionado.

III. Componente

Página 67



Se necesita incorporar un botón animado que extraiga una lista de los amigos que

desea invitar el usuario. Además, la visualización de los eventos debe ser en

forma de mapa con marcadores por evento.

5.3.3. Check-in a un Evento

I. DinámicaEl usuario debe encontrarse dentro de la zona de tolerancia del evento para que el

sistema entienda que puede hacer check-in en este. Para que el usuario se sienta

motivado a hace check-in el sistema debe retroalimentar la posición del usuario

con respecto a la del evento.

II. MecánicaSe debe visualizar la zona de aceptación del evento en el mapa. Además si el

usuario se encuentra dentro del evento, se le debe indicar con un incentivo visual

como por ejemplo cambio de color de la zona de aceptación.

III. ComponenteNo existen componentes en este comportamiento.

6. Especificación de Requerimientos de Software

En total, se obtuvieron 20 Requerimientos y 10 Casos de Uso. Se especificaron formalmente

siguiendo la plantilla de diseño HACER & USOS del Grupo ISTAR de la Pontificia Univer-

sidad Javeriana [30], y se diagramaron los casos de uso utilizando notación UML.

En la presente sección, se resaltarán los aspectos más importantes durante la licitación de

requerimientos del sistema. Es importante aclarar que se aprovechó el desarrollo modular del

framework de Gamification para que los requerimientos tuvieran un diseño estructurado y

acorde (en lo posible) a la Idea de Negocio.

6.1. Requerimientos Funcionales

Dentro de la lista de requerimientos extraídos se estableció una prioridad por cada uno de

ellos. Dadas las restricciones y alcance del presente trabajo de grado, únicamente se decidió

Página 68


enfocar el tiempo de construcción a requerimientos con prioridad alta. En la Tabla 8 se mues-

tra los requerimientos funcionales que fueron escogidos:

Código Descripción Clasificación

FURPS+

R01 El sistema debe permitir al usuario crear una cuenta F

R02 El sistema debe permitir ingresar a su cuenta F

R03 El sistema debe permitir al usuario hacer check-in en un evento F

R04 El sistema debe asegurar que la posición del usuario coincida

con la del evento para poder tomar una foto

F

R05 El sistema debe permitir al usuario persona crear un evento

privado

F

R06 El sistema debe permitir al usuario ver la información de un

evento

F

R07 El sistema debe almacenar la foto tomada por un usuario en el

dispositivo móvil.

F

R08 El sistema debe almacenar la foto y relacionarla con el evento

en curso.

F

R09 El sistema debe permitir invitar a usuarios persona a un evento. F

R10 El sistema debe asegurar que sólo los invitados vean la informa-

ción en un evento privado.

F

R11 El sistema debe mostrar las fotos de un evento a los invitados. F

Página 69



Tabla 8 - Requerimientos Funcionales

6.2. Requerimientos no Funcionales

Los requerimientos no funcionales fueron colaterales a cada una de las componentes de arqui-

tectura del sistema (desplegados en la Tabla 9). Fueron clasificados usando la clasificación

FURPS+ (Funcionalidad, Facilidad de Uso, Fiabilidad, Rendimiento, Soporte, +(Implementa-

ción interfaz, Empaquetamiento)).

Código Descripción Clasificación

FURPS+

R12 El sistema debe permitir usar cámaras integradas. S

R13 El sistema debe utilizar sensores de GPS S

R14 El sistema debe permitir visualizar al usuario la ubicación de los

eventos en curso utilizando un LBS

U+

R15 El sistema debe ser implementado en plataformas Android S+

R16 El sistema debe utilizar la PaaS de Google: App Engine para

Java

S+

R17 El sistema debe utilizar la IaaS de Amazon Web Services para

almacenar las fotos en sus repositorios S3

S+

R18 El sistema debe proveer una interfaz de usuario en español U+

R19 El sistema debe proveer una interfaz de usuario en inglés U+

Página 70


R20 La aplicación móvil debe utilizar la memoria del dispositivo

para que sirva de caché en la carga de las fotos.

P

Tabla 9 - Requerimientos No Funcionales

6.3. Casos de Uso

Los Casos de Uso al ser usados para proveer un diseño de alto nivel del sistema fueron rela -

cionados directamente con la especificación de comportamientos deseados, en la estrategia de

Gamification.

Ilustración 12 - Casos de Uso del Sistema

La Ilustración 12 muestra cómo se incorporaron los casos de uso del sistema y cómo interac-

tuaron con el cliente móvil (el único actor que se debe implementar). Es claro que también se

Página 71



necesita de una interfaz web que permita medir la cantidad de usuarios registrados y el tráfico

de la aplicación. Sin embargo, gracias a las cualidades que presenta la Plataforma Appengine

de Google, el trabajo ya se encuentra realizado por ellos. Las funcionalidades más relevantes

a implementar son:

Cada Usuario podrá crear y participar en un evento.

Cada Usuario podrá invitar hasta 5 usuarios simultáneamente.

Consultar eventos pasados, presentes y futuros.

Realizar Check-in a un evento utilizando un GPS

Consultar los eventos más cercanos.

7. Arquitectura del Sistema

El sistema consta de una aplicación cliente, un servidor de fotos de Amazon Web Services y

un Servidor Google Appengine.

Ilustración 13 - Apreciación Global de la Arquitectura del Sistema propuesto

Página 72


La Ilustración 13 muestra en general, la interacción que existe entre los diferentes nodos del

sistema. La Aplicación Cliente con la ayuda de su cámara integrada, sensores GPS, conexión

a internet y almacenamiento local lograron cumplir con los requisitos mínimos para cumplir

con los casos de uso enunciados anteriormente.

El cliente se conecta a 2 servicios ubicados en diferentes partes del globo. El primero es el

repositorio de datos S3 de Amazon Web Services. S3 es un repositorio optimizado para alma-

cenar objetos binarios de gran tamaño (BLOBs) de tal manera que el sistema pueda tercerizar

algoritmos de compresión, concurrencia y balanceo de cargas.

En segundo lugar, está el Servidor Appengine. Es utilizado para guardar información relevan-

te a los objetos que se manejan en el sistema. Esto incluye información del usuario, sus even-

tos y fotos relacionadas. Las fotos relacionadas no son propiamente su contenido binario sino

los metadatos que la conforman como, por ejemplo, el creador de la foto, fecha en la que fue

tomada, etc.

7.1. Modelo Funcional

El modelo funcional logró desglosar los diferentes componentes de software que existen en la

aplicación. Para asegurar calidad en la construcción de software se intentó, en lo posible, de

mantener una alta cohesión, un bajo acoplamiento y una alta granularidad en la funcionalidad

de los componentes. Esto permitió, respectivamente, que hubiese coherencia y poca depen-

dencia entre las clases desarrolladas.

Página 73



Ilustración 14 - Diagrama de Componentes

En la Ilustración 14 se puede apreciar los diferentes componentes que fueron diseñados para

el sistema a implementar. El Smartphone sigue el patrón Modelo Vista Controlador, en donde

el modelo únicamente está diseñado para almacenar fotos y datos de la sesión local. El con-

trolador también coordina el manejo de sensores del dispositivo y administra las conexiones a

los 2 servidores a través de un administrador de conexiones (CM). Por otra parte, el servidor

Appengine maneja las peticiones que son solicitadas a través de una API y pueden ser res-

tringidas a usuario que únicamente se encuentren autenticados. Los métodos de la API permi-

tirán manejar la persistencia y la lógica de negocio del sistema.

Paralelo a la API existe, en el mismo componente del CM, una Interface Proveedora de Servi-

cios (SPI) que encapsula de forma ligera el modelo del sistema en el dispositivo móvil. La

SPI permitió que hubiera una comunicación más fácil entre el Smartphone y el Servido.

Página 74


7.2. Modelo de Despliegue

El modelo de despliegue sirve para describir la distribución de los componentes de software

en nodos físicos específicos. A continuación se presenta el diagrama de despliegue diseñado.

Ilustración 15 - Diagrama de Despliegue

En la Ilustración 15 se puede apreciar los principales nodos de la aplicación (El dispositivo

móvil, el servidor Appengine y el Servidor de Amazon Web Services. Como Appengine brin-

da una Platarforma como servicio (PaaS), el servidor de aplicaciones se conecta a otros nodos

dentro de la Infraestructura de Google de forma transparente. Sin embargo no se sabe el tipo

de comunicación que hay entre Appengine y su infraestructura interna. Por otra parte, la co-

nexión que hace el dispositivo móvil con los 2 servidores es por medio de solicitudes HTTP.

Página 75



8. Implementación del Sistema

Se implementaron todos los casos de uso propuestos. En las siguientes sub-secciones se pre-

senta la implementación de los casos de uso que fueron más relevantes a la estrategia tanto

para su funcionamiento como para apoyo a la idea de negocio.

8.1. Tomar Foto

El objetivo principal de este caso es que el usuario pueda tomar una foto y que ésta quede

almacenada tanto en el servidor de Amazon como en memoria local del dispositivo. Una

restricción importante de este caso de uso es que el usuario se tiene que encontrar en la zona

del evento y registrado a este. El flujo de este caso (visto en la Ilustración 16) consta de 3

pasos: verificación de ubicación, tomar la foto y describir la foto.

Ilustración 16 - Flujo del CU Tomar Foto

Para verificar la ubicación, se utilizan permisos para acceder a los diferentes métodos de ubi-

cación del Smartphone dependiendo de si el usuario se encuentra en un lugar cerrado o abier-

to. Luego se calcula la distancia a la que se encuentra el usuario del evento. Se utilizó como

restricción un máximo de 150 metros. Si el usuario se encuentra dentro del evento puede

hacer check-in y tomar una foto. Para cuando el usuario escoge la opción de “Tomar Foto” en

el dispositivo, este hace uso de la cámara, enriquecida con todas sus características para que

Página 76


el usuario pueda tomar la foto. Luego, el usuario le da una descripción simple a la foto y la

persiste.

El proceso de persistencia consta de 3 partes. La primera involucra guardar todos los meta-

datos de la foto en Google Appengine, la segunda es utilizar datos del evento para estructurar

lógicamente cómo se va a guardar la foto en los servidores de Amazon y la tercera comprime

la foto tomada y la guarda en el dispositivo y los servidores.

8.2. Ver evento

El caso de Ver Evento involucra varias consideraciones. Se mostró la información general del

evento y además las fotos que han sido tomadas dentro de este. Para brindar una experiencia

de usuario enriquecida, se utilizaron técnicas de Reverse Geocoding para deducir la dirección

del lugar a partir de la longitud y latitud del evento. Por otro parte, cada foto expuesta es una

combinación entre los metadatos extraídos de Google Appengine y el archivo binario de

Amazon Web Services. La Ilustración 17 muestra el flujo de este caso de uso.

Ilustración 17 - Flujo del CU Ver Evento

Página 77



Como es supremamente ineficiente tener estar haciendo peticiones a los 2 servidores para

mostrar las fotos de un evento, se utilizó la memoria caché del dispositivo móvil y del servi -

dor de Google Appengine para hacer transferencias más rápidas de entre los nodos del siste -

ma. Las fotos tienen la descripción de quién las tomó y el tiempo en el que se tomaron. Gra-

cias a la estrategia de Gamification se logró deducir que es mucho más atractivo para un

usuario ver hace cuánto tiempo se tomaron las fotos a en qué fecha se tomaron. De esta forma

se despliega un texto mostrando hace cuantos minutos, horas, días o semanas se tomaron las

fotos.

8.3. Crear Evento

El crear un evento dentro de una aplicación móvil implicó un reto dentro del desarrollo del

sistema. Dentro de una sola pantalla se tuvo que incluir todos los campos a llenar, incluyendo

selección de fecha y ubicación del evento. Para hacer más didáctica la experiencia se hizo uso

de Diálogos Personalizados para la selección de la fecha y de un mapa para escoger la ubica-

ción del evento. Los resultados son mostrados en la Ilustración 18:

Ilustración 18 - Flujo del CU Crear Evento

De esta forma, cuando se presiona el campo de texto de las fechas (Start Date o Finish Date)

se despliega un dialogo para escoger la fecha. La fecha inicial con la que empieza el diálogo

Página 78


se sincroniza con el calendario del teléfono a la fecha actual. Para escoger la ubicación del

evento, el usuario debe sostener su dedo sobre la ubicación del evento dentro del mapa. Auto-

máticamente la aplicación crea un marcador especificando la zona seleccionada. En dado

caso de que el usuario se haya equivocado, se puede volver a presionar sobre el mapa la ubi-

cación, y el marcador se vuelve a regenerar.

8.4. Invitar Amigo

Para invitar a un amigo al evento se debe únicamente presionar el botón de invitar a un amigo

y este redirigirá al usuario a una pantalla donde se muestran todos los amigos del usuario que

no han sido invitados. Apenas se selecciona al amigo que se quiere invitar, este ya queda

incorporado en el sistema y podrá visualizar la existencia del evento en el menú principal.

Es importante resaltar que el único que puede agregar amigos al evento es el creador de este.

De esta forma se aseguró que no apareciera la opción de “invitar a amigos” cuando un invita-

do está visualizando el evento.

9. Recolección de Datos y Validación

Tal y como se muestra en la Ilustración 19, para la recolección de datos se hicieron desarro-

llaron 3 pasos:

Ilustración 19 - Proceso de Recolección de Datos y Validación

Página 79

Seleccion de la Zona de Estudio

Lectura de la ubicación del

Usuario

Análisis de los resultados

Documentados



En la presente sección se describen cada uno de los pasos justificando su propósito dentro de

la validación del sistema.

9.1. Selección de la Zona de Estudio

Cuando se crea un evento en el sistema, este tiene una zona de aceptación en donde los usua-

rios pueden compartir sus fotos. Por motivos de prueba, se estableció una zona de aceptación

constante de 150 metros a la redonda del evento. De esta forma, la zona de estudio tuvo que

ser lo suficientemente amplia para poder comparar la ubicación del usuario (en diferentes

situaciones), con la zona de aceptación del evento. Se escogió el campus de la Pontificia Uni-

versidad Javeriana ya que esta tiene espacios abiertos amplios y cobertura de WiFi en todas

sus instalaciones.

Se creó un evento dentro de la Biblioteca Alfonso Borrero Carvajal y se hicieron las pruebas

circundando alrededor de éste. Adicionalmente, como puede ser visto en la Ilustración 20, se

desarrolló una Actividad especial dentro del dispositivo móvil para que las lecturas de datos

fueran más fáciles de localizar y tabular.

Página 80


Ilustración 20 - Interfaz de Pruebas

La interfaz de pruebas provee la ubicación actual del usuario en términos de Latitud y Longi-

tud terrestres. Además, dentro del evento, se calcula la distancia que hay entre el usuario y el

punto central del evento. Dicho cálculo fue aproximado utilizando la fórmula de Harvesine

[31]:

a = sin²(Δφ/2) + cos(φ1).cos(φ2).sin²(Δλ/2)

c = 2.atan2(√a, √(1−a))

d = R.c

Donde φ es la latitud, λ es la longitud y R es el radio de la tierra.

La fórmula de Harvesine es conveniente para el cálculo de pequeñas distancias entre dos

puntos geográficos. El cálculo encaja con el objetivo de las pruebas, reduciendo sustancial-

mente la incertidumbre causada por las medidas. Los 3 campos que se crearon en la Activi-

Página 81



dad de prueba facilitaron el levantamiento y análisis de los datos.

.

9.2. Lectura de la Ubicación del Usuario

Los datos tomados cumplieron con ciertos criterios:

Al menos un punto debe ser registrado fuera de la zona de aceptación del evento.

Al menos un punto debe ser registrado dentro de la zona de aceptación del evento

Al menos un punto debe ser registrado lo más cercano al borde de la zona de acepta-

ción del evento.

Cada punto que se registre debe ser tomado utilizando tanto WiFi como 3G.

En las ubicaciones que se encuentren al aire libre también se tiene que utilizar el uso

del GPS.

En total se registraron 8 puntos, cada uno utilizando las combinaciones posibles de métodos

de ubicación. Para desplegar los resultados se tuvieron en cuenta las convenciones expuestas

en la Tabla 10:

Convención DescripciónN/A Cuando se toman los datos de un punto cubierto,

el GPS no funciona. Por eso la toma de ese punto No Aplica.

- No se logró obtener mediciones por cuestiones de latencia.

Casilla Verde La ubicación del usuario se encuentra dentro de la zona de aceptación del evento.

Casilla Roja La ubicación del usuario se encuentra fuera de la zona de aceptación del evento.

Tabla 10 - Convenciones utilizadas en los resultados de Confiabilidad del Proyecto.

En la Tabla 11 se presenta un resumen de los puntos que fueron registrados dentro de las

pruebas. Cada uno de ellos fue estratégicamente escogido para que cumpliera condiciones

específicas. Dos puntos fueron registrados utilizando el GPS y los demás utilizando WiFi y

Página 82


3G. A partir de las distancias que registraron se puede deducir un porcentaje de error entre los

métodos de ubicación del celular. Esto permitió evaluar que tan confiable eran los métodos de

ubicación para hacer check-in.

Página 83



GPS WiFi 3GLat Lng Distancia (m) Lat Lng Distancia (m) Lat Lng Distancia (m)

Cafetería Central Universi-dad 4,6285353 -74,064987 85,4231021 4,628235

2 -74,064779 98,3770105 4,6282335 -74,0651292 120,0153501

Tercer piso del Edificio Central N/A N/A N/A 4,6282335 -74,0647765 90,6909901 - - -

Playa de Ingeniería 4,6271142 -74,0638876 196,4253081 4,6272063 -74,0640431 206,6037097 4.6264231 -74.0648211 294,0235502

Departamento de Ingenie-ría de Sistemas N/A N/A N/A 4,626944 -74,0640504 235,9843733 - - -

Cafetería Parqueaderos Javeriana N/A N/A N/A 4,6282283 -74,0632976 154,8212243 4.6278641 -74.0626180 236,5032110

Sexto Piso Edificio José de Carmen Acosta N/A N/A N/A 4,628345 -74,0637092 108,2131216 4,6282335 -74,0637092 198,0215766

Tabla 11 - Resultados de las Pruebas de Validación

Evaluar este aspecto de confiabilidad en la aplicación es de vital importancia dentro de la idea de negocio expuesta en la estrategia de m-Commerce ya que este asegura que los usuarios estén tomando fotos en donde deben y no estén aprovechando las desventajas de las tecnologías para irrumpir en la experiencia general que quiere ser generada en la aplicación

Página 84


9.3. Análisis de los Resultados Documentados

La Tabla 5 de la anterior subsección contiene información que pone a prueba cada tecnología

inalámbrica en la que un dispositivo móvil tiene acceso a servicios de localización. Como el

método de localización más preciso es el GPS se parte de sus resultados para evaluar la preci-

sión de los demás puntos. En dado caso de que no se haya podido extraer puntos con GPS

porque se encuentra en una ubicación interior, se procede a evaluar el segundo método de

localización más preciso (WiFi).

Tabla 12 - Resultados de Precisión de Métodos de Ubicación

La Tabla 13 muestra los porcentajes de precisión resultantes de la prueba de campo. Hubo

dos puntos que no se pudieron evaluar dado a errores de latencia y configuraciones de ti-

Página 85



meout del dispositivo móvil. Para extraer el porcentaje de error entre los puntos se utilizó la

siguiente formula:

% Error=|distanciareferente−distanciaobtenidadistanciareferente |∗100 %

Luego, entre los porcentajes de precisión se hizo una media de error por método de ubicación

y se dedujo el desfase en metros de esta forma:

Desfase del Borde=radio de aceptación del evento× error de precisiónmedio

La diferencia de error de precisión entre los métodos de ubicación es considerablemente alta

lo cual hace que haya problemas de confiabilidad cuando un usuario accede a un evento cu-

bierto y sólo dispone de redes móviles (3G) para acceder a su ubicación.

Otro factor que influenció en la toma de datos fue la cantidad de estos. No se esperaba que

algunos datos no pudieran ser extraídos durante el experimento, lo cual hizo que se trabajara

con un espacio de muestra reducido. Este acontecimiento se muestra en la Ilustración 21.

Página 86


67%

33%

Resumen de Datos ExtraidosDatos Correctos Datos Fallidos

Ilustración 21 - Resumen de datos extraídos

Por este imprevisto, el espacio de muestra se redujo en un 33%. Esto perjudica la exactitud de

las conclusiones a las que se puede llegar ya que los porcentajes de error pueden ser mucho

mayores. Para futuras experiencia se recomienda tomar más datos con las 3 tecnologías.

Página 87



V – CONCLUSIONES, RECOMENDACIONES Y TRABAJOS FUTUROS

1. Conclusiones

Se logró cumplir el objetivo general y todos los objetivos específicos propuestos en el

Trabajo de Grado. En esta sección se presenta las dimensiones que atacó la Estrategia de

Comercio Móvil propuesta a lo largo del proyecto.

I. Liderazgo TecnológicoEl liderazgo Tecnológico identificó la adopción temprana de la tecnología emer-

gente a la idea de negocio utilizando metodologías ágiles de generación de Mo-

delos de Negocio, metodologías ágiles de desarrollo de Software y el manejo de

versiones de código.

II. Infraestructura

La infraestructura se observó desde percepciones estratégicas y organizacionales.

La percepción estratégica consideró (en el BMS), la posibilidad de incorporar

socios clave que aseguraron disponibilidad, balanceo de carga y desempeño ne-

cesarios para implementar el prototipo de la manera más económica posible. La

percepción organizacional alineó las prácticas de trabajo y el flujo de los proce-

sos para ejecutar los objetivos del proyecto con eficiencia y eficacia (ver Ilustra-

ción 9).

III. Servicio

Se evaluaron los factores que determinaron si la propuesta de valor era viable a

partir del prototipo desarrollado. Se dedujo que el buen servicio de la aplicación

dependía de la confiabilidad del sistema y se diseñaron pruebas de validación que

generaron información relevante con respecto a la conectividad y forma de acce-

so de la aplicación móvil. En conclusión, la aplicación es viable tanto para Even-

tos al aire libre como para Eventos cubiertos. Sin embargo, en un Evento cubier-

to, la aplicación debe hacer uso de WiFi.

Página 88


IV. Mercado

Se logró identificar, entender, segmentar y clasificar el mercado objetivo del

Modelo de Negocio. Además se diseñaron dinámicas, mecánicas y componentes

que enriquecieron la forma en cómo se mide el nivel de compromiso del usuario

con la aplicación.

Como conclusión general, cada uno de los entregables que se presentaron y la relación

entre ellos demostraron que la estrategia de comercio móvil que se diseñó fue integral y

completa. Asimismo, se logró abarcar la fase inicial en el proceso de desarrollo de una

EBT, incorporando procesos de creación y administración de Modelos de Negocio con

Ingeniería de Software.

2. Recomendaciones

Es de vital importancia tener en cuenta que hacer Trabajos de Grado con enfoque en creación

de Empresas de Base Tecnológica requiere de trabajo que incorpore Modelos de Negocio y

Pruebas de Concepto (o creación de un prototipo funcional). Por eso se recomienda tener muy

clara la idea antes de ejecutarla.

Por otra parte, las Técnicas de Gamification, por más útiles que sean para generar motivación

intrínseca en los usuarios, siguen siendo estrategias de alto nivel. Es decir que, en términos de

Ingeniería de Software, la capa de desarrollo que provee el framework es de las últimas a

implementar. Es por eso que si se quiere “Gamificar” completamente algún proceso o aplica-

ción en tan poco tiempo, se recomienda que el producto ya exista.

3. Trabajos Futuros

Para darle continuidad al Trabajo de Grado se propone:

I. Investigación en Algoritmos de Inteligencia ArtificialComo se concluyó, la aplicación no es viable para cuando se quiere interactuar con la

plataforma en eventos internos utilizando tecnología 3G. Por eso, sería ideal hacer un

algoritmo de aprendizaje que a partir de los check-ins y la tecnología con la que se

Página 89



hicieron aproxime y deduzca si un usuario intentando tomar una foto se encuentra

dentro de la zona de aceptación del evento.

II. Diseñar e implementar Eventos Públicos en la PlataformaEl alcance del proyecto dio abasto para implementar únicamente los Eventos Públi-

cos de la Idea de Negocio. Se puede extender el prototipo funcional incorporando los

Eventos Públicos al Prototipo.

Página 90


VI - REFERENCIAS Y BIBLIOGRAFÍA

Referencias

[1] R. K. Koshal, «Economies of Scale,» Journal of Transport Economics and Policies, 1972.

[2] B. S. Srinivasan, Merket Research, Wireframing and Design, Stanford, 2013.

[3] eMarketer, «eMarketer,» [En línea]. Available: http://emarketer.com/Article/Smart-phones-Continue-Gain-Share-US-Mobile-Usage-Plateaus/1008958.

[4] Return Path, «returnpath,» [En línea]. Available: www.returnpath.com/resource/email-mostly-mobile/?utm_source=tsather&utm_medium=blog&utm_campaign=mostlymo-bile.

[5] Ministerio de Tecnologías de la Información y las Comunicaciones, «MinTIC,» [En línea]. Available: http://www.mintic.gov.co/index.php/mn-news/1928-mintic-acerca-a-los-emprendedores-tic-con-grandes-empresarios.

[6] Google Inc., «Google Developers,» [En línea]. Available: https://developers.google.-com/appengine/docs/quotas.

[7] Amazon, «Amazon Web Services,» [En línea]. Available: http://aws.amazon.com/es/s3/pricing/.

[8] Bizagi, «Bizagi BPMN 2.0».

[9] A. Osterwalder y Y. Pigneur, «Business Model Generation,» John Wiley & Sons, Inc..

[10] Microsoft Corp., «On the Integration of Human Computation int Traditional Business Processes,» Redmond, 2011.

[11] Metropolitan Chicago Healthcare Council, «Social Media and Healthcare Today,» 2011.

Página 91



[12] R. Perkins, «Net Hosting,» [En línea]. Available: http://www.nethosting.com/buzz/blog/foursquare-case-study/.

[13] N. Sadeh, M-Commerce: Technologies, Services, and Business Models, 2002.

[14] B. Skiba, M. Johnson y M. Dillon, «Lehman Brothers,» 2000. [En línea].

[15] R. Plant, eCommerce formulación de una Estrategia, Prentice Hall.

[16] F. Lehner, «From E-Commerce to M-Commerce: Research Directions,» 2001.

[17] D. E.L., «Intrinsic motivation and self-determination in human behavior.,» Plenum, 1985.

[18] J. McGonigal, «JaneMcGonigal.com,» 2013 6 6. [En línea]. Available: www.janemc-gonigal.com.

[19] M. Jane, «Reality is Broken: Why Games Makes Us Better and How They Can Change the World,» de Reality is Broken: Why Games Makes Us Better and How They Can Change the World, Penguin, 2011, pp. 22-23.

[20] K. Werbach, Dirección, Gamification Course - Coursera. [Película]. USA.2012.

[21] G. Z. &. C. Cunningham, Gamification by Design: Implementing Game Mechanics in Web and Mobile Apps, O'Reilly Media, 2011.

[22] D. H. Kevin Werbach, For The Win: How game thinking can revolutionize your Busi-ness, Philadelphia: Wharton Digital Press, 2012.

[23] H. Huang, «Supporting Smart Mobile Navigation in a Smart Environment,» de Loca-tion-Based Services Handbook, Boca Ratón, CRC Press, 2011, pp. 109-129.

[24] M. Singhai y A. Shukla, «Implementation of Location Based Services in Android using GPS and Web Services,» International Journal of Computes Science Issues (IJCSI), p. 6, 2012.

[25] I. Sommerville, Ingeniería de Software, Madrid: Pearson Addison Wesley, 2005.

Página 92


[26] S. Palmer, A Practical Guide to Feature-Driven Development, Prentice Hall.

[27] P. C. Peter Eeles, The Process of Software Architecting, Boston: Pearson Education, Inc., 2010.

[28] Canvanizer, «http://canvanizer.com/,» [En línea]. Available: http://canvanizer.com/.

[29] T. Eisenmann, «Platform Envelopment,» Strategic Management Journal Vol 32, 2011.

[30] ISTAR, Plantilla HACER & USOS.

[31] Wikipedia, «wikipedia.org,» [En línea]. Available: http://en.wikipedia.org/wiki/Haver-sine_formula.

[32] C. D. Universitario, «Pontificia Universidad Javeriana - Misión,» Acuerdo No. 0066, 22 Abril de 1992, 2012. [En línea]. Available: http://www.javeriana.edu.co/puj/oracle/mision.html. [Último acceso: 2012].

[33] M. L. R. Z. Robin Hunicke, "MDA: A Formal Approach to Game Design and Game Research," Game Developer's Conference, p. 5, 2004.

[34] D. J. Paul, Android How to Program, New Jersey: Prentice Hall, 2013.

[35] M. d. E. Nacional, «03 Portal,» 2011. [En línea]. Available: http://www.graduadosco-lombia.edu.co:8080/o3portal/viewdesktop.jsp?cmnd=open&source=Situacion+Laboral%2FVinculaci%F3n+2011+-+Ingreso+y+Tasa+de+Cotizantes+por+Nivel+de+Forma-ci%F3n%23_public. [Último acceso: 2012].

[36] M. A. Labrador, Location-based information systems developing real-time tracking applications, Chapman and Hall, 2010.

[37] L. M. M. Joshua James Gonzáles Díaz, Análisis de Riesgos de Seguridad de la Infor-mación, Bogotá, 2012.

[38] IBM, «IBM Design Concepts: What is user experience Design?,» 02 08 2013. [En línea]. Available: http://www-01.ibm.com/software/ucd/designconcepts/whatisUX-D.html.

Página 93



[39] Z. M. K. C. K. G. Foong Li Law, «Gamification towards Sustainable Mobile Applica-tion,» de 5th Malaysian Conference in Software Engineering (MySEC), 2011.

[40] J. G. B. K. Y. David N. Crowley, «Gamification of Citizen Sensing through Mobile Social Reporting,» de International Games Innovation Conference, 2012.

[41] E. Castledine, M. Eftos y M. Wheeler, Build Mobile Websites and Appas for Smart Devices, Sitepoint, 2011.

[42] K. Beck, Extreme Programming Explained, 1999.

[43] Anónimo, «Plan Nacional de Desarrollo 2010-2014 Prosperidad para todos,» Alcaldía, Bogotá D.C., 2010.

[44] Bunchball Inc., «USA Networ's Club Psych,» 2010.

[45] Google Inc., Official Google Blog.

[46] Insight Analysis, «Insight Analysis,» 21 7 2010. [En línea]. Available: http://insight-analysis.wordpress.com/2010/07/21/facebook-dau-and-mau-what-they-tell-you-and-what-they-dont/.

Página 94


VII - ANEXOS

Anexo 1. Business Model Canvas

Anexo 2. Software Requirements Specification

Anexo 3. Software Architecture Document

Anexo 4. Estrategia de Gamification

Página 95



Anexo 5. Post-Mortem10. Metodología propuesta vs. Metodología realmente utilizada.

La metodología que se utilizó fue un proceso definido con notación BPMN. Como durante el

desarrollo del proyecto sólo hubo un interesado no se encontró utilidad en manejar metodolo-

gías de ciclo de vida complejas. En términos de desarrollo de Software y creación del Modelo

de Negocio, se siguió la metodología propuesta al pie de la letra.

11. Actividades propuestas vs. Actividades realizadas.

Las actividades propuestas corresponden en un 100% con las actividades realizadas durante

el proyecto.

12. Efectividad en la estimación de tiempos del proyecto

Los tiempos del proyecto correspondieron con el cronograma propuesto. Se hizo entrega de

todos los documentos y se obtuvieron los resultados esperados.

13. Costo estimado vs. Costo real del proyecto

Los costos se redujeron en un % porque no hubo necesidad de pagar por los servicios en la

nube ni por el diseñador gráfico.

Página 96


14. Efectividad en la estimación y mitigación de los riesgos del proyecto.

Los riesgos no interfirieron con la realización del trabajo de grado. Estos fueron mitigados

utilizando los controles expuestos en la Propuesta de Trabajo de Grado.

Página 97


Documents

Propuesta para Trabajo de Grado - …pegasus.javeriana.edu.co/.../entregables/Memoria_Alejan… · Web viewThe boom of mobile technologies and entrepreneurship around the world