UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INFORMÁTICA

GRADO EN INGENIERÍA INFORMÁTICA

TRABAJO FIN DE GRADO

PideMeTú pides, nosotros servimos

José Juan Ramírez de Arellano Díaz Miguel

Julio, 2014

PIDEMETÚ PIDES, NOSOTROS SERVIMOS

UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INFORMÁTICA

Tecnologías y Sistemas de Información

TECNOLOGÍA ESPECÍFICA DE

TECNOLOGÍAS DE LA INFORMACIÓN

TRABAJO FIN DE GRADO

PideMeTú pides, nosotros servimos

Autor: José Juan Ramírez de Arellano Díaz Miguel

Director: David Vallejo Fernandez

Julio, 2014

José Juan Ramírez de Arellano Díaz Miguel

Ciudad Real – Spain

E-mail: JoseJuan.RamirezArellano@alu.uclm.esTeléfono: 684 071 089

c© 2014 José Juan Ramírez de Arellano Díaz Miguel

Permission is granted to copy, distribute and/or modify this document under the terms of the GNUFree Documentation License, Version 1.3 or any later version published by the Free SoftwareFoundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copyof the license is included in the section entitled "GNU Free Documentation License".Se permite la copia, distribución y/o modificación de este documento bajo los términos de laLicencia de Documentación Libre GNU, versión 1.3 o cualquier versión posterior publicada porla Free Software Foundation; sin secciones invariantes. Una copia de esta licencia esta incluida enel apéndice titulado «GNU Free Documentation License».Muchos de los nombres usados por las compañías para diferenciar sus productos y servicios sonreclamados como marcas registradas. Allí donde estos nombres aparezcan en este documento, ycuando el autor haya sido informado de esas marcas registradas, los nombres estarán escritos enmayúsculas o como nombres propios.

i

TRIBUNAL:

Presidente:

Vocal:

Secretario:

FECHA DE DEFENSA:

CALIFICACIÓN:

PRESIDENTE VOCAL SECRETARIO

Fdo.: Fdo.: Fdo.:

iii

Resumen

El presente documento es un ejemplo de memoria del Trabajo de Fin Grado según elformato y criterios de la Escuela Superior de Informática de Ciudad Real. La intención esque este texto sirva además como una serie de consejos sobre tipografía, LATEX, redacción yestructura de la memoria que podrían resultar de ayuda. Por este motivo, se aconseja al lectorconsultar también el código fuente de este documento.

Este documento utiliza la clase LATEX esi-tfg, disponible como paquete Debian/Ubuntu,consulta:

https://bitbucket.org/arco group/esi-tfg.

Si encuentra cualquier error o tiene alguna sugerencia, por favor, utilice el issue trackerdel proyecto esi-tfg en:

https://bitbucket.org/arco group/esi-tfg/issues

El resumen debería estar formado por dos o tres párrafos resaltando lo más destacabledel documento. No es una introducción al problema, es decir, debería incluir los logros másimportantes del proyecto. Suele ser más sencillo escribirlo cuando la memoria está práctica-mente terminada. Debería caber en esta página (es decir, esta cara).

V

Abstract

English version of the previous page.

VII

Agradecimientos

Escribe aquí algunos chascarrillos simpáticos. Haz buen uso de todos tus recursos litera-rios porque probablemente será la única página que lean tus amigos y familiares. Deberíacaber en esta página (esta cara de la hoja).

Juan1

1Sí, los agradecimientos se firman

IX

Lo difícil se consigue, lo imposible sólo se intenta

xi

Índice general

Resumen V

Abstract VII

Agradecimientos IX

Índice general XIII

Índice de cuadros XVII

Índice de figuras XIX

Índice de listados XXI

Listado de acrónimos XXIII

1. Introducción 1

1.1. La tecnología móvil en nuestras vidas . . . . . . . . . . . . . . . . . . . . 2

1.2. Apps a la orden del día . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3. Visión general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2. Objetivos 9

2.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2. Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Estado del Arte 13

3.1. El mundo de las apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1. Evolución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.2. Plataformas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.3. Apps nativas vs WebApps . . . . . . . . . . . . . . . . . . . . . . 19

3.1.4. Lenguajes de programación . . . . . . . . . . . . . . . . . . . . . 20

XIII

3.2. Apps para la venta de productos y servicios . . . . . . . . . . . . . . . . . 22

3.2.1. Visión general . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.2. Restaurantes y locales de ocio . . . . . . . . . . . . . . . . . . . . 22

3.3. Servicios Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.2. Principales alternativas . . . . . . . . . . . . . . . . . . . . . . . . 28

4. Método de trabajo 33

4.1. Metodología de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.1. Aplicación de la metodología . . . . . . . . . . . . . . . . . . . . 35

4.2. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2.1. Lenguajes de programación . . . . . . . . . . . . . . . . . . . . . 35

4.2.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.3. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5. Arquitectura 39

5.1. Descripción general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2. Módulo de gestión de locales . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.2.1. Submódulo de obtención de datos de locales . . . . . . . . . . . . 42

5.2.2. Submódulo de lectura de códigos QR . . . . . . . . . . . . . . . . 43

5.2.3. Submódulo de gestión de base de datos de locales . . . . . . . . . . 43

5.3. Módulo de gestión de productos . . . . . . . . . . . . . . . . . . . . . . . 45

5.3.1. Submódulo de obtención de datos de productos . . . . . . . . . . . 45

5.3.2. Submódulo de gestión de base de datos de productos . . . . . . . . 46

5.4. Módulo de gestión de compras . . . . . . . . . . . . . . . . . . . . . . . . 47

5.4.1. Submódulo de gestión de pedidos . . . . . . . . . . . . . . . . . . 48

5.4.2. Submódulo de envío de pedidos . . . . . . . . . . . . . . . . . . . 48

5.5. Módulo de localización . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.5.1. Submódulo de posicionamiento en mapa . . . . . . . . . . . . . . 50

5.5.2. Submódulo de ruta en mapa . . . . . . . . . . . . . . . . . . . . . 51

5.6. Módulo de análisis de interacción y pruebas . . . . . . . . . . . . . . . . . 52

5.7. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.8. Patrones de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.8.1. Modelo Vista Presentador . . . . . . . . . . . . . . . . . . . . . . 57

5.8.2. Data Access Object . . . . . . . . . . . . . . . . . . . . . . . . . . 58

xiv

6. Evolución, resultados y costes 59

6.1. Evolución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.1.1. Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.1.2. Evolución temporal . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.2.1. Caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.2.2. Análisis de uso de PideMe . . . . . . . . . . . . . . . . . . . . . . 64

6.2.3. Estadísticas del proyecto . . . . . . . . . . . . . . . . . . . . . . . 65

6.2.4. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.3. Costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.3.1. Análisis, diseño y desarrollo . . . . . . . . . . . . . . . . . . . . . 66

6.3.2. Implantación en un entorno real . . . . . . . . . . . . . . . . . . . 67

6.3.3. Monetización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.3.4. Cuota mensual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7. Conclusiones 73

7.1. Objetivos alcanzados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.2. Propuestas y trabajo futuro. . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.3. Valoración personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

A. Ejemplo de anexo 81

Referencias 83

xv

Índice de cuadros

3.1. Comparativa Apps Nativas vs WebApps . . . . . . . . . . . . . . . . . . . 24

3.2. Lenguajes más utilizados a Abril de 2014 . . . . . . . . . . . . . . . . . . 24

3.3. App McDonalds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4. App Telepizza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.5. App Domino’s Pizza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.6. App Foster’s Hollywood . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.1. Estadísticas del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.2. Coste total del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.3. Tarifas de transacción en PayPal . . . . . . . . . . . . . . . . . . . . . . . 69

6.4. Cuotas de inclusión en PideMe . . . . . . . . . . . . . . . . . . . . . . . . 70

6.5. Ejemplo de implantación . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

XVII

Índice de figuras

3.1. Crecimiento apps en 2013 . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2. Sistemas operativos móviles en 2013 . . . . . . . . . . . . . . . . . . . . . 15

3.3. Fragmentación en Android . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4. Actualización Android vs iOs . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5. Telepizza. Categorias y realización de pedido . . . . . . . . . . . . . . . . 25

3.6. Domino’s Pizza. Categorias y realización de pedido . . . . . . . . . . . . . 25

3.7. Foster’s Hollywood. Sugerencias y localización de restaurantes . . . . . . . 26

3.8. Rodilla. Registro de puntos. . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.9. Llaollao. Información y localización de tiendas. . . . . . . . . . . . . . . . 27

4.1. Proceso de trabajo con Desarrollo Incremental . . . . . . . . . . . . . . . . 34

5.1. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.2. Dashboard de Firebase. Locales. . . . . . . . . . . . . . . . . . . . . . . . 43

5.3. Código QR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.4. Etiqueta QR. Local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.5. PideMe. Captura de listado de productos . . . . . . . . . . . . . . . . . . . 45

5.6. Dashboard de Firebase. Local de ejemplo. . . . . . . . . . . . . . . . . . . 46

5.7. PideMe. Captura de localización . . . . . . . . . . . . . . . . . . . . . . . 50

5.8. Dashboard de Firebase. Administración. . . . . . . . . . . . . . . . . . . . 52

5.9. PideMe. SlidingPaneLayout. . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.10. Capturas PideMe. De izquierda a derecha. Arriba: Local, Productos y Mipedido. Medio: Ubicación, Como llegar y Leer mesa. Abajo: Mis locales,Mis pedidos y Acerca de. . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.11. MVP Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.1. Iteraciones en el desarrollo del sistema . . . . . . . . . . . . . . . . . . . . 60

6.2. Actividad del repositorio . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

XIX

Índice de listados

5.1. SQLiteHelper. Creación de Base de datos de locales . . . . . . . . . . . . . 44

5.2. Firebase. Obtención de productos de un local. . . . . . . . . . . . . . . . . 47

5.3. PayPal. Pago de un pedido. . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.4. Firebase. Envío de pedido. . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.5. Layout de mapas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.6. Intent Google Maps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.7. PideMe. Layout Principal. . . . . . . . . . . . . . . . . . . . . . . . . . . 54

XXI

Listado de acrónimos

XXIII

Capítulo 1

Introducción

E N los últimos años, el constante desarrollo de las tecnologías móviles ha llevado aconvertirlas en algo indispensable en nuestra vida diaria. La llegada de dispositivos

móviles que hacen uso de estas tecnologías ha generado una demanda de contenidos digi-tales que deben ser adaptados para diferentes plataformas móviles. El uso de dispositivosmóviles en la actualidad simplifica nuestras actividades cotidianas, facilitando nuestros tra-bajos, estudios o simplemente ocio con las innumerables aplicaciones existentes que se hanido incrementando con el paso del tiempo, sumando a todo esto el ahorro en términos detiempo o movilidad que conlleva su uso.

Actualmente, el negocio de aplicaciones móviles para Smartphones, Tablets e inclusoSmartTVs se encuentra en constante crecimiento siendo España el país de Europa con mayorpenetración de Smartphone [Dat13], en el cual se descargan de manera diaria 4 millones deaplicaciones móviles1 en los markets virtuales de las distintas plataformas. Esto provoca quesea cada vez más frecuente que el usuario haga uso de apps para realizar tareas de su vidadiaria, y por tanto aumenta la importancia en el negocio de una empresa el hecho de disponerde una app para facilitar la vida del usuario. Es por todo esto que cada vez es más importantepara las empresas la presencia en los diferentes markets de apps, dado su elevado consumo yuso así como todas las consecuencias positivas que conlleva, haciendo que la entrada de unaempresa con triunfo en el mercado de las apps incremente sus beneficios de forma bastanteconsiderable asumiendo los gastos que conlleva el desarrollo de apps para distintas plata-formas móviles, como desarrollo, hosting, servidor y QA, además de publicidad en algunoscasos.

A pesar de la cantidad de apps disponibles en los diferentes markets virtuales, podemosencontrar campos en los que su presencia sea un tanto escasa o poco explotada actualmente.Uno de estos campos podría ser la gestión de compra/venta para restaurantes y locales deocio, ya que dadas las facilidades que nos proporcionan las apps resulta interesante aprove-charlas para ahorrar tiempo en realizar una transacción, poder visualizar todos los detallesde una compra, así como la posibilidad de realizar tanto el pago como el envío de pedidosa través de nuestro Smartphone y en una misma app. En el contexto de los locales de ocio,

1apps en el resto del documento

1

resulta interesante su aplicación para la gestión de pedidos, así como el pago de estos a travésuna misma app, personalizada y adaptada para un entorno de este tipo. Este Trabajo Fin deGrado propone el desarrollo de una app, en la parte del cliente, para la gestión de pedidos enrestaurantes y locales de ocio.

1.1 La tecnología móvil en nuestras vidasEspaña se ha convertido en el país europeo con mayor penetración de Smartphone con una

tasa del 66 % [Dat13]. Las tecnologías móviles han cambiado nuestra forma de relacionar-nos, de realizar las tareas cotidianas, de informarnos y, en resumen, han llegado a todos losrincones de nuestras vidas.

Algunos de los más recientes estudios concluyen que en el caso de España el 98 % delos hogares tiene cobertura de banda ancha, y que más del 20 % se conecta a través de sudispositivo móvil. La media que los españoles pasamos conectados al móvil es de 24 horas ala semana, y en el caso de los más jóvenes de edad el 41 % está siempre conectado. El 72 % delos usuarios que poseen un teléfono móvil no lo apaga para dormir, y el 80 % no se despegadel mismo durante la comida. Uno de cada tres lo usa en el baño y un 75 % no lo desconectapara ligar o practicar sexo. Solo un 1,5 % se lo deja en casa cuando se va de vacaciones.Todo esto teniendo en cuenta que en España hay 52 millones de líneas de teléfonos móviles,siendo 47 millones de españoles. De estos millones de habitantes en España, 18 son usuariosactivos de Facebook y 13 de ellos se conectan a esta a través de su móvil. Descata también elhecho de que el 100 % de los menores de 13 años usa el ordenador a diario. Con todo esto,los españoles gastan más de 34.000 millones de euros en tener teléfono, internet o televisiónde pago [WeP13].

En el IV Estudio sobre Mobile Marketing de IAB Spain y The Cocktail Analysis [Spa13]se pueden extraer algunos datos significativos como que el 52 % de los internautas españolestiene un Smartphone y el 77 % se conecta a diario. El uso de Tablet crece situándose entorno al 23 % de penetración, 15 puntos más que en 2011; y que el 38 % de los internautasespañoles utiliza habitualmente códigos QR, un 110 % más que en 2011, que era sólo deun 18 %. En cuanto al uso de dispositivos móviles en España se obtuvieron las siguientesconclusiones. Entre los dispositivos de acceso a Internet más usados por los usuarios seencuentra el Smartphone con un 59 %, el ordenador portátil con un 86 % y el ordenadorde sobremesa con un 77 %. Destaca también el incremento notable del acceso a Internet enmovilidad que del 57 % en 2009, se sitúa actualmente en torno al 82 %, por lo que 8 de cada10 internautas accede a Internet desde el móvil.

En lo que respecta a los lugares de acceso y actividad, teniendo en cuenta los datos deSmartphone y tablets, en casa su uso se eleva hasta un 71 % y 91 % respectivamente. Enotros lugares como transporte público, trabajo o bares y restaurantes encontramos un 41 %,36 % y 36 % respectivamente en el uso de Smartphone, mientras que en el uso de Tablet

2

encontramos un 38 %, 39 % y 35 %. De especial importancia destaca el tipo de actividaddependiendo del dispositivo desde el cual accedemos. En el caso del Smartphone el usoprincipal es el correo electrónico con un 81 %, seguido de chat 80 % y redes sociales con un74 %. Más lejos se encuentra la búsqueda de información y prensa con un 49 %. Por el ladode las tablets destaca de igual forma el uso de correo electrónico con un 74 %, seguido deredes sociales 68 %, prensa y audiovisuales 60 % y juegos con un 53 % [blo13b].

Todos estos dispositivos móviles hacen uso de un sistema operativo para que el usuariopueda realizar sus tareas de una forma rápida y sencilla. En función del lugar en el que haga-mos uso de ellos encontramos bastantes diferencias en el tipo de sistema operativa a utilizar.En el IV Estudio sobre Mobile Marketing de IAB Spain y The Cocktail Analysis [Spa13] seobtuvieron las siguientes conclusiones en el sistema operativo que se usa en el dispositivoprincipal de trabajo. En el caso de ordenadores de sobremesa, destaca el uso de Windows conun 92 %, con una diferencia bastante pronuncia respecto a MacOs y distribuciones libres conun 3 % y 4 % respectivamente. Lo mismo ocurre con ordenadores portátiles donde Windowsse sitúa con un 87 %, pero en este caso se destaca la cuota de mercado de portátiles Apple quese sitúa en el 9 %. Más igualdad encontramos en el mercado de Smartphone donde Androide iOS se sitúan con un 37 % y 34 % respectivamente, seguidos por otros como WindowsPhone, Symbian o Blackberry con un 23 %. Por último en el caso de Tablet, destaca el usode iOs con un 58 % frente a un 23 % de su perseguidor Android. Como dato significativo,Blackberry controla el 15 % de la cuota global de Smartphone de empresa, y el 26 % se usanen el sector financiero.

También se destaca en este estudio los deseos adquisitivos por parte de los trabajadores pa-ra adquirir nuevos dispositivos móviles para su lugar de trabajo. En el caso de los Smartphone208 millones de trabajadores desearían adquirir un iPhone. Por el contrario, 200 millones detrabajadores desearían adquirir una Tablet con Windows como SO.

1.2 Apps a la orden del día

Actualmente, en España se descargan de manera diaria en torno a 4 millones de apps entrelos distintos Store digitales disponibles [1], con más de 22 millones de usuarios activos. Unnegocio que factura más de mil millones al año y que sitúa a España en la cima en cuan-to a penetración de Smartphone. El enorme consumo de apps que realizamos a diario haceposible que encontremos campos en los que la “sobreexplotación” de las mismas nos per-mita encontrar miles de apps que realizan una función similar ó muy parecida. Esto ocurreen campos como la información, la comunicación, redes sociales o educación entre otros. Adiario hacemos usos de millones de apps en todo el mundo que tienen que ver con la infor-mación en tiempo real de todo lo que ocurre a nuestro alrededor, como consultar las últimasnovedades de nuestro artista favorito, ver los goles del último partido de nuestro equipo, vi-sualizar las fotos de la última excursión de nuestros amigos en alguna de las cientos de redes

3

sociales disponibles a día de hoy o simplemente intentar aprender un nuevo idioma con al-guna de las apps de cursos. Aplicaciones que nos mantienen actualizados de lo que ocurre anuestro alrededor y que, en muchos casos, sustituyen al contacto directo entre personas, quenos permiten disfrutar de un ahorro de tiempo considerable en realizar consultas, ó simple-mente simplifican la forma de realizar diferentes tareas ó comportamientos de nuestra vidadiaria. Todo lo contrario ocurre en otros campos de nuestra rutina que aún no se encuentranmuy poblados por estas app, como puede ser realizar la compra diaria en un supermercado,coger cita para la próxima revisión médica ó la realización de un pedido en un local de ocio.Al igual que las redes sociales nos facilitan la comunicación entre personas, y nos hacenposible que dos personas situadas en cualquier parte del mundo puedan comunicarse, en elsector del ocio no encontramos generalmente estas facilidades a la hora de hacer uso de lasapps disponibles para realizar la compra semanal en un supermercado ó gestionar un pedidoy el pago del mismo en un local de ocio repleto de gente.

El mundo de los locales de ocio es uno de los campos que potencialmente se puedenexplotar por parte de las nuevas tecnologías. La gestión de pedidos y cobros en este tipo delocales es uno de los aspectos fundamentales, por lo que es imprescindible que sea fácil,rápida y lo más eficiente posible, lo que se traduce en un aumento de la productividad dellocal y de forma directa de los beneficios. Entendiendo por gestión de pedidos la interacciónque se produce entre el cliente y el trabajador del local de ocio, resulta muy habitual el hechode llegar a un local, acomodarse en una de las mesas libres y esperar a ser atendido por algunode los trabajadores del mismo. Una vez que el pedido ha sido realizado el empleado del localdeber dirigirse a por el pedido para después volver a servirlo. Todo esto supone un tiempomedia de espera de unos 12 minutos, siendo inferior a 5 minutos en un caso óptimo, perollegando incluso a superar los 60 minutos en el peor de los casos. Se observa en el día adía de los locales de ocio, que el principal inconveniente es el que un trabajador del localse encuentre continuamente observando las nuevas peticiones que pueda surgir por parte delos clientes. La “pérdida” de tiempo que se produce en atender a los nuevos clientes, tomarnota de sus peticiones y preparar el pedido para ser servido, lo que lleva a que el tiempoempleado se duplique. Por tanto, se aprecia un importante desaprovechamiento por parte dela tecnología en este campo y, en concreto, de las tecnologías móviles, ya que ofrecen unainmensidad de posibilidades.

