Escuela de Ingenier´ıa Inform ´atica
TRABAJO FIN DE GRADO
Grado en Ingenier´ıa Inform ´atica
(Menci ´on en Ingenier´ıa de Software)
Route66App
Resumen
Cada vez es m ´as com ´un encontrarse la ludificaci ´on aplicada a los procesos empresariales como una forma de incrementar la productividad sobre un determinado aspecto. Una de las aplicaciones m ´as comunes es la fidelizaci ´on de clientes, en donde, por medio de una serie de juegos y actividades, se incita a aumentar el consumo de los usuarios sobre la marca y esta es justa la idea fundamental sobre la que se sustenta este Trabajo de Fin de Grado.
Route66Appes una aplicaci ´on nativa para dispositivosAndroid, orientada a aplicar t ´ecnicas de ludificaci ´on empresarial de fidelizaci ´on de clientes para una cadena de restaurantes de comida r ´apida. Se ha realizado con las ´ultimas tecnolog´ıas propuestas porGooglepara el desarrollo de aplicaciones m ´oviles:FirebaseyKotlin.
Abstract
It is more and more common to find the gamification applied to the different business procedures as a way of increasing the productivity over a certain business aspect. One of the most common applications is the earning of customers loyalty where, thanks to different games and activities, customers are encouraged to increase the expense in the products of the brand and that is exactly the main idea of this Bachelor’s Thesis.
Agradecimientos
Quisiera agradecer, en primer lugar, a mi tutora del Trabajo de Fin de Grado, D ˜na. Margarita Gonzalo Tasis, por su dedicaci ´on e ilusi ´on puesta en este proyecto.
En segundo lugar, a mi familia y amigos, por el apoyo que me han dado en estos cuatro a ˜nos de carrera y en especial a mis padres por haberme ayudado en este trabajo con sus ideas y opiniones.
Por ´ultimo, a mis compa ˜neros de equipo de Telef ´onica Investigaci ´on y Desarrollo, que me han dado la oportunidad de aprender tecnolog´ıas muy utilizadas y relacionadas con el desarrollo de aplicaciones Android.
´Indice de contenidos
1. Introducci ´on y contexto 1
1.1. Introducci ´on y objetivos . . . 1
1.1.1. Introducci ´on . . . 1
1.1.2. Objetivos . . . 2
1.1.3. Motivaci ´on . . . 2
1.2. An ´alisis de aplicaciones similares . . . 3
1.2.1. An ´alisis aplicaciones de restaurantes de comida r ´apida. . . 3
1.2.2. Conclusiones extra´ıdas . . . 8
1.3. Estructura de la memoria . . . 9
1.4. Propuesta . . . 9
1.4.1. Resumen de “Estudio de ludificaci ´on en una empresa para mejorar la fidelizaci ´on de los clientes” . . . 10
2. Herramientas utilizadas 13 2.1. Herramientas utilizadas . . . 13
2.2. Motivaci ´on de las tecnolog´ıas utilizadas . . . 14
2.2.1. Kotlin . . . 14
2.2.2. Firebase . . . 15
2.3. Comunicaci ´on con el servidor . . . 16
3. Route66App 17 3.1. Plan de Desarrollo delSoftware. . . 17
3.1.1. Descripci ´on del proyecto . . . 17
3.1.2. Metodolog´ıa de Desarrollo del proyecto . . . 18
3.1.3. Restricciones . . . 18
3.1.4. Estructura organizativa . . . 19
3.1.5. Gesti ´on del proyecto . . . 20
3.1.6. Relaci ´on de entregables no software . . . 26
3.1.7. Control y seguimiento del proyecto . . . 26
3.1.8. Gesti ´on de riesgos . . . 27
3.1.9. Gesti ´on de configuraciones . . . 29
3.1.10. Estimaci ´on de los costes . . . 29
3.1.11. Desviaciones sobre el calendario planificado . . . 32
3.2. An ´alisis . . . 32
3.2.1. Requisitos . . . 32
3.2.2. Casos de uso . . . 40
3.2.3. Modelo de dominio . . . 54
3.2.5. Usabilidad . . . 68
3.3. Dise ˜no . . . 69
3.3.1. Arquitectura . . . 69
3.3.2. Patrones utilizados . . . 72
3.3.3. Esquema de la base de datos . . . 74
3.3.4. Diagrama de despliegue . . . 76
3.4. Implementaci ´on . . . 77
3.4.1. Niveles, insignias y premios . . . 77
3.4.2. Dependencias . . . 78
3.4.3. Juegos . . . 79
3.4.4. Explicaci ´on de la arquitectura escogida . . . 80
3.4.5. Almacenamiento de datos . . . 82
3.4.6. Implementaci ´on del modelo . . . 82
3.4.7. Funciones . . . 85
3.5. Pruebas . . . 86
3.6. Manual de instalaci ´on . . . 90
3.7. Gu´ıa de usuario . . . 90
3.7.1. Usuarios . . . 90
3.7.2. Equipos . . . 94
3.7.3. Niveles y misiones . . . 97
4. Conclusiones y trabajo futuro 99 4.1. Conclusiones . . . 99
4.2. Trabajo futuro . . . 99
5. Webgraf´ıa y Bibliograf´ıa 100 5.1. Webgraf´ıa . . . 101
5.2. Bibliograf´ıa . . . 104
´Indice de figuras
1.1. Capturas de pantalla de la aplicaci ´on“McDonald’s Espa ˜na - Ofertas“. . . 3
1.2. Capturas de pantalla de la aplicaci ´on“BURGER KINGR Espa ˜na“. . . 4
1.3. Capturas de pantalla de la aplicaci ´on“KFC Espa ˜na–ofertas cerca de ti“. . . 5
1.4. Capturas de pantalla de la aplicaci ´on“Club VIPS: Promociones y pedidos Take Away“. . . 6
1.5. Capturas de pantalla de la aplicaci ´on“Pans & Company“. . . 7
1.6. Capturas de pantalla de la aplicaci ´on“Foster’s Hollywood“. . . 8
2.1. Logotipo deKotlin. . . 14
2.2. Snippetejemplo de unPOJOPunto . . . 14
2.3. Logotipo deFirebase. . . 15
3.1. Fases de la metodolog´ıa UPedu. . . 20
3.2. Diagrama de Gantt para la iteraci ´on 0 (fase de inicio). . . 22
3.3. Diagrama de Gantt para la iteraci ´on 1 (fase de elaboraci ´on). . . 23
3.4. Diagrama de Gantt para la iteraci ´on 2 (fase de elaboraci ´on). . . 24
3.5. Diagrama de Gantt para la iteraci ´on 3 (fase de construcci ´on). . . 24
3.6. Diagrama de Gantt para la iteraci ´on 4 (fase de construcci ´on). . . 25
3.7. Diagrama de Gantt para la iteraci ´on 5 (fase de transici ´on). . . 25
3.8. Diagrama de casos de uso. Parte I. . . 40
3.9. Diagrama de casos de uso. Parte II. . . 40
3.10.Modelo de dominio. Parte que interacciona conFirebase. . . 54
3.11.Modelo de dominio. Parte que interacciona con la base de datos local. . . 55
3.12.Diagrama de secuencia 1 “Modificar equipo“. . . 56
3.13.Diagrama de secuencia del caso de uso 2 “Invitar usuario al equipo“. . . 56
3.14.Diagrama de secuencia del caso de uso 3 “Nombrar un administrador“. . . 57
3.15.Diagrama de secuencia del caso de uso 4 “Eliminar a un miembro de un equipo“. . . 57
3.16.Diagrama de secuencia del caso de uso 5 “Eliminar un equipo“. . . 58
3.17.Diagrama de secuencia del caso de uso 6 “Consultar misiones“. . . 58
3.18.Diagrama de secuencia del caso de uso 7 “Realizar misi ´on“. . . 59
3.19.Diagrama de secuencia del caso de uso 8 “Realizar misi ´on de consumo m´ınimo“. . . 59
3.20.Diagrama de secuencia del caso de uso 9 “Realizar misi ´on competitiva“. . . 60
3.21.Diagrama de secuencia del caso de uso 10 “Realizar juego social“. . . 60
3.22.Diagrama de secuencia del caso de uso 11 “Modificar perfil“. . . 61
3.23.Diagrama de secuencia del caso de uso 12 “Consultar perfil“. . . 61
3.24.Diagrama de secuencia del caso de uso 13 “Consultar logros“. . . 62
3.25.Diagrama de secuencia del caso de uso 14 “Consultar insignias“. . . 62
3.26.Diagrama de secuencia del caso de uso 15 “Consultar ranking“. . . 63
3.28.Diagrama de secuencia del caso de uso 17 “Crear equipo“. . . 64
3.29.Diagrama de secuencia del caso de uso 18 “Registrarse“. . . 64
3.30.Diagrama de secuencia del caso de uso 19 “Aceptar invitaci ´on“. . . 65
3.31.Diagrama de secuencia del caso de uso 20 “Enviar invitaci ´on“. . . 65
3.32.Diagrama de secuencia del caso de uso 21 “Iniciar sesi ´on“. . . 66
3.33.Diagrama de secuencia del caso de uso 22 “Ver posiciones de otros jugadores“. . . 66
3.34.Diagrama de secuencia del caso de uso 23 “Consultar premios“. . . 67
3.35.Diagrama de secuencia del caso de uso 24 “Salir de un equipo“. . . 67
3.36.Diagrama de paquetes de alto nivel de la aplicaci ´on. . . 69
3.37.Diagrama de clasesModel. . . 70
3.38.Diagrama de clases de los paquetesLoginActivity yGameActivity. . . 70
3.39.Diagrama de clases del paqueteMainActivity. . . 71
3.40.Diagrama de clases de los paquetesMissionsActivity yNormalActivity. . . 71
3.41.Diagrama de clases del paqueteTeamActivity. . . 72
3.42.Patr ´on M.V.C. . . 73
3.43.Patr ´on D.A.O. . . 73
3.44.Esquema no relacional basado en documentos y colecciones para las entidades relacionadas con equipos. . . 74
3.45.Esquema no relacional basado en documentos y colecciones para las entidades relacionadas con usuarios. . . 75
3.46.Esquema de la base de datos relacional gestionada por la biblioteca de persistenciaRoom[3]. . . . 76
3.47.Diagrama de despliegue de la aplicaci ´onAndroid. . . 76
3.48.Diagrama en el que se muestra la operaci ´onGET. . . 86
3.49.Captura de pantalla de la vista de inicio de sesi ´on y registro. . . 90
3.50.Capturas de pantalla de la vista principal de la aplicaci ´on. . . 91
3.51.Captura de pantalla de “Mi perfil“. . . 92
3.52.Capturas de pantalla de “Mis logros“. . . 92
3.53.Capturas de pantalla de “Mis insignias“. . . 93
3.54.Capturas de pantalla de “Mis premios“. . . 93
3.55.Capturas de pantalla de “Invitar“, “Ranking global“ y “Equipos“. . . 94
3.56.Capturas de pantalla de la vista que muestra los detalles de un equipo. . . 94
3.57.Capturas de pantalla de “Gestionar usuario“ y “Configuraci ´on del equipo“ . . . 95
3.58.Capturas de pantalla de “C ´odigoQRdel equipo“ y “A ˜nadir miembro al equipo“. . . 96
3.59.Capturas de pantalla de “Salir del equipo“. . . 96
3.60.Capturas de pantalla de “Miembros de un nivel“ y “Misiones de un nivel“. . . 97
3.61.Capturas de pantalla de una misi ´on de tipo social. . . 97
3.62.Capturas de pantalla de una misi ´on de tipo competitiva. . . 98
´Indice de tablas
1.1. Ciudades o niveles de la aplicaci ´on. . . 11
3.1. Roles. . . 19
3.2. Fases del proceso UPedu. . . 21
3.3. Iteraci ´on 0. Fase de Inicio. . . 22
3.4. Iteraci ´on 1. Fase de elaboraci ´on. . . 23
3.5. Iteraci ´on 2. Fase de elaboraci ´on. . . 24
3.6. Iteraci ´on 3. Fase de construcci ´on. . . 24
3.7. Iteraci ´on 4. Fase de construcci ´on. . . 25
3.8. Iteraci ´on 5. Fase de transici ´on. . . 25
3.9. Costes de los recursoshardware. . . 29
3.10.Costes de los recursossoftware. . . 30
3.11.Costes de los recursos humanos. . . 30
3.12.Desviaciones sobre el calendario planificado. . . 32
Cap´ıtulo 1
Introducci ´
on y contexto
1.1.
Introducci ´
on y objetivos
1.1.1.
Introducci ´
on
La ludificaci ´on consiste, seg ´un IEBSchool [29] en“el uso de mec ´anicas de juego en un contexto de no juego para conducir el comportamiento de los participantes (mediante la participaci ´on, la interacci ´on, la adicci ´on o, incluso, la competici ´on) hacia la consecuci ´on de un determinado objetivo de negocio”.
Aunque habitualmente se ha enfocado la ludificaci ´on al ´area comercial o de ventas de cara a los clientes, (como por ejemplo el [35] Monopoly Ganador de McDonalds), existen tambi ´en ejemplos en la educaci ´on, en las relaciones con los proveedores e, incluso, para incrementar el n ´umero de ventas en un centro comercial, (ludificaci ´on orientada a los empleados), tal como se recoge en el Trabajo de Fin de Grado de la alumna del Grado en Ingenier´ıa Industrial, [56] D ˜na. Ana Ruiz Caballero.
Hoy en d´ıa, miles de compa ˜n´ıas utilizan la ludificaci ´on en sus procesos empresariales desde sus relaciones con los empleados hasta con los clientes, pasando por sus comerciales. La ludificaci ´on realmente funciona y, por incre´ıble que parezca, es muy efectiva. De hecho, no son pocos los ejemplos de una aplicaci ´on m ´as que satisfactoria de la misma. As´ı, en 2011, [1] Volkswagen decidi ´o inventar en China, su mercado m ´as importante, una nueva versi ´on de su“people’s car“ y para ello cont ´o con la ayuda de sus clientes, a quienes ofreci ´o una herramienta de dise ˜no y un sistema de puntuaciones. El resultado de este proyecto fue la obtenci ´on de m ´as de 50.000 propuestas diferentes. Otro caso que merece la pena rese ˜nar es el de Correos [30], que en 2012 redise ˜n ´o suweby se plante ´o o bien contratar a una empresa por miles de euros, bien, plantear un sistema de ludificaci ´on en el que los empleados propusieran nuevos dise ˜nos a cambio de peque ˜nos regalos. Esta segunda opci ´on fue la elegida (se presentaron m ´as de 50.000 ideas en un tiempo r ´ecord), y esto supuso un ahorro de un 70 % frente a la primera alternativa.
1.1.2.
Objetivos
El prop ´osito de este Trabajo Fin de Grado es el de realizar una aplicaci ´onAndroid basada en un sistema de ludificaci ´on para un restaurante de comida r ´apida, partiendo de la idea desarrollada en el [55] Trabajo de Fin de Grado de D ˜na. Cristina Mart´ınez Mart´ınez. Los objetivos concretos de la aplicaci ´on vendr ´an detallados en el documento de an ´alisis.
Este Trabajo Fin de Grado detallar ´a el desarrollo, an ´alisis, dise ˜no e implementaci ´on de la parte cliente del sistema inform ´atico en cuesti ´on y se ha dise ˜nado para que esta cambie las diferentes misiones y desaf´ıos de acuerdo con los par ´ametros que el administrador del sistema establezca en elbackend (parte de gesti ´on).
1.1.3.
Motivaci ´
on
1.2.
An ´alisis de aplicaciones similares
Se han analizado diversas aplicaciones de restaurantes de comida r ´apida presentes en Espa ˜na, con el fin de conocer c ´omo son y si han implementado t ´ecnicas de ludificaci ´on a las mismas. Como se ver ´a m ´as adelante, los sistemas de ludificaci ´on aplicados en estos ejemplos son bastante b ´asicos y no permiten extraer todo el potencial que podr´ıan tener.
1.2.1.
An ´alisis aplicaciones de restaurantes de comida r ´apida.
1.2.1.1. McDonald’s
Figura 1.1: Capturas de pantalla de la aplicaci ´on“McDonald’s Espa ˜na - Ofertas“. [34]
Aplicaci ´on estudiada:[34]McDonald’s Espa ˜na - Ofertas.
An ´alisis: La aplicaci ´on m ´ovilMcDonaldsofrece un gran n ´umero de funcionalidades entre las que se en-cuentran un servicio de ofertas, canjeo de cupones, listado de la carta de productos o env´ıo de pedidos a domicilio.
Puntos d ´ebiles:
• Se limita al consumo y no a promocionar la marca por redes sociales ayud ´andose de los clientes.
• Las promociones solo se pueden hacer efectivas en los establecimientos f´ısicos, no en pedidos por Internet.
• No existe ning ´un historial de pedidos.
1.2.1.2. Burger King
Figura 1.2: Capturas de pantalla de la aplicaci ´on“BURGER KINGR Espa ˜na“.
[5]
Aplicaci ´on estudiada:[5]BURGER KINGR Espa ˜na.
An ´alisis:Al igual que McDonalds, ofrece un sistema de fidelizaci ´on llamado“Mis Coronas“, consistente en que cada tres pedidos realizados por medio de laapp m ´ovil o el sitioweb deBurger King, se acumulan coronas y cada cuatro se consigue una hamburguesa gratis. Adem ´as, invitan a registrarse en laappy con el historial de pedidos efect ´uan ofertas personalizadas al cliente.
Las opciones de estaappest ´an bastante limitadas: conseguir un listado de restaurantes, realizar pedidos a domicilio, ver la carta de productos o visualizar un listado de cupones o promociones.
Puntos fuertes:
• Avisa mediante notificacionesPUSHde nuevas ofertas.
• Solicita seguir a la marca por redes sociales (Facebook).
• Tiene un sistema de fidelizaci ´on para sus pedidosonline.
Puntos d ´ebiles:
• La parte de fidelizaci ´on est ´a solo dedicada a la realizaci ´on de pedidos por Internet.
• Las promociones son muy similares, independientemente del perfil del cliente.
• No est ´a orientada a que el cliente realice un determinado consumo.
• No se pueden aplicar los cupones de la aplicaci ´on a pedidos a domicilio.
1.2.1.3. KFC
Figura 1.3: Capturas de pantalla de la aplicaci ´on“KFC Espa ˜na–ofertas cerca de ti“. [26]
Aplicaci ´on estudiada:[26]KFC Espa ˜na–ofertas cerca de ti.
An ´alisis:
Es una de las aplicaciones m ´as simples de las estudiadas pues se limita a poner una carta de productos, un listado de restaurantes y una opci ´on para obtener ofertas.
Puntos fuertes:
• NotificacionesPUSHpara alertar al cliente de nuevas ofertas y promociones.
1.2.1.4. VIPS
Figura 1.4: Capturas de pantalla de la aplicaci ´on“Club VIPS: Promociones y pedidos Take Away“. [46]
Aplicaci ´on estudiada:[46]Club VIPS: Promociones y pedidos Take Away.
An ´alisis:La aplicaci ´on de la cadenaVIPSes, sin lugar a dudas, la m ´as completa de las analizadas. Para fidelizar clientes utiliza el servicioClubEuroVIPS, en el que ofrece uncashback de un 3 %, pudiendo duplicarse bajo ciertas condiciones como aumentar el consumo o hacerlo en determinadas franjas horarias. Adem ´as ofrece un sistema de clasificaci ´on de usuarios por niveles de gasto (niveles cl ´asico, oro y platino) a partir de los cuales podremos obtenerWiFi Premium, bebidas extras o puntos extras.
Paralelamente, la aplicaci ´on invita al usuario a sus lanzamientos o estrenos de nuevos productos. Por ejemplo “te invitamos a nuestras hamburguesas del Chef o a nuestras nuevas pizzas Chicago Style” o “te invitamos a probar nuestras pizzas” y se pueden encontrar funcionalidades propias de un restaurante que apuesta por el crecimiento de su app m ´ovil, como son la posibilidad de pagar desde la app, la funcionalidad
Shake-It, que consiste en realizar su pedido favorito con solo agitar su tel ´efono m ´ovil, o la opci ´on de guardar promociones en la aplicaci ´on. Adem ´as de permitir realizar pedidos online del tipotake-away.
Puntos fuertes:
• La aplicaci ´on integra la tarjetaClub VIPS, que permite sumar puntos gracias a las compras hechas en restaurantes de la marca.
• Se puede duplicar el valor de los puntos delClub VIPSbajo condiciones espec´ıficas.
• NotificacionesPUSHpara informar al cliente de nuevas ofertas y promociones.
• Historial de pedidos.
• Integra un sistema para conectarse autom ´aticamente con las redes WiFi de los restaurantes de la marca. Posibilidad de tenerWiFi Premium en caso de alcanzar un cierto consumo.
• Invitaciones a eventos por el hecho de ser usuario de un determinado nivel.
• Clasificaci ´on del usuario por niveles bas ´andose en el consumo que se hace en los restaurantes.
• Se realizacashbacken los pedidos realizados siendo socio delClub VIPS.
• Se puede conseguir hasta un 25 % de descuento al invitar a usuarios a hacerse socios delClub VIPS.
Puntos d ´ebiles:
• No existe ning ´un juego ni interacci ´on con redes sociales.
1.2.1.5. Pans & Company
Figura 1.5: Capturas de pantalla de la aplicaci ´on“Pans & Company“. [39]
Aplicaci ´on estudiada:[39]Pans & Company.
An ´alisis: Pans & Company ofrece ´unicamente una tarjeta de fidelidad integrada en la mismaapp. Esta tarjeta b ´asicamente consiste en un c ´odigoQRque el usuario puede mostrar en caja para acumular puntos que, posteriormente, se podr ´an convertir en dinero. Adem ´as, se realizar ´an ofertas personalizadas.
Sus funcionalidades son las t´ıpicas de una aplicaci ´on de esta categor´ıa: listado de restaurantes, ofertas y listado de la carta.
1.2.1.6. Foster’s Hollywood
Figura 1.6: Capturas de pantalla de la aplicaci ´on“Foster’s Hollywood“. [21]
Aplicaci ´on estudiada:[21]Foster’s Hollywood.
An ´alisis: El sistema de fidelizaci ´on de clientes deFoster’s Hollywood se basa en un sistema de niveles (blue, silver y gold), en el que cuanto mejor sea el nivel, mayores ventajas tendr ´a el usuario: postre de regalo, descuentos de ocio (en empresas asociadas), o incluso, promoci ´on por el cumplea ˜nos. Para poder aumentar de nivel ser ´a necesario ir un n ´umero de veces a los establecimientos de la cadena.
Se nos identificar ´a como clientes mediante la tarjeta Foster’s Hollywood, un c ´odigo QR localizado en la aplicaci ´on y que el cliente simplemente debe ense ˜nar al realizar el pago, con el fin de que la compra quede asociada a su usuario. Por otra parte, tambi ´en es posible visualizar la carta del restaurante o ver el listado de restaurantes, as´ı como realizar el pedidoonline.
Puntos fuertes:
• NotificacionesPUSHpara informar al cliente de nuevas ofertas y promociones.
• Sistema de fidelizaci ´on basado en niveles e integrado en la aplicaci ´on.
Puntos d ´ebiles:
• No cuenta con interacci ´on entre usuarios ni redes sociales, se limita al sistema de fidelizaci ´on.
1.2.2.
Conclusiones extra´ıdas
Del an ´alisis de las anteriores aplicaciones, pueden extraerse las siguientes conclusiones:
Ninguna emplea un sistema de ludificaci ´on avanzado tal y como se propone en este trabajo.
Todas ofrecen un sistema para obtener ofertas.
Las aplicaciones se limitan a la interacci ´on Usuario-Empresa, ninguna emplea las redes sociales para au-mentar su base de usuarios.
La mayor´ıa de las aplicaciones (todas exceptuando Burger King y KFC) promueven que el usuario vuelva al local, mediante la realizaci ´on de ofertas espec´ıficas para ello. Ir´ıan dirigidas a un perfil de jugador de tipo
triunfador, de acuerdo con la teor´ıa de Bartle [9].
1.3.
Estructura de la memoria
Este trabajo est ´a divido en cuatro partes y, a su vez, en secciones y subsecciones, abarcando as´ı los distintos documentos recogidos en esta memoria:
1. Cap´ıtulo I. Introducci ´on y Objetivos: incluye una breve descripci ´on de lo que es la ludificaci ´on, as´ı como un resumen de la propuesta realizada por la dise ˜nadora del sistema de ludificaci ´on sobre la que est ´a basado el proyecto. Finalmente, tambi ´en contiene un an ´alisis de aplicaciones de restaurantes de comida r ´apida que operan en Espa ˜na, con la finalidad de estudiar si estos incluyen o no un sistema de ludificaci ´on.
2. Cap´ıtulo II. Herramientas utilizadas: justificaci ´on del empleo de alguna de ellas.
3. Cap´ıtulo III. Route66App: es la parte m ´as importante del proyecto porque incluye la gran mayor´ıa de los documentos, como el Plan de Desarrollo de Software, el documento de an ´alisis, el documento de dise ˜no y todos aquellos detalles de la implementaci ´on que merecen la pena rese ˜nar.
4. Cap´ıtulo IV. Conclusiones y l´ıneas futuras.
5. Webgraf´ıa y bibliograf´ıa.
6. Anexos.
1.4.
Propuesta
Este Trabajo de Fin de Grado (T.F.G) estar ´a centrado en el T.F.G. [55] “Estudio de ludificaci ´on en una empresa para mejorar la fidelizaci ´on de los clientes”, elaborado por Da Cristina Mart´ınez Mart´ınez, graduada
durante el curso 2016-2017 en Ingenier´ıa de Organizaci ´on Industrial por la Universidad de Valladolid.
El trabajo de esta alumna, centrado en el dise ˜no de un sistema de ludificaci ´on aplicado a un posible caso real,(restaurante de comida americana), ten´ıa el problema de la imposibilidad de llevarlo a cabo con herramientas profesionales, dado su coste y a la falta de disponibilidad de las mismas. Por este motivo, el T.F.G. se tuvo que defender contando solo con una serie de prototipos basados en un sistema web.
1.4.1.
Resumen de “Estudio de ludificaci ´
on en una empresa para mejorar la
fideliza-ci ´
on de los clientes”
Se propone la realizaci ´on de un sistema de ludificaci ´on para una cadena de restaurantes de comida ame-ricana, que cuenta con un conjunto de franquicias repartidas por todo el territorio espa ˜nol. Es una empresa con muy buenos resultados econ ´omicos y que est ´a respaldada por una amplia y s ´olida base de clientes para quienes decide elaborar una aplicaci ´on que mejore la opini ´on de los mismos sobre la marca, ya que han llegado cr´ıticas sobre el sistema vigente de cupones y descuentos.
Finalmente, el equipo directivo decide encargar una aplicaci ´on basada en la ludificaci ´on cuyos objetivos son los siguientes:
1. Aumentar la fidelizaci ´on de los clientes.
2. Incentivar las ventas.
3. Mejorar la imagen de la marca en redes sociales.
4. Conseguir nuevos clientes.
5. Mejorar la confianza y satisfacci ´on del cliente.
Se medir ´a el cumplimiento de los objetivos anteriores mediante el c ´alculo de una serie de ratios.
P ´ublico objetivo
El p ´ublico objetivo estar ´a formado por hombres y mujeres con edades comprendidas entre los doce y los cincuenta y cinco a ˜nos.
Los conocimientos tecnol ´ogicos esperados en este grupo de edad no tienen por qu ´e ser altos, consi-der ´andose suficientes, conocimientos b ´asicos en uso desmartphonesy de aplicaciones m ´oviles. En el caso en el que nos encontramos, la aplicaci ´on que se va a desarrollar estar ´a enfocada a ser ejecutada sobre terminales de tipo Android.
Los potenciales usuarios de la aplicaci ´on la utilizar ´an para conseguir recompensas y descuentos derivados del uso de la misma.
Por ´ultimo, con el fin de fidelizar a un mayor n ´umero de clientes, y de acuerdo con la [9] teor´ıa de Bartle [9], se realizar ´an actividades que permitan satisfacer las necesidades de los cuatro tipos de jugador.
Roles
Se proponen dos tipos de roles: Administrador y Cliente.
Descripci ´on del juego
El juego se escenifica en la Ruta 66 americana que alude as´ı la tem ´atica del restaurante. Se dividir ´a el camino en once etapas o niveles correspondientes a las principales ciudades por las que pasa esta v´ıa y, para avanzar, el cliente deber ´a completar una serie de actividades, que adem ´as, otorgar ´an insignias, logros y premios. Cabe destacar que la dificultad de los niveles ir ´a aumentando gradualmente, con el objetivo de no perder la motivaci ´on.
1. Chicago.
2. Springfield.
3. St. Louis.
4. Tulsa.
5. Oklahoma City.
6. Amarillo.
7. Santa Fe.
8. Albuquerque.
9. Flagstaff.
10. Williams.
11. Los ´Angeles.
Cuadro 1.1: Ciudades o niveles de la aplicaci ´on.
Todos los niveles excepto el de Chicago tendr ´an un planteamiento similar:
Nivel 1. Chicago: Compuesto por las siguientes actividades:
• Configuraci ´on del perfil del jugador.
• Crear un equipo.
• Seguir en redes sociales la p ´agina del restaurante.
• Puntuar la aplicaci ´on en la tienda de aplicaciones.
• Comentar la aplicaci ´on en la tienda de aplicaciones.
Resto de niveles: Consistir ´an en diez misiones:
• Misiones de nivel social: consistir ´an en tareas como compartir el progreso, subir una foto hecha en el restaurante a las redes sociales, enviar invitaciones, etc ´etera.
• Misiones de minijuegos: ser ´an dos casillas y consistir ´a en jugar a un minijuego de un perfil de jugador.
• Misiones de consumo: el jugador deber ´a realizar consumiciones en los restaurantes de la cadena. Avanzar ´a m ´as o menos casillas en funci ´on del gasto que realice.
• Misiones de retos especiales: en d´ıas se ˜nalados, los jugadores podr ´an participar en retos creados espec´ıficamente para ese d´ıa.
Recompensas
Perfiles de jugador [9]
Se ha aplicado la teor´ıa de Bartle [9] para clasificar los jugadores en cuatro categor´ıas:
Triunfador: tendr ´a como objetivo llevar a cabo las misiones y obtener los premios o recompensas.
Explorador: son jugadores que les gusta descubrir o aprender cosas nuevas.
Socializadores: m ´as que inter ´es en conseguir los logros, buscan aprovecharlos para entablar relaciones sociales.
Killers: buscan ser los primeros en el juego. Quieren destacar sobre otros jugadores.
Es importante destacar que lo que hace que un jugador act ´ue de una forma u otra es su personalidad (en este contexto hablaremos de perfiles). Normalmente, las aplicaciones de juegos est ´an orientadas a un ´unico tipo de jugador, consiguiendo que el resto las abandonen al poco tiempo, al no coincidir los objetivos del juego con su personalidad. Sin embargo, parad ´ojicamente, los objetivos de estos sistemas inform ´aticos son siempre fidelizar a la mayor cantidad de usuarios durante la mayor cantidad de tiempo.
Lo novedoso del sistema de ludificaci ´on es que no est ´a orientado a un ´unico perfil de jugador sino a los cuatro a la vez. Para ello, se cuenta con actividades que tengan como funci ´on satisfacer a estos tipos de usuario.
Grupos
Cap´ıtulo 2
Herramientas utilizadas
2.1.
Herramientas utilizadas
Para la elaboraci ´on de este Trabajo Fin de Grado se han utilizado las siguientes herramientas:
Como editor LATEX,Texmakerv. 4.4.1.1.
Como sistema de control de versiones,GitHub2.
Para la realizaci ´on de copias de seguridad,Dropbox3.
Para tomar notas e ideas,Microsoft OneNote4.
Para realizar los diagramasUML,Astah Professional 7.1.05.
Para la elaboraci ´on de los prototipos iniciales, se ha utilizadoIonic36.
Para la elaboraci ´on de la aplicaci ´onAndroid nativa, se ha utilizandoAndroid Studio3.1.
Para la gesti ´on de historias de usuario, se ha utilizadoTrello.7.
Para el control y seguimiento del proyecto se ha utilizado la herramientaAsana8.
Para la realizaci ´on de los diagramas deGanttse ha empleadoWrikeen una versi ´on de prueba gratuita9.
1http://www.xm1math.net/texmaker/ 2https://www.github.com
3
https://www.dropbox.com/
4https://www.onenote.com/ 5
http://astah.net/
2.2.
Motivaci ´
on de las tecnolog´ıas utilizadas
En esta secci ´on se indican las diferentes tecnolog´ıas se ˜naladas por la tutora para elaborar este trabajo:
FirebaseyKotlin.
2.2.1.
Kotlin
Figura 2.1: Logotipo deKotlin. [28]
Kotlin [49] es un lenguaje de programaci ´on dise ˜nado por la empresaJetbrains(creadora deAndroid Studio
eIntelliJ IDEA), orientado a objetos y de tipado est ´atico, que se ejecuta, en el caso de Android, sobre la m ´aquina virtual deJava (JVM). Fue se ˜nalado porGoogle en elGoogle IOde 201710como uno de los dos lenguajes de
programaci ´on oficiales de Android y se espera que en un futuro sustituya a Java en esta tarea. Actualmente es muy conocido en el mundo del desarrollo de aplicaciones m ´oviles, pero se espera que pr ´oximamente se empiece a utilizar tanto en el back-end de sistemas inform ´aticos como en el front-end (p ´aginasWeb).
Figura 2.2:Snippetejemplo de unPOJOPunto
A la izquierda, la versi ´on enKotlin, a la derecha, la deJava. Elaboraci ´on propia.
Kotlin tiene una serie de ventajas que merecen la pena se ˜nalar [28]:
1. Permite una interoperabilidad completa con Java: al utilizar ambos la misma m ´aquina virtual (y compilar en
bytecode), es posible la ejecuci ´on de m ´etodos deJavaenKotliny viceversa. De esta forma, permite integrar componentes desarrollados en un lenguaje desde el otro.
2. Es conciso: Kotlin elimina gran cantidad de“boilerplate“ en el c ´odigo fuente. Por ejemplo, en el caso de una clasePOJO, los setters y los getters son generados en tiempo de compilaci ´on en el caso de que empleemos una clase de datos (data class).
3. Es “null-safe“: Seg ´un el blog de programaci ´on Tapiki [47], en un estudio realizado sobre 1.000 sistemas inform ´aticos, un 70 % de ellos conten´ıan errores de puntero nulo, que fue el motivo de excepci ´on m ´as frecuente.Kotlinintenta solucionar este problema forzando al programador a utilizar objetos que no pueden ser nulos, o bien, haciendo que tenga que indicar expresamente que un puntero puede ser nulo.
4. Es actualmente un est ´andar en programaci ´on de aplicacionesAndroid: El apoyo queGoogleest ´a dando al lenguaje de programaci ´on es tal que resulta m ´as que recomendable empezar a utilizarlo y acostumbrarse al mismo.
Por otro lado, tambi ´en resulta de inter ´es considerar los inconvenientes que suponen utilizar esta tecnolog´ıa [43]:
1. Curva de aprendizaje:Kotlintiene caracter´ısticas que no tiene Java y, por tanto, existe una cierta curva de aprendizaje que es necesario solventar.
2. Menor cantidad de documentaci ´on frente a Java: al ser un lenguaje tan nuevo, apenas se cuenta con una comunidad de desarrolladores, por lo que encontrar documentaci ´on concreta puede llegar a ser un problema.
2.2.2.
Firebase
Figura 2.3: Logotipo deFirebase. [20]
Firebasees un producto deGoogleenmarcado dentro de su divisi ´onGoogle Cloud, plataforma del Gigante de Internet que ofrece recursos inform ´aticos bajo demanda. Es utilizada para facilitar el desarrollo de aplicaciones
Web y m ´oviles, que posibilita la reducci ´on del tiempo que se dedica a desarrollar ´areas no espec´ıficas de la aplicaci ´on haciendo que el desarrollador pueda centrarse en aquello que la har ´a distinta. Fue creada en el a ˜no 2011 aunque en 2014 fue adquirida porGoogle.
Firebaseofrece un gran n ´umero de componentes ya desarrollados y listos para integrar, como las sesio-nes, las bases de datos, el alojamiento de archivos, las funciosesio-nes, las estad´ısticas, etc ´etera.
Los motivos por los que se ha escogidoFirebaseson los siguientes [36]:
desarro-Firebasetambi ´en tiene una serie de desventajas:
1. Dependencia de una plataforma espec´ıfica: Una vez se lanza una aplicaci ´on elaborada con Firebase es muy complicado cambiar de tecnolog´ıa, puesto que deberemos a ˜nadir los costes de desarrollo de todos aquellos componentes que utilicen la plataforma.
2. Interfaces: Las interfaces de acceso a datos de Firebase no son muy flexibles y en algunos casos no podremos consultar directamente la informaci ´on a la base de datos, sino que ser ´a necesario descargarla por completo para realizar las consultas en otra plataforma.
En cuanto a las bases de datos deFirebase, se ha de destacar que ofrece en su paquete dos de tipo no relacional,Firebase Firestore(basada en documentos) yFirebase Realtime(basada en pares clave-valor). Para este trabajo se ha elegido la primera por varios motivos:
1. Mayor complejidad en las consultas: Firestore ofrece operaciones b ´asicas de tipo WHERE. Igualmente, ofrece los operadoresORDER BY yLIMIT.
2. Mayor escalabilidad: En Realtime cuando se accede a una parte del ´arbol (clave-valor), el usuario debe descargarse todos los hijos. EnFirestore ´unicamente aquellos documentos que se deseen.
3. Mayor seguridad:Firestoreofrece mayores medidas de seguridad al tener reglas de lectura y escritura m ´as complejas y flexibles.
2.3.
Comunicaci ´
on con el servidor
La comunicaci ´on con el servidor es fundamental para el buen funcionamiento de la aplicaci ´on. En concreto, se deber ´a comunicar por los siguientes motivos:
Realizaci ´on de estad´ısticas: inicios y finalizaciones de una misi ´on (para comprobar el ´exito de las mismas), uso del usuario de la aplicaci ´on, etc ´etera.
Realizaci ´on de misiones: las misiones de consumo y de reto social requieren una conexi ´on a Internet para asegurarse de que el usuario haya completado el reto.
Descarga de nuevas misiones y niveles: uno de los requisitos del sistema inform ´atico en su conjunto es el de que el administrador pueda gestionar desde la parte Web los niveles y misiones, a ˜nadi ´endolas y modific ´andolas bajo demanda.
Manteninimiento de un ranking global.
Conexi ´on multidispositivo: se busca que el usuario pueda acceder a la aplicaci ´on desde distintos dispositi-vos, utilizando en todos ellos el sistema operativoAndroid.
Encontraremos dos tipos de conexiones:
Conexiones realizadas aFirebase: datos estad´ısticos, de sesiones, invitaciones, base de datos, etc ´etera.
Cap´ıtulo 3
Route66App
3.1.
Plan de Desarrollo del
Software
3.1.1.
Descripci ´
on del proyecto
La ludificaci ´on comenz ´o a popularizarse en 2010 [56], y desde entonces, tal y como he explicado en puntos anteriores de esta memoria, se ha aplicado en variados ´ambitos (educaci ´on, ventas, proveedores, etc ´etera). En el caso que nos ocupa, un restaurante de comida americana, no podemos encontrar en Espa ˜na ning ´un ejemplo con una aplicaci ´on similar.
Route66App es unaapppara dispositivos m ´oviles basado las ideas expuestas en el Trabajo Fin de Grado de una alumna del Grado en Ingenier´ıa en Organizaci ´on Industrial [55]. Esta aplicaci ´on emplea la Teor´ıaBartle[9] para identificar los diferentes tipos de jugadores y buscar ´a fidelizar y comprometer al usuario con los objetivos del negocio por medio del juego.
Es importante destacar que este trabajo abarca solo una parte del proyecto completo: la del cliente. Para su pleno funcionamiento se requerir ´a el gestor web, en el que se permitir ´an a ˜nadir y modificar las diferentes misiones que conforman el juego.
3.1.1.1. Prop ´osito, objetivos y alcance
El objetivo fundamental de este trabajo es el de la implementaci ´on de un sistema de ludificaci ´on, aplicado a un restaurante de comida americana. En concreto se ocupar ´a de la parte cliente, ejecutada desde terminales m ´oviles con el Sistema OperativoAndroid.
La aplicaci ´on deber ´a contar con las siguientes funciones:
Acciones propias del usuario.
• Realizar misiones y juegos, con el fin de conseguir puntos y aumentar el nivel o posici ´on en un ranking.
• Modificaci ´on del perfil del usuario, permitiendo actualizar el avatar del usuario.
Acciones a realizar en grupo.
• Cosulta de los equipos a los que pertenece el usuario.
• Creaci ´on de nuevos equipos.
Los objetivos ser ´an:
Elaborar un sistema de usuarios mediante el uso de sesiones.
Gestionar un sistema de insignias, premios y logros (asignables tanto a equipos como a usuarios individua-les).
Aumentar el compromiso del usuario con la aplicaci ´on, mediante el uso de juegos o misiones. Se busca que el usuario realice acciones correspondientes a los cuatro roles mencionados anteriormente.
Hacer las funciones de una tarjeta de fidelizaci ´on virtual, que permita al usuario identificarse a la hora de pagar.
3.1.2.
Metodolog´ıa de Desarrollo del proyecto
El proyecto aplicar ´a el Proceso Unificado (Unified Process), en concreto el proceso UPedu [44], cuyas caracter´ısticas b ´asicas [53] son:
Dirigido por los casos de uso.
Centrado en la arquitectura.
Iterativo e incremental.
La iteratividad supone ciertas ventajas, como la de poder mitigar los riesgos m ´as cr´ıticos en las fases m ´as tempranas o permitir obtenerfeedbackmucho antes, adem ´as de reaprovechar el aprendizaje obtenido en etapas posteriores.
3.1.3.
Restricciones
Se imponen las siguientes restricciones, extra´ıdas tras una serie de entrevistas con la tutora del trabajo:
1. Tiempo:Este proyecto se realiza para cumplir con los objetivos de la asignatura Trabajo de Fin de Grado. Menci ´on Ingenier´ıa delSoftware, correspondiente a 12 cr ´editos ECTS, unas 300 horas.
2. Plazo m´ınimo de entrega:Este proyecto se podr ´a entregar cuando haya terminado el resto de asignaturas de la Menci ´on. Por tanto, hasta que no termine y tenga calificada la ´unica asignatura que tendr ´e en el segundo cuatrimestre (Pr ´acticas en Empresa), no podr ´a ser entregado. Las pr ´acticas curriculares en la empresaTelef ´onica Investigaci ´on y Desarrolloconcluyen el d´ıa 10 de Abril de 2018.
3. Requisitos de la plataforma:La aplicaci ´on ser ´a instalable en terminalesAndroid cuya versi ´on deAPIsea igual o superior a la 19 (Android 4.4,KitKat). Seg ´un el sitioWeb oficial de desarrolladores deAndroid 1,
esto supone cubrir la ingente mayor´ıa de los dispositivos (un 92.5 %, a fecha 25 de Noviembre de 2017) [2].
4. Requisitos de software: Se impone que la aplicaci ´on se deba desarrollar en el lenguaje de programaci ´on
Kotlin. As´ı mismo, se ha recomendado el uso deFirebasecomo plataforma para alojar la base de datos y gestionar las sesiones.
5. Datos en el dispositivo: la aplicaci ´on deber ´a contar con una cach ´e de los datos en el dispositivo del cliente con el fin de reducir el n ´umero de peticiones que se hagan contraFirebase, as´ı como para acelerar el funcionamiento de la aplicaci ´on en lugares con una baja conectividad.
3.1.4.
Estructura organizativa
3.1.4.1. Estructura organizativa interna
La estructura organizativa del proyecto estar ´a formada por una ´unica persona, que deber ´a ejercer cada uno de los roles en el momento en el que sea necesario. [44]
Rol Encargado
Desarrollador Alvaro Carreras Regorigo´ Analista Alvaro Carreras Regorigo´ Gestor de proyecto Alvaro Carreras Regorigo´ Dise ˜nador Alvaro Carreras Regorigo´
Cuadro 3.1: Roles.
Desarrollador
Este rol se encarga de implementar el c ´odigo y de realizar las pruebas para los entregables software
generados, con el fin de que sean integrados.
Analista
Organiza y coordina tanto la elicitaci ´on de requisitos como el modelado de casos de uso, indicando y limitando la funcionalidad del sistema y el alcance del mismo.
Gestor de Proyecto
Realiza el control y mando del proyecto, asigna recursos, gestiona los riesgos, distribuye responsabilida-des, gestiona la interacci ´on con los clientes, etc ´etera.
Dise ˜nador
3.1.4.2. Estructura organizativa externa
Solo se identifica un rol en la estructura organizativa externa: el del usuario de la aplicaci ´on.
3.1.5.
Gesti ´
on del proyecto
3.1.5.1. Planificaci ´on del proyecto
En este proyecto se utilizar ´a la metodolog´ıa UPedu [44], compuesta por fases y estas por iteraciones.
Figura 3.1: Fases de la metodolog´ıa UPedu. [44]
En la figura 3.1, se puede observar el esfuerzo necesario de cada disciplina en cada fase del proyecto.
Fase de inicio
En esta fase no se realiza ning ´un entregable de tiposoftware, pues estos se deben tratar antes de comen-zar con la implementaci ´on. Los objetivos fundamentales de esta fase son la definici ´on del alcance del proyecto, la determinaci ´on de los casos de uso cr´ıticos, la estimaci ´on del coste y la duraci ´on del proyecto, y la elaboraci ´on de una primera gesti ´on de riesgos.
Fase de elaboraci ´on
El objetivo fundamental de esta fase [53] es el de la elaboraci ´on del dise ˜no y arquitectura del sistema inform ´atico. Al mismo tiempo, se realizar ´a un an ´alisis del dominio del sistema y se eliminar ´an los elementos de mayor riesgo para el desarrollo del proyecto.
Fase de construcci ´on
Es sin ninguna duda la parte m ´as larga del proyecto y la primera que tendr ´a como output entregables software utilizables. Se ir ´a iterando y mejorando la calidad del producto software en cada ciclo.
La salida de esta fase [53] es software en estado beta.
Fase de transici ´on
Se deber ´a conseguir la aceptaci ´on por parte del usuario, indicando que cumple con la visi ´on inicial del proyecto. De igual modo se distribuir ´a elsoftware.
3.1.5.2. Calendario del proyecto
Como se ha indicado en los apartados anteriores, este proyecto se ha dividido en las fases que el Proceso Unificado, en su variaci ´on UPedu [44] establece. A continuaci ´on, se lista cada fase, el n ´umero de iteraciones y las horas de trabajo y duraci ´on estimadas. Estos c ´alculos son orientativos, las variaciones sobre los mismos est ´an expuestas en el apartado correspondiente.
Nombre de la fase N ´um.. Iteraciones Horas de trabajo Duraci ´on estimada
Inicio 1 10 horas/semana 61 horas
Elaboraci ´on 2 20 horas/semana 80 horas
Construcci ´on 2 20 horas/semana 133 horas
Transici ´on 1 20 horas/semana 42 horas
Cuadro 3.2: Fases del proceso UPedu.
La duraci ´on estimada total es de 316 horas, a las que habr´ıa que a ˜nadir las necesarias para acudir a las tutor´ıas.
Fase de inicio
Figura 3.2: Diagrama de Gantt para la iteraci ´on 0 (fase de inicio).
Nombre de la tarea Fecha de comienzo Fecha de fin Duraci ´on
Estudio del sistema. 03/11/2017 05/11/2017 10 horas
B ´usqueda de informaci ´on. 10/11/2017 11/11/2017 4 horas
Resumen de la propuesta 11/11/2017 17/11/2017 6 horas
Estudio de aplicaciones m ´oviles. 17/11/2017 17/11/2017 2 horas Elaboraci ´on de un prototipo inicial 18/11/2017 19/11/2017 7 horas Estudio de la posible tecnolog´ıa a utilizar. 19/11/2017 19/11/2017 3 horas Plan de Desarrollo de Software. 24/11/2017 01/12/2017 13 horas
Elicitaci ´on de requisitos. 01/12/2017 08/12/2017 12 horas
Identificaci ´on de riesgos. 08/12/2017 09/12/2017 3 horas
Gesti ´on de configuraciones. 09/12/2017 10/12/2017 1 horas
Cuadro 3.3: Iteraci ´on 0. Fase de Inicio.
Reuniones realizadas con la tutora del T.F.G.:
30 de Octubre de 2017.
6 de Noviembre de 2017.
20 de Noviembre de 2017.
Fase de elaboraci ´on
Se ha decidido dejar un lapso temporal de 41 d´ıas (10 de Diciembre - 20 Enero) por la gran acumulaci ´on de trabajos y ex ´amenes.
Esta fase comienza el d´ıa 20 de Enero de 2017 y finaliza el 1 de Marzo de 2018. Consta de dos iteraciones.
Iteraci ´on 1: Con una duraci ´on de 3 semanas.
Iteraci ´on 2: Con una duraci ´on de 1 semana y media.
Figura 3.3: Diagrama de Gantt para la iteraci ´on 1 (fase de elaboraci ´on).
Nombre de la tarea Fecha de comienzo Fecha de fin Duraci ´on Revisi ´on de requisitos 20/01/2018 21/01/2018 5 horas Diagrama de casos de uso 22/01/2018 22/01/2018 1 hora Realizaci ´on de casos de uso 22/01/2018 25/01/2018 10 horas Diagramas de secuencia 26/01/2018 01/02/2018 20 horas
Modelo de Dominio 02/02/2018 03/02/2018 5 horas
Dise ˜no de la Base de Datos 02/02/2018 02/02/2018 3 horas Plan inicial de pruebas 03/02/2018 05/02/2018 5 horas Arquitectura del sistema 05/02/2018 10/02/2018 13 horas
Cuadro 3.4: Iteraci ´on 1. Fase de elaboraci ´on.
Figura 3.4: Diagrama de Gantt para la iteraci ´on 2 (fase de elaboraci ´on).
Nombre de la tarea Fecha de comienzo Fecha de fin Duraci ´on
Actualizaci ´on de casos de uso 11/02/2018 13/02/2018 5 horas
Actualizaci ´on de diagramas de secuencia 14/02/2018 15/02/2018 4 horas Actualizaci ´on del dise ˜no de la Base de Datos 16/02/2018 16/02/2018 2 horas Actualizaci ´on de Plan inicial de pruebas 17/02/2018 18/02/2018 2 horas Actualizaci ´on de la arquitectura del sistema 18/02/2018 20/02/2018 5 horas
Cuadro 3.5: Iteraci ´on 2. Fase de elaboraci ´on.
El d´ıa 20 de Febrero se hace entrega a la tutora de todos los entregables realizados hasta la fecha, con el fin de que puedan ser revisados y validados en profundidad.
Fase de construcci ´on
Comienza el d´ıa 1 de Marzo de 2018 y finaliza el 10 de Abril de 2018.
Figura 3.5: Diagrama de Gantt para la iteraci ´on 3 (fase de construcci ´on).
Nombre de la tarea Fecha de comienzo Fecha de fin Duraci ´on Implementaci ´on del sistema
20/02/2018 01/04/2018 116 horas
Realizaci ´on de casos de prueba
Cuadro 3.6: Iteraci ´on 3. Fase de construcci ´on.
Reuniones realizadas con la tutora del T.F.G.:
6 de Marzo de 2018.
20 de Marzo de 2018.
Figura 3.6: Diagrama de Gantt para la iteraci ´on 4 (fase de construcci ´on).
Nombre de la tarea Fecha de comienzo Fecha de fin Duraci ´on Implementaci ´on del sistema
02/04/2018 05/04/2018 7 horas
Realizaci ´on de casos de prueba
Elaboraci ´on del manual de usuario 05/04/2018 10/04/2018 10 horas
Cuadro 3.7: Iteraci ´on 4. Fase de construcci ´on.
Reuniones realizadas con la tutora del T.F.G.:
10 de Abril de 2018.
Fase de transici ´on
Comienza el d´ıa 10 de Abril de 2018 y finaliza el 30 de Abril de 2018.
3.1.6.
Relaci ´
on de entregables no software
Los distintos entregables, que se considerar ´an como definitivos en su ´ultima versi ´on, son los siguientes:
Fase de inicio
Plan de Desarrollo deSoftware.
Versi ´on inicial del Plan de Gesti ´on de Riesgos.
Fase de elaboraci ´on
Documento de requisitossoftware.
Versi ´on inicial de los Casos de Uso.
Diagramas de secuencia.
Arquitectura del sistema.
Dise ˜no de la Base de Datos.
Elaboraci ´on de prototipos.
Fase de construcci ´on
Versi ´on inicial del manual de usuario.
Documento de casos de prueba.
Documento de resultados de las pruebas.
Fase de transici ´on
Versi ´on final del manual de instalaci ´on.
Versi ´on final del manual de usuario.
3.1.7.
Control y seguimiento del proyecto
Se har ´a un control y seguimiento del proyecto en todo momento, utilizando la herramientaAsana 2, tal y
como se ha expuesto en el apartado “Herramientas utilizadas“.
El control y seguimiento del proyecto resulta ser una tarea fundamental para asegurar el buen progreso del proyecto y asegurar el cumplimiento de los objetivos marcados, en especial en cuanto a la realizaci ´on de los hitos establecidos, ya que el gestor del proyecto podr ´a observar las distintas variaciones de tiempo programadas versus reales, para as´ı poder reaccionar y tomar las medidas que sean precisas para ajustarse al cronograma del proyecto.
2
3.1.8.
Gesti ´
on de riesgos
Se identifican los siguientes riesgos:
R0 Falta de experiencia del alumno
Descripci ´on El alumno ha realizado pr ´acticas enAndroid, pero puede encontrarse en mo-mentos en los que requiera experiencia adicional.
Consecuencia Ralentizaci ´on del trabajo.
Probabilidad Media.
Impacto Bajo.
Estrategia Reservar el riesgo.
Plan de acci ´on Buscar informaci ´on y ayuda, ya sea preguntando a la tutora del trabajo o utili-zando otros medios.
Plan de contingencia Revisi ´on de conocimientos existentes.
R1 Retraso en la planificaci ´on
Descripci ´on Debido a errores en la estimaci ´on, la planificaci ´on no se ajusta a la realidad y se producen demoras en las fechas de entrega.
Consecuencia Retraso en la entrega de los entregables.
Probabilidad Alta.
Impacto Cr´ıtico.
Estrategia Reservar el riesgo.
Plan de acci ´on Realizar una nueva planificaci ´on m ´as realista.
Plan de contingencia Realizar revisiones peri ´odicas del calendario de planificaci ´on.
R2 Adelantos en la planificaci ´on
Descripci ´on Debido a errores en la estimaci ´on, la planificaci ´on no se ajusta a la realidad y se producen adelantos en las fechas de entrega.
Consecuencia Modificaci ´on de toda la planificaci ´on.
Probabilidad Alta.
Impacto Cr´ıtico.
Estrategia Reservar el riesgo.
Plan de acci ´on Realizar una nueva planificaci ´on m ´as realista.
Plan de contingencia Realizar revisiones peri ´odicas del calendario de planificaci ´on.
R3 Falta de experiencia en grandes proyectos
Descripci ´on El equipo no cuenta con experiencia propia de proyectos de gran extensi ´on que le permita calcular mejor las estimaciones, as´ı como realizar el proyecto con mayor celeridad.
Consecuencia Peor organizaci ´on y estimaciones. Grandes picos de trabajo.
R4 Falta de disponibilidad
Descripci ´on El alumno no puede continuar con el trabajo por falta de disponibilidad.
Consecuencia Depender ´a del tiempo en el que est ´e no disponible y las holguras en la planifi-caci ´on. Si es muy largo, puede suponer la no entrega del trabajo a tiempo.
Probabilidad Baja.
Impacto Cr´ıtico.
Estrategia Reservar del riesgo.
Plan de acci ´on Realizar una nueva planificaci ´on bas ´andose en las nuevas fechas de disponibi-lidad.
Plan de contingencia Monitorizar la disponibilidad del alumno.
R5 P ´erdida de datos
Descripci ´on Por cualquier motivo, se pierde total o parcialmente cualquiera de los entrega-bles ya realizados o en proceso de realizaci ´on.
Consecuencia Ralentizaci ´on muy alta del trabajo. Repetici ´on de los entregables perdidos.
Probabilidad Bajo.
Impacto Cr´ıtico.
Estrategia Evitaci ´on del riesgo. Plan de acci ´on No se aplica.
Plan de contingencia Realizaci ´on de copias de seguridad y uso de un sistema de control de versiones (ver apartado gesti ´on de configuraciones).
R6 Falta de medios software de desarrollo
Descripci ´on Las herramientas designadas para desarrollar el proyecto fallan, desaparecen o dejan de estar disponibles.
Consecuencia Ralentizaci ´on muy alta del trabajo. Repetici ´on de los entregables perdidos.
Probabilidad Bajo.
Impacto Cr´ıtico.
Estrategia Evitaci ´on del riesgo. Plan de acci ´on No se aplica.
Plan de contingencia Utilizaci ´on de herramientas profesionales, aplicaci ´on de las ´ultimas actualiza-ciones.
R7 Falta de medios hardware de desarrollo
Descripci ´on Las herramientas designadas para desarrollar el proyecto fallan o dejan de es-tar disponibles.
Consecuencia Adquisici ´on de nuevos materiales.
Probabilidad Bajo.
Impacto Alto.
Estrategia Evitaci ´on del riesgo. Plan de acci ´on No se aplica.
R8 Dise ˜no pobre o incorrecto
Descripci ´on El dise ˜no realizado del sistema es pobre o incorrecto. Consecuencia Ralentizaci ´on del trabajo.
Probabilidad Medio.
Impacto Cr´ıtico.
Estrategia Reducci ´on del riesgo.
Plan de acci ´on Redise ˜nar la arquitectura del sistema.
Plan de contingencia Realizar revisiones con el cliente y realizar pruebas sobre el modelo dise ˜nado.
3.1.9.
Gesti ´
on de configuraciones
Hoy en d´ıa la mayor´ıa de los servicios p ´ublicos que ofrecen alojamiento de repositorios Git, permiten realizar una buena gesti ´on de configuraciones. Esto es debido a que cada cambio que se hace sobre el c ´odigo fuente (commit) viene asociado a informaciones sobre qu ´e se ha cambiado, qui ´en lo ha cambiado, cu ´ando lo ha cambiado, etc ´etera. Adem ´as, las ramas obranches, aquellos lugares donde van dirigidos los cambios, permiten imponer bloqueos sobre escritura a ciertos usuarios, con el fin de proteger los entregables que estuvieran en la misma.
Por otro lado, estos servicios tambi ´en pueden ser utilizados para la gesti ´on dereleases. Esto se puede llevar a cabo mediante la creaci ´on de una rama espec´ıfica para ese prop ´osito o, directamente, y si se permite, mediante el apartado correspondiente desde el sitio web.
En el caso de este proyecto se han utilizado dos repositorios privados enGitHub3, en uno de ellos se tratar ´a el desarrollo de esta memoria y en otro, el del c ´odigo del sistema inform ´atico que se desea construir.
3.1.10.
Estimaci ´
on de los costes
Para una correcta estimaci ´on de los costes, se debe procurar partir de los datos proporcionados por pro-yectos reales, que nos permitan realizarla partiendo de una experiencia. Desafortunadamente, como estos no se hacen p ´ublicos (pues son parte de la estrategia de la empresa), no es posible contar con ellos. Por este motivo, los c ´alculos se han realizado bas ´andose en lo estudiado en la asignatura Planificaci ´on y Gesti ´on de Proyectos [52] y en informaci ´on encontrada por Internet.
El resultado de la estimaci ´on total de costes es de10.094,96e, que se detallar ´an a continuaci ´on.
3.1.10.1. Costeshardwareysoftware
Costeshardware
Dispositivo Coste de compra Horas dispositivo Horas utilizadas Coste total
Tel ´efonoAndroid 120e 17.520 horas (2 a ˜nos, 24 horas diarias) 133 0,92e Port ´atil 399e 11.680 horas (4 a ˜nos, 8 horas diarias) 300 horas 10,25e
Servicio Coste mensual Coste total
GitHub Developer 5,90e 47,20e
Firebase 21e 168e
Astah Professional 7,50e 60e
Cuadro 3.10: Costes de los recursossoftware.
Coste total de software:240,80e.
Los datos anteriores se han calculado bas ´andose en los datos p ´ublicos de las herramientas, convertiendo los importes a euros seg ´un la tasa de cambio del 28 de Noviembre de 2017, para un per´ıodo de 7 meses (Noviembre-Mayo).
El resto desoftwareutilizado (sistema operativo,IDE, etc ´etera) es de licencia gratuita. No se ha empleado software cuya licencia solo fuera gratuita en casos de uso no comercial del mismo.
Coste total de este apartado:251,96e.
3.1.10.2. Costes de dietas, viajes y aprendizajes
Los costes de dietas y de aprendizaje no se aplican en este apartado porque, en primer lugar, no se har ´a ninguna dieta externa y, en segundo lugar, se aplicar ´an los conocimientos adquiridos a lo largo del Grado, as´ı como otros externos que se han adquirido fuera del tiempo de asignaci ´on del proyecto.
En cuanto a los viajes, aquellos que ser´ıan precisos realizar para poder reunirse con la persona que ha encargado el proyecto (la tutora del mismo) van desde mi residencia habitual que est ´a en Laguna de Duero hasta el Campus Miguel Delibes. Utilizado la herramienta de mapasV´ıa Michel´ın4 y un coche urbano de di ´esel, los
costes de viajes y transportes son:
Kil ´ometros recorridos por viaje:33 (16,5 por trayecto).
Coste por viaje:3e (1,50e por trayecto).
Viajes realizados:15.
Coste total viajes:45e.
Por tanto, el coste total de este apartado es:45e.
3.1.10.3. Coste del esfuerzo (recursos humanos y seguros sociales)
Para el caso de los primeros, los costes de los recursos humanos, debemos ver el listado de roles que se van a practicar a lo largo del proyecto:
Rol Salario medio e/Hora Horas estimadas Coste total
Analista 42.987e 22e
300 horas 6.600e
Desarrollador 42.987e 22e
Gestor de proyecto 42.987e 22e
Dise ˜nador 42.987e 22e
Director de proyecto 42.987e 22e
Cuadro 3.11: Costes de los recursos humanos.
Los datos de la tabla anterior han sido calculados bas ´andose en los datos del Informe AnualInfojobs2016 Espa ˜na [25] (salario promedio bruto anual de un arquitecto de proyectos inform ´atico). Se ha dividido la cantidad anterior en doce pagas y veinte d´ıas de trabajo por mes.
Igualmente, habr´ıa que considerar el coste de los seguros sociales. Como la estimaci ´on del proyecto se ha realizado teniendo un ´unico empleado en r ´egimen de aut ´onomo, solo se aplicar´ıa el coste de las cuotas que establece el R ´egimen Especial de Aut ´onomos, que en 2018 es de 50eal mes para nuevos aut ´onomos menores de 30 a ˜nos [24].
Cuota mensual aut ´onomos.
• Importe mensual:50e.
• N ´umero de cuotas (meses): 7.
• Importe total: 350e.
El coste total de este apartado es de6.950e.
3.1.10.4. Costes indirectos aplicados al personal del proyecto
Los costes indirectos son aquellos derivados del uso de calefacci ´on, electricidad, comunicaciones, etc ´etera.
Alquiler: se utilizar ´a el servicio de vivero de empresas que propone el Parque Cient´ıfico de la Universidad de Valladolid [45] para una sala de 23m2. Este tipo de alquileres ya incluye los gastos de calefacci ´on y de
electricidad.
• Coste estimado (mensual): 276e.
• N ´umero de meses:7.
• Coste total:1.932e.
Conexi ´on a Internet y llamadas(Movistar Fibra ´optica 300 MB).
• Coste estimado (mensual):45eal mes + 19.99e al mes por la cuota de l´ınea. Total: 65e al mes.
• N ´umero de meses:7.
• Coste total:455e.
Telefon´ıa m ´ovil(Simyo 4GB + llamadas ilimitadas).
• Coste estimado (mensual):18e al mes.
• N ´umero de meses:7.
• Coste total:126e.
3.1.11.
Desviaciones sobre el calendario planificado
Se adjunta a continuaci ´on la tabla de estimaciones de planificaci ´on, as´ı como los retrasos que ha habido en realidad.
Iteraci ´on Etapa Fecha de inicio real Fecha inicio estimada Fecha de fin real Fecha fin estimada Diferencia finalizaci ´on 0 Inicio 03/11/2017 06/11/2017 12/12/2017 10/12/2017 2 d´ıas
1 Elaboraci ´on 20/01/2018 20/01/2018 15/02/2018 10/02/2018 5 d´ıas 2 Elaboraci ´on 16/02/2018 11/02/2018 23/02/2018 20/02/2018 3 d´ıas 3 Construcci ´on 24/02/2018 20/02/2018 03/04/2018 01/04/2018 2 d´ıas 4 Construcci ´on 04/04/2018 02/04/2018 12/04/2018 10/04/2018 2 d´ıas 5 Transici ´on 13/04/2018 11/04/2018 24/04/2018 25/04/2018 1 d´ıa
Cuadro 3.12: Desviaciones sobre el calendario planificado.
Tras un an ´alisis de los retrasos sobre la planificaci ´on establecida se extraen las siguientes conclusiones:
La planificaci ´on ha estado bastante ajustada a las estimaciones realizadas, encontr ´andose una mayor des-viaci ´on en la iteraci ´on 1, correspondiente a la fase de elaboraci ´on. El motivo fue que se tuvo que compaginar el comienzo de las pr ´acticas (y formaci ´on adicional) junto con el T.F.G., por lo que durante esos d´ıas no se pudo contar con el n ´umero de horas especificadas.
En la segunda fase de elaboraci ´on, el retraso de tres d´ıas se debe a unos redise ˜nos en el modelo de dominio y de la base de datos para ajustarse m ´as al problema concreto.
En la primera fase de construcci ´on, hubo dos d´ıas en los que no se pudo trabajar porque se decidi ´o ampliar la memoria del ordenador y sustituir el disco duro por uno de estado s ´olido (SSD) con el fin de aumentar la productividad en esta fase. En esos d´ıas me dediqu ´e a instalar esos dos componentes, as´ı como los elementossoftwarerequeridos para la continuaci ´on del trabajo.
En la segunda fase de construcci ´on, el retraso de dos d´ıas se debe al tiempo que se dedic ´o a redactar la memoria de las Pr ´acticas en Empresa. Fue un retraso que no se cont ´o en la planificaci ´on inicial.
3.2.
An ´alisis
3.2.1.
Requisitos
3.2.1.1. Requisitos funcionales Relacionados con los usuarios
RF0 Inicio de sesi ´on
Descripci ´on El sistema permitir ´a iniciar sesi ´on.
RF1 Cierre de sesi ´on
Descripci ´on El sistema permitir ´a cerrar sesi ´on.
RF2 Registro e inicio de sesi ´on r ´apido
Descripci ´on El sistema permitir ´a iniciar sesi ´on y registrarse mediante el uso de proveedores de acceso.
RF3 Registro de usuarios
RF4 Configuraci ´on del usuario
Descripci ´on El sistema permitir ´a editar la configuraci ´on del usuario.
RF5 Visualizaci ´on de la configuraci ´on del usuario
Descripci ´on El sistema permitir ´a visualizar la configuraci ´on actual del usuario.
RF6 Cambio de contrase ˜na
Descripci ´on El sistema permitir ´a cambiar la contrase ˜na actual del usuario.
RF7 Ranking de usuarios
Descripci ´on El sistema permitir ´a ver el ranking global de usuarios.
RF8 Invitaci ´on de usuarios a la aplicaci ´on
Descripci ´on El sistema permitir ´a invitar a usuarios a la aplicaci ´on.
RF9 Avatares
Descripci ´on El sistema permitir ´a a ˜nadir una fotograf´ıa de perfil (avatar) al usuario.
RF10 Avatares II
Descripci ´on El sistema permitir ´a visualizar la fotograf´ıa de perfil de otros usuarios de la plataforma.
RF11 Logros
Descripci ´on El sistema permitir ´a consultar los logros de un usuario.
RF12 Insignias
Descripci ´on El sistema permitir ´a consultar las insignias que tiene un usuario.
RF13 Premios
Descripci ´on El sistema permitir ´a consultar los premios que tiene un usuario.
RF14 C ´odigoQR
Descripci ´on El sistema permitir ´a mostrar el c ´odigoQR asociado a una misi ´on de tipo con-sumo.
RF15 Progreso del usuario
Descripci ´on El sistema permitir ´a mostrar los c´ırculos de progreso relativos a cada usuario.
RF16 Identificaci ´on de usuarios
Descripci ´on El sistema permitir ´a identificar usuarios por correo electr ´onico.
RF17 Concesi ´on de premios
Relacionados con los grupos RF19 Creaci ´on de un grupo
Descripci ´on El sistema permitir ´a crear un grupo.
RF20 Eliminaci ´on de un grupo
Descripci ´on El sistema permitir ´a eliminar un grupo.
RF21 Unirse a un grupo
Descripci ´on El sistema permitir ´a unirse a un grupo.
RF22 Salirse de un grupo
Descripci ´on El sistema permitir ´a salirse de un grupo.
RF23 Expulsi ´on de un grupo
Descripci ´on El sistema permitir ´a expulsar a un usuario de un grupo.
RF24 Invitaci ´on de usuarios a un grupo
Descripci ´on El sistema permitir ´a invitar a un usuario a un grupo.
RF25 Detalles de los grupos
Descripci ´on El sistema permitir ´a ver los detalles de los grupos a los que pertenece el usua-rio.
RF26 Avatares en los grupos
Descripci ´on El sistema permitir ´a a ˜nadir una fotograf´ıa de perfil (avatar) al grupo
RF27 Listado de los miembros del equipo
Descripci ´on El sistema permitir ´a mostrar el listado de usuarios miembros del grupo.
RF28 Ascenso en un grupo
Descripci ´on El sistema permitir ´a ascender a un usuario al rol administrador.
RF29 Logros de equipo
Descripci ´on El sistema permitir ´a asignar logros a un equipo.
RF30 Premios de equipo
Descripci ´on El sistema permitir ´a conceder premios a un equipo.
Relacionados con el ranking
RF31 Puntuaci ´on del usuario a nivel global
Descripci ´on El sistema mostrar ´a la puntuaci ´on del usuario en el juego.
RF32 Ranking global
Relacionados con las misiones
RF33 Misiones
Descripci ´on El sistema mostrar ´a al usuario qu ´e acci ´on debe realizar para considerar la mi-si ´on como finalizada.
RF34 Misiones de tipo juego
Descripci ´on El sistema permitir ´a mostrar un juego para que el usuario pueda completar una misi ´on de tipo juego (competitiva).
RF35 Misiones de tipo social
Descripci ´on El sistema permitir ´a mostrar la informaci ´on necesaria para completar una mi-si ´on de tipo social.
RF36 Misiones de tipo consumo
Descripci ´on El sistema comprobar ´a el gasto que haga el usuario en los restaurantes de la cadena, con el fin de comprobar si una misi ´on de tipo gasto ha sido completada.
RF37 Consumo restante en misiones de tipo consumo
Descripci ´on El sistema permitir ´a mostrar el consumo que ya ha realizado el usuario en una determinada misi ´on de tipo consumo.
Otros aspectos
RF38 Notificaciones
Descripci ´on El sistema emitir ´a notificaciones.
RF39 Misiones
Descripci ´on El sistema permitir ´a cumplir o realizar misiones.
RF40 Tratamiento de los errores de la aplicaci ´on
Descripci ´on El sistema monitorizar ´a los errores de aplicaci ´on de los usuarios.
RF41 Estad´ısticas
Requisitos funcionales de informaci ´on
RF42 Usuario
Descripci ´on El sistema almacenar ´a, para cada jugador, la siguiente informaci ´on:
Nombre p ´ublico.
Correo electr ´onico.
Sexo.
Contrase ˜na.
Avatar.
Misiones cumplidas.
Logros del jugador.
Insignias recibidas.
Premios obtenidos.
Consumos realizados.
Puntuaciones: puntuaci ´on glo-bal, puntuaci ´on social, puntua-ci ´on competitiva y puntuapuntua-ci ´on de consumo.
RF43 Insignia
Descripci ´on El sistema almacenar ´a, para cada insignia, la siguiente informaci ´on:
Tipo de insignia.
RF44 Logro de usuario
Descripci ´on El sistema almacenar ´a, para cada logro de usuario, la siguiente informaci ´on:
Tipo de logro.
Fecha y hora del logro.
Consumo realizado (en caso de estar relacionado con una misi ´on de tipo consumo).
Misi ´on (en caso de estar relacionado con una misi ´on).
Puntos.
RF45 Premio
Descripci ´on El sistema almacenar ´a, para cada premio (tanto de usuario como de equipo), la siguiente informaci ´on:
Tipo de premio (o premio en concreto asignado).
Fecha y hora de comienzo de la validez del premio.
