scieee AI-readable full text Open interactive document viewer

Creación de empresas

Álvarez Cruz, Lorenzo; Jiménez Redondo, Raúl

Abstract

La aportación de la informática a la sociedad actual se ha consolidado y encontramos día a día nuevas aplicaciones que aportan valor a las empresas o que simplemente nos ayudan en un acto cotidiano como el de hacer la compra. En nuestro caso, hemos llevado a cabo la realización de un prototipo de aplicación móvil para iOS y Android consistente en la publicación y consulta de ofertas de ocio y hostelería en tiempo real basadas en geolocalización. En esta memoria se describe el trabajo realizado, el plan de negocio relativo al proyecto, las funcionalidades de la aplicación, las tecnologías empleadas, la arquitectura del sistema, el diseño del prototipo, su implementación, las conclusiones a las que se ha llegado y el trabajo futuro a realizar en el proyecto.

Full text

CREACIÓN DE EMPRESAS TRABAJO DE FIN DE GRADO GRADO EN INGENIERÍA INFORMÁTICA Autores: Lorenzo Álvarez Cruz Raúl Jiménez Redondo TUTORES: Juan Antonio Recio García David Pascual Ezama FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID 2016-2017 I A nuestras familiares, por habernos apoyado durante este largo recorrido II AUTORIZACIÓN Los abajo firmantes, alumnos y tutores del Trabajo Fin de Grado (TFG) en el Grado en Ingeniería Informática de la Facultad de Informática, autorizan a la Universidad Complutense de Madrid (UCM) a difundir y utilizar con fines académicos, no comerciales y mencionando expresamente a su autor el presente Trabajo Fin de Grado realizado durante el curso académico 20152016 bajo la dirección de Juan Antonio Recio García y David Pascual Ezama. Así mismo autorizan a la Universidad Complutense de Madrid a que sea depositado en acceso abierto en el repositorio institucional con el objeto de incrementar la difusión, uso e impacto del TFG en Internet y garantizar su preservación y acceso a largo plazo. ____________________ Lorenzo Álvarez Cruz ___________________ Raúl Jiménez Redondo ______________________ Juan Antonio Recio García ___________________ David Pascual Ezama II AGRADECIMIENTOS Queremos dar las gracias a nuestros familiares por todo el esfuerzo depositado en nuestros estudios y por el apoyo brindado durante estos años. También queremos agradecérselo a nuestros compañeros de la Facultad, con los cuales hemos aprendido a trabajar en equipo y colaborar. A los directores del proyecto, que han apostado por nosotros para la realización de un trabajo novedoso en la facultad y por su disposición y ayuda. A nuestros amigos, que han creído en nosotros en todo momento y nos han apoyado Y, por último, a nuestros compañeros de trabajo, los cuales nos han hecho crecer los dos últimos años personal y profesionalmente III RESUMEN RESUMEN La aportación de la informática a la sociedad actual se ha consolidado y encontramos día a día nuevas aplicaciones que aportan valor a las empresas o que simplemente nos ayudan en un acto cotidiano como el de hacer la compra. En nuestro caso, hemos llevado a cabo la realización de un prototipo de aplicación móvil para iOS y Android consistente en la publicación y consulta de ofertas de ocio y hostelería en tiempo real basadas en geolocalización. En esta memoria se describe el trabajo realizado, el plan de negocio relativo al proyecto, las funcionalidades de la aplicación, las tecnologías empleadas, la arquitectura del sistema, el diseño del prototipo, su implementación, las conclusiones a las que se ha llegado y el trabajo futuro a realizar en el proyecto. Palabras clave Ofertas, Hostelería, Aplicación móvil, Geolocalización, Tiempo real, API REST ABSTRACT Nowadays IT contributes in an outstanding way to the global and social development. The continuous emergence of apps has transformed the contemporaneous lifestyle, most times making things much easier by simplifying our daily habits, such as shopping. Our project presents an app prototype designed for iOS and Android that publish an accurate offer of leisure and hospitality sector activities. It is updated in real time and the offers published are based on geo-location. This memory describes the research done and it includes the business plan of the project, as well as the features of the app, the technologies used to develop it, its system architecture, a prototype design and also its implementation. This project includes an analysis of conclusions and a complete proposal of future improvements and further development. Key words Offers, Hospitality sector activities, Geo-location, Real time, API REST IV Tabla de contenido AUTORIZACIÓN............................................................................................. II AGRADECIMIENTOS ...................................................................................... II RESUMEN .................................................................................................... III RESUMEN .......................................................................................................... III ABSTRACT.......................................................................................................... III ÍNDICE DE FIGURAS ..................................................................................... VII CAPÍTULO 1. INTRODUCCIÓN ..................................................................... 1 1.1. Motivación ..............................................................................................1 1.2. Objetivos .................................................................................................2 1.3. Estructura de la memoria .........................................................................3 CHAPTER 1 INTRODUCTION .......................................................................... 4 1.1 Motivation ..............................................................................................4 1.2 Objectives ...............................................................................................5 1.3 Structure .................................................................................................5 CAPÍTULO 2. ESTADO DEL ARTE .................................................................. 6 CAPÍTULO 3. PLAN DE NEGOCIO ................................................................. 8 3.1. Proyecto y objetivos ................................................................................8 3.1.1. La idea ......................................................................................................... 8 3.1.2. ¿Por qué? .................................................................................................... 8 3.1.3. Promotores ................................................................................................. 9 3.1.4. Misión.......................................................................................................... 9 3.1.5. Objetivos ..................................................................................................... 9 3.2. Sector, servicios y mercado .................................................................... 10 3.2.1. Perspectivas del sector ............................................................................. 10 3.2.2. La oportunidad en el sector de los descuentos aplicables ....................... 10 3.2.3. Nuestra app: visión general ...................................................................... 11 3.2.4. Puntos fuertes y ventajas.......................................................................... 11 3.2.5. Usuarios .................................................................................................... 12 3.2.6. Público objetivo ........................................................................................ 12 3.2.7. Estudio de mercado: ampliación .............................................................. 12 3.3. Competitividad ...................................................................................... 13 3.3.1. La competencia ......................................................................................... 13 3.3.2. Principales competidores.......................................................................... 13 3.3.3. Análisis de la competencia ........................................................................ 13 3.4. Plan de Marketing ................................................................................. 15 3.4.1. Análisis DAFO ............................................................................................ 15 3.4.2. Análisis del cliente objetivo ...................................................................... 15 3.4.3. Estrategia de comunicación ...................................................................... 15 3.4.4. Estrategia de aceptación en el mercado................................................... 16 V 3.5. Plan de Ventas....................................................................................... 17 3.5.1. Estrategia de ventas .................................................................................. 17 3.5.2. Plan de ventas anual ................................................................................. 17 3.6. Organización y RRHH ............................................................................. 18 3.6.1. Dirección de la empresa ........................................................................... 18 3.6.2. Plan de RR.HH. .......................................................................................... 18 3.7. Establecimiento ..................................................................................... 19 3.7.1. Plan de establecimiento............................................................................ 19 3.8. Resultados previstos .............................................................................. 20 3.8.1. Análisis del punto de equilibrio ................................................................ 20 3.8.2. Resultado a cinco años.............................................................................. 20 3.8.2.1. Caso esperado ........................................................................................ 20 3.8.2.2. Caso conservador ................................................................................... 21 3.8.2.3. Caso optimista........................................................................................ 21 3.8.3. Resultado y beneficios netos .................................................................... 22 3.9. Plan de financiación ............................................................................... 23 3.9.1. Necesidades financieras y plan de financiación ....................................... 23 3.10. Conclusiones ......................................................................................... 24 3.10.1. Riesgo ...................................................................................................... 24 3.10.2. Puntos fuertes ......................................................................................... 24 3.10.3. Rentabilidad ............................................................................................ 25 3.10.4. Seguridad ................................................................................................ 25 CAPÍTULO 4. DESARROLLO DEL PROTOTIPO ...............................................26 4.1. FUNCIONALIDAD ................................................................................... 26 4.1.1. Funcionalidad de la aplicación .................................................................. 26 4.2. TECNOLOGÍAS EMPLEADAS .................................................................... 37 4.2.1. Aplicación móvil ........................................................................................ 37 4.2.2. Base de datos ............................................................................................ 41 4.2.3. Servidor ..................................................................................................... 41 4.3. ARQUITECTURA DE LA APLICACIÓN ........................................................ 44 4.3.1. Aplicación móvil ........................................................................................ 44 4.3.2. Base de datos ............................................................................................ 45 4.3.3. Servidor ..................................................................................................... 45 4.3.4. API REST .................................................................................................... 45 4.4. MODELO DE DATOS ............................................................................... 49 4.5. DISEÑO.................................................................................................. 52 4.6. IMPLEMENTACIÓN ................................................................................ 59 4.6.1. Aplicación móvil ........................................................................................ 59 CAPÍTULO 5. CONCLUSIONES .....................................................................65 CHAPTER 5. CONCLUSIONS......................................................................66 CAPÍTULO 6. TRABAJO FUTURO .................................................................67 CAPÍTULO 7. APORTACIONES AL PROYECTO ..............................................68 7.1. LORENZO ÁLVAREZ CRUZ ....................................................................... 68 VI 7.2. RAÚL JIMÉNEZ REDONDO ...................................................................... 69 REFERENCIAS ...............................................................................................70 VII ÍNDICE DE FIGURAS Figura 3-1 Análisis DAFO ................................................................................................. 15 Figura 3-2 Plan de ventas anual ...................................................................................... 17 Figura 3-3 Previsión RR.HH. ............................................................................................ 18 Figura 3-4 Resultados previstos: caso esperado ............................................................ 20 Figura 3-5 Resultados previstos: caso conservador ....................................................... 21 Figura 3-6 Resultados previstos: caso optimista ............................................................ 21 Figura 3-7 Previsión de resultados ................................................................................. 22 Figura 3-8 Previsión de beneficios netos ........................................................................ 22 Figura 4-1 Vista de establecimiento: ofertas propias..................................................... 27 Figura 4-3 Vista eliminar/volver a publicar oferta ......................................................... 28 Figura 4-2 Vista creación de oferta ................................................................................ 28 Figura 4-5 Creación de establecimiento ......................................................................... 29 Figura 4-4 Vista establecimiento: detalle de oferta ....................................................... 29 Figura 4-6 Vista público: ofertas ..................................................................................... 30 Figura 4-6 Inicio de sesión en aplicación público ........................................................... 30 Figura 4-9 Vista oferta en mapa ..................................................................................... 31 Figura 4-8 Vista general mapa ........................................................................................ 31 Figura 4-11 Error autenticación usuario ......................................................................... 32 Figura 4-10 Crear usuario público .................................................................................. 32 Figura 4-12 Menú lateral: simular ubicación .................................................................. 33 Figura 4-12 Vista detalle de oferta ................................................................................. 33 Figura 4-14 Diagrama casos de uso: establecimiento .................................................... 34 Figura 4-15 Diagrama casos de uso: usuario no registrado ........................................... 35 Figura 4-16 Diagrama casos de uso: usuario registrado ................................................ 36 Figura 4-17 Logo de Ionic Framework ............................................................................ 37 Figura 4-18 Aplicación nativa vs híbrida ......................................................................... 38 Figura 4-19 Comando ionic serve en consola ................................................................. 39 Figura 4-20 Logo de Google Maps .................................................................................. 40 Figura 4-21 Logo de MySQL ............................................................................................ 41 Figura 4-22 Logo de Dreamfactory ................................................................................. 42 Figura 4-23 Arquitectura de la aplicación....................................................................... 44 Figura 4-24 Ejemplo respuesta API REST establecimiento ............................................. 46 Figura 4-25 Ejemplo respuesta API REST oferta ............................................................. 47 Figura 4-26 Esquema de la base de datos ...................................................................... 49 Figura 4-27 Boceto oferta lista-cuadrícula ..................................................................... 52 Figura 4-28 Boceto vista del mapa ................................................................................. 53 Figura 4-29 Diferencias inicio de sesión ......................................................................... 54 Figura 4-30 Error inicio de sesión ................................................................................... 54 Figura 4-29 Diferencias creación de usuario .................................................................. 55 6 CAPÍTULO 2. ESTADO DEL ARTE Nos estamos encaminando hacia un mundo en el que la tecnología tiene cada vez mayor cabida en nuestro día a día. Podemos encontrar aplicaciones de todo tipo, pensadas para todas las edades y todos los entornos. Dichas aplicaciones tienen diferentes funcionalidades: podemos encontrar aplicaciones de redes sociales, de medios de transporte, de educación, juegos… A pesar del crecimiento exponencial que el mundo de las aplicaciones móviles está sufriendo, pensamos que todavía quedan muchas por salir a la luz. Encontramos infinidad de aplicaciones, en nuestro caso concreto, de ofertas de ocio, bien sea para disfrutarlas al momento o para poder disfrutarlas en un futuro. Podemos encontrar aplicaciones que nos ofrecen un descuento sobre el precio original o simplemente una oferta nueva que lance el establecimiento en cuestión. La finalidad es clara en cualquier caso: dar a conocer un nuevo establecimiento o llamar la atención de nuevos usuarios en aquellos que no estén teniendo el éxito esperado. Nos introducimos en este proyecto en el mercado de las apps móviles, el cual tiene una gran proyección de crecimiento en los próximos años, llegando a alcanzar la cifra de 46.000 millones de euros. En resumen, entramos en un mundo con una gran proyección, pero con gran número de aplicaciones existentes. En nuestro sector en concreto, el de las ofertas en ocio y hostelería, ya existen un gran número de ellas como El Tenedor, LetsBonus o Groupon. Actualmente, todas las aplicaciones del sector tienen el mismo funcionamiento (o muy similar) y se mueven en el mismo ámbito. En todas podremos obtener un ticket a canjear en el establecimiento de ocio seleccionado en unas fechas establecidas por mismo. Las diferencias existentes entre unas y otras residen en el tipo de oferta: porcentaje de descuento sobre un producto o servicio, nueva oferta a precio reducido, nuevo producto que se quiere dar a conocer…). Más allá del tipo de oferta, las diferencias existentes entre aplicaciones son prácticamente nulas. Nuestra aplicación quiere ir un paso más allá. No queremos quedarnos en el concepto de compra de un ticket, canjeo directo en el local y disfrute del mismo. En primer lugar, no será necesaria la descarga de ningún cupón ni la realización de ningún pago vía online. De esta forma, gente contraria a realizar compras vía online o que simplemente no tienen una tarjeta de crédito o débito podrán disfrutar de nuestras ofertas igualmente. Se trata de la primera diferencia que aporta nuestra aplicación respecto al resto: la no necesidad de descarga ni pago. En segundo lugar, hablamos de ofertas para disfrutar en el momento. En muchas plataformas nos piden una reserva anticipada o un periodo de espera para poder disfrutar de 7 nuestra compra. También podemos encontrarnos con un periodo muy reducido para disfrutar de nuestra oferta (una semana concreta, por ejemplo). En nuestro caso, el usuario podrá seleccionar la oferta y disfrutar de la misma en ese preciso momento, en tiempo real, durante el tiempo que el gestor del local estime oportuno para dicha oferta. Para terminar, los usuarios recibirán ofertas en tiempo real en función de la localización, para poder disfrutar de las mismas estableciendo uno mismo el radio de distancia en el que queremos recibir ofertas. De esta forma nos aseguraremos de obtener las ofertas más cercanas y poder acudir al establecimiento que las oferte en el menor tiempo posible. Estamos hablando por tanto de una aplicación cuyas principales diferencias respecto a otras aplicaciones de ofertas son, por un lado, la capacidad de disfrutar de un descuento en tiempo real, sin necesidad de realizar gestiones previas ni pagos y, por otro, obtener las mismas por geolocalización, garantizando de esta forma que podamos disfrutar de una oferta instantáneamente gracias a encontrarnos a poca distancia del establecimiento que haya ofertado el descuento. 8 CAPÍTULO 3. PLAN DE NEGOCIO 3.1. Proyecto y objetivos 3.1.1. La idea ¿Cuántas veces has dicho a tus amigos eso de “¿tomamos algo hoy?” y la respuesta ha sido “vale, ¿dónde?”. ¿Cuántas veces has quedado con tu pareja para cenar pero no sabéis dónde ir? ¿Te molesta ir al centro de tu ciudad y que te paren cada 20 metros para ofrecerte ir a un pub? Este proyecto nace con la idea de desarrollar una app que resuelve todos los problemas anteriormente mencionados. Queremos que pequeños y medianos empresarios de nuestro país puedan ofrecer a través de nuestra plataforma descuentos en tiempo real para el uso por parte de usuarios en el ámbito de la hostelería, como pueden ser bares, restaurantes, salas de concierto o pubs y discotecas. El concepto de la app es muy sencillo. El dueño o responsable del establecimiento añadirá una oferta en tiempo real a nuestra base de datos, de manera que al momento será mostrada a todos los usuarios que se encuentren en un entorno próximo y puedan acudir al establecimiento en un periodo corto de tiempo. Un usuario podrá acceder mediante filtros a los locales que en ese momento tienen activa alguna oferta, o ver en un mapa cuáles son los establecimientos próximos que disponen de oferta. Podrá seleccionar qué es lo que más le apetece en ese instante para encontrar la oferta que mejor se adapta a sus necesidades del momento. Además, la app dispondrá de un sistema de notificaciones de manera que no te pierdas las nuevas ofertas que se activen próximas a ti en tiempo real. ¡Date prisa porque las ofertas no estarán activas eternamente! 3.1.2. ¿Por qué? Hemos observado con el paso de los años que cada vez funciona mejor el apartado de las ofertas dentro de las apps mediante la compra y uso de cupones. Y es que todos salimos ganando. El dueño del local porque consigue clientes, los usuarios porque ahorran sin dejar de salir y hacer cosas que les gusta. Pero en este mundo de las ofertas, falta por entrar en el terreno de las ofertas en tiempo real. Muchas veces nos gustaría comprar uno de esos tickets y poder utilizarlos al momento, y eso no es siempre posible. Con nuestra app no tendremos que esperar ni reservar nada. Si vemos una oferta activa, vamos al local que la haya ofertado y ¡a disfrutar! Además, no será necesario hacer ningún pago vía app, ya que el objetivo es aprovecharnos de estas ofertas en el momento, y esto puede retrasar el proceso. 9 3.1.3. Promotores Este proyecto está compuesto por dos integrantes, Raúl Jiménez Redondo y Lorenzo Álvarez Cruz, futuros graduados en ingeniería informática en la Universidad Complutense de Madrid. Ambos nos encargamos del desarrollo y mantenimiento de la aplicación durante la puesta en marcha de la misma, así como del modelo de negocio y marketing. 3.1.4. Misión Nuestra misión es doble. Por un lado, ayudar al pequeño y mediano empresario que tiene un local atrayendo con ofertas en tiempo real a esas personas que, habiendo decidido salir y disfrutar de un rato de ocio, no saben dónde ir. Y segundo, por supuesto, ayudar a esas personas indecisas a elegir un local y ahorrar dinero al mismo tiempo. 3.1.5. Objetivos Nuestro principal objetivo es el de crecer lo más rápido posible dentro del territorio español. Queremos que una persona cuando salga mire la aplicación para ver qué ofertas se encuentra, aunque tenga claro dónde le gustaría ir. El objetivo, por tanto, es generar en las personas que se descarguen la app la necesidad de mirar las ofertas cada vez que decidan salir por cualquier rincón de la geografía española. Este proyecto está pensado para ser empezado en Madrid, uno de los sitios con mayor actividad en el ámbito que nos movemos. Pero queremos crecer y lo queremos hacer rápido, puesto que se trata de una app con fácil movilidad y que llegará rápidamente a los usuarios de smartphones en nuestro país. La estrategia de expansión y de captación de clientes la comentaremos en el plan de marketing. Para terminar, decir también que nuestro principal objetivo y el destinatario final de la app es el pequeño y mediano hostelero respecto a las grandes franquicias que pueden realizar ofertas por el gran público que tienen. De esta forma queremos convertir a estos locales en competencia mucho más dura respecto de las franquicias, grandes beneficiarias de las ofertas a día de hoy. 10 3.2. Sector, servicios y mercado 3.2.1. Perspectivas del sector Nos introducimos, en primer lugar, en el mercado de las apps móviles, el cual no está sintiendo la crisis y que tiene una gran proyección de crecimiento en los próximos años. Se espera que en los próximos cuatro años el mercado se dispare un 200% y alcance la cifra de 46.000 millones de euros. En ese aspecto, hablamos de un mercado con gran movimiento de dinero y que continúa en alza sin previsiones de descenso a largo plazo. En el caso concreto de nuestra app, que se va a mover en el entorno de las ofertas en hostelería y ocio nocturno, hablamos de un sector más perjudicado por la crisis económica. Según un estudio realizado por El economista, un total de 44.582 establecimientos cerraron sus puertas frente a 39.596 que las abrieron. Este mismo estudio también contempla un aumento de un 3,4% en las ventas por parte de grandes cadenas y franquicias entre 2008 y 2014. Esto supone que una parte del mercado ha sido absorbido por estas grandes empresas y franquicias, siendo el mayor perjudicado el pequeño y mediano empresario. Por este motivo, pensamos que nuestra app móvil tendrá una gran acogida por el público al que va dirigido, sin descartar la expansión en un futuro a medio plazo a este tipo de empresas. En definitiva, nos queremos abrir hueco en el mundo de la hostelería aprovechando un mercado dentro de las apps móviles por explotar. 3.2.2. La oportunidad en el sector de los descuentos aplicables Desde la aparición de las páginas web de ofertas en nuestro país en el año 2008, este sector no ha parado de crecer. De manera conjunta con estas páginas han ido apareciendo aplicaciones móviles que se han hecho hueco en el mercado de una manera más que notable. Estamos hablando de aplicaciones que se pueden encontrar entre las 50 más descargadas de nuestro país. La app de Groupon, por ejemplo, tiene un total de 40 millones de descargas. A pesar de hablar de un mercado con un gran número de descargas y de usuarios, hemos encontrado un apartado sin explotar, y queremos entrar de lleno en él. Hoy en día son muchas las personas que aprovechan estos descuentos para disfrutar de una cena o una actividad. Hemos visto una gran oportunidad porque, entre otros muchos datos, Groupon vendió un total de 400 millones de cupones el último año, lo cual refleja que es un mercado atractivo y en el cual se interesan los usuarios. 11 3.2.3. Nuestra app: visión general Vamos a desarrollar una app móvil fácil de usar y muy intuitiva. En primer lugar, será indispensable el registro para diferenciar los dos perfiles que habrá en nuestra app: empresario y usuario. En el caso de que el perfil creado sea el de empresario, el usuario tendrá acceso a un panel de control desde el que gestionar el establecimiento. Desde ahí se podrán añadir nuevas ofertas, eliminar ofertas vigentes que ya no queremos que aparezcan, añadir fotos del local… Este perfil será de pago y tendrá las siguientes características: Por otro lado, tendremos el perfil del usuario. Dicho perfil será gratuito, y tendremos distintas vías de acceso a las ofertas: • Por ubicación: sin duda alguna, el punto fuerte de la aplicación. Podremos ver en un mapa las ofertas en tiempo real que se encuentren próximas a nuestra posición. • Por notificación: utilizando la ubicación del usuario, existirá la posibilidad de recibir notificaciones con nuevas ofertas que hayan sido añadidas en locales cercanos a nuestra situación. Contemplamos también la posibilidad de que en la pantalla de inicio se muestren las ofertas en relación a la distancia con el usuario, mostrándose en primer lugar las ofertas más cercanas a nuestra ubicación y en último lugar las más lejanas. 3.2.4. Puntos fuertes y ventajas Las ventajas que consideramos en el desarrollo de esta aplicación son las siguientes: • Conocimiento del mercado de las app’s móviles • Conocimiento de la herramienta de desarrollo • Inmediata incorporación al mercado • Abanico de edades muy amplio • Entrada a un apartado del mercado de las ofertas de ocio y hostelería sin explotar (ofertas en tiempo real) Por otro lado, los puntos fuertes para los usuarios de nuestra aplicación son: • Aplicación muy intuitiva y de fácil manejo y gestión. No se requiere de conocimientos previos en gestión de app • Inversión de tiempo muy baja. Los empresarios no tardarán más de 3 minutos en añadir una nueva oferta, una nueva foto o eliminar una oferta vigente. • No hay necesidad de pago vía app. En un principio, no será necesario, por parte de los usuarios, la compra de un ticket vía app. 12 3.2.5. Usuarios Consideramos usuarios potenciales los pequeños y medianos empresarios que regentan este tipo de locales. En España, hay un bar por cada 132 habitantes. Concretamente en Madrid hay un total de 17.271 bares. Contamos con atraer el primer año de vida de la aplicación un total de 458 locales. Se explicará más adelante el procedimiento y la estrategia a seguir para atraer ese número de locales. 3.2.6. Público objetivo Nos centraremos en habitantes españoles con un smartphone con edades comprendidas entre los 18 y los 65 años. Estamos hablando de que en diciembre de 2014 un 53% de la población española tenía un smartphone en ese rango de edades (se calcula que a día de hoy esta cifra podría estar en el 72%). En definitiva, hablamos de aproximadamente 20 millones de usuarios potenciales a día de hoy. Al finalizar el desarrollo de la app e introducirla en el mercado, nos centraremos en un público más joven, comprendido entre los 18 y los 30 años, para que introduzcan la app en su entorno y podamos crecer de una manera más rápida. Es por ello que la idea inicial es hacer una fuerte inversión en publicidad en redes sociales tales como Facebook, Twitter o Instagram. Contemplamos también la posibilidad de contactar con personas influyentes en dichas redes sociales (con más de 1 millón de seguidores) para que la publicidad llegue al mayor número de personas en el menor tiempo posible. 3.2.7. Estudio de mercado: ampliación Queremos destacar también la importancia que está teniendo el mundo de las app’s móviles, cada día más presente en nuestro entorno. Se estima que 1 de cada 3 usuarios de app ha invertido dinero real en una compra virtual alguna vez en su vida. Entrando más a fondo en el mundo de las app’s móviles, según un estudio elaborado en base a los testimonios de 1500 desarrolladores de 83 países, se establece que la facturación media de una app está entre 1200 y 3900 euros mensuales, encontrándose un 65% de las app’s de Google Play en dicha franja. Hablamos por tanto de un mercado muy atractivo y que mueve una gran cantidad de dinero diariamente, y con grandes previsiones en lo que a crecimiento se refiere. Comentar también que la decisión de llevar a cabo esta aplicación basándonos en la geolocalización es debido a la aparición de aplicaciones basadas en este sistema y que están teniendo una gran acogida como Wallapop. 13 3.3. Competitividad 3.3.1. La competencia En lo que a competencia se refiere, nos introducimos en un mercado por explotar a pesar de la gran variedad de aplicaciones destinadas a ofrecer descuentos y a la existencia de aplicaciones de esta índole pero sin haber llegado a abarcar el mercado. Debemos considerar competencia cualquier aplicación de perfil medio y medio/alto dentro del market de Google que se dedique a la gestión de ofertas. Encontramos varias app y páginas web que llevan a cabo la gestión de ofertas, las cuales han sido analizadas y expuestas a continuación. 3.3.2. Principales competidores Los principales competidores que encontramos en el sector al que queremos pasar a formar parte son: • Competidores directos o MyDrink o Restaurantes.com o Atrapalo • Competidores secundarios o El tenedor o Groupon, Groupalia, Letsbonus, Offerum 3.3.3. Análisis de la competencia Haciendo un análisis de los principales competidores que mencionamos anteriormente, consideramos importante separar de nuevo los competidores directos de los competidores secundarios. Hablando de nuestros competidores directos, El tenedor, Restaurantes.com y MyDrink, queremos diferenciar los dos primeros del tercer, ya que la app MyDrink no ha tenido una cabida especial en el mercado, ya que cuenta con menos de 100 descargas en el market de Google. La idea de la aplicación se asemeja bastante a la nuestra, si bien es sólo de bebidas. Pensamos que no ha tenido aceptación debido a que no se le ha dado publicidad y debido a su poco atractivo, ya que no contiene apenas fotos y la base de datos está vacía. El tenedor y Restaurantes.com, por el contrario, son aplicaciones que han tenido una buena aceptación en el mercado y son usadas a diario por un gran número de usuarios. 14 Consideramos oportuno hacer una diferenciación entre estas dos aplicaciones y la nuestra, ya que el mayor flujo de usuarios de ambas proviene de su página web y no de la aplicación móvil como sería nuestro caso. En el caso de El Tenedor, por ejemplo, hablamos de 6 millones de visitas mensuales a la página web frente a un número total de 3 millones y medio de descargas de la aplicación móvil. Respecto a los competidores secundarios, pensamos que nuestra aplicación podría ser un gran complemento, pero en ningún caso competencia directa. El mundo de las ofertas crece a gran velocidad, y un claro ejemplo es que la aplicación de letsbonus cuenta con 1.100.000 descargas. Otro dato interesante que nos ha llevado a apostar por esta idea es el número de cupones vendidos en este tipo de aplicaciones. La empresa Groupon alcanzó el pasado marzo los 1000 millones de cupones vendidos. Por tanto, como conclusión, hablamos de un mercado por explotar, ya que aplicaciones que trabajen con ofertas en tiempo real basadas en geolocalizacion no existen como tal. Grandes empresas como las citadas anteriormente podrían plantearse incorporar este nicho de mercado, por lo que conviene crecer de una manera rápida. 15 3.4. Plan de Marketing 3.4.1. Análisis DAFO Aspectos favorables Aspectos desfavorables Análisis interno Fortalezas • Sencillez en la puesta en marcha • Bajo riesgo - alta recompensa Debilidades • Bajo conocimiento en diseño gráfico • Vida media de una app entre 3-5 años Análisis externo Oportunidades • Entrada a un sector del mercado sin explotar Amenazas • Experiencia de los competidores Figura 3-1 Análisis DAFO 3.4.2. Análisis del cliente objetivo En el desarrollo de la aplicación y nuestra salida al mercado optaremos por crear un producto cuyo cliente objetivo sea el de características más genéricas. Con esta idea se obtiene un cliente objetivo en propiedad de un smartphone con predisposición a descargar nuevas aplicaciones. Hablamos por tanto de un abanico muy amplio, ya que la media de edades de usuarios de smartphones en España va de los 13 años a los 70, aunque para el lanzamiento nos centraremos en un abanico de edades más concretas. 3.4.3. Estrategia de comunicación El sistema de difusión que usaremos para la aplicación será por medio de las redes sociales, usando anuncios destinados a usuarios de edades comprendidas entre los 16 y los 30 años. Planteamos diferentes tipos de difusión, siendo el primero de ellos el de utilizar “influencers”, usuarios de estas redes sociales con un alto número de seguidores. Haciendo un estudio de los precios de este tipo de difusión, las cifras medias oscilan de los 450 euros a los 4.500, cuando la cuenta tiene cientos de miles de seguidores. Una cuenta con 6 millones de fans puede recibir, fácilmente, entre 18.000 y 90.000 euros cada vez que comparte una imagen según la misma publicación según dicha publicación. Otra opción que contemplamos es la de incrustar publicidad en las redes sociales de forma directa, sin pasar por estos usuarios. Queremos publicitarnos en Facebook e Instagram en un primer momento, ya que abarcan los usuarios de edades comprendidas entre los 16 y los 22 3.8.3. Resultado y beneficios netos Figura 3-7 Previsión de resultados Figura 3-8 Previsión de beneficios netos 23 3.9. Plan de financiación 3.9.1. Necesidades financieras y plan de financiación Este proyecto requiere de una financiación para poder llevar a cabo el plan de marketing establecido y poder realizar los pagos en publicidad correspondientes. El resto de los gastos que tiene la empresa se compensan con los ingresos generados. Hablamos por tanto de un total de 100.000€ de inversión inicial para poder arrancar el proyecto y tener cubiertos los cuatro primeros años en lo que a publicidad se refiere. Para ello contemplamos la posibilidad de solicitar financiación a aceleradoras de este tipo de aplicaciones. Hemos previsto cubrir todas las necesidades mediante capital aportado por financiación externa. Mediante la financiación externa vamos a cubrir los gastos en publicidad del proyecto y los salarios de los dos primeros años. 24 3.10. Conclusiones 3.10.1. Riesgo Nos encontramos ante un proyecto con un nivel de riesgo elevado debido a lo novedoso del mismo y a la necesidad de financiación al comienzo del proyecto, a pesar de encontrar a nuestro favor los siguientes factores: • Competencia directa baja puesto que no encontramos ninguna app que gestione ofertas en hostelería en tiempo real. • A pesar de la necesidad de financiación, consideramos esta baja en comparación con los beneficios que la app podría generar. A pesar de contar con los anteriores puntos a nuestro favor, no debemos olvidar que hay un 35% de apps que tienen unos ingresos mensuales por debajo de los 1.400€ y aproximadamente el 40% muere en los dos primeros años. Es por ello que el factor riesgo es elevado, puesto que nuestra app podría tener un número de clientes menor que lo estimado según la aceptación entre los usuarios de la misma. 3.10.2. Puntos fuertes Con el desarrollo de nuestra aplicación consideramos que tenemos los siguientes puntos fuertes a favor: • Poca competencia directa al tratarse de una aplicación novedosa en el ámbito de la hostelería y el ocio nocturno • Capacidad de desarrollar una aplicación con usable e intuitiva • Abarcamos un sector con un público objetivo muy amplio • Necesidad de mantenimiento muy baja • Al tratarse de una app, podemos retirarla del mercado en el momento que consideremos necesario si observamos una tendencia negativa, minimizando de esta forma las pérdidas En resumen, contamos con una serie de puntos a nuestro favor que hacen de nuestra aplicación una buena apuesta de futuro a pesar del riesgo existente. 25 3.10.3. Rentabilidad La viabilidad en el aspecto económico se define como “beneficio comparado con el total de recursos empleados para obtener dicho beneficio”. Así puede afirmarse que la rentabilidad es alta. Analizando desde el caso menos favorable hasta el más favorable, se puede observar que el riesgo es moderado pero los beneficios son considerablemente altos, recuperando la inversión inicial y con perspectivas de crecimiento continuo. De este modo y con el análisis económico se confirma la empresa como viable a medio plazo. 3.10.4. Seguridad Nos encontramos ante un proyecto que consta de una serie de factores que garantizan la seguridad del inversor: • Partimos de una inversión inicial moderada teniendo en cuenta el sector del que hablamos • Conocemos el mercado de las aplicaciones móviles y podemos explotar la app generando el mayor beneficio posible. • Gastos ampliables y reducibles al mismo tiempo, puesto que gran parte de nuestros gastos están destinados a publicidad, pudiendo ampliar contratos publicitarios con otras empresas en caso de encontrarnos con un mayor número de clientes y de público en general y finalizar contratos al mismo tiempo en caso contrario. • Hemos trabajado con números de manera prudente en los casos económicofinancieros. Por tanto, consideramos nuestra aplicación una apuesta de futuro y con gran probabilidad de éxito. 26 CAPÍTULO 4. DESARROLLO DEL PROTOTIPO 4.1. FUNCIONALIDAD El desarrollo de este proyecto se ha llevado a cabo mediante la creación de dos aplicaciones móviles. Esto es así ya que cada uno de ellas está destinada a un usuario diferente. La aplicación establecimiento está creada para que sea usada por los dueños de los establecimientos o algún trabajador de estos de modo que desde esta aplicación es donde se crean y administran las ofertas. En cambio, la aplicación público está pensada para que sea el público en general el que la use ya que esta aplicación se usa para consultar las ofertas que han publicado los establecimientos. Además, con el fin de fidelizar a los usuarios que consultan las ofertas, se dan ciertas ventajas a los usuarios que se registren en la aplicación, aunque la aplicación también puede ser usada sin un registro previo. De este modo, se distinguen claramente tres actores como usuarios del servicio: • Establecimiento: es el creador de contenido. Este rol permite crear, modificar y eliminar ofertas. Sin la participación activa del establecimiento el proyecto deja de funcionar ya que al no haber ofertas los otros tipos de usuarios no encuentran ningún aliciente para usar la aplicación • Usuario no registrado: cualquiera puede usar la aplicación. Para evitar que los usuarios no se acerquen a la aplicación por no registrarse y no dar sus datos personales, se permite el uso de la aplicación sin estar registrado en ella. Este uso es limitado ya que algunas de las funcionalidades no se le ofrecen a este tipo de usuario • Usuario registrado: este tipo de usuario puede realizar las mismas funciones que el usuario no registrado pero además se le ofrecen una serie de privilegios para que la experiencia usando la aplicación sea mejor y quiera volver para seguir utilizándola 4.1.1. Funcionalidad de la aplicación Toda la usabilidad de cara a los usuarios recae sobre las aplicaciones desarrolladas, por tanto, todas las funcionalidades que ahora se describen se dan en alguna de las aplicaciones creadas. A continuación se muestran las funcionalidades para el establecimiento: 27 Funcionalidad 1: Consultar todas las ofertas propias El establecimiento puede consultar, mediante una lista, todas las ofertas publicadas. Esta lista se encuentra ordenada por orden de creación de la oferta. En ella se incluyen tanto las ofertas que ya han caducado como las ofertas que están disponibles actualmente. Esta característica se indica al usuario. Funcionalidad 2: Crear una oferta El usuario del establecimiento crea una nueva oferta y se publica de inmediato. La información necesaria para la publicación de la oferta es la siguiente: • Título: un eslogan llamativo sobre la oferta • Descripción: una descripción escueta indicando en qué consiste la oferta y las condiciones de la misma • Duración: el tiempo que va a permanecer activa la oferta • Tipo: el establecimiento debe elegir la categoría a la que pertenece su oferta. Esta elección se lleva a cabo entre: o Café o Comida o Cerveza o Vino Funcionalidad 3: Volver a publicar una oferta ya publicada Con el fin de agilizar y simplificar el proceso de la publicación de las ofertas existe la posibilidad de volver a publicar una oferta ya publicada con anterioridad. La oferta se publica manteniendo todos los campos tal y como se publicaron la primera vez. Funcionalidad 4: Eliminar una oferta El establecimiento tiene la posibilidad de eliminar una oferta, tanto ya caducada como en vigor. La eliminación de una oferta no disminuye el número de ofertas publicadas dentro del límite de la suscripción. Figura 4-1 Vista de establecimiento: ofertas propias 28 Funcionalidad 5: Consultar ofertas de establecimientos cercanos Se muestran las ofertas publicadas por los establecimientos. Solo se muestran las ofertas vigentes. No se le ofrece la posibilidad al establecimiento de consultar el histórico de ofertas publicadas por otros establecimientos. Funcionalidad 6: Consultar el mapa de los establecimientos con ofertas en vigor Se muestra un mapa, centrado en la ubicación del establecimiento registrado, con todos los establecimientos que tienen ofertas en vigor. Al seleccionar un establecimiento se muestra la información de la oferta. Funcionalidad 7: Consultar las condiciones de una oferta Se muestra de forma detallada toda la información de la oferta incluyendo la dirección y el número de teléfono del establecimiento. Figura 4-3 Vista creación de oferta Figura 4-2 Vista eliminar/volver a publicar oferta 29 Funcionalidad 8: Registrarse como establecimiento El registro en la aplicación es libre. Para poder registrarse como establecimiento es necesaria la información siguiente: • Nombre del establecimiento • Email • Contraseña • Descripción del establecimiento • Número de teléfono • Dirección del establecimiento incluyendo la calle, el número y la ciudad Funcionalidad 9: Iniciar sesión en la aplicación Para acceder a la aplicación es necesario iniciar sesión indicando el email asociado al establecimiento y la contraseña. Las funciones que se pueden realizar desde la aplicación de público son las siguientes: Figura 4-5 Vista establecimiento: detalle de oferta Figura 4-5 Creación de establecimiento 30 Funcionalidad 10: Acceder sin iniciar sesión En la aplicación que usa el público es posible acceder sin un registro previo. Este acceso sin registro hace que disponga de menos funcionalidades. Funcionalidad 11: Consultar las ofertas de establecimientos cercanos Se muestran las ofertas vigentes publicadas por los establecimientos. Funcionalidad 12: Consultar el mapa de los establecimientos con ofertas en vigor Se muestra un mapa, centrado en la ubicación del usuario, con todos los establecimientos que tienen ofertas en vigor. Al seleccionar un establecimiento se muestra la información de la oferta. Funcionalidad 13: Consultar las condiciones de una oferta Se muestra de forma detallada toda la información de la oferta incluyendo la dirección y el número de teléfono del establecimiento. Figura 4-7 Inicio de sesión en aplicación público Figura 4-7 Vista público: ofertas 31 Funcionalidad 14: Registrar un nuevo usuario En caso de que el usuario no registrado quiera pasar a usar la aplicación como usuario registrado lo puede registrando un nuevo usuario. Para el registro es necesaria la siguiente información: • Nombre • Email • Contraseña Por último, si el usuario está registrado e identificado, además de las funciones que dispone cualquier usuario, tiene las siguientes funcionalidades extra: Funcionalidad 15: Marcar un establecimiento como favorito El usuario registrado puede marcar un establecimiento como favorito para consultar posteriormente sus establecimientos favoritos directamente sin necesidad de consultar el resto. Figura 4-9 Vista general mapa Figura 4-9 Vista oferta en mapa 38 Figura 4-18 Aplicación nativa vs híbrida Ionic framework fue creado en 2013 por la compañía Drifty. Esta compañía ya había desarrollado con anterioridad los productos Codiqa y Jetstrap, dos herramientas para la creación de interfaces. Escuchando las necesidades de sus clientes decidieron crear su propia herramienta para el desarrollo de aplicaciones móviles basados en estándares web. De este modo lanzaron en noviembre de 2013 una versión alfa del producto. En mayo de 2015 vio la luz el producto definitivo. Durante 2016 se ha lanzado la versión 2.0 de este framework. Para empezar a utilizar ionic hay que seguir unos pasos muy sencillos: lo primero es tener instalado Node.js [6] para gestionar los paquetes npm. A continuación, mediante esta herramienta se puede instalar ionic a través de una consola con el siguiente comando: npm install -g cordova ionic En el nuestro hemos usado la versión 1.0 del producto ya que cuando comenzamos el desarrollo de nuestra aplicación, la versión 2.0 todavía estaba en fase de pruebas. Ionic framework tiene diferentes plantillas con las que comenzar un proyecto, aunque también se pueden empezar proyectos vacíos: ionic start myApp blank ionic start myApp tabs ionic start myApp sidemenu Mediante estos tres comandos se creará el proyecto myApp en blanco, con pestañas, o con un menú lateral respectivamente. Para poder probar la aplicación es necesario añadir la plataforma del sistema operativo para el que se quiere crear la aplicación. En nuestro caso, al ser dos sistemas operativos diferentes, se añaden las dos plataformas: 39 ionic platform add ios ionic platform add android Por último, es necesario construir el archivo de instalación y lanzarlo en un emulador dentro del mismo ordenador o bien directamente en un dispositivo: ionic build ios ionic emulate ios ionic emulate ios Además, como se puede comprobar en la siguiente imagen, para que la etapa de desarrollo sea más sencilla, también se puede lanzar la aplicación en un servidor interno y comprobar el desarrollo en tiempo real en un navegador web. Figura 4-19 Comando ionic serve en consola Para transformar el código html y javascript en la aplicación móvil, ionic framework utiliza Apache Cordova [7]. La relación entre el hardware del dispositivo y la aplicación es posible gracias a Cordova. En ionic, al usar AngularJs como framework de JavaScript, esta relación se lleva a cabo mediante el paquete ngCordova [8]. ngCordova permite el uso de más de 70 plugins que interactúan entre la aplicación y el hardware del dispositivo. Entre estos plugins se pueden encontrar todo tipo de servicios que facilitan enormemente la implementación de la aplicación entre los que podemos destacar el que permite el acceso a la cámara, uno que realiza la autenticación mediante el sensor de huellas dactilares de los dispositivos o todos lo que permiten ver el estado de los distintos sensores del dispositivo. 40 En nuestra aplicación hemos hecho uso de cordovaGeolocation, un plugin que facilita el acceso a la ubicación del dispositivo permitiendo acceder a esta mediante el uso del GPS o limitando el uso de la ubicación únicamente a la generada por las redes móviles. También hemos usado el plugin angular-moment de angularjs, el cual permite calcular con poco código la diferencia entre dos fechas y expresar esta diferencia en lenguaje natural Figura 4-20 Logo de Google Maps Para la representación de los datos en mapas se ha empleado la API de Google Maps [9] en su versión web. No se ha empleado la versión nativa para Android o iOS y el uso de su SDK ya que al ser una aplicación móvil híbrida y no una aplicación nativa no era posible su uso. Además de este servicio de mapas también se contemplaron otros. El principal rival que contemplamos frente a Google Maps fue Here [10]. Este servicio, en propiedad actualmente de Audi, BMW y Daimler, fue originalmente desarrollado por Nokia. Ofrece prácticamente los mismos servicios que Google Maps y con el uso que se les dan a los mapas en nuestra aplicación hubiera servido cualquiera de los dos servicios, pero al ser Google Maps mucho más popular, la comunidad de desarrollo que usa este servicio frente a Here es mucho mayor por lo que hay más información en la red. Para transformar las direcciones que introducen los establecimientos en coordenadas geográficas se utiliza el servicio de Google Maps Geolocation API, el cual recibe mediante una petición http, una dirección de una calle con la ciudad y devuelve las coordenadas geográficas correspondientes a esa ubicación. En la etapa de aprendizaje de Ionic Framework se realizó el curso Ionic by Example [11] impartido por Mirko Nasato en la plataforma online Udemy. Las herramientas utilizadas para el desarrollo han sido las siguientes: • iTerm2 [12] : consola más completa que la consola utilizada por defecto • Sublime Text [13] :completo editor de texto para el desarrollo del código html y javascript necesario para la aplicación 41 • Xcode 8 [14]: la herramienta de desarrollo de Apple es necesaria para poder compilar el proyecto y desplegar la aplicación en un dispositivo móvil con iOS • OmniGraffle 6 [15]: esta herramienta de diseño ha sido la utilizada en la creación de los gráficos que se muestran en esta memoria 4.2.2. Base de datos Para el uso y almacenamiento de los datos se ha empleado una base de datos MySQL [16]. La principal razón para elegir este tipo de base de datos ha sido el hecho de ser de código abierto. Al ser código abierto permite que Dreamfactory [17], la API REST empleada en este proyecto, lo incluya de manera gratuita y fiable dentro de su amplia gama de bases de datos soportadas. Figura 4-21 Logo de MySQL Antes de decantarnos por MySQL se contempló también el uso de bases de datos no relacionales, pero dato el carácter marcadamente estructurado de nuestros datos se consideró que era mejor usar una base de datos relacional. Además, como última razón para tomar esta decisión se consideró que la existencia de experiencia previa con este tipo de bases de datos agilizaba su uso. 4.2.3. Servidor Para el desarrollo del servidor y el acceso a los datos almacenados en la base de datos se ha creado una API REST desde la que la aplicación solicita los datos necesarios en cada momento y este se los entrega. En la creación de esta API REST hemos usado Dreamfactory [17]. Esta herramienta, de código abierto, permite crear para cualquier base de datos una API REST a la que acceder mediante peticiones http para gestionar los recursos de la base de datos. 42 Figura 4-22 Logo de Dreamfactory Dreamfactory es una plataforma gratuita, aunque también dispone de dos planes de pago en los que las principales ventajas son la asistencia técnica y la inclusión y soporte de bases de datos extra. Soporta tanto bases de datos relacionales como no relacionales. Entre las relacionales destacan: • PostgreSQL • MySQL • SQLite Además, en las versiones de pago se incluye soporte para SQL Server y para Oracle. Entre las bases de datos no relacionales se encuentra: • MongoDB • CouchDB • Cassandra También soporta bases de datos propias de proveedores de servicios cloud: • AWS DynamoDB • Azure Tables Por último, Dreamfactory también es capaz de crear una API REST en servicios de almacenamiento de ficheros como: • AWS S3 • Azure BLOB • Ficheros locales La gestión del acceso a los recursos de la API REST se puede hacer que sea de forma totalmente pública, mediante la autenticación con el sistema OAuth, o como se ha hecho en nuestra aplicación, mediante el registro en la aplicación y el acceso a ella con un usuario y contraseña con la adquisición de un Token con una validez durante un tiempo determinado. Para este tipo de autenticación es posible crear roles dentro de una misma API otorgando a cada uno acceso y modificación o no a los distintos recursos existentes en la base de datos. Se genera documentación automáticamente de la API REST a través de Swagger 2.0 [18], el proyecto open-source más popular para la generación de documentación para API Se puede hacer uso de esta herramienta de formas distintas: en un servidor privado, descargando la imagen del servidor, válida para Windows, Linux y MacOS; o creando la imagen del servidor en cualquier proveedor de servicios cloud en los que ya existe la imagen AMI para instalar, entre los que se encuentras los principales proveedores cloud como Amazon Web 43 Services, Google Cloud o Microsoft Azure. Este tipo de despliegue no incurre en ningún gasto extra, únicamente el que se genera por la máquina del servidor cloud. En nuestro caso nos hemos decantado por esta última opción desplegando dreamfactory en un servidor de Microsoft Azure mediante una instancia de tipo A0. 44 4.3. ARQUITECTURA DE LA APLICACIÓN Figura 4-23 Arquitectura de la aplicación La aplicación está estructurada en tres servicios diferenciados: aplicación móvil, servidor y base de datos. Desde la aplicación se generan las ofertas que se envían al servidor mediante una petición http de la API REST. Además, desde las aplicaciones también se hacen las consultas, mediante el mismo sistema, para obtener la información de los establecimientos y las ofertas. El servidor de Dreamfactory transforma mediante la API REST las consultas http en consultas adaptadas a MySQL 4.3.1. Aplicación móvil Las dos aplicaciones móviles que incluye este proyecto están desarrolladas tanto para Android como para iOS. La aplicación iOS está desarrollada bajo la versión 10 del sistema operativo de Apple. Esto supone que la aplicación es apta para, al menos, el 76% [19] de los dispositivos con este sistema operativo. La versión Android mínima que soporta la aplicación creada es Android 4.1, por lo que se da cobertura al 97% [20] de estos teléfonos. Observando el último informe Gartner [21] publicado en el 17 de noviembre de 2016 y que hace referencia al tercer trimestre de 2016, se aprecia que el uso de iOS y Android es de un 11,5% y 87,8% respectivamente, lo que indica que un total de 94,1% de los smartphones en la actualidad pueden usar alguna de las dos aplicaciones desarrolladas para el proyecto, teniendo en cuenta la versión de cada sistema operativo. 45 4.3.2. Base de datos La base de datos del proyecto es una base de datos de plataforma como servicio (PaaS) puesto que está alojada en un servidor remoto de Microsoft Azure [22] hospedado en la región Este de Estados Unidos. Se decidió hacer uso de este proveedor de servicios cloud en lugar de otros como Amazon Web Services o Google Cloud Platform debido a que el proveedor elegido para alojar la API REST fue Azure y se consideró que la agrupación de todos los servicios en un mismo proveedor haría más fácil su manejo y mantenimiento. 4.3.3. Servidor El acceso a la base de datos se realiza mediante una API REST configurada mediante Dreamfactory. Este servicio está alojado en un servidor de Microsoft Azure en la región Estados Unidos Este. El tipo de instancia contratada es una A0. Esta instancia tiene las siguientes características: • Núcleos: 1 • RAM: 0,75GB • Tamaño de disco: 20GB Para el uso en los primeros meses de vida de la aplicación, las características de este servidor son suficientes, aunque no se descarta que sea necesario incrementar la potencia del mismo. En tal caso se podría realizar gracias a la escalabilidad del servicio. 4.3.4. API REST La API REST creada para la aplicación permite acceder de forma sencilla a los recursos de la base de datos. Además hace posible que si en un futuro se crea una versión web la aplicación, esta API REST sea reutilizable y se pueda acceder a ella del mismo modo. El modo de uso es sencillo: simplemente hay que hacer una petición HTTP indicando el recurso al que se desea acceder. Estas peticiones permiten además incluir parámetros para hacer una petición más certera. Las peticiones posibles son las siguientes: • Establecimiento: o GET /api/v2/dbeb/_table/establecimiento ▪ Se obtiene una lista con todos los establecimientos o GET /api/v2/dbeb/_table/{id_establecimiento } ▪ Se obtiene la información del establecimiento con id id_establecimiento o POST /api/v2/dbeb/_table/establecimiento 46 ▪ Se crea un establecimiento. Los campos necesarios se incluyen dentro de body Figura 4-24 Ejemplo respuesta API REST establecimiento • Oferta: o GET /api/v2/dbeb/_table/oferta ▪ Se obtiene una lista con todas las ofertas o GET /api/v2/dbeb/_table/oferta/{id_oferta} ▪ Se obtiene la información de la oferta con id id_oferta o POST /api/v2/dbeb/_table/oferta ▪ Se crea una oferta. Los campos necesarios se incluyen dentro de body o DELETE /api/v2/dbeb/_table/oferta/{id_oferta} ▪ Se eliminar la oferta con id id_oferta 47 Figura 4-25 Ejemplo respuesta API REST oferta Otros endPoints de la API • GET /api/v2/dbeb/_table/cuenta o Usado para consultar todos los tipos de cuenta (suscripción que existen) • GET /api/v2/dbeb/_table/cuenta/{id_cuenta} o Usado para consultar la información del tipo de cuenta con id id_cuenta • GET /api/v2/dbeb/_table/ cuentaasociada o Usado para consultar todas las suscripciones que tienen los establecimientos • GET /api/v2/dbeb/_table/ cuentaasociada /{id_cuentaasociada } o Usado para consultar la información de la suscripción con id id_cuentaasociada • POST /api/v2/dbeb/_table/ cuentaasociada o Usado para crear una suscripción. Los campos necesarios se incluyen dentro de body • GET /api/v2/dbeb/_table/ usuario o Usado para consultar todos usuarios • GET /api/v2/dbeb/_table/ usuario /{id_ usuario } o Usado para consultar la información del usuario con id id_ usuario • POST /api/v2/dbeb/_table/ usuario o Usado para crear un usuario. Los campos necesarios se incluyen dentro de body • GET /api/v2/dbeb/_table/favorito o Usado para consultar todos los favoritos que hay almacenados • GET /api/v2/dbeb/_table/ favorito /{id_ favorito } o Usado para consultar la información del favorito con id id_ favorito • POST /api/v2/dbeb/_table/favorito 54 A continuación se muestran imágenes de la aplicación con las distinciones que existen entre ellas: El inicio de sesión en ambas aplicaciones requiere únicamente del email y la contraseña para acceder a la aplicación y desde esta vista, en ambas aplicaciones se puede acceder a la creación del usuario: establecimiento público. En la aplicación público además se puede pulsar el botón entrar sin registrarse para acceder a la aplicación. En ambas aplicaciones se mostrará un error si no se puede iniciar sesión. No se indica si el error reside en la contraseña o en que no se encuentra el usuario como medida de seguridad Figura 4-29 Diferencias inicio de sesión Figura 4-30 Error inicio de sesión 55 La creación de los usuarios (establecimiento o público) también difiere de una aplicación a otra, aunque las dos conservan el mismo patrón de diseño. La vista principal de la aplicación establecimiento se centra en las ofertas propias. Esta visualización se compone de una imagen indicando el tipo de oferta en la que se engloba, el título de la oferta que se ha publicado, un breve texto explicando en qué consiste la oferta y por último la caducidad de la oferta. Todas las ofertas se muestran en forma de lista y se deslizará hacia abajo en caso de que todas las ofertas no quepan en la pantalla. El acceso a las otras vistas principales de la aplicación se realiza mediante pestañas: home, ofertas otros bares y mapa. En la esquina superior derecha se encuentra el botón para acceder a crear una oferta y en la esquina superior izquierda se muestra el botón que despliega en el menú auxiliar donde se cerrará la sesión. Desde esta vista, es posible deslizar hacia la izquierda una oferta para mostrar el menú que ofrece la posibilidad de borrar la oferta deslizada o volverla a publicar Figura 4-31 Diferencias creación de usuario Figura 4-32 Vista principal de la aplicación establecimiento 56 La vista para crear oferta muestra dos cuadros de texto en los que se introducirá el título y la descripción de la oferta. El tiempo que la oferta estará activa se introduce mediante dos parámetros. El tipo de oferta se selecciona de un total de cuatro opciones que su muestran en forma de desplegable al pulsar tipo de oferta. La forma en la que se visualizan las ofertas de otros establecimientos, tanto en forma de lista como en versión sobre un mapa, es la misma en la aplicación establecimiento y en la de público. En la visualización en forma de lista es posible deslizar las ofertas hacia abajo para volver a cargar las ofertas disponibles en el sistema Figura 4-34 Vista menú lateral Figura 4-34 Vista eliminar oferta Figura 4-35 Vista crear oferta 57 La vista en detalle de una oferta también es la misma en las dos aplicaciones. En la parte superior se muestra en grande el nombre del establecimiento y a continuación se muestra un cuadro en el que incluye la información de la oferta y del establecimiento. En la esquina superior izquierda aparece el icono del tipo de oferta. El primer texto que aparece es el título que se le ha dado a la oferta y a continuación la descripción de la misma. Después se puede ver la descripción del establecimiento que ha publicado la oferta. El último texto que se muestra en color negro es el tiempo necesario para llegar hasta la ubicación de ese establecimiento. Los dos últimos ítems que se muestran son la dirección del establecimiento y el número de teléfono del mismo. Ambos son botones que lanzarán la aplicación de mapas del dispositivo con las indicaciones para llegar al establecimiento o la de teléfono para llamar al mismo. Figura 4-38 Iconos tipo de oferta Figura 4-37 Tirar para actualizar Figura 4-37 Vista oferta detallada 58 La vista del mapa muestra un globo rojo para indicar la posición del usuario o la posición del establecimiento desde el que se ha iniciado sesión. Mediante globos verdes se muestran los establecimientos cercanos que tienen ofertas en vigor. Al pulsar sobre el globo rojo se muestra un texto indicando al usuario que esa es su posición. Si se pulsa sobre un globo verde aparece un cuadro de texto indicando el nombre del establecimiento en grande y con una fuente menor se muestra el título de la oferta y su descripción. Figura 4-40 Vista del mapa Figura 4-40 Vista mapa con oferta seleccionada 59 4.6. IMPLEMENTACIÓN 4.6.1. Aplicación móvil Como ya se ha explicado previamente, las dos aplicaciones que forman este proyecto han sido desarrolladas utilizando Ionic Framework. La organización de un proyecto realizado con Ionic es similar a como sería organizado un proyecto Angular. La estructura de la aplicación es la siguiente: • Aplicación o hooks o platforms ▪ android ▪ ios o pluggins o resources ▪ android ▪ ios ▪ icon.png ▪ splash.png o scss o www ▪ css ▪ img ▪ js ▪ lib ▪ templates ▪ index.html El directorio más importante del proyecto es el último, www, en él es donde se crea toda la aplicación. En la carpeta css se almacenan los ficheros para darle el aspecto visual a la aplicación. En img se guardan las imágenes que se muestran en la aplicación. En la carpeta js se guardan los ficheros javascript que controlan el negocio de la aplicación. Hay uno para las rutas de cada vista, uno para los controladores, uno para los servicios y un último que inicializa todo. El directorio lib almacena las librerías necesarias para ejecutar la aplicación. En templates se guardan cada una de las vistas o actividades de la aplicación, esto se hace en formato html. El último fichero, index.html, es el que se muestra por primera vez al iniciar la aplicación. 60 El directorio resources almacena los iconos y splash de cada plataforma paraa la que se va a generar una aplicación. Tanto los iconos como los splash se guardan en todos los tamaños que vayan a ser necesarios. En la carpeta pluggins se almacena una carpeta para cada pluggin de ionic/cordova necesario para el funcionamiento de la aplicación. Cuando se genera la aplicación mediante los comandos ionic build ios ionic build Android se genera una carpeta para cada sistema operativo en el que se crea un proyecto idéntico al que se hubiera creado si la aplicación hubiera sido desarrollada en Java para Android o Swift para iOS. En estas carpetas se encuentra el archivo .apk para Android y el .xcodeproj necesario para compilar la aplicación para iOS. A continuación se explica cómo se han implementado cada una de las funciones que se pueden realizar desde la aplicación móvil: Funcionalidad 1: Consultar todas las ofertas propias Se realiza una petición GET a la API al recurso oferta e incluyendo como filtro el propio email del establecimiento e incluyendo el token recibido al iniciar sesión. Como respuesta se obtiene un JSON con todas las ofertas creadas por este establecimiento. Esta colección se añade al template http correspondiente mediante Angular. Gracias al plugin momento de Angular se muestra el tiempo que hace (o queda) que la oferta caducó (caducará) respecto al momento actual, en lugar de mostrar una fecha y una hora tal cual. Funcionalidad 2: Crear una oferta Se añaden los campos necesarios para crear una oferta y se envía un mensaje POST al recurso oferta incluyendo el token recibido al iniciar sesión y en el campo body se añaden la información de la oferta. Se recibe una confirmación positiva o negativa en función de si fue posible o no crear la oferta. Funcionalidad 3: Volver a publicar una oferta ya publicada En la vista principal, desplazando una oferta hacia la izquierda se muestran dos opciones: volver a publicar y eliminar. La primera envía un mensaje POST al recurso oferta incluyendo la misma información que en la oferta original pero modificando la fecha de fin de validez por la fecha actual más el tiempo de duración de la oferta original. Como en el resto de peticiones, es necesario incluir el token. 61 Funcionalidad 4: Eliminar una oferta Al seleccionar la opción eliminar oferta se envía una petición DELETE con el id de la oferta seleccionada y esta queda eliminada de la base de datos, Funcionalidad 5: Consultar ofertas de establecimientos cercanos Se realiza una petición GET a la API al recurso oferta y añadiendo como filtro el propio email para evitar que se reciban las ofertas publicadas por el propio establecimiento. Se obtiene un JSON JSON con todas las ofertas creadas por otros establecimientos. La distancia del propio establecimiento a cada uno de los otros establecimientos se realiza mediante la siguiente función: function Dist(lat1, lon1, lat2, lon2) { rad = function(x) {return x*Math.PI/180;} var R = 6378.137; //Radio de la tierra en km var dLat = rad( lat2 - lat1 ); var dLong = rad( lon2 - lon1 ); var a = Math.sin(dLat/2) * Math.sin(dLat/2) + Math.cos(rad(lat1)) * Math.cos(rad(lat2)) * Math.sin(dLong/2) * Math.sin(dLong/2); var c = 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1-a)); var d = R * c; d = d*1000; return d.toFixed(); } Esta función calcula la distancia en km. Aplicando una velocidad de paseo de 5km/h se transforma esta distancia en el tiempo que le llevaría a una persona llegar hasta el establecimiento. Este tiempo, por tanto, es meramente informativo. Las coordenadas utilizadas como ubicación del establecimiento son las coordenadas del propio establecimiento, no las de la posición del dispositivo móvil en el momento de realizar la operación. Esto es así para permitir al dueño de un establecimiento ver las ofertas de los establecimientos cercanos a su propio establecimiento incluso aunque él no se encuentra en su establecimiento. Funcionalidad 6: Consultar el mapa de los establecimientos con ofertas en vigor La petición que se realiza es la misma que la realizada en la funcionalidad 5, pero en este caso la representación no se hace mediante el mismo template. En esta ocasión se añaden como un marker de Google Maps para que en el momento de mostrar el mapa se muestre la información de los establecimientos y sus ofertas. Funcionalidad 7: Consultar las condiciones de una oferta En la vista creada en la funcionalidad 5 existe la posibilidad de seleccionar una oferta y, utilizando el id de la oferta y el email del establecimiento que ha creado la oferta se hacen una petición GET al recurso oferta incluyendo la información de la relación con el recurso establecimiento para obtener toda la información en la misma petición. 62 Funcionalidad 8: Registrarse como establecimiento Se le piden al usuario los datos necesarios para crear un establecimiento. Mediante la API Geocoding de Google se transforma la dirección introducida (Ej: Paseo del Prado, 3, Madrid) en coordenadas geográficas (Ej: 40.417671, -3.692895), que son las que se almacenan en la base de datos, además de la dirección para poder mostrarla a los usuarios. Primero se envía el email y la contraseña para generar un nuevo usuario en el servicio de gestión de usuarios. A continuación se crea el establecimiento en la base de datos y ya es posible iniciar sesión con los datos de este establecimiento. Funcionalidad 9: Iniciar sesión en la aplicación El inicio de sesión se realiza mediante autenticación en la API. Se envía una petición POST para iniciar sesión en la API enviando el email, la contraseña y el token de la aplicación, que se encuentra almacenado en la aplicación. Si las credenciales son correctas, se devuelve un JSON con el token para realizar las peticiones y su información. Si las credenciales son incorrectas se devuelve un JSON con la información del error. Funcionalidad 10: Acceder sin iniciar sesión La aplicación permite acceder a la información de las ofertas y establecimientos sin estar registrado. En la pantalla de inicio de la aplicación de público se muestra un botón en el que se indica Iniciar sesión sin registrarse. Dado que es necesario obtener un token para utilizar la API del proyecto, se realiza el mismo procedimiento que en la funcionalidad 19 pero el usuario y la contraseña son los almacenados en la aplicación como usuario predeterminado. Así se obtiene el token necesario para la API y es posible consultar información sin estar registrado en la aplicación. Funcionalidad 11: Consultar las ofertas de establecimientos cercanos Se realiza del mismo modo que la funcionalidad 5 pero incluyendo el token del usuario público en lugar de la del establecimiento. Además, se aplica un filtro en el que si la distancia entre el usuario y el establecimiento es mayor de 2km no se mostrará la información de esta oferta en el caso de que esta funcionalidad se realice como usuario no registrado. Para calcular la ubicación del usuario se utiliza el sensor GPS del dispositivo móvil, o la ubicación proporcionada por la conexión a internet si el GPS no está activado. Funcionalidad 12: Consultar el mapa de los establecimientos con ofertas en vigor Se realiza del mismo modo que la funcionalidad 6 pero incluyendo el token del usuario público en lugar de la del establecimiento. Además, se aplica un filtro en el que si la distancia entre el usuario y el establecimiento es mayor de 2km no se mostrará la información de esta oferta en el caso de que esta funcionalidad se realice como usuario no registrado. 63 Para calcular la ubicación del usuario se utiliza el sensor GPS del dispositivo móvil, o la ubicación proporcionada por la conexión a internet si el GPS no está activado. Funcionalidad 13: Consultar las condiciones de una oferta Se realiza del mismo modo que la funcionalidad 7 pero incluyendo el token del usuario público en lugar de la del establecimiento. Funcionalidad 14: Registrar un nuevo usuario Se le piden al usuario los datos necesarios para crear un establecimiento. Primero se envía el email, el nombre y la contraseña del usuario para generar un nuevo usuario en el servicio de gestión de usuarios. A continuación se crea el usuario en la tabla usuarios de la base de datos. Funcionalidad 15: Marcar un establecimiento como favorito Se envía un mensaje post al recurso favorito de la API indicando en el body el email del usuario y el email del establecimiento. De este modo queda almacenado el establecimiento como establecimiento favorito del usuario. Esta funcionalidad no está implementada en la aplicación. Funcionalidad 16: Consultar las ofertas vigentes de sus establecimientos favoritos Se realiza del mismo modo que la funcionalidad 11. Se realiza otra petición al recurso favorito incluyendo como filtro el email del usuario. Al recibir la información de las dos peticiones se cruzan estos datos y se muestran al usuario únicamente las ofertas que pertenecen a establecimiento que ha marcado como favorito. Esta funcionalidad no está implementada en la aplicación. Funcionalidad 17: Simular su ubicación para consultar las ofertas de otro lugar Al igual que en la funcionalidad 8, se hace uso de la API Geocoding de Google para transformar la dirección introducida por el usuario en coordenadas geográficas. Esta ubicación queda almacenada como la ubicación actual del usuario y todas las operaciones se realizan utilizando esta nueva ubicación. Esta funcionalidad no está implementada en la aplicación. Funcionalidad 18: Filtrar las ofertas Se muestran al usuario los cuatro tipos de oferta posibles. El usuario selecciona el tipo de oferta que quiere buscar y a continuación se filtran las ofertas de modo que solo se muestran las ofertas cuyo tipo es el marcado por el usuario registrado. Esta funcionalidad no está implementada en la aplicación. Funcionalidad 19: Iniciar sesión como usuario registrado En la primera vista de la aplicación público se muestra al usuario dos entradas de texto para introducir el email del usuario y la contraseña. Cuando el usuario introduce estos datos y 70 REFERENCIAS [1] Apple, «iOS 10,» [En línea]. Available: http://www.apple.com/es/ios/ios10/. [Último acceso: 10 01 2017]. [2] J. Bristowe, «Telerik Developer Network,» 15 03 2015. [En línea]. Available: http://developer.telerik.com/featured/what-is-a-hybrid-mobile-app/. [Último acceso: 15 01 2017]. [3] Google, «Android,» [En línea]. Available: https://www.android.com/intl/es_es/. [Último acceso: 10 01 2017]. [4] Drifty, «Ionic,» 2013. [En línea]. Available: https://ionicframework.com. [Último acceso: 11 01 2017]. [5] Google, «WebView,» [En línea]. Available: https://developer.android.com/reference/android/webkit/WebView.html. [Último acceso: 15 01 2017]. [6] Node.js Foundation, «Node.Js,» [En línea]. Available: https://nodejs.org/. [Último acceso: 13 01 2017]. [7] Apache, «Cordova,» [En línea]. Available: https://cordova.apache.org. [Último acceso: 10 01 2017]. [8] Ionic, «ngCordova,» [En línea]. Available: http://ngcordova.com/docs/plugins/. [Último acceso: 10 01 2017]. [9] Google, «Google Maps,» [En línea]. Available: https://developers.google.com/maps/. [Último acceso: 10 01 2017]. [10] Here, «Here,» [En línea]. Available: https://developer.here.com. [Último acceso: 10 01 2017]. [11] M. Nasato, «Udemy: Ionic By Example,» [En línea]. Available: https://www.udemy.com/ionic-by-example/l. [Último acceso: 08 01 2017]. [12] G. Nachman, «iTerm2,» [En línea]. Available: https://www.iterm2.com. [Último acceso: 11 01 2017]. [13] «SublimeText,» [En línea]. Available: https://www.sublimetext.com. [Último acceso: 10 01 2017]. [14] Apple, «Xcode 8,» [En línea]. Available: https://developer.apple.com/xcode/. [Último acceso: 10 01 2017]. [15] The Omni Group, «Omnigraffle,» [En línea]. Available: https://www.omnigroup.com/omnigraffle. [Último acceso: 14 01 2017]. [16] Oracle Corporation, «MySQL,» [En línea]. Available: https://www.mysql.com. [Último acceso: 13 01 2017]. [17] DreamFactory, 1998. [En línea]. Available: https://www.dreamfactory.com. [Último acceso: 12 01 2017]. 71 [18] SmartBear Software, «Swagger,» [En línea]. Available: http://swagger.io. [Último acceso: 15 01 2017]. [19] Techtimes, «iOS 10 Adoption Rate: Installed On 76 Percent Of iDevices,» [En línea]. Available: http://www.techtimes.com/articles/191556/20170106/ios10-adoption-rate-installed-on-76-percent-of-idevices.htm. [Último acceso: 04 01 2017]. [20] According to Apple’s official figures, iOS 10 adoption rate now at 54%, «Techcrucnch,» [En línea]. Available: https://techcrunch.com/2016/10/11/according-to-apples-official-figures-ios-10adoption-rate-now-at-54/. [Último acceso: 04 01 2017]. [21] Gartner, «Worldwide Sales of Smartphones,» [En línea]. Available: http://www.gartner.com/newsroom/id/3516317. [Último acceso: 11 01 2017]. [22] Microsoft, «Azure,» [En línea]. Available: https://portal.azure.com/. [Último acceso: 10 01 2017]. [23] Google, «Google Maps Geolocation API,» [En línea]. Available: https://developers.google.com/maps/documentation/geolocation/intro?hl=es419. [Último acceso: 11 01 2017].