Cribi: aplicación Android para la gestión de eventos deportivos

Universidad de Valladolid Escuela de Ingenier´ ıa Inform´ atica Trabajo Fin de Grado Grado en Ingenier´ıa Inform´atica (Menci´ on Tecnolog´ ıas de la Informaci´ on) Cribi: Aplicaci´on Android para la gesti´on de eventos deportivos. Autor: D. Abel Garc´ıa de Prada Tutor: D. Joaqu´ın Adiego Rodr´ıguez Resumen Es innegable el auge de los dispositivos m´oviles y las facilidades que aportan en nuestra vida. La gran evoluci´on que han tenido estos terminales nos permite realizar pr´acticamente cualquier tarea desde nuestro ’Smartphone’ de una manera simple, r´apida y eficaz. Adem´as, la sociedad cada vez tiene una vida m´as sedentaria debido a las rutinas tan marcadas y la especializaci´on de los trabajos. Es por ello que surge la necesidad de unir ambos mundos y utilizar el dispositivo m´ovil para facilitarnos la pr´actica de deporte. Actualmente, si navegamos por las tiendas de aplicaciones, podemos encontrar infinidad de apps que nos permiten mantener un tracking de nuestros entrenamientos individuales y en gimnasios. Pero no podemos encontrar apenas aplicaciones que nos faciliten la pr´actica de deportes colectivos, que tan importantes son para nuestra salud f´ısica y mental. Debido a esto, surge la idea de facilitar el acceso a estos deportes, puesto que normalmente se practican con un grupo de gente conocida y limitada, en la que si alguna persona no est´a disponible el partido no se puede disputar. Cribi nace para solucionar estos problemas, ofreciendo una soluci´on multideporte y en tiempo real que permite a los clubs ofrecer sus instalaciones libres para la pr´actica de partidos y a los jugadores unirse y conocer a otras personas que compartan su afici´on por el deporte. Abstract It is undeniable the rise of mobile devices and the facilities they bring to our lives. These terminals have evolved so much, that allow us to do almost any task from our ’Smartphone’ in a simple, fast and efficient way. In addition, sedentary lifestyles appear to be increasingly widespread due to the marked routines and specialization of jobs. This is why the need arises to use the mobile device to facilitate the practice of sport. Nowadays, if we browse the app stores, we can find countless apps that allow us to keep a tracking of our workouts. But we can hardly find applications that facilitate the practice of collective sports, which are so important for our physical and mental health. Because of this, the idea arises to facilitate access to these sports, since they are usually practiced with a group of friends and if someone is not available, the match can not be played. Cribi was born to solve these problems, offering a multisport, realtime solution that allows clubs to offer their free fields for the practice of matches and players to join and meet other people who share their passion for sport. ´ Indice general 1. Introducci´on 1 1.1. Contextoymotivaci´on.................................... 1 1.2. Objetivos ........................................... 1 1.3. Metodolog´ıautilizada .................................... 2 1.4. Resumen del contenido de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Entorno tecnol´ogico 3 2.1. Herramientas y tecnolog´ıas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. AndroidStudio.................................... 3 2.1.2. Github......................................... 3 2.1.3. Overleaf........................................ 3 2.1.4. Firebase........................................ 4 2.1.5. AndroidImageCropper ............................... 5 2.1.6. Glide ......................................... 5 2.2. Entornodedesarrollo .................................... 6 3. Plan de Desarrollo de Software 7 3.1. Introducci´on.......................................... 7 3.1.1. Prop´osito ....................................... 7 3.1.2. Alcance ........................................ 7 3.2. Visi´on general del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Objetivos ....................................... 8 3.2.2. Suposiciones y/o restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.3. Caracter´ısticas del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.4. Elecci´on de la metodolog´ıa de desarrollo de software . . . . . . . . . . . . . . . 9 3.2.5. Entregables del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Organizaci´on del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. Rolesdelproyecto .................................. 10 3.3.2. Reuniones, eventos y planes operativos . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Estimaciones del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.1. Estimaci´ontemporal................................. 10 3.4.2. Estimaci´ondecostes................................. 11 3.4.3. Desviaci´on real del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Seguimiento del proyecto 12 4.1. Introducci´on.......................................... 12 4.2. Sprint 1: 4 de Febrero - 24 de Febrero . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.1. US01 - Como Equipo quiero tener configurado el entorno de trabajo completo para poder empezar a trabajar en el proyecto . . . . . . . . . . . . . . . . . . . 13 4.2.2. US23 - Como Product Owner quiero tener una documentaci´on inicial del proyecto para tener una visi´on global del mismo . . . . . . . . . . . . . . . . . . . 14 4.2.3. US02 - Como usuario Jugador quiero poder registrarme en la aplicaci´on mediante emailycontrase˜na. ................................. 14 4.2.4. US03 - Como usuario Jugador quiero poder identificarme de forma ´unica en la aplicaci´on de jugadores con mis credenciales. . . . . . . . . . . . . . . . . . . . 14 4.2.5. US04 - Como usuario Club quiero poder identificarme de forma ´unica en la aplicaci´on de Clubes con mis credenciales. . . . . . . . . . . . . . . . . . . . . . 15 4.2.6. US24 - Como Product Owner quiero tener un modelo de dominio inicial de ambas aplicaciones a desarrollar. . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Sprint 2: 25 de Febrero - 17 de Marzo . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3.1. US05 - Como usuario Jugador quiero poder crear y editar mi perfil. . . . . . . 16 4.3.2. US06 - Como usuario Jugador quiero poder a˜nadir una imagen de perfil. . . . . 16 4.3.3. US07 - Como usuario Club quiero poder crear y editar mi perfil. . . . . . . . . 17 4.3.4. US08 - Como usuario Club quiero poder a˜nadir el logo de mi club a mi perfil. . 17 4.4. Sprint 3: 18 de Marzo - 7 de Abril . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.4.1. US09 - Como usuario Jugador quiero poder visualizar mi perfil de usuario. . . 18 4.4.2. US10 - Como usuario Jugador quiero poder cerrar mi sesi´on. . . . . . . . . . . 18 4.4.3. US11 - Como usuario Club quiero poder visualizar mi perfil de club. . . . . . . 18 4.4.4. US12 - Como usuario Club quiero poder cerrar mi sesi´on. . . . . . . . . . . . . 19 4.4.5. US25 - Como Product Owner quiero tener una primera versi´on de la arquitectura ydise˜nodelproyecto. ................................ 19 4.5. Sprint 4: 8 de Abril - 28 de Abril . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.5.1. US13 - Como usuario Club quiero poder crear nuevos partidos para que los jugadores puedan visualizar y acceder a ellos. . . . . . . . . . . . . . . . . . . . 20 4.5.2. US14 - Como usuario Jugador quiero poder ver un listado de los partidos disponiblesparaunirme. ................................ 20 4.5.3. US15 - Como usuario Club quiero poder ver un listado completo de todos los partidos que he creado para tener un seguimiento en tiempo real. . . . . . . . . 20 4.6. Sprint 5: 29 de Abril - 19 de Mayo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.6.1. US16 - Como usuario quiero consultar la informaci´on completa de un partido. . 21 4.6.2. US17 - Como usuario quiero consultar el listado de jugadores que se han inscrito aunpartido. ..................................... 21 4.6.3. US18 - Como usuario Jugador quiero consultar el perfil del club que ha organizadoelpartido..................................... 22 4.7. Sprint 6: 20 de Mayo - 9 de Junio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.7.1. US19 - Como usuario Jugador quiero filtrar la lista de partidos seg´un diferentes par´ametros. ..................................... 22 4.7.2. US20 - Como usuario Club quiero filtrar la lista de mis partidos seg´un el estado delosmismos. .................................... 23 4.7.3. US21 - Como usuario Jugador quiero poder unirme y abandonar un partido. . 23 4.7.4. US22 - Como usuario Club quiero poder actualizar el estado de un partido. . . 24 4.8. Sprint 7: 10 de Junio - 23 de Junio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.8.1. US26 - Como Product Owner quiero disponer del Plan de Desarrollo de Software finalysuseguimiento................................. 24 4.8.2. US27 - Como Product Owner quiero disponer de la memoria completa del proyecto. 24 5. Plan de Gesti´on de Riesgos 26 5.1. Introducci´on.......................................... 26 5.1.1. Gesti´ondelriesgo .................................. 26 5.1.2. Controlderiesgos .................................. 28 6. Requisitos 29 6.1. Los requisitos en el desarrollo ´agil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.2. Requisitosfuncionales .................................... 29 6.3. Requisitosnofuncionales .................................. 30 6.4. Requisitos de informaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7. An´alisis 32 7.1. ModelodeCasosdeUso................................... 32 7.1.1. Actores ........................................ 32 7.1.2. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.1.3. Especificaci´on de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.1.4. ModelodeDominio ................................. 40 7.1.5. Descripci´on de las clases del modelo de dominio . . . . . . . . . . . . . . . . . . 41 7.1.6. Diagramas de actividad Cribi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 7.1.7. Diagramas de actividad Cribi Clubs . . . . . . . . . . . . . . . . . . . . . . . . 53 8. Dise˜no 58 8.1. Dise˜nodelaarquitectura .................................. 58 8.1.1. Patr´on arquitect´onico MVVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 8.1.2. Arquitecturageneral................................. 59 8.1.3. Estructura del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 8.1.4. Interacci´on entre componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 8.2. Dise˜no de la base de datos no relacional . . . . . . . . . . . . . . . . . . . . . . . . . . 62 9. Pruebas 63 9.1. Introducci´on.......................................... 63 9.2. Casosdeprueba ....................................... 63 9.2.1. Aplicaci´on para jugadores Cribi . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 9.2.2. Aplicaci´on para organizadores Cribi Clubs . . . . . . . . . . . . . . . . . . . . . 67 10.Conclusiones 69 10.1.Valoraci´onpersonal...................................... 69 10.2.L´ıneasfuturas......................................... 69 11.Bibliograf´ıa 70 A. Manual de usuario 72 A.1.Introducci´on.......................................... 72 A.2. Cribi - Aplicaci´on para los jugadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 A.2.1. Identificaci´on de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 A.2.2. Registro de nuevos usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 A.2.3.P´aginaprincipal ................................... 74 A.2.4.Home ......................................... 74 A.2.5.Filtrarpartidos.................................... 75 A.2.6. Ver informaci´on completa del partido . . . . . . . . . . . . . . . . . . . . . . . 76 A.2.7. Ver listado de jugadores inscritos . . . . . . . . . . . . . . . . . . . . . . . . . . 77 A.2.8. Ver perfil de club organizador . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 A.2.9.Unirseapartido ................................... 79 A.2.10.Abandonarpartido.................................. 80 A.2.11.Perfildeusuario ................................... 81 A.2.12.Editar perfil de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 A.2.13.Cerrarsesi´on ..................................... 82 A.2.14.Listado de partidos inscritos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 A.3. Cribi Clubs - Aplicaci´on para Organizadores . . . . . . . . . . . . . . . . . . . . . . . . 83 A.3.1. Identificaci´on de Clubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 A.3.2. P´agina principal Cribi Clubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 A.3.3. Ver informaci´on del partido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 A.3.4. Cambiar estado del partido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 A.3.5.Crearnuevopartido ................................. 85 A.3.6.Ajustes ........................................ 86 A.3.7.EditarPerfil ..................................... 87 B. Manual de instalaci´on 88 C. Contenido del soporte digital 89 ´ Indice de figuras 2.1. LogotipodeAndroidStudio................................. 3 2.2. LogotipodeFirebase..................................... 4 2.3. Jerarqu´ıadeFirestore .................................... 5 2.4. LogotipodeGlide ...................................... 6 4.1. FlujodetrabajodeScrum.................................. 12 7.1. Diagrama de casos de uso actor Jugador . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.2. Diagrama de casos de uso actor Organizador . . . . . . . . . . . . . . . . . . . . . . . 33 7.3. Modelo de dominio de la aplicaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 7.4. Diagrama de actividad CU01. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 7.5. Diagrama de actividad CU02. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.6. Diagrama de actividad CU03. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 7.7. Diagrama de actividad CU04. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 7.8. Diagrama de actividad CU05. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 7.9. Diagrama de actividad CU06. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 7.10. Diagrama de actividad CU07. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 7.11. Diagrama de actividad CU08. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 7.12. Diagrama de actividad CU09. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 7.13. Diagrama de actividad CU10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 7.14. Diagrama de actividad CU11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 7.15. Diagrama de actividad CU12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 7.16. Diagrama de actividad CU16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 7.17. Diagrama de actividad CU17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 7.18. Diagrama de actividad CU20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 7.19. Diagrama de actividad CU21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 8.1. ArquitecturaMVVM..................................... 58 8.2. Arquitectura MVVM en conjunto con Firestore . . . . . . . . . . . . . . . . . . . . . . 59 8.3. Paquetes aplicaci´on Cribi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 8.4. Paquetes aplicaci´on Cribi Clubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 8.5. Interacci´on componentes Club. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 8.6. Interacci´on componentes Match. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 A.1.P´aginadeidentificaci´on.................................... 72 A.2.Falloenidentificaci´on..................................... 72 A.3. P´agina de registro de usuarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 A.4. Registrando nuevo usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 A.5.Falloalregistrarse....................................... 73 A.6. Configurar perfil de usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 A.7.P´aginaprincipal. ....................................... 74 A.8.Men´udenavegaci´on...................................... 74 A.9.Listadodepartidos. ..................................... 75 A.10.Filtrarpartidos......................................... 75 A.11.Modal de selecci´on de filtros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 2.1.4. Firebase Firebase[5] es una plataforma que permite a los desarrolladores crear aplicaciones relativamente f´acil y sencillo. Ofrece una gran variedad de servicios ya construidos y preparados para utilizar, as´ı como herramientas para determinar la experiencia de los usuarios en la aplicaci´on. Figura 2.2: Logotipo de Firebase Es parte de la creciente tendencia conocida como ”Back end como un servicio”. No es necesario crear y configurar un servidor. No se necesita comprobar si ha habido cambios en el servidor cada vez. No es indispensable crear una API para recuperar los datos. B´asicamente Firebase libera a los desarrolladores de la gesti´on del backend y permite centrar el esfuerzo en la experiencia de usuario. Razones por las que se eligi´o Firebase para el desarrollo del proyecto: Firebase ofrece, como se ver´a posteriormente, la posibilidad de a˜nadir un mecanismo de autenticaci´on en la aplicaci´on para un acceso seguro a la misma. Firebase facilita un backend en tiempo real para la aplicaci´on de f´acil integraci´on que permite centrar los esfuerzos en el desarrollo de la misma. Firebase ofrece almacenamiento en la nube para poder almacenar cierta cantidad de archivos dependiendo sus planes. Firebase proporciona estad´ısticas en tiempo real de los usuarios en la aplicaci´on y de c´omo es su experiencia en la app. Firebase Authentication Como la mayor´ıa de aplicaciones, Cribi tambi´en necesita la identificaci´on de usuarios para proporcionar una experiencia de usuario ´optima. Para ello, se ha utilizado Firebase Authentication [6]. Esta funcionalidad de Firebase permite registrar y autenticar a los usuarios de forma segura, adem´as de integrarla con otras funcionalidades de la plataforma. Firebase Firestore Para el almacenamiento de datos, Firebase ofrece dos opciones. Ambas son NoSQL, flexibles, escalables y en la nube. La primera es Realtime Database [7], que ofrece un almacenamiento en formato JSON y cuyas limitaciones se encuentran, principalmente, en el n´umero de usuarios concurrentes. En segundo lugar, Firebase Firestore [8], que proporciona un almacenamiento de datos en documentos que contienen campos que se asignan a valores. Estos documentos se almacenan en colecciones, que son contenedores para los documentos y que podemos usar para organizar los datos y compilar consultas. Esta jerarqu´ıa se muestra en la Figura 2.3. La principal limitaci´on de este tipo de almacenamiento es que ofrece una cantidad determinada y limitada de lecturas, escrituras y borrados al d´ıa/mes. 4 Figura 2.3: Jerarqu´ıa de Firestore Las diferencias entre estos almacenamientos est´an resaltadas de forma acertada en esta referencia [9]. Finalmente, se utiliz´o Firestore para el almacenamiento por las siguientes razones: Escalabilidad: La jerarqu´ıa de documentos y colecciones permite un almacenamiento m´as sencillo y m´as escalable. Con Realtime Database, aparece cierto l´ımite en n´umero de conexiones concurrentes y n´umero de escrituras por segundo en la misma base de datos. A partir de ah´ı, tendremos que fragmentar los datos en distintas bases de datos. En Firestore ese problema desaparece, puesto que escala de forma autom´atica sin importar el n´umero de usuarios que tenga la aplicaci´on. Consultas: Firestore ofrece consultas indexadas con ordenamiento y filtrado compuestos. A diferencia de Realtime Database, se puede encadenar filtros y combinar distintos tipos de filtrados por colecciones, subcolecciones o documentos. Tambi´en dispone de operaciones at´omicas de escritura y transacciones que se repiten autom´aticamente hasta completarse. Coste: En Realtime Database se cobra por n´umero de usuarios concurrentes, por ancho de banda y almacenamiento. En cambio, en Firestore el coste viene dado por operaciones de lectura, escritura y borrado en la base de datos y con una tarifa inferior por ancho de banda y almacenamiento. Es por ello, que con una buena estructura, se pueden optimizar y reducir los costes de Firestore frente a Realtime. Firebase Storage Para el almacenamiento de archivos se ha usado Cloud Storage [10]. Cloud Storage para Firebase es un servicio de almacenamiento de objetos simple y gratuito hasta cierta cuota construido para almacenar contenido generado por el usuario. Esto, a˜nadido a la sencilla integraci´on con los dem´as servicios de Firebase, lo convierten en una buena opci´on para el almacenamiento. En este caso, ser´a de utilidad para almacenar im´agenes de perfil. 2.1.5. Android Image Cropper Se ha utilizado esta librer´ıa [11] para poder obtener las im´agenes de perfil de los usuarios. De esta forma, con los permisos necesarios, se puede generar un selector de im´agenes que el usuario tendr´a en el dispositivo. Con esto se pueden recortar las im´agenes para reducir su tama˜no y limitar sus dimensiones (formato cuadrado) y obtener as´ı una mejor disposici´on en la interfaz. 2.1.6. Glide Glide [12] es una librer´ıa de c´odigo abierto que permite una carga r´apida y eficiente de im´agenes en la interfaz. Ofrece una API de f´acil uso para la carga de im´agenes tanto locales como remotas. Adem´as, dispone de la posibilidad de cargar im´agenes por defecto en caso de qu´e falle la obtenci´on de la imagen por cualquier motivo. 5 Figura 2.4: Logotipo de Glide 2.2. Entorno de desarrollo El entorno de trabajo durante el desarrollo del proyecto ha sido un ordenador port´atil Acer con las siguientes caracter´ısticas: Equipo Marca Acer Modelo Aspire F5-573G Hardware Procesador Intel Core i7-6500U Memoria 16Gb DDR4 Disco duro 1 Tb 7200 rpm. Tarjeta gr´afica Nvidia GeForce GTX 950M Pantalla 15,6” 1920 x 1080 Software OS Windows 10 Home Tabla 2.1: Caracter´ısticas del ordenador port´atil utilizado para el desarrollo Adem´as del dispositivo anterior, se han utilizado diferentes dispositivos m´oviles para realizar las pruebas. Entre ellos se encuentran: Xiaomi Redmi Note 4x: Android 7.0. Xiaomi Redmi Note 5: Android 8.1.0. Honor 9 Lite: Android 9. Con la selecci´on de estos dispositivos, la aplicaci´on se ha probado en diferentes versiones de android y diferentes tama˜nos y resoluciones de pantalla. 6 Cap´ıtulo 3 Plan de Desarrollo de Software 3.1. Introducci´on En esta secci´on de la memoria se detallar´a la visi´on global del proyecto. Adem´as se comentar´a la decisi´on de la utilizaci´on del modelo de desarrollo ´agil Scrum para este proyecto Software. 3.1.1. Prop´osito El prop´osito del Plan de Desarrollo de Software es proporcionar la informaci´on detallada para realizar un control sobre el proyecto a realizar. Como usuarios de este documento se encuentran: El alumno: se encargar´a de analizar, dise˜nar, planificar, desarrollar y documentar el proyecto. El tutor del TFG: se encargar´a de revisar la implementaci´on y documentaci´on del proyecto, as´ı como su avance mediante la aportaci´on de nuevas ideas y soluciones a los problemas que puedan surgir. 3.1.2. Alcance En esta memoria se incluye una visi´on general del proyecto, se identifican los participantes y sus roles y se desarrolla un plan de trabajo en iteraciones. Adem´as, se a˜nadir´a m´as informaci´on que pueda ser relevante para su desarrollo. Resumen del plan de desarrollo El plan de desarrollo de software se puede dividir en las siguientes secciones: Visi´on general del proyecto: se subdivide en las siguientes subsecciones: •Objetivos del proyecto. •Suposiciones y/o restricciones. •Caracter´ısticas del proyecto. •Elecci´on de Scrum como modelo de desarrollo. •Elecci´on del tipo de desarrollo a utilizar. •Entregables del proyecto. Organizaci´on del proyecto: incluye la estructura del proyecto, los roles en el mismo y las reuniones que se han llevado a cabo. Estimaciones del proyecto: se muestran tanto las estimaciones temporales como de costes del proyecto, as´ı como las desviaciones del mismo. 7 3.2. Visi´on general del proyecto 3.2.1. Objetivos El objetivo principal de este proyecto consiste en el desarrollo de una plataforma android que permita realizar la gesti´on de eventos y pistas deportivas desde el smartphone. De esta manera, los organizadores publicar´an sus pistas libres y las pondr´an a disposici´on de los jugadores. Por su parte, los jugadores podr´an unirse a otros jugadores para completar un partido y practicar un deporte de forma r´apida y eficiente. Puesto que el desarrollo corresponde a la realizaci´on de dos aplicaciones, a continuaci´on se muestra brevemente la funcionalidad de cada una de ellas: Aplicaci´on de gesti´on para los clubes. A trav´es de esta aplicaci´on, los organizadores y responsables del club podr´an crear partidos y gestionarlos. Adem´as, podr´an actualizar su perfil de club para que los jugadores puedan encontrar las instalaciones o ponerse en contacto sin ning´un tipo de inconveniente. Aplicaci´on para los jugadores. A trav´es de esta aplicaci´on, los usuarios podr´an encontrar partidos a los que apuntarse. Para ello dispondr´an de diferentes filtros: Deporte, d´ıa, o precio. Los usuarios dispondr´an de un perfil de jugador que podr´an actualizar y que se ir´a completando con los partidos que va disputando. 3.2.2. Suposiciones y/o restricciones El proyecto estar´a limitado por las siguientes restricciones: 1. Restricciones de presupuesto: Se utilizar´an servicios y/o bibliotecas de libre distribuci´on o servicios que permitan su uso de forma gratuita hasta cierta cuota. 2. Restricciones de recursos: El equipo de trabajo est´a compuesto ´unicamente por dos integrantes: tutor y alumno. El plazo de entrega m´ınimo depender´a de la terminaci´on del resto de asignaturas, y el m´aximo de las convocatorias de trabajo de Fin de Grado. Ordinaria: 26/06/2019 y Extraordinaria: 10/07/2019 3. Restricciones de aplicaci´on: Las aplicaciones ser´an desarrolladas para el sistema operativo Android con una versi´on m´ınima de API 16. Esto permite una compatibilidad con m´as del 95 % de los dispositivos m´oviles actuales[13]. Las aplicaciones deben actualizar datos en tiempo real para la correcta sincronizaci´on entre distintos tipos de usuarios. 3.2.3. Caracter´ısticas del proyecto A continuaci´on se muestran las caracter´ısticas generales de este proyecto: Proyecto de una duraci´on estimada de 300 horas. Desarrollado por el alumno ´unicamente, y supervisado por el tutor del proyecto, que guiar´a y propondr´a cambios y mejoras en el proyecto. Entrega de documentaci´on detallada y completa de todo el proceso, incluyendo diagramas, dise˜nos, planificaci´on y manual de usuario. 8 Requisitos susceptibles a cambios, ampliaciones o reducciones dependiendo de prioridad, tiempo etc. Se requieren actualizaciones en tiempo real para el correcto funcionamiento de la aplicaci´on. La gesti´on de riesgos se antoja importante debido a que no se tiene familiaridad con m´etodos de autenticaci´on y servicios de actualizaci´on en tiempo real. 3.2.4. Elecci´on de la metodolog´ıa de desarrollo de software En la actualidad se utilizan diferentes metodolog´ıas para el desarrollo de software desde el desarrollo en cascada hasta las metodolog´ıas ´agiles, incluyendo proceso unificado, o programaci´on extrema. Para este proyecto se seleccion´o el modelo de Scrum para realizar el desarrollo, principalmente por los siguientes factores: Simplicidad: el proyecto cuenta con un equipo limitado a una persona, el alumno, y a un tiempo limitado de 300 horas. Rapidez: focalizar el proyecto a disponer de un producto m´ınimo viable y a˜nadir valor y funcionalidad en cada iteraci´on se antojaba como la mejor opci´on considerando la limitaci´on del tiempo. Flexibilidad: el producto puede evolucionar y sufrir cambios en los requisitos o funcionalidad. Es por ello, que se eligi´o Scrum para la realizaci´on del proyecto teniendo en cuenta que se puede adaptar en cada iteraci´on. Retroalimentaci´on: al crear un producto en varias iteraciones, se obtiene retroalimentaci´on del tutor en cada una de las etapas. Scrum es un m´etodo de desarrollo ´agil, y como tal hay que valorar m´as el software que funciona a la documentaci´on exhaustiva. Pero dadas las caracter´ısticas del proyecto y las condiciones de entrega de un Trabajo de Fin de Grado, es necesaria la entrega de una documentaci´on completa. Scrum permite esto a˜nadiendo en cada sprint la realizaci´on de la documentaci´on correspondiente. De esta forma, en la ´ultima iteraci´on se dispondr´a de una documentaci´on completa. 3.2.5. Entregables del proyecto Como se ha mencionado en el punto anterior, los entregables estar´an sujetos a cambios a lo largo del desarrollo para obtener as´ı una versi´on final al t´ermino de la ´ultima iteraci´on. Los artefactos entregables ser´an los siguientes: Plan de Desarrollo de Software. Seguimiento del proyecto. Plan de Gesti´on de Riesgos. Especificaci´on de requisitos. Modelo de an´alisis. Modelo de dise˜no y arquitectura. Pruebas. Versi´on final del producto. Manual de usuario. Manual de instalaci´on 9 3.3. Organizaci´on del proyecto 3.3.1. Roles del proyecto Los roles del proyecto, atendiendo al modelo de Scrum [14] son, principalmente, los siguientes: Product Owner: es la persona que se encarga de definir los objetivos del proyecto. Participa activamente en el desarrollo para planificar y priorizar las historias de usuario. Scrum Master: es el principal valedor para que se cumpla la metodolog´ıa ´agil y se encarga de reducir los posibles impedimentos y no afecten al equipo de desarrollo. Equipo de desarrollo: grupo de personas con los conocimientos t´ecnicos necesarios para desarrollar el proyecto. Se encargar´an de llevar a cabo las historias en cada sprint y de la calidad del software a desarrollar. Para este proyecto, la asignaci´on de roles se ha realizado de la siguiente manera: Nombre Rol Joaqu´ın Adiego Rodr´ıguez Product Owner Abel Garc´ıa de Prada Scrum Master y Equipo de desarrollo Tabla 3.1: Asignaci´on de roles del proyecto 3.3.2. Reuniones, eventos y planes operativos Para el seguimiento de Scrum se realizaron los eventos[14] mostrados en la Tabla 3.2. Eventos Descripci´on Reuni´on inicial Reuni´on inicial en la que se plantea la idea y la planificaci´on del proyecto. Sprint Planning Reuni´on durante la cual se determinan las historias a completar en ese sprint. Pueden ser nuevas, o del anterior sprint que no se completaron o se requieren cambios. Reuni´on diaria El equipo de desarrollo (el alumno) identifica las tareas realizadas el d´ıa anterior y las tareas a desarrollar en el d´ıa de trabajo. Demo Reuni´on al final de cada sprint para mostrar el trabajo realizado al Product Owner (el tutor). Retrospectiva Se analiza lo que se ha realizado correctamente en el ´ultimo sprint y lo que se puede mejorar de cara al siguiente sprint. Tabla 3.2: Eventos de Scrum 3.4. Estimaciones del proyecto 3.4.1. Estimaci´on temporal Para el desarrollo del proyecto, se establecieron unas fechas de inicio y final aproximadas y se dividi´o en diferentes sprints. La duraci´on de los sprints se defini´o de 3 semanas debido a que la realizaci´on del mismo solo cuenta con una persona en el equipo de desarrollo y se consider´o que esta duraci´on ser´ıa suficiente para aportar valor en cada iteraci´on. Para finalizar, se establecer´ıa un sprint de dos semanas para terminar los ´ultimos detalles de la aplicaci´on y documentaci´on. 10 A continuaci´on, en la Tabla 3.3 se muestran las fechas estimadas de cada iteraci´on. Sprint Fecha de inicio Fecha de fin 1 04/02/2019 24/02/2019 2 25/02/2019 17/03/2019 3 18/03/2019 07/04/2019 4 08/04/2019 28/04/2019 5 29/04/2019 19/05/2019 6 20/05/2019 09/06/2019 7 10/06/2019 23/06/2019 Tabla 3.3: Iteraciones del proyecto Durante estas iteraciones, considerando como d´ıas de trabajo los d´ıas laborales (de lunes a viernes) y estimando un trabajo diario de 3h persona/d´ıa, se puede estimar el trabajo total como vemos a continuaci´on: 3 horas persona/d´ıa x 5 d´ıas/semana x 3 semanas/sprint x 6 sprints de tres semanas = 270 horas/persona 3 horas persona/d´ıa x 5 d´ıas/semana x 2 semanas/sprint x 1 sprint de dos semanas = 30 horas/persona Esto hace un total de 300 horas/persona que se ci˜ne al tiempo estimado para la realizaci´on del Trabajo de Fin de Grado. 3.4.2. Estimaci´on de costes La estimaci´on de costes no corresponder´ıa a un proyecto real, puesto que del trabajo de desarrollo se encargar´a un alumno universitario y es un Proyecto de Fin de Grado, por lo que no se percibir´a ninguna remuneraci´on. A´un as´ı, seg´un la estimaci´on de 300 horas/hombre y estimando el coste de un Ingeniero Inform´atico en 15 euros/hora, el coste del desarrollo ser´ıa de 4500 euros. A esta estimaci´on habr´ıa que a˜nadir los costes derivados por el uso de herramientas y/o tecnolog´ıas. En este caso, el coste de usar Firebase es nulo debido a que el plan gratuito Spark [15] ser´a m´as que suficiente para el desarrollo del proyecto. Adem´as, las otras herramientas utilizadas disponen de un plan gratuito o son de c´odigo abierto. 3.4.3. Desviaci´on real del proyecto El proyecto sufri´o alguna desviaci´on de lo estimado en la secci´on 3.4.1, debido principalmente a la inexperiencia del equipo en el ´ambito de las herramientas de Firebase. Esta inexperiencia propici´o la necesidad de realizar algunas pruebas adicionales para poder trabajar con soltura con la plataforma, lo que conllev´o un mayor tiempo para el desarrollo del proyecto. Adem´as, los sprints 6 y 7 se alargaron unos d´ıas m´as de lo estimado debido a la necesidad de preparar otras asignaturas para poder presentar el TFG en el actual curso acad´emico. Teniendo en cuenta estos retrasos, en general, las estimaciones han sido correctas, y se ha completado el proyecto dentro de las fechas l´ımites establecidas. 11 Cap´ıtulo 4 Seguimiento del proyecto 4.1. Introducci´on En este cap´ıtulo se comentar´an los aspectos fundamentales del seguimiento del proyecto, desde las fases iniciales, hasta la finalizaci´on completa de la aplicaci´on. Como se ha comentado anteriormente, para el desarrollo de la aplicaci´on se ha seguido el modelo de Scrum. En la figura 4.1 (Fuente: [16]) se muestra gr´aficamente el ciclo de esta metodolog´ıa presentada previamente en la secci´on 3.3.2. Figura 4.1: Flujo de trabajo de Scrum En la imagen anterior se pueden diferenciar las diferentes etapas en este desarrollo. A continuaci´on se describir´an brevemente cada una de ellas: 1. Inicialmente se forma el Product Backlog o Pila de Producto. Se trata b´asicamente de la pila de requisitos desde la visi´on del usuario final. Se conforma con la funcionalidad o historias de usuario de todo el producto ordenadas por prioridad por el cliente. 2. En el sprint planning se seleccionan las historias de usuario con mayor prioridad, de tal forma que la carga de trabajo sea asumible por el equipo de desarrollo. 3. Cuando ya se tienen las historias de usuario seleccionadas, el equipo de desarrollo, se desglosan y dividen las historias en tareas a realizar. Esta lista de tareas formar´a el Sprint Backlog. 4. Durante la duraci´on del Sprint, en este caso se estableci´o en tres semanas, se trabaja sobre esta pila de sprint. 12 5. Al comienzo de cada jornada de trabajo, se realiza una breve reuni´on para comprobar lo realizado durante el d´ıa anterior y lo que se va a realizar en el actual. 6. Al final del sprint, se obtiene una parte funcional del producto, y se examina lo realizado durante el sprint, detectando problemas y proponiendo soluciones para que no se repitan en los pr´oximos sprints. 4.2. Sprint 1: 4 de Febrero - 24 de Febrero En este Sprint se comienza con la documentaci´on y el desarrollo de las aplicaciones tanto de Jugadores como de Clubes. Adem´as se esboza el primer modelo de dominio de la aplicaci´on. Este Sprint lo forman las historias de usuario de la Tabla 4.1. ID Descripci´on US01 Como Equipo quiero tener configurado el entorno de trabajo completo para poder empezar a trabajar en el proyecto US23 Como Product Owner quiero tener una documentaci´on inicial del proyecto para tener una visi´on global del mismo US02 Como usuario Jugador quiero poder registrarme en la aplicaci´on mediante email y contrase˜na. US03 Como usuario Jugador quiero poder identificarme de forma ´unica en la aplicaci´on de Jugadores con mis credenciales de usuario. US04 Como usuario Club quiero poder identificarme de forma ´unica en la aplicaci´on de Clubes con mis credenciales de usuario. US24 Como Product Owner quiero tener un modelo de dominio inicial de ambas aplicaciones a desarrollar. Tabla 4.1: Historias de usuario del Sprint 1 4.2.1. US01 - Como Equipo quiero tener configurado el entorno de trabajo completo para poder empezar a trabajar en el proyecto Descripci´on En esta historia de usuario se configurar´a el entorno de trabajo completo que permita empezar el desarrollo del mismo. Es lo b´asico para empezar a trabajar sin ning´un tipo de inconveniente que podr´ıa conllevar el retraso en la entrega del proyecto. Estimaci´on Esta historia de usuario se ha valorado con 2 puntos, debido a la necesidad de configurar las herramientas que se emplear´an para desarrollar el proyecto. Tareas Crear el proyecto en Overleaf para comenzar la documentaci´on. Configurar el proyecto en Overleaf y la estructura de la documentaci´on. Instalaci´on y configuraci´on de Android Studio en su ´ultima versi´on. Creaci´on del repositorio en Github que permita la gesti´on del control de versiones. Creaci´on del proyecto Android en Android Studio. Enlazar Android Studio con Github. 13 4.5.1. US13 - Como usuario Club quiero poder crear nuevos partidos para que los jugadores puedan visualizar y acceder a ellos. Descripci´on Esta funcionalidad es una de las imprescindibles y m´as importantes de la aplicaci´on porque es la que permitir´a a los clubes crear los partidos a los que los jugadores podr´an unirse posteriormente. Estimaci´on Se ha estimado esta historia con 5 puntos puesto que hay que crear una interfaz de usuario y gestionar las comunicaciones con Firestore. Tareas Creaci´on de una interfaz de usuario que permita recoger los datos del partido. Gestionar la comunicaci´on con Firebase Firestore. Gestionar los posibles errores. 4.5.2. US14 - Como usuario Jugador quiero poder ver un listado de los partidos disponibles para unirme. Descripci´on Esta historia de usuario permitir´a a los jugadores ver un listado completo de los partidos disponibles creados por los clubes correspondientes. Estimaci´on Esta historia de usuario se ha estimado con 8 puntos debido a la necesidad de observar en tiempo real los posibles cambios en los partidos. Adem´as, hay que gestionar la paginaci´on para no cargar todos los partidos a la vez, lo que podr´ıa consumir demasiados recursos si hay muchos partidos en la aplicaci´on. Y por supuesto hay que crear un layout para esta informaci´on. Tareas Creaci´on de un layout para los partidos. Gestionar la comunicaci´on con Firebase Firestore. Gestionar la actualizaci´on en tiempo real del listado. Gestionar la paginaci´on. Gestionar los posibles errores. 4.5.3. US15 - Como usuario Club quiero poder ver un listado completo de todos los partidos que he creado para tener un seguimiento en tiempo real. Descripci´on Al igual que los jugadores necesitan ver los partidos disponibles, los clubes necesitan mantener un listado de todos los partidos que han creado para gestionar esos partidos de forma eficiente y r´apida. Estimaci´on Se ha estimado esta historia con 3 puntos debido a la similitud con la US12 y la posibilidad de reutilizar el c´odigo implementado. 20 Tareas Creaci´on de un layout para los partidos. Gestionar la comunicaci´on con Firebase Firestore. Gestionar la actualizaci´on en tiempo real del listado. Gestionar la paginaci´on. Gestionar los posibles errores. 4.6. Sprint 5: 29 de Abril - 19 de Mayo En este Sprint se contin´ua con el desarrollo de las aplicaciones tanto de Jugadores como de Clubes, y se gestiona la informaci´on completa de cada partido. Este Sprint lo forman las historias de usuario de la Tabla 4.5. ID Descripci´on US16 Como usuario quiero consultar la informaci´on completa de un partido. US17 Como usuario quiero consultar el listado de jugadores que se han inscrito a un partido. US18 Como usuario Jugador quiero consultar el perfil del club que ha organizado el partido. Tabla 4.5: Historias de usuario del Sprint 5 4.6.1. US16 - Como usuario quiero consultar la informaci´on completa de un partido. Descripci´on Esta funcionalidad trata de mostrar toda la informaci´on relacionada con un partido, de tal forma que se tenga un visi´on m´as completa que el mostrado en los listados. Estimaci´on Se ha estimado con 5 puntos puesto que se necesita la creaci´on de un layout, y las consultas a la base de datos. Tareas Creaci´on de layout con la informaci´on completa del partido. Gestionar la comunicaci´on con Firestore. Gestionar los posibles errores. 4.6.2. US17 - Como usuario quiero consultar el listado de jugadores que se han inscrito a un partido. Descripci´on Esta funcionalidad permitir´a visualizar un listado de todos los jugadores que se han apuntado a un partido con su imagen y nombre. 21 Estimaci´on Se ha estimado con 5 puntos puesto que hay que crear un layout para los jugadores y gestionar el listado de los mismos. Tareas Creaci´on de un layout para los jugadores. Gestionar la comunicaci´on con Firebase Firestore. Gestionar los posibles errores. 4.6.3. US18 - Como usuario Jugador quiero consultar el perfil del club que ha organizado el partido. Descripci´on Como jugador se necesita poder consultar el perfil del club que ha creado el partido. De esta forma, el jugador podr´a acceder a la informaci´on de contacto si as´ı lo necesitase, y a la localizaci´on de las instalaciones donde se va a disputar el partido. Estimaci´on Se ha estimado con 3 puntos esta historia de usuario debido a que se puede reutilizar parte de la implementaci´on de la US12. Tareas Creaci´on de una interfaz de usuario para mostrar el perfil. Gestionar la comunicaci´on con Firebase Firestore. Gestionar los posibles errores. 4.7. Sprint 6: 20 de Mayo - 9 de Junio En este Sprint se contin´ua con el desarrollo de las aplicaciones tanto de Jugadores como de Clubes, se implementan varios filtros en los listados y se a˜naden las uniones y abandonos a los partidos. En principio ser´ıa el final del desarrollo de las aplicaciones. Este Sprint lo forman las historias de usuario de la Tabla 4.6. ID Descripci´on US19 Como usuario Jugador quiero filtrar la lista de partidos seg´un diferentes par´ametros. US20 Como usuario Club quiero filtrar la lista de mis partidos seg´un el estado de los mismos. US21 Como usuario Jugador quiero poder unirme y abandonar un partido. US22 Como usuario Club quiero poder actualizar el estado de un partido. Tabla 4.6: Historias de usuario del Sprint 6 4.7.1. US19 - Como usuario Jugador quiero filtrar la lista de partidos seg´un diferentes par´ametros. Descripci´on A nivel de experiencia de usuario, poder filtrar los partidos dependiendo de ciertos par´ametros es fundamental. 22 Los filtros permitidos ser´an en funci´on de partidos a los que nos hemos unido previamente, por deporte, fecha o precio. Se podr´an marcar uno o varios al mismo tiempo y se actualizar´a el listado en funci´on. Estimaci´on Esta historia de usuario tendr´a una estimaci´on de 3 puntos debido a que el filtrado no tiene demasiada complejidad. Tareas Creaci´on de una interfaz de usuario que permita seleccionar los filtros. Gestionar la comunicaci´on con Firebase Firestore. Gestionar los posibles errores. 4.7.2. US20 - Como usuario Club quiero filtrar la lista de mis partidos seg´un el estado de los mismos. Descripci´on Al igual que en la aplicaci´on de jugadores, se antoja importante filtrar los partidos de la aplicaci´on de Clubes. De esta manera, la gesti´on de los partidos ser´a m´as r´apida porque estar´an filtrados dependiendo del estado de los mismos. Estimaci´on Se ha estimado esta historia de usuario con 3 puntos. Tareas Creaci´on de una interfaz de usuario que permita seleccionar los filtros. Gestionar la comunicaci´on con Firebase Firestore. Gestionar los posibles errores. 4.7.3. US21 - Como usuario Jugador quiero poder unirme y abandonar un partido. Descripci´on Esta funcionalidad es una de las mas importantes, puesto que el ciclo de un partido pasa por estas acciones. Esta uni´on deber´a ser controlada, de tal forma que si el partido admite un m´aximo de 10 personas, no se permitir´a la uni´on cuando el partido est´e completo. Estimaci´on Debido a la inexperiencia en el uso de transacciones en Firebase Firestore, a la necesidad de crear dos transacciones, una para unirse y otra para abandonar, se estimado esta historia en 5 puntos. Tareas Creaci´on de un layout para la uni´on y abandono a partidos. Creaci´on de transacciones en Firebase Firestore. Gestionar los posibles errores. 23 4.7.4. US22 - Como usuario Club quiero poder actualizar el estado de un partido. Descripci´on Esta funcionalidad permitir´a al club gestionar el ciclo de vida de un partido. Podr´a cancelar el partido en cualquier momento, as´ı como establecer y confirmar la convocatoria del mismo. De esta forma el club tendr´a el control total de sus partidos. Estimaci´on Se ha estimado con 3 puntos esta historia puesto que su complejidad no es muy alta. Tareas Creaci´on de un layout para la gesti´on de los partidos. Gestionar las comunicaciones con Firebase Firestore. Gestionar los posibles errores. 4.8. Sprint 7: 10 de Junio - 23 de Junio En este Sprint se contin´ua con la documentaci´on del proyecto, se terminar´ıa la memoria y con ello se completar´ıa el Trabajo de Fin de Grado. Este Sprint lo forman las historias de usuario de la Tabla 4.7. ID Descripci´on US26 Como Product Owner quiero disponer del Plan de Desarrollo de Software final y su seguimiento. US27 Como Product Owner quiero disponer de la memoria completa del proyecto. Tabla 4.7: Historias de usuario del Sprint 7 4.8.1. US26 - Como Product Owner quiero disponer del Plan de Desarrollo de Software final y su seguimiento. Descripci´on En esta historia de usuario se deber´a aportar la versi´on final del Plan de Desarrollo de Software y el Seguimiento realizado durante todo el desarrollo. Estimaci´on Se ha estimado esta historia de usuario con 5 puntos. Tareas Aportar la versi´on final del Desarrollo de Software. Aportar todo el seguimiento del proyecto. 4.8.2. US27 - Como Product Owner quiero disponer de la memoria completa del proyecto. Descripci´on En esta historia de usuario se deber´a aportar una memoria completa del trabajo realizado. 24 Estimaci´on Esta historia de usuario se ha estimado con 5 puntos. Tareas Realizar el manual de usuario. Revisar la memoria completa, aportar las versiones finales de Modelo de Dominio, el dise˜no final de la aplicaci´on y las valoraciones personales obtenidas al desarrollar este trabajo. Corregir los posibles errores y las mejoras reportadas por el tutor. 25 Cap´ıtulo 5 Plan de Gesti´on de Riesgos 5.1. Introducci´on La Gesti´on de Riesgos permite la resoluci´on de cualquier situaci´on adversa que pueda surgir a lo largo del desarrollo del proyecto. Por eso es importante definirlos en etapas iniciales del desarrollo con el fin de tener planes de acci´on en caso de que ocurran. 5.1.1. Gesti´on del riesgo A continuaci´on se identifican los riesgos y sus planes de acci´on: R01 Falta de experiencia del alumno Descripci´on El alumno ha realizado pr´acticas y proyectos simples en Android, pero puede encontrar dificultades en el desarrollo de un proyecto complejo. Consecuencia Ralentizaci´on del desarrollo que puede afectar al resto del proyecto Probabilidad Media Impacto Bajo Estrategia Reservar el riesgo Plan de acci´on Consulta de documentaci´on, tutoriales o consultar con un experto en la materia. Plan de contingencia Comprobaci´on de conocimientos adquiridos antes de comenzar el desarrollo. R02 Mala planificaci´on Descripci´on Debido a errores en la estimaci´on, la planificaci´on no se ci˜ne a la realidad y pueden producirse retrasos en las fechas de entrega. Consecuencia Retraso en la entrega de proyecto Probabilidad Alta Impacto Cr´ıtico Estrategia Reservar el riesgo Plan de acci´on Realizar una planificaci´on que se ajuste a la realidad. Plan de contingencia Mantener un seguimiento exhaustivo durante el ciclo de desarrollo. 26 R03 P´erdida de artefactos Descripci´on Por cualquier motivo, se pierden parcial o completamente los artefactos de entrega. Consecuencia Ralentizaci´on alta del proyecto, conllevar´ıa la repetici´on de los artefactos perdidos. Probabilidad Baja Impacto Cr´ıtico Estrategia Evitaci´on del riesgo Plan de acci´on - Plan de contingencia Creaci´on de copias de seguridad en documentaci´on y uso de control de versiones para el desarrollo. R04 Dise˜no pobre o incorrecto Descripci´on El dise˜no de la soluci´on no es correcto o es pobre debido a la inexperiencia del equipo en la captaci´on de requisitos. Consecuencia Ralentizaci´on del proyecto y actualizar el dise˜no en consecuencia Probabilidad Medio-Bajo Impacto Cr´ıtico Estrategia Reducci´on del riesgo Plan de acci´on Rehacer o actualizar el dise˜no de la soluci´on. Plan de contingencia Consulta de cada dise˜no con el cliente para verificar la calidad del dise˜no. R05 Disponibilidad de miembros del equipo Descripci´on Baja disponibilidad de alg´un miembro del equipo. Consecuencia Si el tiempo de disponibilidad es demasiado bajo puede acarrear la no consecuci´on de los objetivos y entrega del proyecto. Probabilidad Baja Impacto Cr´ıtico Estrategia Reservar el riesgo Plan de acci´on Actualizar la planificaci´on del proyecto para adecuarse a la disponibilidad de los miembros. Plan de contingencia Consulta de disponibilidad del equipo R06 Mala estimaci´on en los puntos de una historia de usuario Descripci´on Debido a errores en la estimaci´on, la planificaci´on no se ci˜ne a las fechas l´ımite. Consecuencia Puede ocasionar retrasos en la planificaci´on. Probabilidad Media-Alta Impacto Medio Estrategia Reducci´on del riesgo Plan de acci´on Replanificaci´on del sprint. Plan de contingencia Realizar una peque˜na investigaci´on sobre las necesidades de cada historia antes de realizar la estimaci´on de los puntos. 27 R07 Seguimiento de tareas limitado Descripci´on Debido a diversas causas, el seguimiento del proyecto no se realiza adecuadamente y se pierde la noci´on de qu´e tareas se han realizado, o que funcionalidad todav´ıa queda por desarrollar. Consecuencia Puede ocasionar retrasos en la planificaci´on. Probabilidad Baja Impacto Medio Estrategia Evitaci´on del riesgo Plan de acci´on Revisi´on completa del proyecto para comprobar lo desarrollado y lo que no. Plan de contingencia Realizar un seguimiento de lo desarrollado y lo que falta por realizar apoy´andose en aplicaciones externas y en la reuni´on diaria de Scrum. 5.1.2. Control de riesgos Debido a la realizaci´on de un proyecto complejo, que comprende la realizaci´on de dos aplicaciones que deben sincronizarse en tiempo real, se han disparado algunos riesgos que comentaremos a continuaci´on. El riesgo R01 se ha disparado debido a la inexperiencia del alumno en algunas tecnolog´ıas empleadas, lo que ha conllevado emplear m´as tiempo del estimado inicialmente para poder realizar la entrega del proyecto en los plazos estimados. El riesgo R05 se ha disparado debido a la falta de disponibilidad del alumno en periodos de ex´amenes, lo que ha acarreado el retraso en la entrega del proyecto, y la ampliaci´on del tiempo estimado para la realizaci´on completa del proyecto. El riesgo R06 se ha disparado debido a que algunas estimaciones eran inferiores al tiempo empleado finalmente, debido a la inexperiencia en algunas facetas del desarrollo, lo que ha implicado aumentar el tiempo dedicado a resolver este defecto. 28 Cap´ıtulo 6 Requisitos 6.1. Los requisitos en el desarrollo ´agil La especificaci´on de requisitos en el desarrollo ´agil difiere en varios puntos respecto al desarrollo tradicional. Es por ello, que se comentar´an las principales diferencias a fin de clarificar los objetivos. Al igual que en un desarrollo tradicional, los requisitos y funcionalidad deseada es definida por el cliente. Las principales diferencias se encuentran en qui´en, c´omo y d´onde se especifican los requisitos. En un proyecto tradicional, los requisitos son recogidos por una persona o equipo especializado en captaci´on de requisitos y los especifica en un documento invariable al comienzo del proyecto. En cambio, en un desarrollo ´agil, las necesidades del cliente son conocidas por todo el equipo, y se intenta guiar al cliente para adaptar y orientar el producto a realizar. Los requisitos en una metodolog´ıa ´agil se separan en historias de usuario que se agrupan en un Backlog ordenado por prioridad que ir´a evolucionando a lo largo del desarrollo. Teniendo esto en cuenta, se obtienen los siguientes requisitos que han ido evolucionando a lo largo del desarrollo. 6.2. Requisitos funcionales Debido a la creaci´on de dos aplicaciones, se definir´an los requisitos de cada una de ellas de manera separada. En la tabla 6.1 se mostrar´an los requisitos funcionales acordes a la aplicaci´on de los jugadores. 29 CU09 Consultar jugadores inscritos a un partido Actor Jugador y Organizador Descripci´on El usuario desea ver todos los jugadores inscritos a un partido. Precondici´on El usuario est´a identificado en el sistema. Flujo normal 1. El caso de uso comienza cuando el usuario selecciona la opci´on de ’Mostrar jugadores inscritos’ en la informaci´on de un partido. 2. El sistema muestra un listado completo de los jugadores inscritos. Postcondici´on Se muestra un listado con los jugadores inscritos. Flujo alternativo 2.a El sistema no dispone de conexi´on a internet. Se notifica, y el caso de uso queda sin efecto. Tabla 7.9: Descripci´on de CU09 CU10 Unirse a partido Actor Jugador Descripci´on El usuario desea unirse a un partido. Precondici´on El usuario est´a identificado en el sistema y no est´a inscrito al partido. Flujo normal 1. El caso de uso comienza cuando el usuario selecciona ’Unirse a partido’ en la informaci´on de un partido. 2. El sistema muestra informaci´on relativa al partido. 3. El usuario acepta dicha informaci´on. 4. El sistema comprueba si el jugador puede unirse al partido. 5. El sistema inscribe al jugador en el partido Postcondici´on El usuario aparece inscrito al partido. Flujo alternativo 3.a El usuario rechaza la informaci´on. El caso de uso queda sin efecto. 4.a El sistema determina que el usuario no puede unirse al partido. Se notifica y el caso de uso queda sin efecto. Tabla 7.10: Descripci´on de CU10 CU11 Abandonar partido Actor Jugador Descripci´on El usuario desea abandonar un partido. Precondici´on El usuario est´a identificado en el sistema y aparece como inscrito al partido. Flujo normal 1. El caso de uso comienza cuando el usuario selecciona ’Abandonar partido’ en la informaci´on de un partido. 2. El sistema muestra informaci´on relativa al partido. 3. El acepta dicha informaci´on. 4. El sistema elimina al jugador del partido Postcondici´on El usuario aparece como no inscrito al partido. Flujo alternativo 3.a El usuario cancela. El caso de uso queda sin efecto. Tabla 7.11: Descripci´on de CU11 36 CU12 Cerrar sesi´on Actor Jugador Descripci´on El usuario desea cerrar sesi´on. Precondici´on El usuario est´a identificado en el sistema. Flujo normal 1. El caso de uso comienza cuando el usuario selecciona ’Cerrar sesi´on’. 2. El sistema cierra la sesi´on del usuario. 3. El sistema muestra la pantalla de identificaci´on. Postcondici´on El usuario aparece como no identificado en el sistema. Flujo alternativo Ninguno. Tabla 7.12: Descripci´on de CU11 Aplicaci´on Cribi Clubs para organizadores CU13 Iniciar sesi´on como organizador Actor Organizador Descripci´on El usuario desea identificarse en la aplicaci´on Precondici´on El usuario no est´a identificado en el sistema. Flujo normal 1. El caso de uso comienza cuando el usuario selecciona ’Iniciar sesi´on’. 2. El sistema muestra la pantalla de identificaci´on. 3. El usuario introduce las credenciales. 4. El sistema comprueba que las credenciales son correctas. 5. El sistema identifica al usuario y muestra su pantalla de inicio. Postcondici´on El usuario aparece identificado en el sistema. Flujo alternativo 2.a 3.a El usuario cancela y el caso de uso queda sin efecto. 4.a El sistema no dispone de conexi´on a internet para realizar la identificaci´on. Se notifica y el caso de uso queda sin efecto. 4.b Las credenciales del usuario no son correctas. Se notifica y el caso de uso contin´ua en el paso 2. Tabla 7.13: Descripci´on de CU13 CU14 Consultar perfil Actor Organizador Descripci´on El usuario desea consultar su perfil. Precondici´on El usuario est´a identificado en el sistema. Flujo normal 1. El caso de uso comienza cuando el usuario selecciona ’Consultar perfil’. 2. El sistema muestra el perfil del usuario. Postcondici´on Se muestra el perfil completo del usuario. Flujo alternativo 2.a El sistema no dispone de conexi´on a internet para realizar la consulta de perfil. Se notifica y el caso de uso queda sin efecto. Tabla 7.14: Descripci´on de CU14 37 CU15 Modificar perfil de organizador Actor Organizador Descripci´on El usuario desea modificar su perfil. Precondici´on El usuario est´a identificado en el sistema. Flujo normal 1. El caso de uso comienza cuando el usuario selecciona ’Modificar perfil’. 2. El sistema muestra un formulario con los datos actualizables y sus valores actuales. 3. El usuario modifica los datos a su elecci´on. 4. El sistema comprueba los datos y actualiza el perfil. Postcondici´on El perfil ha sido actualizado. Flujo alternativo 3.a El usuario cancela y el caso de uso queda sin efecto. 4.a El sistema no dispone de conexi´on a internet para actualizar los datos. Se notifica y el caso de uso queda sin efecto. 4.b Los datos introducidos por el usuario no son v´alidos. Se notifica y el caso de uso contin´ua en el paso 2. Tabla 7.15: Descripci´on de CU15 CU16 Consultar lista de partidos organizados Actor Organizador Descripci´on El usuario desea ver la lista de partidos que ha organizado. Precondici´on El usuario est´a identificado en el sistema. Flujo normal 1. El caso de uso comienza cuando el usuario selecciona ’Mostrar partidos organizados’. 2. El sistema muestra un listado con los partidos que ha creado el propio organizador. Postcondici´on Se muestra un listado con los partidos organizados. Flujo alternativo 2.a El sistema no dispone de conexi´on a internet para actualizar los datos. Se notifica y el caso de uso queda sin efecto. Tabla 7.16: Descripci´on de CU16 CU17 Filtrar listado de partidos organizados Actor Organizador Descripci´on El usuario Organizador desea filtrar los partidos que ha organizado por estado de cada uno de ellos para acceder r´apidamente a aquellos que tiene pendientes. Precondici´on El usuario est´a identificado en el sistema. Flujo normal 1. El caso de uso comienza cuando el usuario selecciona ’Filtrar partidos’. 2. El sistema muestra diferentes estados al usuario. 3. El usuario selecciona un estado. 4. El sistema filtra la lista de partidos. 5. El sistema muestra un listado con los partidos que se encuentran en ese estado. Postcondici´on Se muestra un listado de partidos con el estado elegido. Flujo alternativo 3.a El usuario cancela. El caso de uso queda sin efecto. Tabla 7.17: Descripci´on de CU17 38 CU18 Consultar informaci´on de partido Actor Organizador Descripci´on El usuario desea ver la informaci´on completa de un partido. Precondici´on El usuario est´a identificado en el sistema. Flujo normal 1. El caso de uso comienza cuando el usuario selecciona un partido del listado ofrecido por ’Mostrar partidos’. 2. El sistema muestra la informaci´on completa del partido. Postcondici´on Se muestra la informaci´on completa del partido. Flujo alternativo Ninguno. Tabla 7.18: Descripci´on de CU18 CU19 Consultar jugadores inscritos a un partido Actor Organizador Descripci´on El usuario desea ver todos los jugadores inscritos a un partido. Precondici´on El usuario est´a identificado en el sistema. Flujo normal 1. El caso de uso comienza cuando el usuario selecciona la opci´on de ’Mostrar jugadores inscritos’ en la informaci´on de un partido. 2. El sistema muestra un listado completo de los jugadores inscritos. Postcondici´on Se muestra un listado con los jugadores inscritos. Flujo alternativo 2.a El sistema no dispone de conexi´on a internet. Se notifica, y el caso de uso queda sin efecto. Tabla 7.19: Descripci´on de CU19 CU20 Cambiar estado de partido Actor Organizador Descripci´on El usuario desea cambiar el estado de un partido. Precondici´on El usuario est´a identificado en el sistema. Flujo normal 1. El caso de uso comienza cuando el usuario selecciona ’Cambiar estado de partido’ en la informaci´on de un partido. 2. El sistema muestra un listado de los posibles estados siguientes. 3. El usuario selecciona un estado. 4. El sistema cambia el estado del partido. Postcondici´on El estado del partido cambia al elegido por el organizador. Flujo alternativo 3.a El usuario cancela y el caso de uso queda sin efecto 4.a El sistema no dispone de conexi´on a internet. Se notifica, y el caso de uso queda sin efecto. Tabla 7.20: Descripci´on de CU20 39 CU21 Crear nuevo partido Actor Organizador Descripci´on El usuario desea crear un nuevo partido. Precondici´on El usuario est´a identificado en el sistema. Flujo normal 1. El caso de uso comienza cuando el usuario selecciona ’Crear nuevo partido’. 2. El sistema muestra un formulario con los datos requeridos para crear el partido. 3. El usuario introduce los datos. 4. El sistema comprueba los datos y crea el partido. Postcondici´on Se crea un nuevo partido. Flujo alternativo 3.a El usuario cancela y el caso de uso queda sin efecto. 4.a El sistema no dispone de conexi´on a internet. Se notifica, y el caso de uso queda sin efecto. 4.b Los datos introducidos no son v´alidos. Se notifica, y el caso de uso queda sin efecto. Tabla 7.21: Descripci´on de CU21 CU22 Cerrar sesi´on de organizador Actor Organizador Descripci´on El usuario desea cerrar sesi´on. Precondici´on El usuario est´a identificado en el sistema. Flujo normal 1. El caso de uso comienza cuando el usuario selecciona ’Cerrar sesi´on’. 2. El sistema cierra la sesi´on del usuario. 3. El sistema muestra la pantalla de identificaci´on. Postcondici´on El usuario aparece como no identificado en el sistema. Flujo alternativo Ninguno. Tabla 7.22: Descripci´on de CU22 7.1.4. Modelo de Dominio Figura 7.3: Modelo de dominio de la aplicaci´on. 40 7.1.5. Descripci´on de las clases del modelo de dominio User Descripci´on: clase que modela un usuario jugador. Atributos: •id: identificador ´unico para cada usuario. •name: nombre del usuario. •descr: breve descripci´on del usuario. •city: ciudad del usuario. •muni: localidad del usuario. •profile img: url de acceso a la imagen de perfil del usuario. Player Descripci´on: clase que modela a un jugador inscrito en un partido. Atributos: •id: id del usuario. •timestamp: Fecha de inscripci´on en el partido. •profile img: url de acceso a la imagen de perfil del usuario. •name: nombre del usuario. Club Descripci´on: clase que modela a un organizador o club. Atributos: •id: identificador ´unico de organizador. •name: nombre del club organizador. •image logo: url de acceso a la imagen de perfil del organizador •city: ciudad en la que el organizador ofrece sus instalaciones. •address: direcci´on completa de las instalaciones. •email: correo electr´onico de contacto. •web: direcci´on web de contacto. •telephone: tel´efono de contacto. Match Descripci´on: clase que modela un partido. Atributos: •id: identificador ´unico de partido. •sport: deporte del partido a disputar. •matchDate: fecha de comienzo del partido. •matchClose: fecha l´ımite para unirse a un partido. •placeId: identificador del club organizador donde que ofrece las instalaciones. •price: precio del partido. •duration: duraci´on del partido. •capacity: n´umero de jugadores necesarios para disputar el partido. •status: estado en el que se encuentra el partido. 41 7.1.6. Diagramas de actividad Cribi CU01: Iniciar sesi´on Figura 7.4: Diagrama de actividad CU01. 42 CU02: Registrarse Figura 7.5: Diagrama de actividad CU02. 43 CU03: Consultar perfil Figura 7.6: Diagrama de actividad CU03. 44 CU04: Modificar perfil Figura 7.7: Diagrama de actividad CU04. 45 CU11: Abandonar partido Figura 7.14: Diagrama de actividad CU11. 52 CU12: Cerrar sesi´on Figura 7.15: Diagrama de actividad CU12. . 7.1.7. Diagramas de actividad Cribi Clubs Debido a que ambas aplicaciones comparten cierta funcionalidad, los diagramas de actividad ser´an iguales. A continuaci´on se muestran aquellos que son compartidos por ambas aplicaciones: CU13: Comparte diagrama de actividad con CU01, representado en la Figura 7.4. CU14: Comparte diagrama de actividad con CU03, representado en la Figura 7.6. CU15: Comparte diagrama de actividad con CU04, representado en la Figura 7.7. CU18: Comparte diagrama de actividad con CU07, representado en la Figura 7.10. CU19: Comparte diagrama de actividad con CU09, representado en la Figura 7.12. CU22: Comparte diagrama de actividad con CU12, representado en la Figura 7.15. Se mostrar´an a continuaci´on los diagramas de actividad exclusivos de la aplicaci´on Cribi Clubs: 53 CU16: Consultar lista de partidos organizados Figura 7.16: Diagrama de actividad CU16. 54 CU17: Filtrar listado de partidos organizados Figura 7.17: Diagrama de actividad CU17. 55 CU20: Cambiar estado de partido Figura 7.18: Diagrama de actividad CU20. 56 CU21: Crear nuevo partido Figura 7.19: Diagrama de actividad CU21. 57 Cap´ıtulo 8 Dise˜no 8.1. Dise˜no de la arquitectura 8.1.1. Patr´on arquitect´onico MVVM En la actualidad existen diferentes patrones arquitect´onicos para el desarrollo de aplicaciones m´oviles. Entre ellos est´an los conocidos MVC, MVP o MVVM. Para este proyecto se decidi´o el uso del patr´on MVVM, al que Google le ha dedicado especial atenci´on desde la salida de los componentes de arquitectura en 2017 [17]. Estos componentes de arquitectura forman parte de Android Jetpack[18]. Jetpack es una colecci´on de componentes software de Android que permite desarrollar aplicaciones Android s´olidas, mantenibles y testeables. Jetpack permite acelerar el desarrollo, manteniendo componentes que pueden usarse individualmente y que facilitan tareas tediosas como la administraci´on del ciclo de vida de las aplicaciones. Pero lo m´as destacado es la escalabilidad, testeabilidad y mantenimiento de las aplicaciones construidas usando estos componentes. Adem´as, mediante el uso de esta arquitectura, cada componente tendr´a una ´unica responsabilidad, tal y como dicta el principio de responsabilidad ´unica. De esta forma se abandonar´a el error com´un de introducir toda la l´ogica de negocio dentro de una Activity, lo que evidentemente la convierte en dif´ıcil de leer, testear y mantener. La arquitectura base de una aplicaci´on utilizando estos componentes se muestra en la Figura 8.1[19]. Figura 8.1: Arquitectura MVVM 58 Como se puede observar, cada componente depende exclusivamente del que se encuentra un nivel m´as abajo. El repositorio ser´ıa el ´unico que dependa de otras clases, puesto que las fuentes de datos podr´an ser locales o remotas. Adem´as el ViewModel no tendr´ıa ning´un conocimiento sobre qu´e vistas est´an haciendo uso de ´el. As´ı mismo, el repositorio tampoco sabr´ıa qu´e ViewModel estar´ıa haciendo uso de el. Este dise˜no permite un desacoplamiento total entre modelo y vista, lo cual permite una testeabilidad completa y simplificada. Adem´as, hace que no se tengan que enviar datos a la propia vista para que se actualice como si que ocurre en otros patrones, ya que estar´a observando cambios en el modelo a trav´es del LiveData como se comentar´a posteriormente. A continuaci´on se detallar´an los principales detalles del patr´on arquitect´onico MVVM (Model-View- ViewModel) [20]. Model: El modelo contendr´a la l´ogica de negocio de la aplicaci´on. El repositorio ser´ıa la ´unica fuente de verdad para los ViewModel, de tal forma que cuando el ViewModel necesita de alg´un dato, lo tomar´a del repositorio. A su vez, el repositorio ser´a el encargado de obtener esa informaci´on desde la fuente de datos local o desde una fuente de datos remota. View: En el contexto de MVVM, la vista se encargar´a de mostrar informaci´on y de manejar la interacci´on directa con el usuario. Esta vista no mantendr´a l´ogica de negocio alguna, si no que se encargar´a de comunicar al ViewModel los eventos producidos al interaccionar con el usuario. ViewModel: El ViewModel establecer´ıa un puente entre la vista y el modelo. Se encargar´ıa de solicitar las operaciones necesarias al modelo para proporcionar las necesidades que tiene la vista. 8.1.2. Arquitectura general Para esta aplicaci´on, la arquitectura MVVM se ha adaptado como en la Figura 8.2 (Fuente: [21]). Figura 8.2: Arquitectura MVVM en conjunto con Firestore A continuaci´on se comentar´a el uso de cada componente y el por qu´e se ha utilizado esta soluci´on. 59 En primer lugar tendremos el repositorio, cuya ´unica fuente de datos ser´a Firebase. Esta elecci´on es debida al aprovechamiento de las cach´es que ofrece Firestore de las consultas recientes. Es por ello que no se ha utilizado la capa de persistencia Room para almacenamiento local, aunque podr´ıa ser interesante a˜nadirla en el futuro. Este repositorio gestionar´a todas las conexiones a la base de datos (Firebase Firestore), al almacenamiento de im´agenes (Firebase Storage) y al servicio de autenticaci´on (Firebase Authentication). A trav´es de estas conexiones realizar´a las operaciones y obtendr´a los datos requeridos por otros componentes. Para mantener estos datos se utilizar´an LiveDatas. LiveData es un objeto observable que respeta los ciclos de vida de los dem´as componentes. De esta forma, solo notificar´a de cambios a los observadores que tengan un ciclo de vida activo. En segundo lugar se encuentra el ViewModel, que como se puede observar en la Figura 8.1, tendr´a una conexi´on con el repositorio, pero el repositorio no tendr´a una conexi´on con el propio ViewModel. Esto permite una estructura completamente testeable y mantenible. Pero el ViewModel, al ser el nexo entre repositorio y vista, entonces tendr´a que mantener una conexi´on para proporcionar los datos a la vista. Esta conexi´on se realiza a trav´es de LiveDatas. De esta forma, el ViewModel recuperar´a los datos del repositorio y los expondr´a a la vista a trav´es de estos observables. Adem´as, el ViewModel permite administrar el ciclo de vida de una actividad o fragmento puesto que se mantiene en memoria hasta que el ciclo de vida de mismo finaliza. Esto permite que los datos no se pierdan aunque haya cambios de configuraci´on como, por ejemplo, la rotaci´on de pantalla. Por ´ultimo, se encuentra la Vista. Esta vista se encargar´a de recibir los distintos eventos que realice el usuario en la interfaz y mantendr´a una conexi´on con el ViewModel para gestionar estos eventos. Mediante esta conexi´on, la vista observar´a el LiveData del ViewModel, de tal manera que actualizar´a la pantalla en funci´on de los datos del mismo. 60 8.1.3. Estructura del proyecto Figura 8.3: Paquetes aplicaci´on Cribi Figura 8.4: Paquetes aplicaci´on Cribi Clubs 8.1.4. Interacci´on entre componentes En esta secci´on se mostrar´an algunos de los detalles de la implementaci´on de la arquitectura MVVM en la aplicaci´on Cribi y la interacci´on entre los diferentes componentes. Esta implementaci´on ser´a com´un a lo largo de todo el proyecto. 61 CP23 Ver listado de partidos establecidos Descripci´on Ir a la pesta˜na de Partidos Establecidos. Resultado esperado Se muestra un listado completo de los partidos confirmados por el organizador. Resultado obtenido Correcto Tabla 9.23: Descripci´on del CP23 CP24 Cambiar el estado de un partido Descripci´on Seleccionar un partido de la lista, seleccionar Cambiar Estado y seleccionar el estado deseado. Resultado esperado El estado del partido se actualiza al nuevo. Resultado obtenido Correcto Tabla 9.24: Descripci´on del CP24 CP25 Crear partidos Descripci´on Ir a la pesta˜na de Crear partidos, rellenar el formulario con datos correctos y aceptar. Resultado esperado Se crea el partido con los datos recibidos. Resultado obtenido Correcto Tabla 9.25: Descripci´on del CP25 CP26 Crear partidos II Descripci´on Ir a la pesta˜na de Crear partidos, rellenar el formulario con fecha de cierre posterior a fecha del partido y aceptar. Resultado esperado Se muestra un mensaje de error estableciendo que la fecha de cierre ha de ser al menos una hora anterior a la hora del partido. Resultado obtenido Correcto Tabla 9.26: Descripci´on del CP26 CP27 Cerrar sesi´on organizador Descripci´on Ir a la pesta˜na de ajustes y seleccionar cerrar sesi´on. Resultado esperado La sesi´on de organizador se cierra y se redirecciona a la ventana de identificaci´on. Resultado obtenido Correcto Tabla 9.27: Descripci´on del CP27 68 Cap´ıtulo 10 Conclusiones 10.1. Valoraci´on personal A nivel personal este Trabajo de Fin de Grado ha sido muy enriquecedor y me ha permitido afianzar los conocimientos desarrollados a lo largo del grado de Ingenier´ıa Inform´atica y continuar con el aprendizaje en el desarrollo nativo de aplicaciones Android. Adem´as, me ha permitido planificar y documentar un proyecto software completamente, reforzando los conocimientos en Ingenier´ıa del Software, evolucionando la idea inicial hasta el producto final y empleando LaTeX para el desarrollo de una memoria completa y profesional. El desarrollo de este proyecto se presentaba como un reto complejo, ya que requer´ıa sincronizaci´on en tiempo real entre ambas aplicaciones para su correcto funcionamiento. El uso de Firebase ha simplificado en gran parte esta dificultad, permitiendo a las dos aplicaciones el acceso a una base de datos ´unica y en tiempo real. Destacar tambi´en que me ha permitido aprender a utilizar el patr´on MVVM en Android, as´ı como muchos de los componentes que ofrece Android Jetpack para el desarrollo de aplicaciones nativas, mantenibles, testeables y robustas. Para finalizar, cabe resaltar que a nivel personal y educativo ha sido una experiencia muy provechosa, en la que se han conseguido los objetivos propuestos de manera satisfactoria. 10.2. L´ıneas futuras Como trabajo futuro se podr´ıan realizar las siguientes mejoras: Redise˜no de la interfaz con las pautas marcadas por Google. Migraci´on de la aplicaci´on a Kotlin. Adici´on de test unitarios para realizar pruebas autom´aticas, r´apidas y eficientes. Posible nueva funcionalidad de competiciones, de tal forma que un club pueda crear un torneo y los jugadores se puedan inscribir y seguir los resultados a trav´es de la aplicaci´on. Integraci´on de Firebase Cloud Messaging para enviar notificaciones cada vez que se crea un partido y/o cuando se completa. Implementaci´on de m´as filtros en la b´usqueda de pistas. Implementaci´on de un historial de partidos con resultados que permita a los jugadores tener un historial completo con estad´ısticas. 69 Cap´ıtulo 11 Bibliograf´ıa [1] Elena Sanz. Espa˜na es uno de los pa´ıses europeos con m´as sedentarismo.url:https://www. muyinteresante.es/salud/articulo/espana-es-uno-de-los-paises-europeos-con-mas- sedentarismo-331380271623. (´ Ultimo acceso: 15/03/2019). [2] Android Studio. Documentaci´on de Android Studio.url:https://developer.android.com/ studio. (´ Ultimo acceso: 14/02/2019). [3] Github. P´agina de inicio de Github.url:https://github.com/. (´ Ultimo acceso: 11/03/2019). [4] Overleaf. Documentaci´on de LaTeX.url:https://www.overleaf.com/learn/latex/Main_ Page. (´ Ultimo acceso: 14/06/2019). [5] Firebase. ¿Qu´e es firebase? url:https://firebase.google.com/?hl=es-419. (´ Ultimo acceso: 14/03/2019). [6] Firebase. Firebase Authentication.url:https://firebase.google.com/docs/auth?hl=es- 419. (´ Ultimo acceso: 15/03/2019). [7] Firebase. Firebase Realtime Database.url:https://firebase.google.com/docs/database? hl=es-419. (´ Ultimo acceso: 15/03/2019). [8] Firebase. Firestore.url:https: // firebase . google. com / docs / firestore ?hl = es - 419. (´ Ultimo acceso: 25/05/2019). [9] Firebase. C´omo elegir tu base de datos: Cloud Firestore o Realtime Database.url:https : //firebase.google.com/docs/firestore/rtdb-vs-firestore?hl=es-419. (´ Ultimo acceso: 15/03/2019). [10] Firebase. Cloud Storage.url:https://firebase.google.com/docs/storage?hl=es-419. (´ Ultimo acceso: 07/04/2019). [11] ArthurHub. Android Image Cropper.url:https://github.com/ArthurHub/Android-Image- Cropper. (´ Ultimo acceso: 06/04/2019). [12] Bump Technologies. Glide.url:https : / / bumptech . github . io / glide/. (´ Ultimo acceso: 07/04/2019). [13] Google. Versiones de la plataforma.url:https://developer.android.com/about/dashboards. (´ Ultimo acceso: 18/02/2019). [14] Softeng. Proceso y roles de Scrum.url:https : / / www . softeng . es / es - es / empresa / metodologiasde- trabajo/metodologiascrum/procesoroles- descrum.html. (´ Ultimo acceso: 05/03/2019). [15] Firebase. Firebase pricing.url:https://firebase.google.com/pricing. (´ Ultimo acceso: 07/06/2019). [16] EPM. The SCRUM Process.url:https://expertprogrammanagement.com/2010/08/thescrum-process/. (´ Ultimo acceso: 05/03/2019). 70 [17] Firebase. Announcing Architecture Components 1.0 Stable.url:https://android-developers. googleblog.com/2017/11/announcing-architecture-components-10.html. (´ Ultimo acceso: 05/02/2019). [18] Android Developers. Introducci´on a Android Jetpack.url:https://developer.android.com/ jetpack?hl=ES. (´ Ultimo acceso: 09/06/2019). [19] Android Developers. Gu´ıa de arquitectura de apps.url:https://developer.android.com/ jetpack/docs/guide. (´ Ultimo acceso: 09/06/2019). [20] Resocoder. Introduction to MVVM on android.url:https://resocoder.com/2018/08/31/ introduction-to-mvvm-on-android/. (´ Ultimo acceso: 03/04/2019). [21] Firebase. Firebase and Android Jetpack: Fit Like a Glove - Doug Stevenson.url:https://www. youtube.com/watch?v=WXc4adLMDqk. (´ Ultimo acceso: 05/02/2019). [22] Firebase. Selecciona una estructura de datos.url:https://firebase.google.com/docs/ firestore/manage-data/structure-data. (´ Ultimo acceso: 13/05/2019). [23] Firebase. Cloud Firestore Data Modeling (Google I/O’19).url:https://www.youtube.com/ watch?v=lW7DWV2jST0. (´ Ultimo acceso: 18/05/2019). 71 Ap´endice A Manual de usuario A.1. Introducci´on En este ap´endice se detallar´an las funcionalidades desarrolladas para este proyecto mediante descripciones e im´agenes ilustrativas. A.2. Cribi - Aplicaci´on para los jugadores A.2.1. Identificaci´on de usuarios Figura A.1: P´agina de identificaci´on. Figura A.2: Fallo en identificaci´on. 72 A.2.2. Registro de nuevos usuarios Figura A.3: P´agina de registro de usuarios. Figura A.4: Registrando nuevo usuario. Si el registro falla, se mostrar´a un mensaje de error (Figura A.5). Si los datos son correctos, se redirige a la configuraci´on del perfil (Figura A.6). Figura A.5: Fallo al registrarse. Figura A.6: Configurar perfil de usuario. Una vez que se configura el perfil de usuario, se muestra la p´agina principal. 73 A.2.3. P´agina principal En esta pantalla podemos distinguir el men´u de navegaci´on en la Figura A.8. Como se puede observar, ser´a un men´u de navegaci´on con tres niveles: Home, Mi Perfil y Mis Partidos. Figura A.7: P´agina principal. Figura A.8: Men´u de navegaci´on. En esta navegaci´on se disponen las siguientes opciones: Home: En esta opci´on, se mostrar´a un listado completo de todos los partidos disponibles y abiertos que los clubes han publicado. M´as informaci´on en la subsecci´on A.2.4. Mi Perfil: En esta opci´on, se mostrar´a el perfil del usuario y se dispondr´a de ciertas opciones. Para m´as informaci´on, consultar la subsecci´on A.2.11. Mis Partidos: En esta opci´on, se mostrar´a un listado de los partidos a los que el propio usuario se ha inscrito. Para m´as informaci´on, consultar la subsecci´on A.2.14. A.2.4. Home En esta pantalla principal ’Home’, se dispondr´a un listado de los partidos disponibles (Figura A.9). Inicialmente estar´an todos mezclados, pero se puede realizar un filtro dependiendo de lo que el usuario est´e buscando. Para filtrar los partidos, se pulsar´ıa el bot´on de la Figura A.10. Si seleccionamos alguno de los partidos de la lista, se mostrar´ıa la informaci´on completa de ese partido. Para m´as informaci´on, en la subsecci´on A.2.6. 74 Figura A.9: Listado de partidos. Figura A.10: Filtrar partidos. A.2.5. Filtrar partidos Al pulsar dicho bot´on se despliega un modal en el cual se seleccionar´an los diferentes filtros a aplicar (Figura A.11). Una vez que se seleccionan los filtros deseados, puede ser uno o varios, se mostrar´a un listado aplicando los filtros elegidos por el usuario (Figura A.12). Al igual que en el listado anterior, si seleccionamos un partido de la lista, se mostrar´a la informaci´on completa de dicho partido. Figura A.11: Modal de selecci´on de filtros. Figura A.12: Listado de partidos filtrado. 75 A.2.6. Ver informaci´on completa del partido La pantalla de informaci´on del partido, comprende dos ´ambitos. Un ´ambito informativo (Figura A.13) y un ´ambito en el que podemos realizar ciertas acciones (Figura A.14). Figura A.13: Informaci´on del partido. Figura A.14: Acciones disponibles. En la informaci´on del partido se muestran todos los datos del mismo y se disponen dos botones. El primero de ellos es el de Ver Jugadores (V´ease subsecci´on A.2.7) en el que se muestran los jugadores inscritos al partido. En segundo lugar tenemos el bot´on de Ver Organizador (V´ease subsecci´on A.2.8) en el que se muestra el perfil del club y toda la informaci´on acerca del mismo. Las opciones disponibles depender´an del estado del partido y si el jugador ya se ha inscrito o todav´ıa no. En la Figura A.14 se muestra la opci´on de unirse al partido, puesto que el partido est´a abierto y no nos hemos inscrito a´un. Se mostrar´an a continuaci´on los dem´as casos posibles: Partido completo a la espera de confirmaci´on del organizador (Figura A.15). Partido confirmado por el organizador (Figura A.16). Partido confirmado y jugado (Figura A.17). Partido cancelado (Figura A.18). 76 Figura A.15: Partido completo. Figura A.16: Partido confirmado por el club. Figura A.17: Partido jugado. Figura A.18: Partido cancelado. A.2.7. Ver listado de jugadores inscritos Si se selecciona ver los jugadores inscritos a un partido, se mostrar´a un listado con los propios jugadores. Si no hay jugadores inscritos, se mostrar´a en pantalla (Figura A.19). En cambio, si existen jugadores inscritos, se dispondr´a un listado con la imagen de perfil y el nombre (Figura A.20). 77 Este men´u de navegaci´on cuenta con cinco niveles para facilitar la gesti´on de las pistas al organizador: Home: En esta opci´on se muestra un listado con los partidos creados por el propio organizador y que se encuentran en estado Abierto. Es decir, esperando a que se unan jugadores. Completo: En esta opci´on se muestra un listado con los partidos creados por el propio organizador y que se encuentran en estado Completo. Es decir, se han unido suficientes jugadores al partido y se est´a esperando a que el organizador confirme el partido. Establecido: En esta opci´on se muestra un listado con los partidos creados por el propio organizador y que se encuentran en estado Establecido. Es decir, se ha confirmado el partido y se est´a esperando a que se juegue. Nuevo Partido: En esta opci´on se permite al organizador crear un nuevo partido. M´as informaci´on en la secci´on A.3.5. Ajustes: En esta opci´on el organizador puede ver su perfil, editarlo y cerrar sesi´on. M´as informaci´on en la secci´on A.3.6. En cualquiera de los listados de partidos anteriores, se permite el acceso a la informaci´on completa del partido, donde se permitir´a gestionar el estado de los mismos. Para mas informaci´on, en la secci´on A.3.3. A.3.3. Ver informaci´on del partido De forma an´aloga a la aplicaci´on de los jugadores, se muestra la informaci´on de partido. La funcionalidad del listado de jugadores es similar, por lo tanto, se recomienda ver la secci´on A.2.7 del manual de usuario de Cribi. Figura A.40: Informaci´on del partido Una de las diferencias de esta pantalla respecto a la de jugadores, es que no dispondremos de la opci´on de ver el organizador puesto que es el propio usuario. La otra diferencia, es en las posibles acciones a realizar. En este caso, se podr´a cambiar el estado del partido como se muestra en la siguiente secci´on. 84 A.3.4. Cambiar estado del partido Cambiar el estado de un partido es cr´ıtico para un organizador. Es por ello que se detallar´an todos y cada uno de los posibles estados y a qu´e estados pueden cambiarse: Partido abierto: Estado en el cual se est´an buscando nuevos jugadores para que se unan al partido. El cambio es autom´atico a partido completo cuando se unen los jugadores necesarios. A´un as´ı, el organizador puede cancelar el partido. Partido completo: Estado en el cual se ha unido el n´umero de jugadores requerido para disputar el partido. El organizador podr´a cambiar el estado a establecido, o bien cancelarlo. Partido establecido: Estado en el cual el organizador ha confirmado el partido y se est´a esperando a disputarse. Puede cambiar a estado jugado y a cancelado. Partido jugado: Estado definitivo y que no puede cambiarse. Partido cancelado: Estado definitivo y que no puede cambiarse. El partido se cambiar´a utilizando el siguiente di´alogo, en el cual el organizador seleccionar´a el nuevo estado de un Spinner. Figura A.41: Cambiar estado de partido. Figura A.42: Cambio de estado ´exitoso. A.3.5. Crear nuevo partido Esta funcionalidad permitir´a al organizador crear nuevos partidos seleccionando el deporte, las fechas, la duraci´on y el precio del mismo. La fecha de cierre no podr´a ser posterior a la fecha del partido y tendr´a que dejar un margen de una hora entre ambas para que el administrador pueda confirmar el partido en el caso de que se una un jugador a ´ultima hora. 85 Figura A.43: Crear nuevo partido. Figura A.44: Creaci´on de partido con ´exito. A.3.6. Ajustes En los ajustes se mostrar´a el perfil del club tal y como lo ven los jugadores cuando lo visitan. Adem´as se a˜naden las opciones de editar perfil (Ve´ase secci´on A.3.7) y la opci´on de cerrar sesi´on que redirigir´a a la pantalla de inicio. Figura A.45: Ajustes Cribi Clubs. 86 A.3.7. Editar Perfil De forma an´aloga a la edici´on del perfil de jugadores, los organizadores tambi´en dispondr´an de esta funcionalidad. Se podr´a aportar el nombre del club, la direcci´on completa, y la informaci´on de contacto relevante. Adem´as, contar´a con un selector de im´agenes en formato cuadrado que permitir´a seleccionar el logo del club para una correcta adaptaci´on a las distintas pantallas de Cribi. Figura A.46: Editar perfil de club. Figura A.47: Selector de logo del club. 87 Ap´endice B Manual de instalaci´on Para la instalaci´on de la aplicaci´on, depender´a si se dispone del ejecutable apk, o si se necesita compilar e instalar a trav´es del proyecto de Android Studio. En el primer caso, si disponemos del ejecutable apk, los pasos a seguir ser´an los mismos de cualquier aplicaci´on Android, siendo necesarios los siguientes requisitos: Dispositivo Android con versi´on m´ınima de 4.1. Tener activada la opci´on de ((Or´ıgenes desconocidos)) en el dispositivo Android accesible desde el men´u de Ajustes. Disponer de, al menos, 20 Mb de almacenamiento disponibles. En el segundo caso, el proyecto cuenta con todo lo necesario para la correcta compilaci´on y ejecuci´on del mismo. Simplemente se tendr´ıa que abrir Android Studio, importar el proyecto adjunto en el soporte digital, compilarlo y ejecutarlo. 88 Ap´endice C Contenido del soporte digital El contenido del soporte digital entregado es el siguiente: cribi: carpeta con el proyecto de Android Studio de la aplicaci´on Cribi. Contiene todos los ficheros necesarios para importar y compilar la aplicaci´on. cribiclubs: carpeta con el proyecto de Android Studio de la aplicaci´on Cribi Clubs. Contiene todos los ficheros necesarios para importar y compilar la aplicaci´on. memoria.pdf: Documento de la memoria del TFG. Cribi.apk: Contiene el ejecutable de la aplicaci´on Cribi. CribiClubs.apk: Contiene el ejecutable de la aplicaci´on Cribi Clubs. 89