El tiempo empleado por el trabajador del local en tomar nota de los pedidos y servirlos, asícomo el tiempo de espera de los clientes, podrían verse reducidos de forma muy drástica sise hiciese uso de una app que gestionase los pedidos a través del Smartphone del cliente, enla cual realizase el pedido a través de su Smartphone y dicho pedido fuese recibido por partedel local en su aplicación de escritorio, donde visualizaría de manera inmediata el pedidocompletado y sólo debería preocuparse de servirlo lo más rápido posible al cliente.

Aprovechando las oportunidades que brinda el mercado de las aplicaciones móviles, el

4

local de ocio dispondría de una app móvil desde la cual el usuario podría consultar contodo lujo de detalles los productos disponibles, acompañando cada uno de ellos con unabreve descripción del mismo y una fotografía de presentación que ayudasen al cliente ensu elección. Podría realizar un pedido a través de la misma app y además realizar el pagode dicho pedido también a través de la app y de manera electrónica, por lo que sólo sepreocuparía de que el pedido fuese servido. Por parte del local de ocio, el trabajador dellocal no debería estar constantemente pendiente de las nuevas peticiones de pedidos quepuedan surgir y su única función sería la de servir los pedidos que reciba en su aplicaciónde escritorio enviadas por parte de los clientes a través de la app de su Smartphone. De estaforma se facilita al usuario la elección del producto elegido, ya que en todo momento puedevisualizar una imagen de presentación del producto acompañado de una breve descripcióndel mismo. Además el cliente puede tomarse todo el tiempo que desee en realizar su eleccióny no sentirse presionado por la presencia de un empleado del local que espera recibir elpedido de la forma más rápida posible. Otra de las ventajas es el tiempo de espera en seratendido, ya que estaría condicionando principalmente por la agilidad por parte del empleadodel local en servir los pedidos, así como por el número de personas que se encuentren en ellocal. Por parte del local de ocio se disminuiría el tiempo de espera en atender a los clientesdel local, ya que únicamente se encargaría de servir los pedidos recibidos en su aplicaciónde escritorio, por lo que aumentaría la productividad, se podría servir más pedidos con elmismo personal y, en consecuencia, aumentarían los ingreso del local. Todo esto sin contarque como consecuencia de que los pedidos sean servidos de manera más rápida, implica deuna forma directa que pueda pasar más gente por el local y por tanto sea posible facturar máspedidos con el consecuente aumento de ingresos.

Dicha solución sería beneficiosa para ambas partes: por parte del cliente porque veríareducido de forma considerable su tiempo de espera y por parte del local porque con elmismo personal sería capaz de servir mayor número de pedido y, por lo tanto generar, másingresos.

1.3 Visión general

Actualmente, existen problemas en el mundo de las apps en todos los markets virtualesdentro del ámbito de restaurantes y ocio y más concretamente en la gestión de compra/ventade pedidos. Resulta interesante la implantación de este tipo de apps dadas las facilidades quepodrían proporcionar como la reducción en tiempo en realizar una transacción, visualizar endetalle una compra, así como realizar el pago a través de una misma app. Aplicando todoesto a un restaurante o local de ocio mediante una app personalizada, se podría realizar tantola gestión de pedidos como el pago de los mismos a través de una app.

Facilitar a los clientes de un restaurante o local de ocio la interacción con el mismo, pu-diendo visualizar tanto los detalles de todos los productos como del local supone la adapta-

5

ción de un restaurante o local de ocio al campo de las apps. Un cliente llegaría al local, sesentaría en una de sus mesas y a través de su Smartphone mediante la app del local, podráen primer lugar ubicar su posición dentro del local mediante la lectura de un código QR queidentifica cada una de las mesas del local, y después visualizar los productos disponible en ellocal con la posibilidad de incluirlos al carro de la compra para realizar el pedido. Por último,el usuario podrá realizar el pago de su pedido a través de la misma app. Una vez completadotodo esto, el pedido será servido por un trabajador del local.

Con la adaptación del local al mundo de las apps, se facilita al usuario la elección de loque desea tomar ya que puede visualizar una fotografía del producto así como una brevedescripción del mismo. Además no se sentirá presionado por la presencia de un empleadodel local y el tiempo de espera para que su pedido sea servido se reduce. Por parte del localse puede destacar que con el mismo personal sería capaz de servir mayor número de pedidosy por tanto aumentar sus ingresos.

Teniendo en cuenta todo lo anterior, en este Trabajo Fin de Grado se describe una solu-ción al problema de la gestión y pago de pedidos en restaurantes y locales de ocio. La apppropuesta mostraría una descripción del local acompañada de una fotografía del mismo, asícomo un listado agrupado por categoría de todos los productos ofrecidos por el restaurante olocal. La app permitiría además realizar pedidos y el pago de los mismos.

El desarrollo de la aplicación se ha basado en un desarrollo ágil de software, más concre-tamente siguiendo la metodología Scrum. Por tanto se ha realizado un desarrollo iterativo eincremental. Además es escalable y modulable para facilitar su posterior migración a otrasplataformas o dispositivos. Todo esto es posible gracias a la aplicación del patrón de diseñoModelo-Vista-Presentador, que permite compartir el modelo entre todas las plataformas e in-cluso los presentadores cuando se pretende desarrollar una versión para un nuevo dispositivocon el mismo SO y por lo tanto sólo sería necesario implementar la parte de la vista.

La app se propone con una visión comercial para su futura explotación en locales de ocio,ya que la adaptación de un local para hacer uso de esta no es nada costosa, y sólo consistiríaen rellenar un modelo de la cual se alimenta la base de datos remota tanto para la descripcióndel local como para las categorías de productor que este quisiera ofrecer que después esconsumido y mostrado por la app. Además los datos podrían ser actualizados en cualquiermomento y serían ofrecidos en tiempo real al usuario, ya que la app haría uso de esta basede datos remota.

La solución planteada se centra en el desarrollo en la parte cliente de una aplicación parala plataforma móvil Android para Smartphone, siendo este el sistema operativo móvil másusado a nivel mundial. Su implementación seguiría un modelo de desarrollo que permitiríasu futura adaptación a la versión de Tablet. Además la adaptación a otras plataformas mó-viles haría uso de la misma base de datos remota, por lo que sólo sería necesario realizar la

6

adaptación de la app.

Por lo tanto, este Trabajo Fin de Grado pretende mejorar la interacción de locales deocio mediante una app, que facilitaría la realización de un pedido al usuario y aumentaríala productividad y por tanto los beneficios económicos de un local. Además su explotacióncomercial sería rápida y muy beneficiosa para el local.

1.4 Estructura del documentoEste documento ha sido elaborado siguiendo la normativa de Trabajo Fin de Grado (TFG)

en la Escuela Superior de Informática (ESI) de la Universidad de Castilla-La Mancha (UCLM).Está compuesto de los siguientes capitulos:

Capítulo 1: IntroducciónSe realiza una breve introducción del ámbito en el que se encuentra PideMe, así comoun breve descripción de la solución planteada al problema de la gestión de pedidos ypagos en restaurantes y locales de ocio.

Capítulo 2: ObjetivosSe describen los objetivos planteados que debe cubrir este Trabajo Fin de Grado. Sedescribe tanto el objetivo general como los objetivos específicos que ayudará a resol-ver.

Capítulo 3: Estado del arteSe realiza un estudio sobre la evolución del mundo de las Apps centrandose en lasApps para la venta de productos y servicios en las distintas markets virtuales disponi-bles.

Capítulo 4: Arquitectura de PideMeSe especifica la metodología utilizada en el desarrollo del proyecto. Además se analizacada uno de los submódulos en los que se divide la arquitectura.

Capítulo 5: Método de trabajoSe recoge la metodología utilizada para desarrollar este Trabajo Fin de Grado así comolas herramientas necesarias para su implementación

Capítulo 6: Evolución, resultados y costesSe detalla la evolución del proyecto, definiendo los sprints necesarios para el desa-rrollo del mismo. También se detallan los resultados obtenidos por el sistema y una

7

estimación del coste del proyecto.

Capítulo 7: Conclusiones y propuestasSe realiza una valoración general tanto del desarrollo de la aplicación como de losresultados obtenidos. Se expone la posible adaptación al mundo real y la futura explo-tación en otras plataformas. También se incluye una valoración personal de lo que hasupuesto el desarrollo de este Trabajo Fin de Grado

8

Capítulo 2

Objetivos

La motivación del presente Trabajo Fin de Grado, titulado PideMe. Tú pides, nosotros

servimos1, surge de la necesidad de mejorar calidad de atención, desde el punto de vista dela eficiencia, a los clientes de restaurantes y locales de ocio en el contexto específico de lagestión de pedidos y de pagos.

2.1 Objetivo generalEl principal objetivo de PideMe consiste en mejorar la calidad en el servicio a los clientes

de restaurantes y locales de ocio mediante una aplicación móvil que facilite la interacciónentre dichos actores, gestionando la forma mediante la cual se realizan los pedidos dentro deéstos y el modo en el que se realizan los pagos.

La aplicación gestionará de manera eficaz la forma en la que los clientes realizan sus pedi-dos en un restaurante o local de ocio con el único requisito de tener instalada la aplicación ensu smartphone pudiendo visualizar los productos ofrecidos y realizar un pedido directamentedesde ella, lo que mejora la atención al cliente que verá reducido el tiempo de espera en elque su pedido sea atendido. La aplicación debe ser extensible y configurable proporcionan-do la posibilidad de implantarla en cualquier restaurante o local de ocio de manera rápida ysencilla.

Una de las principales limitaciones en restaurantes y locales de ocio reside en que untrabajador permanace atento de forma continua a las nuevas peticiones que puedan surgirpor parte de los clientes, debiendo acudir a tomar nota de los nuevos pedidos y volver aprepararlos para terminar sirviéndolos en la mesa del cliente. Teniendo en cuenta que eltiempo de espera medio de un cliente en un restaurante hasta ser atendido es de 12 minutos[Coq12], observamos la ineficiencia en el método de gestión de pedidos con elevados tiemposde espera, agobio por parte del empleado del restaurante o local para anotar el pedido lo queimplica una menor calidad en la atención al cliente, y un desaprovechamiento de los recursoshumanos en cuestión de tiempo y eficiencia para servir un pedido. Todo este proceso podríamejorarse drásticamente gracias a las nuevas tecnologías, en especial tecnologías móviles yel uso de smartphones en restaurantes y locales de ocio.

1PideMe en el resto del documento

9

PideMe plantea solucionar este problema mediante la implantación de una aplicación mó-vil que facilite la forma en la que los clientes realizan sus pedidos dentro de un restaurante olocal de ocio y automatice la gestión de los mismos por parte del restaurante o local. El clien-te entraría a un restaurante o local, que se encuentra registrado y disponible en PideMe y, através de la app instalada en su smartphone y mediante la lectura de un código QR, identifi-cará el local en el cual se encuenta para, a continuación, mostrar en la app todos los detallesdel restaurante o local. A continuación se sentaría en una mesa que se encuentra identificadapor otra etiqueta QR y que sirve de localización dentro del local. El cliente puede visualizartodos los productos del local de forma relajada y con alto nivel de detalle, visualizando cadauno de los productos en una sugerencia de presentación y una descripción de preparación eingredientes que contiene. Por último el cliente podrá realizar un pedido con los productosque desee y que será recibido por el restaurante o local para poder servirlo. EL pago delpedido se podra realizar de forma electrónica a través de la propia app o de forma tradicionalen efectivo.

La implantación de PideMe supondría una considerable mejora de la calidad en la aten-ción al cliente, ya que no se encontraría agobiado en ningún momento por un empleado delrestaurante o local para realizar el pedido y se reducirían los tiempos de espera en servirlo.Además, supondría un ahorro de costes ya que con el mismo personal se podría servir unmayor número de pedidos lo que de forma directa se traduce en un aumento de la eficienciadel local y, por tanto, en un aumento de los ingresos obtenidos. Desde el punto de vista delcliente, éste vería reducido su tiempo de espera en servir su pedido, facilitando la realizaciónde un pedido y el pago del mismo a través de una sola app instalada en su smartphone. La in-teracción con la app será sencilla e intuitiva por parte del cliente y mejorará la productividady los beneficios por parte del restaurante o local de ocio.

En resumen, el objetivo principal de PideMe es mejorar la eficiencia respecto a la relaciónexistente entre restaurante y locales de ocio con sus clientes así como la gestión de pedidosdentro de ellos. La implantación de la app también podría ser extendida a otros ámbitos denegocio en un futuro, como supermercados en los que realizar la compra por medio de laaplicación y que sea enviada a casa, en estaciones de servicio en las que el tipo de combusti-ble y la cantidad sería elegida en la aplicación así como el pago del mismo, en el transportepúblico donde la compra de billetes se realizaría de forma electrónica o en la compra de en-tradas para eventos deportivos, conciertos o salas de cine en los que la aplicación contendríala entrada para los mismos.

2.2 Objetivos específicosA partir de este objetivo general surge una serie de objetivos específicos que detallan el

alcance del presente Trabajo Fin de Grado:

Incremento de la calidad del servicio de atención a clientes. La implantación de la

10

aplicación móvil PideMe en un restaurante o local de ocio supondría un incrementode la calidad en el servicio a clientes, cuya consecuencia principal el aumento de laeficiencia, ya que verían reducidos de forma considerable el tiempo de espera para queel pedido se sirva y la facilidad en la forma de pago del mismo que, además del métodotradicional, podrá realizar el pago de forma virtual a través de PideMe. Por tanto, losclientes recibirían un trato de más calidad, en menor tiempo y con más facilidad.

Facilidad de uso. Se pretende que el uso de PideMe sea fácil e intuitivo con un interfazy una navegación sencilla que guíe al cliente.

Ahorro de costes y retorno de la inversión. Con la implantación de PideMe en unrestaurante o local de ocio se produciría un ahorro de costes ya que con los mismosrecursos sería capaz de atender mayor cantidad de pedidos por lo que se obtendría unmayor beneficio. Además la inclusión de un nuevo restaurante o local de ocio supon-dría el ingreso de una cuota anual además de un pago por la implantación y puesta enmarcha de la aplicación.

Escalabilidad. La inclusión de nuevos restaurantes o locales de ocio en PideMe sedebería realizar de una forma rápida y sencilla sin que suponga cambios en la arqui-tectura. Se pretende conseguir que el sistema sea extensible, es decir que se permitadefinir la inclusión de nuevos restaurante o locales de manera sencilla, así como lamodificación de alguno de los restaurantes o locales ya existentes, sin afectar al restode la aplicación móvil.

Modularidad. La arquitectura de la aplicación estará formada por diferentes módulos,siendo cada uno de ellos lo más independiente posible y con unas responsabilidadesbien acotadas con el objetivo de obtener un acoplamiento bajo y una cohesión alta.Además se pretende que la arquitectura sea escalable para, en un futuro, poder añadirnuevos módulos con nuevas funcionalidades de forma sencilla sencilla.

Adaptabilidad. Diseño de una arquitectura adaptativa basada en el uso de patrones dediseño y que pueda ser fácilmente extensible.

Robustez. La aplicación deberá ser tolerante a fallos de manera que se recupere deerrores y pueda continuar operando con normalidad.

11

Capítulo 3

Estado del Arte

E N este capítulo se realizará un estudio acerca del estado del arte en las áreas de tra-bajo vinculadas directamente con la temática del presente Trabajo Fin de Grado. En

concreto, se estudiarán las diferentes plataformas móviles así como las apps más utiliza-das actualmente para la venta de productos y servicios a través del Smartphone. Respectoa la lógica del servidor, se realizará un estudio con los servicios web más influyentes en laactualidad.

3.1 El mundo de las appsLas apps se encuentran en el día a día, en todas partes, y son capaces de entretener, infor-

mar e incluso sirven de ayuda en el trabajo, convirtiendose en parte de la vida del usuario deun Smartphone [UPS13]. La función principal de un Smartphone es servir como plataformapara que las apps se aprovechen de las características del mismo, siendo las apps aquellas quecumplen una pequeña función dentro del Smartphone ya sea para comunicarse, visualizar oeditar documentos o simplemente jugar.

3.1.1 EvoluciónLos primeros teléfonos catalogados como Smartphones aparecieron a finales de los años

90 y traían precargadas aplicaciones muy básicas como agenda, contactos, melodias, jue-gos y en algunos casos correo electrónico. No es hasta la llegada de la tecnología EDGE[Ent] y su conexión a internet cuando se produce una pequeña evolución permitiendo unmayor desarrollo de las aplicaciones existentes. Condicionado todo ello a las restricciónespor parte de los fabricantes de teléfonos que desarrollaban sus propios sistemas operativos yque no permitían la inclusión de desarrolladores externos, se produjo un estancamiento en laindustria en la que importaba más el hardware que el software.

Es en el año 2007 cuando se produce la verdadera revolución en el mercado de las appscon la aparición del primer iPhone de Apple, que ofrece su telefono como una plataformaen la que hacer uso de aplicaciones de desarrolladores y compañias externas y además eranofrecidas al resto de usuarios de este dispositivo a través de su App Store. Lo mismo ocurriócon Android y su Android Market, que al ser una plataforma de código abierto permitió unamayor libertad y la posibilidad de llegar a Smarphones de bajo coste. Así comenzo el boom y

13

para finales de 2008 había practicamente una aplicación para casi todo. Cuando la App Sto-re abrió sus puertas contaba con 500 apps mientras que Android Market, actualmente PlayStore, con 50; a finales de 2013 la App Store contaba con 775.000 apps, por 800.000 de PlayStore cada una diseñada para realizar una función o serie de funciones que aprovechan lascaracterísticas del Smartphone [CEO12]. Por tanto, resulta más habitual ver a personas decualquier edad y estatus haciendo uso de estas apps, que poco a poco se han vuelvo impres-cindibles en la vida del usuario, facilitado todo ello por el abundante y variado ecosistemade aplicaciones existentes para las distintas plataformas móviles.

En el año 2013 más del 90 % de la población mundial tenía un teléfono móvil, de las cualesel 56 % de ellas poseía un Smartphone. Además se descargaron mas de 56.000 millones deapps para Smartphones y 14.000 millones de apps para tabletas [Soc13]. Se puede observarque el futuro es móvil, y cada vez más las empresas se preocupan de tener una buena versiónadaptada para móviles o en mejor caso una app disponible en los diferentes markets deapps. Como dato curioso, desde el año 2012 Facebook registra un mayor tráfico originadodesde dispositivos móviles que desde computadoras y, además, actualmente los contratos deinternet móvil duplican en número a los de conexión fija.

Según el estudio elaborado por Flurry [blo13a], tras tener en cuenta cerca de 400.000 apps,recoge que el uso general de apps creció en el año 2013 un 115 % con respecto a años an-teriores (Figura 3.1). Las aplicaciones que más crecieron fueron las de mensajería y redessociales, utilidades y productividad. Personalizando en las apps más utilizadas, encabeza lalista Google Maps que se calcula que el 54 % de los 1000 millones de smartphones que exis-ten en el planeta la tengan instalada [Ric13]. Destacan tambien en esta lista las principalesredes sociales como Facebook, Google+, Twitter o Instagram, así como las apps de mensaje-ría instantanea como WeChat, Facebook Messenger o WhatsApp. Se puede apreciar por tantola importancia de las redes sociales y las apps de mensajería instantánea en la actualidad queocupan el top 10 de las apps más utilizadas en el año 2013.

3.1.2 Plataformas

En los últimos años se ha producido un crecimiento exponencial de las ventas de smartp-hones, llegando a cifras tales como la venta de 1 millón de unidades de iPhone 4S en 24horas en EEUU [Lar11]. En 2011 y por primera vez, la venta de smartphones superó encantidad a la venta conjunta de PCs (sobremesa y portátiles), tablets y netbooks, llegando alos 500 millones de terminales [dTdG12]. Este es uno de los motivos por el que las aplica-ciones para dispositivos móviles se han revelado como un mercado emergente con grandesposibilidades.

En términos de número de aplicaciones y negocio generado, el mercado actual de lasaplicaciones móviles está liderado por Apple y Google[IDC13], con iOS y Android comosistemas operativos, seguidos por Windows Phone, sistema operativo móvil de Microsoft,

14

Figura 3.1: Crecimiento apps en 2013

Figura 3.2: Sistemas operativos móviles en 2013

BlackberryOs, así como la aparición de nuevos sistemas operativos móviles como UbuntuMobile desarrollado por Canonical, Tizen desarrollado por Samsung o Firefox OS desarro-llado por Mozilla (Figura 3.2).

A continuación se describen en detalle los sistemas operativos móviles presentes en lamayoría de los smartphones comercializados a nivel mundial en la actualidad.

Android.

En el año 2003 se funda Android Inc. que empieza sus andadas en el mercado de lascámaras digitales a las cuales quería llevar a otro nivel, pero que finalmente fue deshechadoporque no era un mercado lo suficientemente grande. En 2005 Google adquiere Android,

15

pero no es hasta 2007 con la fundación de la Open Handset Alliance, organización lideradapor Google y compuesta por 84 compañías, entre las que destacan Samsung, HTC, LG, Intelo Nvidia entre otras, cuando se anuncia el sistema operativo móvil Android1. La versiónAndroid 1.0 es lanzada en septiembre de 2008 y actualmente se encuentra en la versiónKitKat 4.4 [Sta13].

Android se ha convertido en la plataforma móvil más popular en los smartphones con unmercado cada vez más decantado a su favor y que se espera se convierta en el estándar defacto en la industria de las telecomunicaciones. Además, dicho sistema operativo puede serusado en tablets y otros dispositivos móviles como relojes u ordenadores. Es un sistema ope-rativo basado en Linux, de código abierto a excepción de alguna parte que aún es propietariopor parte de Google, tiene licencia Apache2 que es libre y de código abierto lo que permitea los desarrolladores crear librerías y programas generados en otros lenguajes y compilarlosen la arquitectura ARM de los terminales Android como si se tratasen de liberías nativas delsistema permitiendo mejorar el sistema constantemente. La estructura de Android se com-pone de apps que se ejecutan en un entorno Java sobre un núcleo de librerías de Java en unamáquina virtual denominada Dalvik.

La oferta de smartphones con Android es amplia y variada tanto en marcas como en pre-cios, existiendo multitud de dispositivos en el mercado (entre smartphones y tablets) quefuncionan sobre este sistema operativo. Además, el gran éxito de ventas sitúa a Android co-mo el sistema operativo con mayor cuota de mercado global con cerca del 81 % [IDC13]. Sinembargo, esta gran diversidad a nivel hardware está generando también una gran fragmen-tación de versiones de Android (Figura 3.3), debido a la necesidad de hacer adaptaciones acada dispositivo concreto. Esta situación se traduce en un incremento en la complejidad deldesarrollo de aplicaciones, sobre todo a la hora de garantizar fiabilidad, soporte y experien-cia de uso adecuada, características que son responsabilidad del desarrollador, debido a lainexistencia de revisiones y controles a la hora de publicar aplicaciones en Google Play.

Android como lider en el mercado de sistemas operativos móviles, con una gran expansióny una cuota de mercado del 81 % en smartphones y cerca de un 63 % en el mercado de tabletspretende dar el salto a nuevos mercados tecnológicos como los relojes inteligentes. Ademásdel mercado de los relojes inteligentes, considerado uno de los mercados con ás potencialde cara al futuro, Google también ha dado algunos pasos en el mercado de las televisionescon Google TV, una versión modificada de Android. El salto definitivo en el mercado delos televisores pretende darlo con Chromecast3, un dispositivo de reproducción multimedialanzado en marzo de 2014. Además, los mercados de consolas, con la inclusión de títulos

1http://www.android.com/2Licencia que permite al usuario del software la libertad de usarlo para cualquier propósito, distribuirlo,

modificarlo, y distribuir versiones modificadas de ese software. (http://www.apache.org/licenses/LICENSE-2.0.html)

3http://www.google.com/intl/es/chrome/devices/chromecast/

16

Figura 3.3: Fragmentación en Android

más madurosy completos, o el mercado de ordenadores que aún son una rareza pero quepronto estarán a la orden del día con Android y Chrome OS como ya ocurre en Asia.

iOs.

Sistema operativo móvil de Apple Inc. que se dio a conocer en enero de 2007 en la Mac-world Conference y Expo junto con el iPhone con el nombre de iPhone OS y lanzado enjunio de ese año. Originalmente fué desarrollado para el iPhone pero terminó siendo utiliza-do en otros productos de la compañia como el iPod Touch, iPad o Apple TV. En sus inicios,las aplicaciones de terceros no fueron compatibles y no fué hasta octubre de 2007 cuandoApple anuncia el desarrollo de un kit de desarrollo de software nativo. Es en 2010 cuandose rebautiza como iOs y actualmente se encuentra en su versión 7. A diferencia de Android,en el que uno de sus principales problemas es la fragmentación, en iOs más del 80 % de losdispositivos ya están actualizados a la última versión (Figura 3.4).

iOs es un sistema operativo móvil desarrollado y distribuido por Apple Inc. y que, a di-ferencia de Android, no proporciona licencia para su instalación en hardware no Apple. Setrata de un sistema operativo que deriva de OS X, sistema operativo para ordenadores tam-bién de la compañia y que a la vez esta basado en Darwin BSD4 y por lo tanto es un sistemaoperativo Unix, con la misma filosofía de licencias. La interfaz de usuario de iOs se basa enel concepto de manipulación directa, haciendo uso de gestos multitáctiles.

Actualmente se ejecuta en iPhone, iPad, iPod touch y Apple TV, todos ellos productoshardware de Apple, con una cuota de mercado del 12.9 % y con el 78 % de los dispositivosiOS actualizados a la versión 7. De parte de los desarrolladores, todas las aplicaciones sonrevisadas antes de publicarlas en la App Store asegurandose de que cada aplicación funcionacorrectamente y cumple sus políticas de publicación, algunas de ellas como el no permitir

4Sistema que subyace en Mac OS X para funcionar en computadoras Macintosh

17

Figura 3.4: Actualización Android vs iOs

que se recomiende o promueva la venta de otras aplicaciones o hacer uso de notificacionesPush para mandar anuncios, promociones o marketing directo de cualquier tipo.

Windows Phone.

Sucesor de la versión del sistema operativo móvil Windows Mobile5 basada en el núcleoWindows Embedded CE 6.06, desarrollado por Microsoft. Fue presentado en el Mobile WorldCongress en febrero de 2010 en Barcelona y la versión Windows Phone 7 fué lanzada enseptiembre de 2010 que actualmente se encuentra en la versión Windows Phone 8 lanzadaen mayo de 2012.

Windows Phone es un sistema operativo móvil dirigido principalmente al mercado de con-sumo en lugar de al mercado empresarial. Microsoft ha creado una nueva interfaz de usuario,interfaz Metro con su lenguaje de diseño llamado el lenguaje de diseño moderno. Además,el software está integrado con los servicios de terceros y servicios de Microsoft, y estable-ce unos requisitos mínimos de hardware en el que se ejecuta. Destaca la no compatibilidadde aplicaciones de Windows Mobile en Windows Phone debido al paso de pantallas conpunteros a pantallas táctiles capacitativas.

En febrero de 2011, Microsoft anunció la alianza con Nokia por la cual Windows Phone seconvertía en el sistema operativo principal en los Smartphones de Nokia, en la que se preten-día crear un nuevo ecosistema móvil global que compitiese con Android e iOs. ActualmenteWindows Phone posee una cuota de mercado del 3.9 % y se sitúa tercera en el ranking desistemas operativos móviles desbancando a Blackberry OS de esta posición [IDC13].

5Sistema operativo móvil compacto desarrollado por Microsoft para smartphones y dispositivos móviles6Sistema operativo desarrollado por Microsoft para sistemas embebidos

18

Blackberry.

Blackberry OS es un sistema operativo móvil desarrollado por RIM7 para dispositivosBlackberry. Su desarrollo se remonta al año 1999 y esta orientado a un uso profesional comogestor de correo electrónico y agenda. Actualmente se encuentra en caída libre y su cuota demercado global se situa en torno al 1.7 % [Net13].

Tizen.

Es un proyecto de sistema operativo móvil basado en Linux. El desarrollo está dirigido porIntel, Samsung y algunos ex-desarrolladores de MeeGo8 y estará orientado para su uso entablets, netbooks, smartphones, televisores inteligentes y sistemas integrados de informacióny entretenimiento [tiz]. Está basado en HTML5 y otros estándares web.

Firefox OS.

Desarrollado por Mozilla Corporation bajo el apoyo de empresas como Telefónica, es unsistema operativo móvil basado en HTML5 con núcleo Linux, de código abierto para variasplataformas. Esta diseñado para permitir a las aplicaciones HTML5 comunicarse directa-mente con el hardware del dispositivo usando JavaScript [fir].

3.1.3 Apps nativas vs WebApps

En medio de una revolución tecnológica y como ya ocurriera en la década pásada con elboom de las punto com en la que era imprescindible para un negocio disponer de un websi-te, han aparecido en el mundo de las apps móviles nuevos modelos de negocio mucho másdirectos que cualquier web. Al tratarse de un mercado bastante jóven y con la constante apa-rición de nuevas plataformas móviles sumada a la ya amplia lista de plataformas existentesprovoca un serio problema en los desarrolladores a la hora de llevar a cabo el desarrollo deuna nueva app y decantarse por una de las principles opciones disponibles: un desarrollonativo para cada una de las plataformas o un enfoque multiplataforma. También se podríadesarrollar un enfoque híbrido con parte en desarrollo nativo y parte en lenguaje web.

WebApp

Una WebApp es una versión optimizada de una web mediante HTML5, CSS3 y jQueryMobile para su correcta visualización en los distintos dispositivos con distanta plataformamóvil.

7Compañía canadiense de dispositivos inalámbricos. Fabricante y promotor del dispositivo de comunicaciónde mano BlackBerry

8Unión de los sistemas operativos Maemo de Nokia y Moblin de Intel, con los que se pretendía competircon Android

19

App Nativas

Es una aplicación implementada en el lenguaje nativo de cada terminal y por tanto podráexplotar al máximo las características del dispositivo móvil.

La elección de un entorno u otro de desarrollo dependerá principalmente de los siguientescampos:

Multiplataforma. Teniendo en cuenta que no todos los smartphones funcionan bajo lamisma plataforma móvil es importante llegar al mayor número de plataformas posibleso al menos a las más importantes como Android o iOs. Una de las principales venta-jas de una WebApp es que originalmente son multiplataforma ya que son capaces deejecutarse en cualquier navegador que soporte HTML5. Por el contrario, para una appnativa será necesario el desarrollo para cada plataforma lo que supone un incrementoen el coste de desarrollo de la aplicación.

Market Places. Canales de distribución y promoción para mostrar y vender apps comopueden ser Google Play de Android o App Store de iOs. Solo las app nativas tienenacceso a ellas aunque no todo son ventajas ya que se encuentran con comisiones dehasta un 30 % en las ventas dentro de la propia app.

Experiencia de usuario. Es uno de los puntos fuertes de las app nativas ya que alestar escritas en el propio lenguaje de la plataforma funcionan de forma mas fluida porlo que ofrecen una mejor experiencia de usuario. Ademas, las webapp cuenta con ladesventaja de tener que disponer de conexión a internet.

Proceso de validación y actualizaciones. El proceso de validación por parte de losmarket places para las aplicaciones nativas puede varias desde los 10 minutos por partede Android hasta la semana por parte de Apple que además debe cumplir una estrictaguía para desarrolladores. Este proceso se repite con cualquier actualización de la appa publicar. Es un punto muy a favor de las webapp al no depender de los market places.

Funcionalidad nativa. Una de las principales ventajas de una app nativa es poderhacer uso de los accesorios o sensores integrados en el dispositivo de los que no sepuede hacer uso en una webapp.

A continuación se muestra la comparativa Apps nativas vs WebApps (ver Cuadro 3.1).

3.1.4 Lenguajes de programaciónLenguaje de programación multiplataforma.

OpenFL. Es un kit de desarrollo, anteriormente conocido como NME, que proporciona unentorno para el desarrollo de juegos y aplicaciones nativas para Android, iOs, BlackBerry,Windows, Mac, Linux, Flash y HTML5, que permite a los desarrolladores construir proyec-tos en lenguaje Haxe. OpenFL surge de una implementación del código abierto de la API de

20

Flash, que se compila en C++ para sus plataformas de destino. Se trata de un framework librede usar y modificar y que actualmente se esta desarrollando abiertamente en Github.

PhoneGap. Se trata de una solución de código abierto para la creación de aplicaciones mó-viles multiplataforma con tecnologías Web basadas en estándares como HTML, JavaScript oCSS. PhoneGap es una implemetación libre y de código abierto que permite a los desarrolla-dores y empresas utilizarlo libremente sin necesidad de atribución o licencia de ningún tipo.Con PhoneGap y a través de JavaScript se tiene acceso a la API del sistema operativo en usopara acceder a elementos como el acelerómetro, la cámara ó las notificaciones entre otros.Por tanto, las aplicaciones resultantes son aplicaciones híbridas, ya que el renderizado serealiza mediante vistas web y no con interfaces nativas del sistema operativo, pero se puedeacceder a la API del sistema nativo.

jQuery Mobile. Es la adaptación para dispositivos móviles del framework de JavaScriptmas utilizado en la web, jQuery, que combina HTML5 y jQuery para la creación de portalesweb móviles cuya apariencia será la misma independientemente del dispositivo desde el quese acceda. La principal función de jQuery Mobile es la de optimizar las funciones nativaspara mejorar el diseño y la velocidad en dispositivos móviles.

MonoGame. Es una implementación de código abierto de Microsoft XNA 4 (conjunto deherramientas de Microsoft para el desarrollo de juegos para Microsoft) que permite a losdesarrolladores XNA de Xbox, Windows 7 y Windows Phone 7 portar sus juegos a otrasplataformas como iOs, Android, Windows Phone 8, MacOs, Linux, Windows 8, PlayStationMobile y la consola Ouya.

Titanium mobile. Se trata de un framework JavaScript para el desarrollo de aplicacionesde escritorio y para móviles, entre las que se puede desarrollar para iOs, Android y Black-berryOS permitiendo generar aplicaciones nativas e, hibridas para HTML5. Es un frameworkde código abierto y que puede ser utilizado tanto para desarrollo personal como comercialsin necesidad de ningún tipo de licencia.

Lenguajes de desarrollo nativos.

Java. Es un lenguaje de programación y la primera plataforma informática creada por SunMicrosystems en 1995. Se trata de un lenguaje de propósito general, concurrente, orientadoa objetos y basado en clases que permite que sus aplicaciones compiladas puedan ejecutarseen cualquier máquina virtual Java (JVM) sin importar la arquitectura de la computadora odispositivo electrónico. Por lo tanto se trata de un lenguaje independiente de la plataforma.

21

Esto se consigue gracias a la creación de una máquina de Java para cada sistema que ha-ce de puente entre el sistema operativo y el programa Java posibilitando que se entiendanperfectamente. Java es el lenguaje utilizado para el desarrollo de aplicaciones en la plata-forma Android, que se ejecutan a través de la máquina virtual Dalvik, y también en fasebeta en la máquina virtual Android Runtime (ART). Además, Java es el segundo lenguaje deprogramación más utilizado actualmente, sólo por detrás de C (ver Cuadro 3.2).

Objective-C. Es un lenguaje de programación orientado a objetos, nacido y desarrolladopor Brad Cox en la década de los 80 , creado como un superconjunto de C. Más tarde fueadoptado por NeXT, compañía fundad por Steve Jobs cuando dejó Apple, y utilizado comobase para construir el sistema operativo de sus computadores. En 1996 NeXT fue adquiridapor Apple y, su sistema operativo pasó a convertirse en Mac OS X en 2001. Actualmentees el lenguaje de programación utilizado para programar las aplicaciones nativas de iOs yMac OS X, y se trata del tercer lenguaje de programación más utlizado en la actualidad (verCuadro 3.2).

.NET. Se trata de un framework para el desarrollo de aplicaciones en plataforma Windows,desarrollado por Microsoft. Permite el desarrollo en lenguajes como C# y Visual Basic. Esel framework de desarrollo potencia por Microsoft para el desarrollo de aplicaciones paracualquiera de sus plataformas de una manera ágil, robusta y segura.

3.2 Apps para la venta de productos y servicios3.2.1 Visión general

El uso de teléfonos inteligentes o Smartphones es cada día más frecuente entre la pobla-ción, independientemente de su edad, nivel cultural o estado social, haciendo uso de el para larealización de gran parte de actividades de la vida cotidiana. Esto se traduce en un consumomasivo de apps móviles para cualquier actividad o momento. En el campo de las apps parala venta de productos y servicios se ha incrementando la necesidad por parte de las grandesempresas en disponer de una app para la venta electrónica de sus productos. Estas apps vandesde lo más sencillo como puede ser mostrar el catálogo de productos, listado de tiendas orestaurantes hasta permitir realizar el pedido de un artículo a través de la propia app. Ade-más, con el uso de este tipo de apps las empresas pueden realizar estudios de consumo desus usuarios. Este tipo de estudios permite realizar sugerencias personalizadas a cada uno delos clientes en función de sus compras anteriores o productos deseados.

3.2.2 Restaurantes y locales de ocioLa gestión de pedidos y cobro en restaurantes o locales de ocio es uno de los aspectos fun-

damentales para el adecuado funcionamiento de estos. La forma tradicional de realizarlos esmediante el desplazamiento al local físico, realizando en él tanto el pedido como el pago de

22

este. Con el auge de restaurantes de comida rápida surgen nuevas formas de gestionar los pe-didos. La primera de ellas fue la posibilidad de realizarlos por teléfono para que despues seaservido en casa del cliente; más tarde algunas cadenas de comida rápida permitían realizar yrecoger los pedidos sin tener que bajarse del vehículo e incluso se permite poder realizar elpedido a través de la página web del restaurante.

Con la aparición de los smartphones y el masivo uso que se hace de ellos surgen nuevasideas para la gestión de pedidos y cobros, a la vez que surgen nuevas necesidades para losusuarios como puede ser realizar un pedido y el pago del mismo desde su smartphone através de una app proporcionada por el restaurante o local de ocio. Las principales ventajasque proporcionaría son la automatización de tareas cotidianes, el ahorro de tiempo en lasgestiones y la mejora de eficiencia de los empleados del restaurante o local.

Algunos restaurantes de comida rápida ya disponen de aplicación corporativa que permitevisualizar todos los productos disponibles y, solo en casos muy concretos, permite realizarel pedido a través de la propia app.

A continuación se muestra el estado actual de algunas aplicaciones similares de restauran-tes o locales de ocio.

McDonalds. Restaurante de comida rápida, presente en 119 países del todo el mundoy con mas de 34.000 restaurantes. Se pueden encontrar diferentes apps en función delpais en el que nos encontremos, pero en el caso de España la app permite la visuali-zación de todos sus productos disponibles, agrupados por categorias y acompañadosde una fotografía. Además permite la localización de restaurantes a partir de nuestraubicación, así como la opción de mostrar todos los restaurantes disponibles en unadeterminada ruta. La app muestra las promociones disponibles en el local dentro de laapp. Posee un diseño adaptado a los colores corporativos de la marca, así como unainterfaz amigable e intuitiva. Las principales ventajas son la organización de productosy una interfaz amigable y sencilla. Sin embargo los productos carecen de descripcióny no se permite realizar pedidos a través de la app (ver Cuadro 3.3).

Telepizza. Restaurante de comida rápida especializado en pizzas, de origen español ypresente principlamente en la Península Ibérica y paises de América Latina con masde 1100 restaurantes. La app ofrece todos los productos disponibles en el restaurante,y además permite realizar pedidos ya sea para el envío al domicilio o para recogerlosen el local más cercano, pudiendo ser almacenados como favoritos (Figura 3.5). Laprincipal ventaja de esta app es el poder realizar pedidos a través de ella, así comola organización de los productos disponibles en categorías. Como parte negativa, lospedidos a través de la app no se pueden realizar en todos los restaurantes, los productosno vienen acompañados de una descripción y es obligatorio el registro para poderrealizar un pedido (ver Cuadro 3.4).

23

Ventajas Desventajas

App Nativas Rendimiento Una implementación por plataformaExperiencia de usuario Desarrollo más costosoUso API nativaAcceso a Market Places

WebApps Multiplataforma Siempre con conexión a InternetHTML5 y CSS3 emulan las animaciones Acceso reducido a la API nativa

Cuadro 3.1: Comparativa Apps Nativas vs WebApps ([Her13])

Posición Lenguaje Programación Uso

1 C 17.631 %2 Java 17.348 %3 Objective-C 12.875 %4 C++ 6.137 %5 C# 4.820 %6 Visual Basic 3.441 %7 PHP 2.773 %8 Python 1.993 %9 JavaScript 1.750 %10 Visual Basic .NET 1.748 %

Cuadro 3.2: Lenguajes más utilizados ([Sof14])

McDonaldsVentajas Desventajas

- Interfaz sencilla y amigable - Carece de descripción de productos- Productos organizados en categorias - No permite realizar pedidos- Muestra todos los resturantes geográficamente

Cuadro 3.3: App McDonalds

TelepizzaVentajas Desventajas

- Interfaz sencilla y guiada - Carece de descripción de productos- Productos organizados en categorias - Demasiadas sugerencias al realizar un pedido- Permite realizar pedidos - Pedidos no disponibles en todos los restaurantes- Guardar pedidos en favoritos - Registro obligatorio

Cuadro 3.4: App Telepizza

24

Figura 3.5: Telepizza. Categorias y realización de pedido

Figura 3.6: Domino’s Pizza. Categorias y realización de pedido

Domino’s Pizza. Restaurante especializado en pizzas, presente en más de 60 paises ycon más de 10.000 restaurantes. La app para España permite realizar pedidos con laopción de envío a domicilio o recogida en alguno de los locales cercanos (Figura 3.6).Su interfaz es poco amigable y compleja, con demasiadas opciones poco específicas.Además la app no es más que un enlace a la web de Domino’s Pizza en España. Laprincipal ventaja es permitir realizar pedidos, pero en contrapartida no es más que unenlace a una página web con una interfaz poco amigable (ver Cuadro 3.5).

Foster’s Hollywood. Restaurante dedicado a comida americana localizado únicamenteen España y que cuenta con más de 186 restaurantes. La app proporciona todas las

25

Figura 3.7: Foster’s Hollywood. Sugerencias y localización de restaurantes

promociones disponibles en los restaurantes, previo registro en ella, además de facilitarla localización de los restaurantes más cercanos en un mapa. La app muestra productossugeridos, pero es imposibles visualizar el catalogo de productos disponibles y, por lotanto, no es posible realizar pedidos a través de la app (Figura 3.7). La ventaja principalde la app es informarnos de las promociones disponibles en los restaurantes, pero tienecomo desventajas carecer de catálogo de productos y disponer de una interfaz complejay poco intuitiva (ver Cuadro 3.6).

Rodilla. Restaurante especializado en sandwiches, de origen español, y presente sola-mente en España con mas de 90 restaurantes repartidos por todo el territorio, princi-palmente en Madrid. La app unicamente nos permite acumular los puntos de nuestrospedidos, previo registro en la app, para canjearlos por regalos, así como informarnosde las promociones disponibles en los restaurantes (Figura 3.8).

Llaollao. Heladería especializada en yogur helado, granizados y batidos, de origenespañol y solo presente en España con mas de 90 establecimientos. La app solo permitevisualizar las promociones disponibles en los establecimientos así como mostrar laubicación de todos ellos en un mapa (Figura 3.9).

3.3 Servicios Web3.3.1 Introducción

El concepto de computación en la nube o servicios web empezó en proveedores de ser-vicio de Internet a gran escala como Google, Amazon AWS o Microsoft, y que según elIEEE Computer Society9, es un paradigma en el que la información se almacena de manera

9Institute of Electrical and Electronics Engineers (http://www.ieee.org/)

26

Figura 3.8: Rodilla. Registro de puntos.

Figura 3.9: Llaollao. Información y localización de tiendas.

permanente en servidores de Internet y se envía a cachés temporales de cliente, lo que in-cluye cualquier tipo de dispositivo. Es decir, se trata de servidores en Internet encargados deatender peticiones de los usuarios en cualquier momento y desde cualquier lugar.

La mayoría de las apps hacen uso de estos servicios en la nube, obteniendo los datos quemuestran en tiempo real, siempre actualizados y en el menor tiempo posible. Las facilidadesque proporcionan los servicios en la nube permiten que una app obtenga los datos solicitadospor el usuario en tiempo real y siempre actualizados.

Un servicio en la nube es aquel que se encarga del procesamiento y almacenamiento masi-

27

vo de datos en servidores que alojan información del usuario. La principal ventaja que ofrecees el acceso instantáneo y en cualquier momento a los datos desde cualquier lugar y desdecualquier dispositivo [Arb13].

Además de la movilidad y disponibilidad de los datos de forma continua, los servicios enla nube ofrecen otra serie de ventajas.

Facilidad de uso. Los servicios web fueron creados para personas no expertas en tec-nología por lo que son fáciles de usar, proporcionando al usuario rapidez y simplicidadpara realizar sus tareas.

No necesitan software extra. El esfuerzo de procesamiento se aloja en los servidoresde los que se hace uso y no en el dispositivo utilizado. De esta forma se puede utilizarde una manera más óptima los recursos del dispositivo.

Ahorro. El acceso a aplicaciones y servicios sin necesidad de descarga ayuda a laimplantación de proyectos en menor cantidad de tiempo.

Gestión. El prestador de servicios se encarga de todo, el usuario no tiene que preocu-parse de nada

Pero no todo son ventajas para los servicios en la nube; también tiene una serie de desven-tajas entre las que destaca la seguridad en el acceso a la información.

Dependencia. Tanto de los proveedores de servicio y como de la disponibilidad deacceso a Internet

Confidencialidad. Los datos sensibles no se encuentran alojados en instalaciones dela empresa, lo que genera una alta vulnerabilidad al robo de información. Además lainformación podría recorrer varios nodos hasta llegar a su destino, propiciando muchosfocos de inseguridad.

Privacidad. Los datos que expuestos a terceros que pueden acceder a ellos.

Por tanto, los servicios en la nube son de gran ayuda para el mercado de las apps, ya queproporcionan los datos solicitados por el usuario en cualquier momento y en cualquier lugar,ahorrando en procesamiento por parte del dispositivo desde el que se realizan las peticio-nes, pero en contrapartida en temas de seguridad los datos podría perder confidencialidad yprivacidad.

3.3.2 Principales alternativasAmazon Web Services (AWS).

Surgió en 2006 y se encarga principalmente de ofrecer servicios en línea del lado delcliente para otros sitios web o aplicaciones, tanto móviles como de escritorio. Es decir setrata de una colección de servicios web o de escritorio remoto cuyo conjunto ofrece unaplataforma de computación en la nube a través de www.amazon.com.

28

Las características principales de Amazon Web Services son:

Seguridad. Plataforma tecnológica con certificaciones y auditorías reconocidas, mul-tiples capas de seguridad tanto operativa como física para asegurar la integridad yseguridad de los datos así como un amplio sistema de supervisión de seguridad y deredes.

Bajo coste. Ofrece precios bajos dependiendo del uso.

Abierto y flexible. Permite determinar tanto la plataforma de desarrollo o modelo deprogramación como, los servicios de los cuales se quiere hacer uso.

Agilidad y elasticidad instantánea. Proporciona una infraestructura en red globalmasiva que permite desplegar nuevas aplicaciones en el momento e incluso aumentaro reducir la capacidad inmediatamente en función de la carga de trabajo o la demanda.

La plataforma de Amazon Web Services ofrece la flexibilidad de ejecutar una aplica-ción independientemente de la industria y el uso. Algunas de las soluciones más popularesson:

Alojamiento de aplicaciones.

Copia de seguridad y almacenamiento.

Alojamiento web.

TI Empresarial.

Entrega de contenido.

Alguna de las aplicaciones de las que se suele hacer uso de forma diaria que utilizan estaplataforma son Dropbox, Foursquare o HootSuite.

Google App Engine.

Se trata de una plataforma como servicio (PaaS) que ofrece permitir crear y ejecutar apli-caciones en la infraestructura de Google10. Fue lanzado en abril de 2008 y se trata de unservicio gratuito de hasta un Gigabyte de almacenamiento y cinco millones de visitas men-suales. Aunque lo que más limita la versión gratuita es el número de escrituras e instancia-s/hora limitada a 28. Google App Engine soporta aplicaciones escritas en Java, Python, PHPy Go, este último creado por Google. Destacan las siguientes características:

Almacenamiento. Persistente con las consultas, la clasificación y transacciones.

Escala automática.

Balanceo de carga.

Colas de tareas asíncronas. Utilizadas para la realización de trabajos fuera del ámbitode una solicitud.

10https://developers.google.com/appengine/?csw=1

29

Programación de tareas. Permite activar eventos en momentos seleccionados o inter-valos especificados.

Integración. Con otros servicios y APIs de Google.

Las aplicaciones se ejecutan dentro de un entorno seguro y confiable independiente delhardware, sistema operativo o localización del servidor.

Windows Azure.

Es una plataforma de nube abierta y flexible que permite compilar, implementar y admi-nistrar aplicaciones rápidamente, dentro de una red global de centros de datos administradospor Microsoft11. Permite compilar aplicaciones en cualquier lenguaje, herramienta o marco,integrando las aplicaciones de nube pública con el entorno de TI existente.

Las principales características son las siguientes:

Disponibilidad. Windows Azure ofrece un nivel de servicio mensual del 99,95 %12

permitiendo compilar y ejecutar aplicaciones de alta disponibilidad sin importar lainfraestructura.

Abierto. Permite utilizar cualquier lenguaje, marco o herramienta para crear aplicacio-nes. Las características los servicios se exponen utilizando protocolos REST abiertos.

Escalabilidad. Permite escalar aplicaciones con facilidad, aumentando o disminuyen-do los recursos en función de las necesidades.

Flexibilidad. Windows Azure proporciona una plataforma que puede satisfacer losrequisitos de cualquier aplicación.

Firebase.

Se trata de un servicio en la nube, que ofrece solución escalable de backend en tiemporeal para aplicaciones tanto Web como móviles, permitiendo construir aplicaciones sin lanecesidad de desarrollar del lado del servidor. Se trata de una librería que proporciona unaestructura de datos que se sincroniza automáticamente con el servidor y los demás clien-tes.

Las principales características son:

Soporte multiplataforma. Disponible para web, OS X, iOS y Android. Además so-porta todos los principales navegadores y funciona en cualquier conexión de red.

Seguridad. Proporciona una gama completa de métodos de autenticación. Todo eltráfico desde y hacia Firebase utiliza SSL. Además todos los datos se almacenan deforma redundante y en copias de seguridad fuera del sitio.

11http://azure.microsoft.com/12Contratos de nivel de servicio (http://www.microsoft.com/windowsazure/es/es/sla/)

30

Acceso. Los datos son accesibles en en cualquier momento y ofrece la posibilidad deexportarlos en JSON.

Permite el modo offline. Sincroniza los datos instantáneamente.

Los datos son almacenados como JSON. Cada dato almacenado en Firebase tiene supropia URL.

31

Domino’s PizzaVentajas Desventajas

- Permite realizar pedidos - Interfaz poco amigable- Información sobre ofertas y promociones - Demasiadas sugerencias al realizar un pedido- Localización de restaurantes cercanos

Cuadro 3.5: App Domino’s Pizza

Foster’s HollywoodVentajas Desventajas

- Sugerencia de productos - Interfaz compleja y poco intuitiva- Localización de locales - Carece de catálogo de productos- Información de promociones actuales No permite realizar pedidos

Cuadro 3.6: App Foster’s Hollywood

32

Capítulo 4

Método de trabajo

E N este capítulo se determina el método de trabajo seguido para el desarrollo de presenteTrabajo Fin de Grado, así como una descripción del ciclo de vida del mismo. Además

se especifican las tecnologías y herramientas, tanto software como hardware, empleadas enla implementación del mismo.

4.1 Metodología de desarrolloLa metodología de trabajo utilizada en este trabajo ha sido un desarrollo iterativo e incre-

mental. Se ha optado por este modelo ya que, el proyecto se planifica en diversos bloquestemporales llamados iteraciones. En cada iteración se repite un proceso de trabajo similar(Figura 4.1) para proporcionar un resultado completo al trabajo final. De este modo, cadarequisito se debe completar en una única iteración completando todas las tareas que seannecesarias. Después de cada iteración el trabajo va evolucionando a partir de los resultadoscompletados en iteraciones anteriores, añadiendo nuevos requisitos o mejorando los com-pletados anteriormente. Por tanto un aspecto fundamental para este tipo de desarrollo es lapriorización de requisitos en función del valor que aporten al producto.

En un principio, se identificaron los requisitos fundamentales que implementa actualmentela aplicación con el cliente1 que después fueron refinandose en sucesivas iteraciones. Losrequisitos del trabajo fueron aumentando en función de las expectativas del cliente debido acambios en las condiciones del mercado y a la reacción y aceptación al uso de los primerosresultados de la aplicación. De esta forma, se gestionaron de forma natural los cambios queiban apareciendo en el trabajo. Al final de cada iteración el cliente proporcionaba su feedbacktras examinar el resultado obtenido. A partir de esta información era posible planificar loscambios necesarios que debían introducirse para cumplir con las expectativas del clientey minimizar el número de errores en cuanto a desarrollo. Así, aumentó la calidad de laaplicación y al finalizar el proyecto el cliente obtuvo los objetivos esperados.

Los pasos que se repiten en cada iteración siguiendo este método de desarrollo se puedenapreciar en la figura 4.1. Después de cada iteración se obtiene un prototipo. Desde el puntode vista de ingeniería del software un prototipo se define como el desarrollo de un sistema

1En el caso del presenta trabajo, el usuario es el director del proyecto David Vallejo Fernández.

33

Figura 4.1: Proceso de trabajo con Desarrollo Incremental

con la funcionalidad necesaria para abordar diferentes requisitos [Vli07]. El prototipo iráevolucionando en cada iteración, añadiendo o modificando funcionalidad.

1. Análisis. En esta etapa, desarrollador y cliente realizan una puesta en común de re-qusitos y acuerdan cuales debe tener el prototipo a implementar. Además, tambiénse realiza un refinamiento del sistema final por lo que, se realizan modificaciones derequisitos en prototipos anteriores.

2. Diseño. En función de los requisitos definidos en la etapa anterior se procede al diseñode los esquemas que describan la estructura del prototipo.

3. Implementación. Los componentes diseñados en la etapa anterior se implementan,generando un primer prototipo.

4. Pruebas. Una vez completada la implementación y generado el primer prototipo, serealizan pruebas tanto de diseño como de funcionalidad. Una vez que las pruebas hansido realizadas de manera satisfactoria se genera el prototipo final. Este prototipo seráel que se muestre al cliente.

5. Comprobación del prototipo. El prototipo obtenido es mostrado al cliente. El clien-te puede decidir nuevas funcionalidades que desea incluir en el nuevo prototipo o,modificar el comportamiento de las que ya posee con el objetivo de refinarlo. Con elprototipo obtenido y el feedback del cliente se inicia de nuevo el proceso. Este buclellegará a su fin cuando el cliente obtenga toda la funcionalidad que necesite con elprototipo final.

34

En el presente trabajo se ha optado por está metodología por las siguientes razones:

Los requisitos de la aplicación no se definen completamente al principio, sino que sevan aumentando con el desarrollo y las nuevas funcionalidades incluidas por el cliente.

Al tratarse de un desarrollo incremental permite que el desarrollador adquiera expe-riencia de iteraciones anteriores.

Se pueden gestionar la expectativas del cliente ya que desde el principio está involu-crado en todo el proceso.

La generación de prototipos de manera regular produce una sensación de avance queno se da en otras metodologías de desarrollo. Además con esto, el cliente puede obtenerresultados usables ya desde las primeras iteraciones

Permite conocer el progreso real del proyecto desde las primeras iteraciones así comola viabilidad de su fecha de finalización.

En resumen, el desarrollo iterativo e incremental es la mejor opción para el diseño y desa-rrollo de una aplicación móvil, debido al conocimiento en tiempo real del estado de desarro-llo así como la fácil adaptación de nuevos requisitos o funcionalidades y la modificación delos requisitos ya presentes.

4.1.1 Aplicación de la metodologíaLa metodología de desarrollo iterativo e incremental está ideada para cualquier equipo

de desarrollo. Es el caso particular de este Trabajo Fin de Grado, al tratarse de un únicodesarrollador no existen restricciones a la hora de llevar a cabo el proceso de desarrollo de laaplicación haciendo uso de esta metodología.

El desarrollador de la aplicación es José Juan Ramírez de Arellano Díaz Miguel. Por otraparte, David Vallejo Fernández actúa como director de proyecto y usuario final de la apli-cación. Los prototipos han sido generados de forma ágil, ya que, durante el desarrollo delproyecto se mantenian reuniones periódicas cada dos semanas. De esta forma, se decidiannuevos requisitos para incluir o se modificaban requisitos desarrollados en la última itera-ción.

4.2 HerramientasA continuación se detallan los recursos, tanto software como hardware, empleados en la

construcción del presente trabajo.

4.2.1 Lenguajes de programaciónEl lenguaje de programación utilizado en el desarrollo de la lógica de PideMe ha sido

Java2. La versión utilizada ha sido Java 7. Mientras que para la implementación de la in-2www.java.com

35

terfaz gráfica se ha utilizado XML3. Se ha utilizado Java para el desarrollo de la lógicaya que se trata del lenguaje nativo y oficial para el desarrollo de aplicaciones móviles parala plataforma Android. Además se trata de un lenguaje orientado a objetos, muy sencillode utlizar y muy legible. Al tratarse de un lenguaje orientado a objetos, proporciona a laaplicación encapsulación, abstracción y polimorfismo. Para el desarrollo de interfaces se hautilizado XML lenguaje oficial de Android el cual, proporciona un vocabulario XML sencillocorrespondiente tanto a las clases y subclases de las vistas como los widgets y layout. Portanto, XML permite el desarrollo rápido y ágil de interfaces de usuario para aplicacionesAndroid.

4.2.2 SoftwareA continuación se describen la librerias, aplicaciones, herramientas y tecnologías emplea-

das en el desarrollo de PideMe.

Sistema Operativo

Os X. Sistema operativo basado en Unix4, desarrollado, comercializado y vendido porApple Inc5. La versión utilizada ha sido la 10.9 Mavericks. Se ha hecho uso de el parael desarrollo de la aplicación móvil para la plataforma Android.

Ubuntu. Distribución del sistema operativo GNU/Linux basada en Debian. La versiónempleada ha sido 12.04 LTS, también conocida como Precise Pangolin. En Ubuntu seha realizado el desarrollo de la documentación para el presente Trabajo Fin de Grado.

Software de desarrollo

AndroidStudio. Entorno de desarrollo integrado (IDE) para la plataforma Android.Está basado en IntelliJ IDEA6 y diseñado especificamente para el desarrollo de An-droid. Se ha empleado para la implementación del cliente Android del presente pro-yecto. La principal razón de uso es la integración con el kit de desarrollo de Android(Android SDK7) que facilita el desarrollo y depuración de aplicaciones para Android.

Make. Herramienta para la automatización de tareas repetitivas para el usuario. Enel proyecto se ha hecho uso de esta herramienta para generar la documentación delmismo.

Gestión de la base de datos

SQLite. Sistema de gestión de base de datos relacional utilizada en aplicaciones An-droid8. Android incorpora todas las herramientas necesarias para la creación y gestión

3www.xml.com4Sistema operativo portable, multitarea y multiusuario. Desarrollado por un grupo de empleados de los

laboratorios Bell de AT&T5www.apple.com/es/osx/6Entorno inteligente para desarrollar aplicaciones Java, cliente y servidor (www.jetbrains.com/idea/)7developer.android.com/intl/es/sdk/8www.sqlite.org

36

de bases de datos SQLite, además de una completa API para llevar a cabo de manerasencilla todas las tareas necesarias a través de una clase auxiliar llamada SQLiteOpen-

Helper. La funcionalidad principal de este lenguaje en la aplicación es la recuperacióny almacenamiento de la información almacenada en la base de datos local al clienteAndroid.

Documentación y gráficos

LATEX. Lenguaje que permite la generación y maquetación de documentos técnicos.En el presente proyecto se ha hecho uso de el para la elaboración de la presente docu-mentación. Se ha hecho uso de la plantilla en LATEXproporcionada por el grupo ARCOde la UCLM que corresponde con la especificación de formato de la Escuela Supe-rior Informática de Ciudad Real9. Además se ha hecho uso del paquete esi-tfg que hafacilitado la creación de la documentación.

LibreOffice Draw. Suitte de productividad de calidad profesional10 distribuida de ma-nera gratuita y libre. Se ha empleado para la elaboración de gráficos tipo árbol. Laversión empleada ha sido 3.5.7.2.

LibreOffice Draw. Hoja de cálculo desarrollada por Apple Inc para Os X11. Se heempleado para la creación de las gráficas del presente documento. La versión utilizadaha sido 3.2.

Librerias

Android Support Library. Conjunto de librerias de código que proporcionan compa-tibilidad con versiones anteriores de Android12. Se ha hecho uso de la versión 19.1.0de Marzo de 2014.

Google Play Services. Conjunto de librerías de servicios de Google, para el acceso acaracterísticas como Mapas, Google+ o actualizaciones automáticas a través de GooglePlay 13. Se ha utilizado la versión 4.3.23 para el uso de la localización en mapas dentrode la aplicación.

Firebase. Librería para la comunicación con la base de datos remota de la que seobtienen los productos de la aplicación Android14. La versión utilizada es la 1.0.1.

Picasso. Librería para la simplificación de la carga de imágenes desde una URL enAndroid15. La versión utilizada es la 1.0.1.

Roboguice. Librería para la simplicidad y facilidad de inyección de dependencias en

9webpub.esi.uclm.es10es.libreoffice.org11www.apple.com/es/mac/numbers/12developer.android.com/intl/es/tools/support-library/13developer.android.com/intl/es/google/play-services/14www.firebase.com15square.github.io/picasso/

37

Android16, haciendo uso de la libreria Guice de Google17. La versión utilizada es la2.0.

PagerSlidingTabStrip. Librería para indicador de página interactivo18 compatible conViewPager de Support-library-v4 de Android. La versión utilizada es la 1.02.

PayPal. Librería para el pago dentro de la aplicación a traves de PayPal19. La versiónutilizada es la 2.0.

ZBarScanner. Librería para la lectura de códigos QR a través de la cámara dentro dela aplicación20.

Control de versiones

BitBucket. Servicio de alojamiento basado en web para proyectos21 que utilizan elsistema de control de versiones tanto de Git22 como de Mercurial23. En este caso par-ticular se ha hecho uso de Git como software de control de versiones.

Construcción de proyectos

Gradle. Herramienta para la automatización en la construcción del proyecto 24. Uti-lizado principalmente para la automatización de dependencias y la construcción devarios proyectos relacionados. Gradle es la herramienta de automatización en la cons-trucción de proyectos recomendada por Android para el desarrollo de sus aplicaciones.

4.2.3 HardwarePara el desarrollo del siguiente proyecto se han utilizado dos ordenadores personales por-

tátiles.

16github.com/roboguice/roboguice17(code.google.com/p/google-guice/)18github.com/astuetz/PagerSlidingTabStrip19github.com/paypal/PayPal-Android-SDK20github.com/dm77/ZBarScanner21bitbucket.org/22git-scm.com/23mercurial.selenic.com/24www.gradle.org/

38

Capítulo 5

Arquitectura

E N este capítulo se describe detalladamente la arquitectura en la que está basado el pre-sente Trabajo Fin de Grado. Se trata de una arquitectura modular y adaptativa, esto

es, se trata de una arquitectura divida en módulos interconectados entre sí, sobre la cual sepueden realizar cambios e incorporar nuevas funcionalidades de una forma sencilla.

Para la descripción de la arquitectura de PideMe se ha utilizado un diseño descendente

o Top-Down. Es decir, una vez que se ha especificado la funcionalidad general de la aplica-ción, se discuten los módulos o componentes que la forman, de manera que el lector puedatener una primera visión general y, más adelante, pueda produndizar en los detalles de cadauno de los módulos de la arquitectura.

5.1 Descripción general

La arquitectura está compuesta por un total de cinco módulos (ver figura 5.1), los cuálesse introducen brevemente a continuación. PideMe es un sistema software de gestión de pe-didos y pagos, en el cual un restaurante o local de ocio dispone de una aplicación móvil porparte del usuario y un portal de administración web para el servidor por parte del restauranteo local de ocio. Los pedidos realizados a través de la aplicación móvil por parte del clienteson registrados en el servidor para ser mostrados al restaurante o local de ocio. El objetivoprincipal es mostrar todos los productos disponibles en un local y permitir realizar un pe-dido de estos productos. En PideMe se pueden apreciar cinco módulos interconectados quecomponen la aplicación móvil. A través del módulo de análisis e interacción con la conexiónexistente con los módulos de gestión de locales, gestión de productos y gestión de compras,se muestra toda la información al usuario. Además a través de la conexión con el módulode localización se obtiene posicionamiento de un restaurante o local en un mapa. El módulode análisis e interacción se conecta con todos los módulos de la aplicación. En cuanto a laconexión entre los diferentes módulos de gestión, se encuentra la existente entre la gestiónde productos y gestión de compras. Es necesaria para el almacenamiento del listado de pro-ductos de un pedido. Por último, los módulos de gestión de locales y localización sólo seconectan con el módulo de análisis e interacción.

39

Módulo de gestión de locales. La función principal de este módulo es la obtenciónde los datos referentes a un local determinado así como las mesas de las que dispone.Los datos se obtienen de una base de datos remota y son almacenados en local a laaplicación móvil. La URL de la que obtener los datos de cada local será obtenida de uncódigo QR. El código QR será leido por la cámara del dispositivo y se comprobará siel local está registrado en la base de datos. Si el local se encuentra registrado, tambiénse comprobará que la mesa pertenece a dicho local. Además, este modulo se encargaráde proveer de los datos de un local determinado al módulo de análisis de interacción,el único con el que se conecta.

Módulo de gestión de productos. El principal objetivo de este módulo es obtener losproductos de un determinado local y almacenarlos en la base de datos local. Ademásse encargará de proveer de todos los productos de un local, agrupados por categorias,al módulo de análisis de interacción. Tambíen proveera de productos al módulo degestión de compras. Este módulo está conectado con el módulo de gestión de comprasy el módulo de análisis de interacción.

Módulo de gestión de compras. Su principal función es almacenar los pedidos com-pletados por el usuario. Los pedidos son almacenados tanto en la base de datos localcomo en la base de datos remota. En local los pedidos son almacenados por usuariomientras que en remoto los pedidos son almacenados por local. Además este módulotambién gestionará el pago de pedidos a través de PayPal o en efectivo. A través de laconexión con el módulo de gestión de productos, obtiene los productos pertenecientesa un pedido para su almacenamiento. También se encuentra conectado con el módulode análisis de la interacción para mostrar al usuario los pedidos que ya ha completado.

Módulo de localización. El principal objetivo de este módulo consiste en obtención dela posición de un determinado local dentro un mapa. Además, facilitará el como llegardesde la posición actual a la del local pero rediriguiendonos a Google Maps. Se conectacon el módulo de análisis de la interacción para mostrar al usuario el posicionamientoen el mapa.

Módulo de análisis de interacción. La principal función de este módulo consiste eninteractuar con el usuario y la funcionalidad de la aplicación. A través de este módulo,el usuario puede realizar peticiones a la aplicación y será el encargado de comunicarsecon los distintos modulos para dar respuesta a las peticiones del usuario y que puedavisualizarlas. Entre las funciones que se pueden realizar en este módulo se encuentran:mostrar un local, visualizar los productos de un determinado local asi como una brevedescripción de cada uno de ellos, realizar el pago de un pedido, mostrar mis localesalmacenados y mis pedidos completados, mostrar la posición de un local en el mapa yofrecerme una ruta para llegar a el, y leer las etiquetas QR pertenecientes a un local omesa dentro de él. Por tanto, este módulo se encuentra interconectado con el resto de

40

Figura 5.1: Arquitectura del sistema

módulos que componen la aplicación.

A continuación, se describirán más en profundidad cada uno de los módulos que compo-nen PideMe. Se realizará una descripción más exhaustiva de la funcionalidad concreta decada uno de ellos así como la discusión de los aspectos técnicos utilizados.

5.2 Módulo de gestión de locales

Este módulo es el encargado de procesar la información perteneciente a locales y mesasdentro de ellos. Los datos se encuentran tanto en el servidor remoto de la aplicación comoen la base de datos relacional local a la aplicación, si ya se ha hecho uso de ella al menosuna vez. Además cada local posee su propia URL que referencia a todos los datos en remotopertenecientes al local como productos agrupados en categorias, información del local, mesasde las que dispone el local y el registro de pedidos. La aplicación es capaz de procesar todoslos datos de un local obtenidos de un servidor remoto. La información obtenida del servidorremoto se almacena en las tablas correspondientes de la base de datos. También es capaz deleer de la base de datos local a la aplicación los datos almacenados con anterioridad.

En este módulo se pueden distinguir tres submódulos diferentes:

Obtención de datos de locales (ver sección 5.2.1).

Lectura de códigos QR (ver sección 5.2.2).

Gestión base de datos de locales (ver sección 5.2.3).

41

5.2.1 Submódulo de obtención de datos de locales

Todos los datos relativos a locales y mesas de las que dispone cada uno de ellos se en-cuentran en un servidor remoto, más concretamente en Firebase (ver sección 3.3.2). Firebasees una plataforma especializada en el almacenamiento y sincronización de aplicaciones entiempo real. Firebase proporciona una API1 que facilita la interacción. Además en el caso deAndroid también proporciona un SDK para facilitar el desarrollo a nivel de cliente. En cuan-to a la seguridad, Firebase requiere cifrado SSL de 2048 bits para todas las transferencias dedatos permitiendo restringir la lectura y la escritura a través de controles de acceso granulary autenticación personalizada. Todos los datos almacenados en Firebase se encuentran repli-cados y con copia de seguridad en múltiples ubicaciones seguras. La elección de Firebasecomo servidor remoto se debe a su facilidad de integración y de uso así como la seguridadque proporciona en la transmisión y almacenamiento de los datos.

Dentro de Firebase encontramos una tabla en la que podemos encontrar todos los localesdisponibles en la aplicación. Cada local posee una URL que hace referencia a la tabla dellocal con todos sus datos, los productos agrupados por categorías y los pedidos realizados enel. La gestión de los datos en remoto se realizán a través de la web de Firebase2 ya que no sedispone de un cliente de escritorio para gestionarlos. A través de ella se puede incluir nuevoslocales, modificar los ya existentes, modificar productos o categorías de locales,... todo deuna forma fácil e intuitiva (Figura 5.2).

Por parte de la aplicación Android, los datos se obtienen del servidor remoto haciendo usode la librería proporcionada por Firebase (Firebase SDK). Dicha librería permite la obten-ción de datos de una URL de Firebase indicando la tabla que se desea obtener. La libreríade Firebase se encarga de gestionar la obtención de datos, la actualización de los datos yaobtenidos y la gestión de errores. Los datos obtenidos desde Firebase se almacenan en labase de datos local de la aplicación. La aplicación se encarga de crear la base de datos y lastablas si es la primera vez que se utiliza la aplicación. El módulo Gestión de base de datos

de locales(ver sección 5.2.3) es el encargado de todo lo referente a la base de datos.

La aplicación en su primer inicio obtiene la URL de Firebase de todos los locales que seencuentran registrados en el servidor. Estos datos son almacenados en la base de datos localy utilizados para la comprobación de si un local está o no en la aplicación cuando se procedea la lectura de un local mediante su etiqueta QR. En el caso de las mesas, cada local poseeun determinado número de mesas registradas, cada una con una etiqueta identificativa. Elproceso de comprobación que se sigue para comprobar si una mesa esta registrada en unlocal es el mismo procedimiento que en los locales.

1https://www.firebase.com/docs/2www.firebase.com

42

5.2.2 Submódulo de lectura de códigos QRLa obtención de la URL de Firebase de cada local y la mesa en la cual nos encontramos

dentro de un local se hace desde una etiqueta QR (ver figura 5.3). Cada local y dentro de élcada mesa, dispondrá de un etiqueta QR identificativa, tanto de local como de mesa, dentrodel local. Para la lectura del código QR se hace uso de la librería ZBarScanner (ver sección4.2.2). El procedimiento para leer una etiqueta QR desde la propia aplicación Android esmuy simple. Para la obtención del contenido de una etiqueta QR, se lanza un nuevo Intent3

y se obtiene el resultado del escaneo en el Activity4 desde el que se ha lanzado Intent. Elresultado obtenido puede ser positivo, en cuyo caso se obtiene una URL perteneciente a unlocal o una mesa en la cual localizarse dentro del local. El caso negativo puede producirseporque el dispositivo móvil desde el que se está intentando realizar la lectura no dispone decámara o posee una cámara no válida.

5.2.3 Submódulo de gestión de base de datos de localesUna vez que los datos de locales han sido obtenidos desde el servidor remoto y almace-

nados en la base de datos local de la aplicación, necesitan ser gestionados. Este submódulose encarga de la insercción, lectura y modificación de los datos contenidos en la base dedatos local referentes a locales. Además, si la aplicación se lanza por primera vez será ca-paz de crear la base de datos local y todas las tablas necesarias para el almacenamiento deinformación local.

Cada vez que se inicia la aplicación móvil se comprueba si existe la base de datos local,para que en caso de que no exista crearla. También se comprueba que existe la tabla de

3En Android, un Intent sirve para invocar nuevas Activities, que son componentes de la interfaz gráfica,servicios, código en segundo plano, broadcast receivers o proveedores de contenido.

4Un Activity se encarga de la creación de una ventana en la que se puede colocar la interfaz de usuario conla que interactuar.

Figura 5.2: Dashboard de Firebase. Locales.

43

locales y se encuentra actualizada. La creación de la base de datos local se realiza a travésde sentencia SQLite. La clase SQLiteHelper que extiende de SQLiteOpenHelper se encargade la creación (ver listado 5.1) y modificación de la base de datos. La obtención de los datosalmacenados en la tabla de Locales se realiza también a través de sentencias SQLite paradespues a través del Módulo de análisis de interacción y pruebas mostrarselos al usuario.

public class SQLiteHelper extends SQLiteOpenHelper {

@Overridepublic void onCreate ( SQLiteDatabase db) {

db. execSQL (" CREATE TABLE LOCALS (name TEXT , url TEXT , imageTEXT)");

}}

Listado 5.1: SQLiteHelper. Creación de Base de datos de locales

Figura 5.3: Código QR.

Figura 5.4: Etiqueta QR. Local

44

Figura 5.5: PideMe. Captura de listado de productos

5.3 Módulo de gestión de productos

Este módulo es el encargado de procesar los datos de todos los productos de un local.Cada producto va acompañado de una fotografía, una breve descripción y un precio. Al igualque ocurre con los datos de locales, en este caso ocurre lo mismo, los datos se encuentrantanto en el servidor remoto como en la base de datos local. Los productos se encuentranagrupados en categorías en ambos lados. Cada local dispone tanto de sus categorías como desus productos por lo que los productos son propios de cada local.

En este módulo podemos distinguir dos submódulos diferentes:

Obtención de datos de productos.

Gestión base de datos de productos.

La aplicación es capaz de obtener todos los productos de un local agrupados en categorías.Los productos son almacenados en la base de datos local de la aplicación Android. Ademáses capaz de obtener los datos ya almacenados en la base de datos local para comunicarse conel módulo de análisis de interacción y pruebas que se encargará de mostrarselos al usuario(Figura 5.5).

5.3.1 Submódulo de obtención de datos de productosCada local posee una serie de categorías de productos. Cada una de estas categorías esta

formada por un conjunto de productos. Este módulo se encarga de obtener todos los produc-tos de un local agrupados en categorías de un servidor remoto de Firebase. Dentro de Firebasecada local posee una tabla (ver imagen IMAGEN-TABLA) en la que podemos encontrar lascategorías de las que dispone el local y los productos que componen cada categoría. Ade-

45

Figura 5.6: Dashboard de Firebase. Local de ejemplo.

más cada producto esta formado por una URL que referencia una imagen de producto, unnombre, una descripción y el precio del mismo (Figura 5.6). La modificación de este modelode datos implicaría la modificación de los modelos tanto a nivel de servidor como a nivelde cliente, ya que ambos deben compartir el mismo modelo de datos para poder realizar latransferencia de información. La gestión de productos de cada local en el servidor remotose gestionan a través del Dashboard de Firebase al cual se accede a través de su web5. Através de ella se pueden incluir o eliminar categorias o productos en un determinado local o,modificar las categorias o productos ya existentes en un local.

En la aplicación Android, al igual que ocurría con los datos de los locales, se obtienendel servidor remoto haciendo uso de la librería proporcionada por Firebase (Firebase SDK).El procedimiento para la obtención de los productos desde el servidor remoto de Firebasees la misma que para los locales. A través de la URL que cada local registrado en PideMe

posee se puede acceder a la tabla que contiene las categorías del local. Una vez obtenidas lascategorías y haciendo uso de ellas, se obtienen los productos contenidos en cada una de ellasaccediendo a la tabla de cada una de ellas. Los productos obtenidos se almacenan en la basede datos local a la aplicación (ver listado 5.2) para después acceder y mostrarlos cuando elusuario lo solicite a través del módulo de análisis de interacción y pruebas. En caso de quesea la primera vez que se accede a un local, la aplicación se encargará de crear la base dedatos y las tablas necesarias para almacenar los productos de un local. De esto se encarga elmódulo de Gestión de base de datos de productos(ver sección 5.3.2)

5.3.2 Submódulo de gestión de base de datos de productosEste módulo se encarga de la gestión de la base de datos de productos de un determinado

local. Si es la primera vez que accede a un local, la aplicación es capaz de generar las tablas

5www.firebase.com

46

Firebase ref = new Firebase ("URL").child(" localTable ");

ref. addChildEventListener (new ChildEventListener () {

@Overridepublic void onChildAdded ( DataSnapshot arg0 , String arg1) {

Product p = arg0. getValue ( Product .class);

SQLiteDatabase db;SQLiteHelper usdbh = new SQLiteHelper ( activity .

getApplicationContext (), " DBProducts ", null, 1);db = usdbh. getWritableDatabase ();ContentValues newProduct = new ContentValues ();newProduct .put("name", p. getName ());newProduct .put("price", p. getCost ());newProduct .put("image", p. getPhoto ());newProduct .put(" description ", p. getDescription ());db. insert (tableDB , null, newProduct );db.close ();

}});}

Listado 5.2: Firebase. Obtención de productos de un local.

necesarias para el almacenamiento en categorías de todos los productos de un local.

Cada vez que se accede a un local se obtienen todos los productos del mismo a través delsubmódulo de obtención de productos. Los productos obtenidos se almacenan en la base dedatos local de la aplicación. Lo mismo ocurre cada vez que se cambia de local. Esto sucedeporque no hay un control de versiones, es decir no existe un control sobre si los datos quela aplicación tiene en local están actualizados con los que hay disponibles en remoto. Porlo tanto, cada vez que se accede a la aplicación o se cambia de local se elimina la base dedatos del local y se crea y se pobla con los datos obtenidos del nuevo local. La aplicaciónno dispone de un control de versiones ya que este debería realizarse tanto a nivel de localcomo a nivel de dispositivo. Además, la lógica del control de versiones debería realizarse ena nivel de servidor, aumentando el grado de complejidad de este. Debido a que esto sale delos objetivos marcados en el proyecto, se decidió no implementar el control de versiones yrealizar la descarga de todos los datos de un local en cada lectura de una etiqueta QR.

Por tanto, la principal función de este módulo es la creación y modificación de la basede los productos de un local, agrupados en categorías. Además, será capaz de obtener losproductos almacenados de una categoría para a través del Módulo de análisis de interaccióny pruebas mostrarlos al usuario.

5.4 Módulo de gestión de comprasLa aplicación móvil permite la opción de completar pedidos y el pago de los mismos a

través de la propia aplicación. Este módulo se encarga de la gestión de pedidos, del pago de

47

los mismos y el envío de los pedidos completados al servidor remoto de Firebase. El pagode pedidos se podrá realizar a traves de PayPal, integrado en la aplicación, o en efectivo.Además se almacenará en la base de datos local de la aplicación los pedidos completadospor el usuario en un local.

En este módulo podemos distinguir dos submódulos diferentes:

Gestión de pedidos.

Envío de pedidos.

La aplicación es capaz de gestionar los pedidos a nivel local de la aplicación para des-pués enviar al servidor remoto de Firebase los pedidos completados. Además, es capaz dealmacenar en la base de datos local los pedidos completados por el usuario.

5.4.1 Submódulo de gestión de pedidosEste módulo se encarga principalmente de gestionar los pedidos del usuario a nivel de

aplicación. Su principal función es la agregación, modificación o eliminación de productos alpedido que el usuario está realizando en tiempo real, así como el pago de un pedido completo.Controla que para poder realizar el pago de un pedido, el usuario haya leído previamente laetiqueta de la mesa en la cual se encuentra ubicado dentro del local. En caso de encontrarsesin mesa leída y querer realizar el pago del pedido se obligará al usuario a leer la etiqueta dela mesa en la que se encuentra.Con una mesa identificada y un pedido completo, se puede realizar el pago del mismo. Elpago de un pedido en PideMe se puede realizar a traves de PayPal o en efectivo. El pagoa través de PayPal se realiza a haciendo uso de su SDK para desarrolladores Android6 (verlistado 5.3). Una vez que el pago se ha completado, el módulo de Envío de pedidos se encargade comunicar el pedido al servidor remoto. Además, se almacena el pedido en la base dedatos de la aplicación.A través de este módulo también se podrán obtener los pedidos almacenados en la base dedatos local de la aplicación para a través del módulo de análisis de interacción y pruebasmostrar al usuario los pedidos completados en un local.

5.4.2 Submódulo de envío de pedidosLos pedidos completados en un local, además de almacenarse en la base de datos local de

la aplicación, se deben almacenar en el servidor remoto de Firebase. En el servidor remotode Firebase, cada local posee una tabla de pedidos. Cada pedido esta formado por un costetotal del pedido, una lista de productos y una mesa. La comunicación con el servidor remotode Firebase y el envío del pedido se realiza a través de la librería de Firebase (Firebase SDK)(ver listado 5.4). Cada local almacenada en una tabla todos los pedidos completados a través

6developer.paypal.com/docs/integration/mobile/android-integration-guide/

48

public class PaypalActivity extends Activity {

@Overrideprotected void onCreate ( Bundle savedInstanceState ) {

super. onCreate ( savedInstanceState );

PayPalPayment thingToBuy = new PayPalPayment ("Total", "EUR", "Id_Order ");

Intent intent = new Intent (this, PaymentActivity .class);intent . putExtra ( PaymentActivity . EXTRA_PAYPAL_ENVIRONMENT , "

Enviroment ");intent . putExtra ( PaymentActivity . EXTRA_CLIENT_ID , " credential

from developer . paypal .com");intent . putExtra ( PaymentActivity . EXTRA_RECEIVER_EMAIL , "

matching paypal email address ");intent . putExtra ( PaymentActivity . EXTRA_CLIENT_ID , "credential−

from−developer . paypal .com");intent . putExtra ( PaymentActivity . EXTRA_PAYER_ID , "your−customer

−id−in−your−system ");intent . putExtra ( PaymentActivity . EXTRA_PAYMENT , thingToBuy );

startActivityForResult (intent , 0);}

@Overrideprotected void onActivityResult (int requestCode , int resultCode ,

Intent data) {if ( resultCode == Activity . RESULT_OK ) {

PaymentConfirmation confirm = data. getParcelableExtra (PaymentActivity . EXTRA_RESULT_CONFIRMATION );

if ( confirm != null) {// Pedido completado

}} else if ( resultCode == Activity . RESULT_CANCELED ) {

// Cancelado por usuario} else if ( resultCode == PaymentActivity .

RESULT_PAYMENT_INVALID ) {// Metodo de pago no valido

}finish ();

}

Listado 5.3: PayPal. Pago de un pedido.

de la aplicación de Android.

Firebase ref = new Firebase ("URL").child(" Pedidos ");ref.push (). setValue ("Order");

Listado 5.4: Firebase. Envío de pedido.

49

Figura 5.7: PideMe. Captura de localización

5.5 Módulo de localizaciónLa aplicación muestra la posición geográfica de un local en el mapa (Figura 5.7). En la

obtención de los datos de un local determinado, se obtiene la longitud y latitud del local enel mapa. Este módulo se encarga de posicionar un local dentro de un mapa para despuésmostrarlo al usuario. Además es capaz, haciendo uso de Maps, de mostrar la ruta desde laposición actual del usuario hasta la posición del local.

En este módulo podemos distinguir dos submódulos diferentes:

Posicionamiento en mapa.

Ruta en mapa.

5.5.1 Submódulo de posicionamiento en mapaEste módulo se encarga de posicionar un local en un mapa con las coordenadas del local

obtenidas en la obtención de datos. Para el posicionamiento se hace uso del SDK de Google

Play Services, en concreto de API v2.

Para poder hacer uso del servicio de mapas de Google es necesario obtener una API Key.Esta se obtiene a través de la consola de APIs de Google7. En primer lugar, se debe regis-trar el proyecto para tener acceso a todas las APIs de Google. En el presente proyecto soloserá necesario hacer uso de Google Maps Android API v2. Una vez registrado el proyectoobtenemos la API Key del mismo que en este caso permite hacer uso del servicio de mapasen la aplicación. Cabe destacar que para obtener el API Key para el uso de los mapas será

7code.google.com/apis/console/

50

necesario indicar el nombre de la aplicación, el tipo Android, el modo de acceso en esteAccesing APIs directly from Android, el paquete Java utilizado en la aplicación y la huelladigital SHA1 del certificado con el que se firma la aplicación. Este último se obtiene delentorno de desarrollo en el cual se desarrolla la aplicación. Con todo lo anterior ya se tendríaacceso a la API de Mapas desde la aplicación.

En la aplicación Android, para poder acceder a la API de Mapas de Google es necesarioincluir algunas modificaciónes en AndroidManifest.xml 8. La primera de ella es la API Keyobtenida en el registro a través de la consola de APIs de Google. Además se deben incluiruna serie de acceso que permitan acceder a Internet, conocer el estado de la red, acceder alalmacenamiento externo del dispositivo para la caché de mapas y hacer uso de los serviciosde Google.

Para el posicionamiento de un local en un mapa, se debe introducir el mapa en forma defragment9 en el layout correspondiente al mapa.

<fragment xmlns:android ="http: // schemas . android .com/apk/res/ android "xmlns:tools ="http: // schemas . android .com/tools"android:layout_width =" match_parent "android:layout_height =" match_parent "android:id ="@+id/map"tools:context ="com.tfg. location .app. MapsActivity "android:name ="com. google . android .gms.maps. SupportMapFragment "/

>

Listado 5.5: Layout de mapas.

Por parte de Java, se referencia el mapa introducido en el layout y se configuran la posicióndel local para que se muestre en el mapa. Además se configurán una serie de parámetroscomo el tipo de mapa o la posición de la cámara al mostrar el mapa. También se añade unamarca en el mapa con la posición exacta del local. Dicha marca mostrará más informaciónsobre el local al pulsar sobre ella.

A través de este módulo mediante el acceso desde el módulo de análisis de interacción ypruebas, se mostrará al usuario la posición de un local en el mapa.

5.5.2 Submódulo de ruta en mapaLa aplicación Android permite la creación de una ruta desde la posición actual del usuario

hasta la posición del local actual. Cuando se obtiene la información del local actual se obtiene8AndroidManifest.xml es un archivo que posee toda aplicación Android. El archivo presenta información

esencial acerca de la aplicación para el sistema Android. Principalmente contiene el nombre del paquete Javade la aplicación, los componentes que componenen la aplicación, los permisos necesarios para su ejecución oel nivel mínimo de la API sobre la que puede ejecutarse entre otros

9Un fragment es una porción de interfaz de usuario en un Activity (develo-per.android.com/intl/es/guide/components/fragments)

51

Figura 5.8: Dashboard de Firebase. Administración.

la latitud y longitud del mismo. Haciendo uso de Google Maps10 y a través de un nuevoIntent se muestra la ruta solicitada al usuario (ver listado 5.6). A través de este módulo desdeel módulo de análisis de interacción y pruebas se accede a la aplicación de Google Maps conla ruta desde la posición actual del usuario hasta la posición del local.

Local local = (( PidemeApplication ) getActivity (). getApplication ()).getLocal ();

Uri uri = Uri.parse("http :// maps. google .com/maps ?& saddr=" + local.getLatitude () + ","

+ local. getLongitude () + "&daddr=" + local. getLatitude () + ","+ local. getLongitude ());Intent intent = new Intent ( Intent . ACTION_VIEW , uri);startActivity ( intent );

Listado 5.6: Intent Google Maps.

5.6 Módulo de análisis de interacción y pruebasLa interacción con el usuario final de la aplicación móvil como con el administrador de

la parte del servidor es la parte fundamental para el funcionamiento de la aplicación. Lainteracción por la parte del servidor se realiza en el Dashboard de Firebase (Figura 5.8). Através del Dashboard se puede gestionar desde la creación de nuevas aplicaciones, hasta laeliminación o modificación de datos de aplicaciones ya existentes. En el caso de la presenteaplicación, a través de él se gestionarán las diferentes tablas de locales, una por cada unode ellos. Se puede añadir, modificar o eliminar cualquiera de las categorias contenidas en latabla, datos del local, mesas de las que dispone, categorías de productos, productos de cadacategoría e incluso los pedidos.

Por parte de la aplicación Android, la interacción se realiza a través de un dispositivomóvil con plataforma Android. La navegación a través de la aplicación se realiza haciendo

10Aplicación de navegación de Google (www.google.es/mobile/maps/)

52

Figura 5.9: PideMe. SlidingPaneLayout.

uso del layout nativo SlidingPaneLayout11. En el SlidingPane se encuentran cada uno de loselementos que podemos visitas y, al pulsar en alguno de ellos, aparecen los detalles (Figura5.9). En cuanto a la implementación, primero se define el aspecto principal de la aplicacióna traves de un layout (ver listado 5.7). SlidingPaneLayout está compuesto por un ListView12,que contiene las categorías de las que está compuesta la aplicación y, un FrameLayout13 queirá conteniendo cada uno de los fragment de las categorías conforme se vaya pulsando enellas.

La funcionalidad de SlidingPaneLayout se define en la clase Java principal de la aplica-ción. En la creación de la vista se instancia el layout que contiene el SlidingPaneLayout.Primero se rellena la lista con todas las categorías de las que dispone el local y se define laacción al pulsar sobre alguna de ellas. También se define el comportamiento del boton ho-me del ActionBar14. A través del método selectItem se produce la carga en el FrameLayoutdel fragment correspondiente a la sección en la que el usuario ha pulsado, mostrando porpantalla dicho fragment.

Haciendo uso de SlidingPaneLayout, el usuario puede acceder a toda la información de laaplicación. A continuación de describe la comunicación que existe entre cada categoría del

11developer.android.com/intl/es/reference/android/support/v4/widget/SlidingPaneLayout12Vista que muestra una lista de elementos y que puede desplazarse (develo-

per.android.com/intl/es/guide/topics/ui/layout/listview)13Contenedor de fragment que bloque un área de la pantalla (develo-

per.android.com/intl/es/reference/android/widget/FrameLayout)14La barra de acción identifica la ubicación del usuario y proporciona las acciones del usuario y métodos de

navegación (developer.android.com/intl/es/guide/topics/ui/actionbar).

53

<android . support .v4. widget . SlidingPaneLayout xmlns:android ="http: //schemas . android .com/apk/res/ android "android:id ="@+id/ drawer_layout "android:layout_width =" match_parent "android:layout_height =" match_parent "android:background =" @android:color /white">

<ListViewandroid:id ="@+id/ left_drawer "android:layout_width ="240 dp"android:layout_height =" match_parent "android:background =" #000000 "android:choiceMode =" singleChoice "android:divider ="# FFFFFF "android:paddingLeft ="15dp"android:paddingRight ="15dp"android:paddingTop ="5dp"android:dividerHeight ="0.1 dp" />

<FrameLayoutandroid:id ="@+id/ content_frame "android:layout_width =" match_parent "android:layout_height =" match_parent " />

</ android . support .v4. widget . SlidingPaneLayout >

Listado 5.7: PideMe. Layout Principal.

SlidingPaneLayout y los diferentes módulos de la aplicación (Figura 5.10).

Local. Muestra información acerca del local actual en el que se encuentra el usuario.Además muestra una fotografía del local. La información de esta categoría se obtienede la comunicación con el módulo de gestión de locales(ver sección 5.2), en concretocon el submódulo de gestión de base de datos de locales. Se obtienen los datos dellocal y se muestra al usuario.

Productos. En comunicación con el módulo de gestión de productos y, dentro de elcon el submódulo de gestión de base de datos de productos (ver sección 5.3.2). A travésde dicho submódulo, se muestran al usuario todos los productos disponibles en el localagrupados en categorias. Para mostrar las categorías se hace uso de tabs, a través dela librería PagerSlidingTabStrip (ver sección 4.2.2). Dentro de cada tab los datos semuestran en forma de lista haciendo uso de un listView. Se puede obtener informacióndetallada de cada productos pulsando sobre el. Al pulsar sobre un producto se muestraen un nuevo layout una descripción del producto y se visualiza en mayor tamaño lafotografía del producto seleccionado.

Mi pedido. Muestra en tiempo real los productos añadidos a la compra así como elnúmero de unidades de cada uno de ellos. Los datos del pedido se obtienen de la co-municación con el módulo de gestión de compras y en concreto, con el submódulode gestión de pedidos (ver sección 5.4.1). A través de este módulo también se ges-

54

Figura 5.10: Capturas PideMe. De izquierda a derecha. Arriba: Local, Productos y Mi pedi-do. Medio: Ubicación, Como llegar y Leer mesa. Abajo: Mis locales, Mis pedidos y Acercade.

55

tiona el pago de los pedidos. Una vez que el pedido ha sido completado, a través delsubmódulo de envío de pedidos (ver sección 5.4.2), estos son enviados al servidor.

Ubicación. Muestra la posición exacta del local actual en el mapa. Esto se consigue através del módulo de localización y en concreto a través del submódulo de posiciona-miento en mapa (ver sección 5.5.1).

Como llegar. Obtiene la ruta desde la posición del usuario hasta la posición del local.En comunicación con el submódulo de ruta en mapa (ver sección 5.5.2) se muestra enGoogle Maps la ruta anterior.

Leer mesa. Cada mesa está identificada dentro de un local por una etiqueta QR. Lomismo ocurre con los locales. En esta sección se mostrará la mesa en la que se encuen-tra el usuario. La mesa en la que se encuentra el usuario será leida de una etiqueta QRhaciendo uso del submódulo de lectura de códigos QR (ver sección 5.2.2). Además sepodrá cambiar de mesa repitiendo el proceso.

Mis locales. Es esta sección se muestra un listado de todos los locales leidos a travésde una etiqueta QR. Además pulsando en alguno de ellos se cargará en la aplicacióntodos los detalles pertenecientes al local seleccionado. La lista de locales se obtienea través del módulo de gestión de locales y en concreto, a tráves del submódulo degestión de base de datos de locales (ver sección 5.2.3).

Mis pedidos. Muestra todos los pedidos completados por el usuario en el local actual.A través del submódulo de gestión de pedidos (ver sección 5.4.1) se obtienen los pe-didos completados para mostrarlos al usuario. De cada pedido se visualizan todos losdetalles como mesa, importe total, fecha y tipo de pago además, al seleccionar cadauno de ellos se puede visualizar la lista de productos del pedido.

5.7 PruebasEn cuanto al aspecto de pruebas, David Vallejo, director del presente TFG, ha actuado

como asegurador de la calidad15 de la aplicación móvil Android. Se ha encargado de que elproducto cumpla con los requisitos de calidad acordado en las planificaciones. Además decomprobar que la aplicación cumplia los requisitos de funcionalidad acordados. También hapropuesto modificaciones de diseño para conseguir una aplicación amigable al usuario y defácil uso.

5.8 Patrones de diseñoEn la presente aplicación se hace uso de dos patrones de diseño. En cuanto a la arquitectura

de la aplicación móvil se hace uso del patrón Modelo Vista Presentador16 para conseguir una

15QA: Quality Assurance16En adelante MVP.

56

aplicación extensible y facilmente mantenible. Por parte de la gestión de datos dentro de laaplicación móvil se hace uso de patrón Data Access Object17.

5.8.1 Modelo Vista PresentadorLa arquitectura de una aplicación Android que está cobrando gran importancia en su desa-

rrollo es el patrón MVP. El modelo MVP es un patrón derivado del conocido MVC (ModeloVista Controlador). El patrón MVP permite separar la lógica de la aplicación de su capa depresentación es decir, todo lo relacionado con como funciona la interfaz queda separado delcómo mostralo al usuario en pantalla. El caso ideal del patrón MVP es conseguir que unamisma lógica pudiera tener vistas totalmente diferentes e intercambiables. Un ejemplo detodo esto sería la misma lógica para mostrar la información a través de dos vistas diferentesen un smartphone y en una tablet. Dos dispositivos con distintas dimensiones de pantalla ypor lo tanto distinta representación en la misma pero, con la misma lógica.

Uno de los problemas en el desarrollo de Android es el hecho de que los Activity estánintimamente aclopados tanto con la interfaz como con el acceso a datos. Para que una apli-cación sea fácilmente extensible y mantenible es necesario tener bien separadas sus capas.El modelo MVP se encarga de independizar la vista de la forma en la que se consiguen losdatos que tiene que mostrar. De esta forma, se divide la aplicación en tres capas, una capade Modelo, otra de Vista y una última de Presentador, pudiendo ser testeadas de forma inde-pendiente.

La función de cada una de las vistas se describre a continuación y la relación entre ellaspuede verse reflejada en la figura 5.11.

Modelo. En una aplicación con una buena arquitectura por capas, el modelo no es másque la puerta de enlace de la capa de dominio o de lógica de negocio. Es el proveedorde los datos a mostrar en la vista.

Vista. Cada vez que se realice una acción sobre la interfaz, se encargará de llamaral presentador para ejecutar la acción solicitada. En el presente proyecto la vista estahabitualmete implementada por un fragment y en ocasiones por un fragmentActiviyt.La vista es la encargada de crear el objeto presentador.

Presentador. Actua de intermediario entre la vista y el modelo. Su función es recupe-rar los datos del modelo y devolverlos formateados a la vista. La diferencia de MVPcon el MVC tradicional es que el presentador también decide que ocurre cuando seinteractua con la vista.

En resumen, una aplicación Android con independencia entre la interfaz y la lógica ha-ciendo uso del modelo MVP, proporciona una aplicación fácilmente mantenible y escalable.Además en proyectos de aplicaciones Android relativamente grandes es imprescindible unabuena organización del código y el modelo categórico.

17En adelante DAO.

57

Figura 5.11: MVP Android

5.8.2 Data Access ObjectLa gestión de los datos dentro de la aplicación móvil se gestiona de forma eficiente ha-

ciendo uso de este patrón. Este patrón esta compuesto por las clases de modelo necesarias enla aplicación y, una interfaze que posee los métodos necesarios para obtener y almacenar losdatos de todas las clases de modelo. Esta interfaze no tiene conexión ninguna con la base dedatos ni ningún medio de almacenamiento usado. Por otro lado se encuentra la implementa-ción de la interfaz DAO con las consultar correspondientes a la base de datos.Con este patrón solo la implementación de la interfaz DAO tiene comunicación con la basede datos local de la aplicación. Además, al hacer uso de la interfaz DAO, se podrá cam-biar la implementación o la fuente de obtención de datos sin que esto afecte al resto de laaplicación.

58

Capítulo 6

Evolución, resultados y costes

E N este capítulo se describen las fases e iteraciones de desarrollo de PideMe. Tú pides,

nosotros servimos. Se describen todos los hitos así como las características consegui-das en cada uno de ellos. Además se muestran datos relacionados con la complejidad y elcoste temporal. Asimismo, se aportan datos del rendimiento de la aplicación en el caso deestudio de un local de ocio. Por último, se detallan los costes de desarrollo de la aplicación anivel económico. El desarrollo del presente proyecto ha seguido la metodología Scrum1 Lametodología Scrum es un modelo de desarrollo ágil que se caracteriza principalmente porseguir una estrategia de desarrollo incremental en vez de un desarrollo del producto comple-to.

6.1 EvoluciónEn esta sección se detallan las diferentes iteraciones llevadas a cabo para el desarrollo de

PideMe. Se describe la información relevante como los hitos alcanzados en cada iteración,la complejidad o el esfuerzo. La motivación principal del presente TFG es la falta de apps enel mercado para facilitar la realización de pedidos y el pago de los mismos en restaurantes olocales de ocio. En primer lugar se estableció el domino del presente TFG a restaurantes ylocales de ocio. Tras determinar el dominio, se elaboró un informe de aplicaciones similares,ver sección 3.2.2, y se obtuvieron tablas con ventajas e inconvenientes de cada una de ellas.Tras evaluar las diferentes aplicaciones similares se definieron los objetivos iniciales delproyecto. Dichos objetivos se enumeran a continuación y quedan detallados en el capítulo2:

El diseño y la implementación del sistema debe dar soporte al despliegue de gestiónde pedidos y pago de los mismos en locales de ocio o restaurantes.

La arquitectura debe ser independiente del dominio para ofrecer la posibilidad de des-pliegue en distintos locales de ocio o restaurantes.

La arquitectura debe ser modular y escalable para facilitar la integración de módulossegún las necesidades expuestas.

1Metodología en la que un proyecto se ejecuta en bloques temporales cortos y fijos de los cuales se obtieneun resultado completo (www.scrum.org).

59

Figura 6.1: Iteraciones en el desarrollo del sistema

El sistema de comunicación deber ser estable, orientado al tipo de información.

La aplicación debe hacer uso de bibliotecas libres y estándares abiertos.

Tras la definición de los requisitos iniciales del sistema, se dió comienzo al desarrollo delmismo (FECHA). El desarrollo ha seguido varias iteraciones que se describen a continua-ción.

6.1.1 SprintsPara el desarrollo del presente proyecto se ha seguido la metodología Scrum. La aplicación

de esta metodología ha hecho que se establezcan sprints de dos semanas. Cada comienzo desprint se establecian unas tareas que debían ser completadas a lo largo del sprint. Al final decada uno de ellos, exceptuando el primer y segundo sprint, se obtenía una aplicación com-pletamente funcional y que incluia las tareas completadas a lo largo de las dos semanas.

Sprint 1Al comienzo de esta iteración se crea la estructura del proyecto basada en el modelo MVP

(ver sección 5.8). Además se determinó que todo el proyecto debería estar gestionado porun sistema de control de versiones. Se implantó un sistema que soportara la estructura delproyecto, así como los cambios que iban sucediendo.

El objetivo de este sprint se resume en la creación de esqueleto de la aplicación móvil.Gradle2 fué elegido como gestor de construcción de proyecto. También se determinó quela información gestionada por la aplicación móvil sería obtenida de un servidor remoto quealmacenaría toda la información relativa a un restaurante o local de ocio y se almacenaráa nivel local de aplicación en una base de datos relacional, en el caso de Android SQLite.Firebase (ver sección 4.2.2) fue elegido para la gestión del servidor remoto. Mientras se im-plementa esta funcionalidad se define el modelo de datos utilizado en la aplicación para la

2Gradle es una herramienta para la construcción de proyectos de forma automática como compilación,testing, empaquetado y despliegue.

60

comunicación entre el servidor remoto y la aplicación Android.El resultado de este sprint no supuso ninguna aplicación funcional. Sin embargo, se cons-

truyo el esqueleto inicial de la aplicación Android siguiendo el patrón MVP.

Sprint 2Una vez que el primer sprint estuvo completado, se implementó la primera aproximacion

de todas las clases de modelo necesarias en el cliente Android. La funcionalidad a imple-mentar son las clases DAO que se encargan de la gestión de la base de datos local de laaplicación.

Con respecto al servidor, se pobló la base de datos del servidor remoto gestionado por Fi-rebase con dos locales de ejemplo. Para la población de la base de datos remota se siguió elmodelo impuesto en la aplicación Android para que tanto cliente como servidor compartanel mismo modelo de datos. Firebase proporciona la opción de poblar la base de datos a travésde la importación de un JSON o a través de un gestor web. También permite la exportaciónde todos los datos o de una tabla en concreto en JSON. En este caso la población de datos serealizó a través del gestor web proporcionado por Firebase.

El resultado de este sprint, al igual que el anterior, no supuso ninguna aplicación funcio-nal, pero define funcionalidad necesaria para el almacenamiento de los datos en local cuandose realice la comunicación cliente-servidor. Por parte del servidor se completo la poblaciónde la base de datos remota.

Sprint 3Se realiza la comunicación entre el cliente Android y el servidor Firebase. Para ello se hizo

uso de la librería proporcionada por Firebase para obtener los datos de su servidor remoto.Además se hizo uso del modelo creado en el sprint anterior para la obtención de los datosobtenidos haciendo uso de la librería de Firebase. Se implementó la clase para la obtenciónde los datos del servidor remoto a partir de una URL y un modelo de datos. Los datos obteni-dos en una primera comunicación fueron solo los detalles de un local determinado, nombre,descripción e imagen del local. Estos datos eran almacenados en la base de datos local de laaplicación Android utilizando las clases DAO implementadas en el sprint anterior.

Con los datos obtenidos del servidor remoto almacenados en la base de datos local seprocedió a la implementación de la categoría Local. En ella se obtenían los datos almacena-dos en la primera parte de este sprint para mostrarlos al usuario. Se implemento también elmodo de navegación de la aplicación, SlidingPaneLayout3 para el despliegue del menú de laaplicación haciendo swipe desde el borde lateral izquierdo de la pantalla o pulsando sobre elbotón de menú.

En este sprint se obtiene la primera aplicación funcional con la categoría de Local. Además

3developer.android.com/reference/android/support/v4/widget/SlidingPaneLayout

61

se implementa la comunicación entre el cliente Android y el servidor Firebase que permiteobtener cualquier tabla almacenada en remoto. Tambien se integra el modo de navegación dela aplicación haciendo uso del widget nativo SlidingPaneLayout. En este sprint se desarrollóla funcionalidad integra del módulo de gestión de locales (ver sección 5.2).

Sprint 4Aprovechando la implementación en el cliente Android de la comunicación con la base

de datos remota en Firebase se obtienen las categorías de productos y los productos. Se ob-tenian dichos datos y se almacenaban en la base de datos local utilizando las clases DAO.Una vez obtenidos los datos y almacenados se implementó la categoría de Productos. En estacategoría se mostraban los productos ofertados por el local agrupados por categorías. Para laimplementación de la vista de esta categoría se hizo uso de la librería PagerSlidingTabStrip

(ver sección 4.2.2) para el uso de tabs personalizadas y del ViewPager4 nativo de Androidpara mostrar las diferentes listas de productos. La implementación completa mostraba alusuario los productos agrupados por categorías. Además al seleccionar algún elemento de lalista se mostraba una descripción del productos seleccionado.

El resultado de este sprint, supuso la segunda aplicación funcional con las categorías deLocal y Productos. A lo largo del segundo sprint se desarrollo la funcionalidad del módulode gestión de productos (ver sección 5.3).

Sprint 5Una vez completada la obtención y visualización por parte del usuario de los datos del

local y todos los productos del mismo, se precedió a la implementación de crear pedidos. Lafuncionalidad a implementar en este sprint era la creación de una nueva categoría Mi pedido.La función de esta categoría es la gestión de un pedido a partir de los productos del local quese está visualizando. De esta forma, en la categoría de Productos se podían ir añadiendo alpedido con el número de unidades elegidas por el usuario. En la nueva categoría añadida sepodía visualizar el listado completo de productos del pedido así como el número de unidadesde cada uno de ellos y el precio total del pedido.En este sprint, también se implementó el pago de un pedido completo a través de PayPal.Para ello se implementó, haciendo uso del SDK de PayPal para Android (ver sección 4.2.2),la comunicación con PayPal para el pago del mismo. Previamente se realizó el registro de laaplicación en el apartado de desarrolladores de PayPal. Tambíen se implemento la el paso depedidos completados de la aplicación Android al servidor remoto. De esta forma todos lospedidos completados se almacenaban en el servidor remoto.

El resultado de este sprint, fué una aplicación completamente funcional en la que ya sepodía visualizar los detalles de un local y sus productos ademas de la posibilidad de realizar

4developer.android.com/reference/android/support/v4/view/ViewPager

62

un pedido y el pago del mismo. Todo ello a través de la aplicación Android. La funcionalidadimplementada en este sprint corresponde al módulo de gestión de compras (ver sección 5.4).

Sprint 6En PideMe los locales se obtendrían a partir de la lectura de un código QR. Lo mismo

ocurría con las mesas de un local. En este sprint la funcionalidad a incluir fué la integraciónde la librería ZBarScanner (ver sección 4.2.2) para la lectura de códigos QR. Con esta libre-ría se obtenía tanto un local como una mesa de local de una etiqueta QR. En el caso de loslocales, cada vez que se leía una etiqueta QR de un local registrado en PideMe cargaba todoslos datos del local.

Los locales leídos eran almacenados en la base de datos local de la aplicación para des-pues mostralos al usuario en forma de lista en una nueva categoría, Mis Locales. En el casode las mesas, una vez que una mesa era leído se mostraba al usuario la mesa en la que seencontraba. Además se permitía la opción de cambiar de mesa leyendo un nuevo código.

La aplicación funcional obtenida en este sprint permitía la obtención de los datos de unlocal a partir de una etiqueta QR. Se obtenían los datos del la base de datos remota de Fire-base y se mostraban al usuario los datos del local leído. Al final de este sprint la aplicaciónpermitía visualizar tanto el local como los productos de un local obtenido a partir de unaetiqueta QR. Además se permitía realizar un pedido y el pago del mismo. Al final de estesprint se completo el desarrollo del módulo de análisis de interacción (ver sección 5.6).

Sprint 7Este sprint se centro en la localización de un local en un mapa y la posibilidad de crear una

ruta desde la posición actual del usuario hasta la del local con GoogleMaps. Se implementola sección de Ubicación en la que se mostraba la localización exacta del local en un mapa.Los datos relativos a la localización del local eran obtenidos del servidor remoto cuando serealiza la obtención del local. Fue necesaria una reimplementación del modelo de Local tantoen servidor como en remoto.También se implemento la categoría de Como llegar. En ella se traslada al usuario a la apli-cación de GoogleMaps y se le mostraba la ruta desde su posición actual hasta la posición dellocal. Esta sección no puede ser visualizada dentro dePideMe ya que necesitaba ser visua-lizada en GoogleMaps. A través de GoogleMaps se permite seleccionar la forma en la quedesplazarse hasta el local y las opciones para obtener la ruta indicada.

Este sprint añade a la aplicación la funcionalidad de visualizar un local en un mapa asícomo la posibilidad de crear la ruta para desplazarse hasta el. En este sprint se desarrolló lafuncionalidad del módulo de localización (ver sección 5.5).

Sprint 8

63

En este sprint se llevo a cabo la implementación de una categoría que surgió del uso de laaplicación. Esta categoría es Mis Pedidos y en ella se muestran los pedidos completados porun usuario en un local determinado. Anteriormente los pedidos completados se almacenabanen remoto en cada local. La implementación consisitió en almacenar los pedidos completadosen la base de datos local de la aplicación para después mostrarlos al usuario en la categoríade Mis Pedidos.

Con la funcionalidad de este sprint se dió por concluida la implementación de la aplicaciónAndroid y la gestión de la base de datos remota de Firebase. Al final de este sprint se obtuvouna aplicación completamente funcional y que incluía toda la funcionalidad desarrollada alo largo de los ocho sprints. La funcionalidad desarrollada en este sprint es una ampliacióndel módulo de gestión de compras (ver sección 5.4).

Tras una serie de pruebas de la aplicación en diferentes tipos de usuarios, el desarrollo dePideMe fue finalizado logrando los objetivos planteados durante la etapa de análisis. A partirde este punto se empezó a desarrollar la presente documentación haciendo uso de la plantillaproporcionada por el grupo ARCO de la UCLM. Después se realizó la presentación para ladefensa del presente proyecto.

6.1.2 Evolución temporalLa evolución del presente proyecto respecto al tiempo puede observarse en la figura 6.1

6.2 ResultadosLa aplicación obtenida con la realización del presente TFG facilita a los usuario de res-

taurantes y locales de ocio la realización de sus pedidos. PideMe es una aplicación paraplataforma móvil Android sencilla y fácil de utilizar que, muestra todos los productos ofre-cidos por un local y reduce considerablemente los tiempos de espera en la realización deun pedido. Además, la integración de nuevos locales en PideMe es rápida y sencilla. Comose puede observar en el caso de estudio realizado con la implantación en un local de ocioreal, los usuario han obtenido unos resultados muy satisfactorios. Por último, con caractermás técnico se ha realizado un estudio estadístico acerca del proyecto, incluye algunos datoscomo número de líneas ó uso del repositorio.

6.2.1 Caso de estudioSe ha realizado la construcción de un caso de uso de la aplicación para recoger estadísticas

e información acerca de la funcionalidad y rendimiento de la aplicación móvil. Además, sedetalla el caso de estudio realizado y se analizan en profundidad los resultados obtenidos.

6.2.2 Análisis de uso de PideMeCuadrante para definir perfiles de usuario.

Definir una tarea compleja.

64

Crear un sencillo tutorial que se ajuste a la tarea.

Dejarle la aplicacion a los usuarios dandoles.

Tasa de exito / tasa fallo.

Tiempo medio.

Cuestionario SUS.

1. Me gustaría utilizar este sistema con frecuencia.

2. Encontré el sistema innecesariamente complejo

3. Pensé que el sistema era fácil de usar

4. Creo que voy a necesitar el apoyo de un técnico para poder utilizar este sistema

5. Me pareció que las diversas funciones de este sistema se integran bien.

6. Pensé que no había demasiada inconsistencia en este sistema.

7. Me imagino que la mayoría de la gente aprenderá a utilizar este sistema muyrápidamente.

8. Encontré el sistema muy complicado de usar.

9. Me sentí muy seguro al usar el sistema.

10. Yo tendría que aprender un montón de cosas antes de que empezar a utilizar estesistema.

6.2.3 Estadísticas del proyectoEn esta sección se estudian estadísticas acerca del presente proyecto. Este estudio se centra

principalmente en el número de líneas que componen cada una de las partes y el uso delrepositorio que permite obtener la actividad del desarrollador con el sistema de control deversiones.

Líneas de códigoEn la tabla 6.1 se detallan las líneas de código escritas en cada uno de los lenguajes utili-zados durante el desarrollo de la aplicación. Para obtener dichos datos se ha empleado laherramienta libre cloc5, que contabiliza el número de líneas escritas de un proyecto en cadalenguaje.

Lenguaje Ficheros Líneas en blanco Comentarios Total

- Java 10 50 20 10- Java 10 50 20 10

Cuadro 6.1: Estadísticas del proyecto

Uso de repositorio

5cloc.sourceforge.net

65

Figura 6.2: Actividad del repositorio

En este apartado se detalla la actividad del desarrollador de la aplicación con el sistemade control de control de versiones empleado. La figura 6.2 muestra el uso del repositorioapoyandose en dos datos: el número de commits y el número de cambios que ha sufrido elsoftware. Las estadísticas son generadas mensualmente, lo que permite obtener el mes conmás relevancia para el desarrollo del proyecto, noviembre. Si se tienen en cuenta las tareasdesarrolladas en cada uno de los sprints (ver sección 6.1.1), se llega a la conclusión de quenoviembre fue el mes con más cambios debido a que se desarrollo el cuerpo de la aplicaciónsobre la cual se apoya el resto de la aplicación. Este desarrollo incluyó la creación y gestiónde la base de datos tanto a nivel local como remoto y la comunicación entre ambos. Es poresto que durante este mes se generaron el mayor número de cambios significativos en laaplicación. Por otra parte, encontramos que diciembre es el mes que contiene más commits.Esto se debe a que es la etapa del proyecto donde se implementaron tareas muy pequeñaspero que aportaban funcionalidad extra al proyecto, de ahí la gran cantidad de commits quese producieron.

6.2.4 Pruebas6.3 Costes

En esta sección se detallan los costes en cuanto análisis, diseño y desarrollo de PideMeademás, de los recursos empleados en su realización. También se ofrece una estimación delcoste de implantación del proyecto en un entorno real. Finalmente, se analiza la monetizaciónen cuanto a términos de publicidad dentro de la aplicación, costes de PayPal o cuota mensualpor estar presente en PideMe.

6.3.1 Análisis, diseño y desarrollo

La implementación del presente TFG viene precedido de un análisis y diseño previo aldesarrollo. En primer lugar se realizó un estudio en el que se afianzaron los requisitos que

66

debía satisfacer PideMe en función de un estudio analítico de aplicaciones similares. A con-tinuación se realizó una primera aproximación en cuanto a diseño de la app. El diseño hasufrido varias modificaciones en el transcurso de la implementación de PideMe. Una vezdefinidos los requisitos y realizado un primer diseño se procedió al desarrollo del mismo. Eltiempo de implementación del presente TFG es de cuatro meses, divididos a los largo de 8sprints (ver sección 6.1.1). Para la implementación de la app se supone un trabajo diario de5 horas, asumiendo 5 días de trabajo a la semana y que el sueldo de una persona con conoci-miento de desarrollador de aplicaciones móviles para Android es de 25e/hora. Además, hayque añadir el coste de los dos computadores utilizados durante el desarrollo. EL coste totaldel proyecto asciende a 11.918 e(véase tabla 6.2)

Elemento Precio Unidades Total

Desarrollador Android 25 e/h 400h 10.000 eOrdenador Portatil Sony VAIO PCG-71811M 699 e 1 699 eOrdenador Portatil Apple MacBook 5,1 1219 e 1 1219 e

11.918 e

Cuadro 6.2: Coste total del proyecto

6.3.2 Implantación en un entorno realLa implantación del presente proyecto en un entorno real, restaurante o local de ocio sería

rápida y sencilla.

En primer lugar se realizará el registro de la base de datos del productos, categoríasy detalles del local en Firebase. En una primera aproximación se haría uso del planCandle, con un coste de $49 (35,62 e6) y, que cubriría las necesidades iniciales deimplantación.

Una vez obtenida la cuenta Firebase se procedería al poblado de la base de datos conlos productos que el local desee, además de los datos de categorías y detalles del local.La población de la base de datos de Firebase se hará siguiendo el modelo determinadoen la aplicación (ver sección modelo). De esta forma la base de datos de Firebaseestaría preparada para ser leída desde la aplicación móvil.

El siguiente paso sería el registro en PayPal con una cuenta de vendedor para poderrecibir transacciones a favor. Los costes de PayPal en cuanto a transacciones se puedeconsultar en la sección (ver sección 6.3.3).

Una vez completado tanto el registro en Firebase como en PayPal se puede proceder aal registro del local en PideMe.

El último paso para la implantación de un entorno real, será el registro del local en labase de datos de PideMe para ser reconocido por la aplicación móvil y obtener todos

6cambio dólar-euro a 10 de Mayo de 2014

67

sus datos de Firebase. Además se crearán las etiquetas QR identificativas tanto de localcomo de las mesas del local.

Con todo lo anterior, el local estaría completamente integrado en el ecosistema de Fireba-se.

6.3.3 MonetizaciónCon la aplicación completada para el lanzamiento sólo quería realizar la promoción de la

misma para obtener el mayor número de descargas posibles y monetizarla. Para la moneti-zación en Android encontramos tres posibilidades: app de pago, app con publicidad y appgratuita con compras dentro de la app. Además se debe tener en cuenta el coste por transac-ción en PayPal y la decisión de establecer una cuota mensual al restaurante o local de ocioque use la app.

Tipos Apps Android

En cuanto a monetización se refiere, en Android se pueden identificar distintos tipos deaplicaciones[Gor14] para rentabilizar la aplicación:

Aplicaciones de pago. El usuario deberá abonar una cantidad de dinero para poderrealizar la descarga de la aplicación.

Aplicaciones gratuitas con publicidad. Estas aplicaciones no tienen un coste para elusuario pero si deberá soportar la aparición de publicidad durante su uso.

Aplicaciones con opción mixta. La aplicación se encuentra disponible como aplica-ción de pago y como aplicación gratuita con publicidad. Es una opción que en Androidsuele funcionar bastante bien, ya que los usuarios no suelen comprar una aplicaciónsin antes probarla.

Aplicaciones gratuitas con compras dentro de la aplicación (Freemium). Estasaplicaciones son gratuitas para el usuario con una funcionalidad básica. Si desea añadirfuncionalidad más compleja debería ir comprando módulos que aporten esa funciona-lidad extra. Es el modelo seguido en la mayoría de juegos de plataformas móviles.

Aplicaciones con suscripción. El usuario deberá abonar una suscripción mensual oanual para hacer uso de la aplicación.

Aunque no se engloben dentro de monetización, en Android también se encuentran apli-caciones gratuitas. En el caso del presente proyecto como aproximación se recurrirá a estetipo de aplicación, ya que los gastos relacionados con la implantación y el mantenimiento dela aplicación serán sufragados por el conjunto de locales integrados en PideMe. En caso deno producirse el recibimiento esperado se plantearía una segunda opción con la inclusión depublicidad en la aplicación. Dicha publicidad abarataría el coste para los locales de pertene-cer a PideMe. Además, la publicidad mostrada en PideMe no sería genérica, si no que podría

68

ser contratada por empresas relacionadas con el campo de restaurantes o locales de ocio asícomo por los propios locales que pertenecen a PideMe. Se descartan las dos opciones res-tantes. La aplicación de pago por que el usuario no puede hacerse cargo de los gastos por unservicio del cual es el local el que obtiene el beneficio. Por parte de aplicación gratuita concompras dentro de la aplicación no es lógica ya que, la aplicación debe tener funcionalidadcompleta para que su uso tenga sentido.

PayPal. Comisión por pedido.

Dentro de la aplicación se contemplan dos posibilidades para realizar el pago de un pedido.Una de ellas es PayPal7. PayPal es un servicio utilizado por empresas y particulares paraenviar y recibir dinero a través de Internet. En el contexto del presente proyecto, cada localdeberá registrar una cuenta como vendedor para recibir los pagos realizados a través dePayPal. Las ventajas del uso de PayPal en PideMe son las siguientes:

Acepta pagos con tarjetas de crédito o débito, además de las propias cuentas de PayPal.

Es rápido. El pago se realiza de manera inmediata en la cuenta de PayPal asociada acada local.

Es seguro. PayPal ofrece avanzadas tecnologías de cifrado y antifraude.

El uso de PayPal ofrece comodidad y rapidez para el usuario a la hora de realizar un pagoy, seguridad y un amplio abanico de posibilidades de pago para cada uno de los localesregistrados. En el caso de los locales, PayPal no tiene tarifa mensual, de establecimiento ocancelación, sin embargo si cobra una tarifa por cada transacción en función de los ingresosrecibidos por el local a través de PayPal. Dicha tarifa esta formada por la suma de un importebase de 0.35 emás un porcentaje del total del importe de la transacción que se calcula enfunción de los ingresos realizados en el mes anterior por el local a través de PayPal (verTabla Tarifas PayPal8).

Ingresos mensuales Por transacción

0.00 e- 2.500,00 e 3,4 % + 0,35 e2500,01 e- 10.000,00 e 2,9 % + 0,35 e10.000,01 e- 50.000,00 e 2,7 % + 0,35 e50.000,01 e- 100.000,00 e 2,4 % + 0,35 e>100.000,01 1,9 % + 0,35 e

Cuadro 6.3: Tarifas de transacción en PayPal

Play Store.

La aplicación debería de ser de fácil acceso para el usuario por lo que será publica enla tienda de aplicaciones oficial de Android denominada Play Store. Para la publicación de

7www.paypal.com8www.paypal.com

69

PideMe en Play Store sólo será necesario obtener una cuenta de desarrollador por 25$ , pagoúnico. Una vez obtenida esta cuenta se podrá realizar la subida de aplicaciones sin límite ysin coste adicional. Para la subida a Play Store sólo es necesario generar un APK9, realizarunas capturas de las app y añadir una descripción. Además, se deberá indicar la categoría ala que pertenece la app y el precio de descarga para el usuario.

6.3.4 Cuota mensualLa aplicación será gratuita para el usuario, por lo que será el local quien se haga cargo

de los gastos. Dichos gastos estarían formados por el mantenimiento de la aplicación asícomo, la mejora en cuanto a diseño y funcionalidad de la misma. Por tanto los locales queformen parte de la aplicación deberán abonar una cuota mensual o anual, a elección dellocal, correspondiente al mantenimiento y mejora de la aplicación. En dicha cuota tambiénse contempla la gestión y mantenimiento de las bases de datos de los locales que componenPideMe como medida de soporte. La inclusión de un local en PideMe está contemplada endos cuotas diferentes una mensual y otra anual (ver tabla 6.4)

Tipo Cuota Precio

Mensual 49,90 e/mesAnual 499 e/año

Cuadro 6.4: Cuotas de inclusión en PideMe

Además, debido a que no existe cuota de alta nueva para la inclusión en PideMe, si existeun contrato de permanencia de 12 meses. De esta forma el local no deberá hacer un desem-bolso inicial elevado para su inclusión dentro de PideMe. Pero, debido a los costes de manode obra de la inclusión de un local en PideMe, registro de cuentas en FireBase y PideMe asícomo, la creación de etiquetas QR tanto para local como para las mesas que lo componen,se establece una permanencía mínima que asegure la estabilidad económica de la aplicación.Cabe destacar que a esta cuota, se debe añadir el gasto total del almacenamiento y uso enFirebase, $49. Además, no incluye los gastos producidos por las transacciones a través dePayPal, que correrán a cargo de cada uno de los locales y que, variarán en función del númerode ingresos mensuales realizados por el local a través de PayPal.

Ejemplo de coste total en un restaurante.

Supongamos un ejemplo para calcular el coste total para un restaurante de la implanta-ción de PideMe dentro de el. Se supone un restaurante que ha elegido la cuota mensualy que además, realiza en PayPal unos ingresos que se engloban dentro de la segundacategoría, entre 2.500,01 e- 10.000,00 e. También se supone que la medía de importede los pagos realizados a través de PayPal es de 250,00 econ una medía de unos 50

9Formato de paquete utilizados por el sistema Android para la distribución e instalación de aplicaciones. Setrata de una variante del formato JAR de Java.

70

pedidos mensuales. Con todo lo anterior, el coste mensual para el restaurante por laimplantación de PideMe es de 465,52 e(ver detalle tabla 6.5)

Tipo Gasto Precio/Unidad Cantidad Total

Cuota mensual mantenimiento 49,90 e 1 49,99 eCuota mensual Firebase 35,62 e($49) 1 35,62 e($49)Cuota transacciones PayPal (2,9 %) 7,6 e 50 380 e

465,52 e

Cuadro 6.5: Ejemplo de implantación

71

Capítulo 7

Conclusiones

E N este capítulo se realiza una valoración sobre los objetivos alcanzados en la realizacióndel presente Trabajo Fin de Grado. PideMe ha cumplido con los objetivos marcados

de manera previa a su desarrollo. Además, se realizan una serie de propuestas futuras paraampliar y mejorar las funcionalidades de PideMe. Por último, se incluye una conclusiónpersonal sobre el aporte que ha supuesto la realización de este trabajo.

7.1 Objetivos alcanzados.El objetivo principal de este trabajo consistía en mejorar la calidad en el servicio a los

clientes de restaurantes o locales de ocio. Después de la realización de un caso de estudio(ver sección 6.2.1), se puede apreciar como se ha conseguido mejorar la interacción entreclientes y restaurantes o locales de ocio, gestionando de forma directa la realización y el pagode sus pedidos dentro de ellos. Por tanto, se ha alcanzado el objetivo principal planteandopara el desarrollo de PideMe.

Además, se plantearon una serie de objetivos específicos (ver capítulo 2) que han sidoalcanzados tal y como se describe a continuación:

Incremento de la calidad del servicio de atención a clientes. El incremento de la ca-lidad del servicio es considerado el objetivo principal del presente trabajo. Para cum-plir con este objetivo, se proporciona al cliente de un restaurante o local de ocio unaaplicación móvil para su smartphone Android. Con esta aplicación, el cliente ve in-crementanda la calidad del servicio proporcionada y a su vez la eficiencia, ya que vereducido el tiempo de espera. Además, aumenta la facilidad para realizar el pago de supedido, ya sea de forma electrónica o tradicional. Por tanto, se ha logrado este objetivomejorando el trato de calidad recibido por los clientes de un restaurante o local de ocio,el tiempo de espera y la facilidad para realizar un pedido.

Facilidad de uso. El diseño final de la aplicación móvil proporciona una navegaciónsencilla. Apoyada en patrones de diseño nativos de Android para adaptarse a una in-teracción de usuario lo más nativa posible al sistema del que se esta haciendo uso,Android. Además, se trata de una aplicación fácil de manejar e intuitiva con una inter-faz amigable y clara. Para la consecución de este objetivo se ha hecho especial incapié

73

en la interacción con el usuario siguiendo patrones de diseño nativos.

Ahorro de costes y retorno de la inversión. La implantación de PideMe en un restau-rante o local de ocio, supone una inversión inicial (ver sección 6.3) que es fácilmenterecuperable por el aumento de la productividad. Con los mismos recursos humanos, elrestaurante o local de ocio es capaz de atender mayor cantidad de pedidos por lo queincrementa sus beneficios. Por parte de PideMe, la inclusión de un nuevo restauranteo local de ocio en la aplicación supone nuevos ingresos. Estos ingresos corresponde almantenimiento y mejora de la aplicación móvil asi como, la implantación y puesta enmarcha de PideMe en un nuevo restaurante o local de ocio. La consecución de este ob-jetivo corresponde con el aumento de ingresos tanto para el local en el que se implantacomo para PideMe.

Escalabilidad. La arquitectura final tiene un diseño que fomenta la escalabilidad. Paracumplir este objetivo, se diseño una arquitectura modular, adaptable y sobre todo efi-ciente. La inclusión de nuevos restaurantes o locales de ocio se realiza de forma rápidoy sencilla (ver sección 6.3.2) y no supone ningún tipo de cambios en la arquitectura. Elsistema es extensible, ya que la inclusión, modificación o eliminación de restauranteso locales de ocio de PideMe se realiza sin afectar al resto de la aplicación.

Modularidad. La arquitectura de PideMe está formada por diferentes módulos, cadauno de ellos independiente y con una funcionalidad bien definida. En PideMe existenuna serie de módulos bien diferenciados tal y como se estudió en el capítulo 5. De estaforma se obtiene un sistema con un acoplamiento bajo y una cohesión alta. Además,la consecución de este objetivo junto con el anterior, escalabilidad, proporciona unaarquitectura sencilla para la inclusión de nuevos módulos con nuevas funcionalidades.

Adaptabilidad. La arquitectura fue diseñada siguiendo el patrón de diseño MVP (versección 5.8.1). Además, ofrece la posibilidad de expandir la arquitectura de manerarelativamente sencilla. Por tanto la insercción de nuevas funcionalidades no supondríaun rediseño de la arquitectura de PideMe.

Robustez. La arquitectura desarrollada en PideMe es tolerante a fallos, capaz de re-cuperarse y seguir operando con normalidad. Esto es posible gracias a la gestión deerrores desarrollada en PideMe, que proporciona una aplicación estable y recupera-ble en caso de errores. Con este objetivo conseguido se logra una gran mejora en lainteracción con el usuario de la aplicación móvil.

En resumen, el objetivo principal de la creación de este Trabajo Fin de Grado, que eramejorar la calidad del servicio a los clientes de restaurantes o locales de ocio, ha sido cubier-to. Además, los objetivos específicos planteados también han sido conseguidos por lo que eltrabajo final cumple con los objetivos marcados antes de su desarrollo.

74

7.2 Propuestas y trabajo futuro.PideMe no pretende ser sólo un Trabajo Fin de Grado, sino una aplicación de referencia

en el ámbito de restaurantes y locales de ocio. Para ello, se debe trabajar duro para alcanzarnuevos objetivos que hagan de PideMe una aplicación cada vez mas completa y utilizada.

A continuación, se enumeran una serie de líneas de trabajo futuro para lograr una mejorasustancial de PideMe:

Disponibilidad multiplataforma. Actualmente, PideMe se encuentra disponible úni-camente para dispositivos móviles con plataforma Android. En una línea futura sepredente llegar a las plataformas mayoritarias. De este modo se plantea el desarrollopara plataforma iOS, la cual junto con Android están presente en la mayoría de dispo-sitivos móviles. También se plantea la disponibilidad en tablets de ambas plataformas.Para esto solo sería necesario el desarrollo de un nuevo diseño adaptado a estos dispo-sitivos, ya que se haría uso de la lógica utilizada en las aplicaciones de Smartphone. Deesta forma su implantación sería más rápida que la exportanción a nuevas plataformas.Por último se estudiaría la exportanción a la plataforma Windows Phone en función dela demanda que se produzca por parte de los usuarios y la cantidad de dispositivos conesta plataforma presentes en el mercado.

Monitorización de escritorio. Por parte de restaurantes y locales de ocio, los pedidosson visualizados a través de la web mediante el acceso a la base de datos remota deFirebase. Una de las mejoras del sistema es el desarrollo de la aplicación de escritoriopara recibir los pedidos en tiempo real y poder ser gestionados. La aplicación mostraríalos pedidos recibidos para ser gestionados. Además se debería poder realizar la inclu-sión, modificación o eliminación de nuevos productos por parte del local. Por tanto laaplicación de escritorio permitiría gestionar la base de datos remota del local así comorecibir los pedidos en tiempo real.

Identificación de locales. Una funcionalidad futura podría ser la incorporación denuevas formas de reconocimiento de locales que complemente la lectura de códigosQR. Una de estas formas podría ser el reconocimiento por posicionamiento GPS. Esdecir, la aplicación sería capaz de identificar el local en el que nos encontramos me-diante localización. Este método complementaría al de reconocimiento de locales pormedio de etiquetas QR.

Puesta en contacto con firmas comerciales. Para que el proyecto pueda evolucionarson necesarios diferentes recursos, tanto económicos como de infraestructura o mar-keting, entre otros. Por tanto, sería un aliciente más para la continuación del desarrollodel proyecto obtener financiación de organizaciones comerciales.

Nueva funcionalidad. Actualmente, la aplicación solo permite realizar el pago denuestros pedidos y que estos sean servidos dentro del restaurante o local de ocio. Al-

75

gunas de las funcionalidades que se podría incluir en la aplicación móvil es la opciónde permitir realizar el pago de pedidos de otras mesas o la realización de pedidos pa-ra ser recogidos en el restaurante o local. Estas nuevas funcionalidades ampliarían elrango de uso de la aplicación y facilitaría aún más la interacción del usuario con elrestaurante o local de ocio.

Nuevos ámbitos de implantación. El primer ámbito en el que se ha implantado el usode PideMe ha sido en restaurantes o locales de ocio. El sistema desarrollado podría serimplantado en otros ámbitos de forma rápida y sencilla simplemente modificando elmodelo de datos utilizado en todo el sistema.

76

7.3 Valoración personalLa realización del presente proyecto lo he considerado como un reto para adentrarme en

una de las materias con más futuro en la actualidad como son las plataformas móviles y eldesarrollo de sus apliaciones. La realización de un Trabajo Fin de Grado, es lo más similaral entorno laboral en lo que me he enfrentado a lo largo de la titulación universitaria. Conel trabajo diario, considero que he conseguido unos muy buenos resultados en el desarrollodel sistema y que no son más que el principio de un proyecto personal que llevar a cabo enel futuro y que no acaba con la realización de este Trabajo Fin de Grado. Me enorgullezcode todo lo conseguido con la realización del proyecto, con esfuerzo y tesón las cosas queparecen imposibles en principio no lo son tanto en realidad. Con este proyecto he aumentadomis conocimientos en Informática, una de las áreas más importantes de mi vida.

Desde el punto de vista tecnológico, he realizado un proyecto que me ha hecho disfrutarcon lo que hago, con lo que es esta profesión. El desarrollo de aplicaciones para dispositivosmóviles es un tema puntero en la actualidad y muy satisfactorio por saber que algo que hasdesarrollado puede llegar a cientos de personas y hacerles la vida un poco más fácil. La satis-facción de que tu trabajo sirve para mejorar profesionalmente y facilitar el día a día de otraspersonas que hacen uso de tus aplicaciones. Por tanto, este proyecto ha superado mis expec-tativas previas y me ha hecho progresar cuantiosamente como Ingeniero Informático.

En conclusión, la realización de este proyecto me ha servido para sentirme preparadopara afrontar el salto a un mundo laboral tan competitivo. Con este proyecto se culmina unaetapa más en mi vida, la etapa de aprendizaje y formación que tan importante es para elfuturo. Aprender y progresar han sido los retos principales durante mi andadura universitariay estoy convencido que seguirán siendo los objetivos principales en mi nueva andadura, laprofesional.

77

ANEXOS

79

Anexo A

Ejemplo de anexo

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Etiam lobortis facilisis sem. Nu-llam nec mi et neque pharetra sollicitudin. Praesent imperdiet mi nec ante. Donec ullamcor-per, felis non sodales commodo, lectus velit ultrices augue, a dignissim nibh lectus placeratpede. Vivamus nunc nunc, molestie ut, ultricies vel, semper in, velit. Ut porttitor. Praesentin sapien. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Duis fringilla tristiqueneque. Sed interdum libero ut metus. Pellentesque placerat. Nam rutrum augue a leo. Morbised elit sit amet ante lobortis sollicitudin. Praesent blandit blandit mauris. Praesent lectustellus, aliquet aliquam, luctus a, egestas a, turpis. Mauris lacinia lorem sit amet ipsum. Nuncquis urna dictum turpis accumsan semper.

81

Referencias

[Arb13] Lizzette Pérez Arbesú. Beneficios y retos de los servicios en la nube.2013. http://searchdatacenter.techtarget.com/es/noticias/2240180173/Beneficios-y-retos-de-los-servicios-de-nube.

[blo13a] Flurry blog. Mobile Use Grows 115 % in 2013. 2013.http://blog.flurry.com/bid/103601/Mobile-Use-Grows-115-in-2013-Propelled-by-Messaging-Apps.

[blo13b] Movistar blog. El uso de smartphones en España – 2013. 2013. http://www.go-movil.es/index.php/el-uso-de-smartphones-en-espana-2013/.

[CEO12] ShoutEm CEO. The History of Mobile App Stores. 2012.http://blog.shoutem.com/2012/02/07/infographic-the-history-of-mobile-app-stores/.

[Coq12] Diego Coquillat. Servicio al cliente excelente. 2012.http://www.diegocoquillat.com/el-66-de-los-clientes-esta-dispuesto-pagar-mas-por-servicio-al-cliente-excelente/.

[Dat13] The App Date. Informe de APPs Septiembre 2013. 2013.http://madrid.theappdate.com/informe-apps-2013/.

[dTdG12] Gradiant. Centro Tecnológico de Telecomunicaciones de Gali-cia. El éxito de las plataformas de aplicaciones móviles. 2012.http://www.gradiant.org/es/actualidad/noticias/606-el-exito-de-las-plataformas-de-aplicaciones-moviles.html.

[Ent] Entel. EDGE. http://www.entelpcs.cl/compania/edge.iws.

[fir] Firefox OS. http://www.mozilla.org/es-ES/firefox/os/. Acceso 08-Abril-2014.

[Gor14] Antonio Leiva Gordillo. Como monetizar. Guia para desarrollar una app perfectaen Android. 2014. www.limecreativelabs.com/como-monetizar-guia-desarrollar-app-android-perfecta/.

83

[Her13] Luis Hernández. Apps nativas vs Web Apps. 2013.http://sinlios.com/blog/2013/06/07/apps-nativas-vs-web-apps/.

[IDC13] IDC. Android Pushes Past 80 % Market Share While Windows PhoneShipments Leap 156.0 % Year Over Year in the Third Quarter. 2013.http://www.idc.com/getdoc.jsp?containerId=prUS24442013.

[Lar11] Apple. Paco Lara. Los pedidos anticipados del iPhone 4S lle-gan al millón de unidades en las primeras 24 horas. 2011.http://www.apple.com/es/pr/library/2011/10/10iPhone-4S-Pre-Orders-Top-One-Million-in-First-24-Hours.html.

[Net13] Busines News Network. BlackBerry’s global market share falls to just 1.7 %.2013. http://www.bnn.ca/News/2013/11/12/BlackBerrys-global-market-share-falls-to-just-17.aspx.

[Ric13] Felix Richter. Google Maps is the Most-Used Smartphone App in the World.2013. http://www.statista.com/chart/1345/top-10-smartphone-apps-in-q2-2013/.

[Soc13] Cubix Social. 2013 and the Mobile Market. 2013.http://www.socialcubix.com/blog/2013-and-the-mobile-market.

[Sof14] TIOBE Software. TIOBE Index for April 2014. 2014.http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html.

[Spa13] IAB Spain. V Estudio Anual IAB Spain Mobile Marketing. 2013.

[Sta13] Startapp. History of Android. 2013.http://www.startapp.com/infographics/history-of-android.aspx.

[tiz] Tizen. https://www.tizen.org/es. [Acceso 08-Abril-2014].

[UPS13] UPSABolivia. Aplicaciones móviles, la evolución. 2013.http://upsasoyyo.wordpress.com/2013/09/17/aplicaciones-moviles-la-evolucion/.

[Vli07] H. Vliet. Software Engineering: Principles and Practice. Wiley; 3 ed (May 30,2008), 2007.

[WeP13] WePlan. ¿Hasta qué punto las tecnologías ( y en especial el móvil ) han cambiadonuestras vidas? 2013. http://weplan-app.com/tecnologias-movil-cambio-vidas/.

84

Este documento fue editado y tipografiado con LATEXempleando la clase esi-tfg que se puede encontrar en:

https://bitbucket.org/arco group/esi-tfg

[Respeta esta atribución al autor]

85