AppGenda: app Android como agenda virtual de las PYMEs de servicios de un ayuntamiento

Universidad de Valladolid ESCUELA DE INGENIER´ IA INFORM´ ATICA GRADO EN INGENIER´ IA INFORM ´ ATICA Menci´on en Ingenier´ıa del Software AppGenda: app Android como agenda virtual de las PYMEs de servicios de un Ayuntamiento Alumno: Juan Carlos Garrote Gasc´on Tutor: Yania Crespo Gonz´alez-Carvajal A mi familia, que siempre ha estado ah´ı I II AGRADECIMIENTOS Agradecimientos A mi familia, que siempre me ha apoyado y ha aguantado mis altibajos estos meses. A mis amigos, que tambi´en me han apoyado y animado a conseguir lo que me propusiese. A mis compa˜neros de carrera que se han convertido en amigos, sin vosotros no habr´ıa sido lo mismo este paso por la universidad. A los establecimientos de mi pueblo, por colaborar de manera desinteresada en este proyecto con lo que he necesitado. A Samuel Alfageme, Fernando Javier Rodr´ıguez, Alejandra Mart´ınez y Silvia Garrote, que me han ayudado de una manera u otra con ciertas tareas en algunos puntos del proyecto. A mi tutora Yania, que a pesar de trabajar de sol a sol, siempre ha sacado tiempo para atenderme y ayudarme cuando lo he necesitado. Gracias a todos III AGRADECIMIENTOS IV RESUMEN Resumen El objetivo de este proyecto es desarrollar una aplicaci´on m´ovil que permita funcionar como un sustituto de la agenda en papel de los diversos negocios que trabajan con citas y/o pedidos. Adem´as, la aplicaci´on ofrece la posibilidad de establecer una interacci´on entre los clientes y los due˜nos de negocio mediante solicitudes y sus correspondientes respuestas, as´ı como un mapa y un tabl´on de anuncios para facilitar la comunicaci´on desde los establecimientos hacia los clientes. El proyecto se ha desarrollado como una app para el sistema operativo Android, empleando Java como lenguaje de programaci´on, siguiendo las pautas marcadas por el marco de trabajo ´agil Scrum as´ı como una gu´ıa de buenas pr´acticas y de estilo para conseguir un producto de alta calidad. V RESUMEN VI ABSTRACT Abstract The aim of this project is to develop a mobile application which allows to work as a substitute for the paper agenda of the various businesses that work with appointments and/or orders. Moreover, the application offers the possibility to establish an interaction between the clients and the business owners through requests and their corresponding replies, as well as a map and a noticeboard to facilitate communication from the establishments towards the clients. The project has been developed as an app for Android operating system, using Java as programming language, following the guidelines set by Scrum agile framework as well as a guide of best practices and of style to get a high quality product. VII ´ INDICE GENERAL XIV LISTA DE FIGURAS Lista de Figuras 2.1. Roles en el equipo Scrum y sus relaciones [129] . . . . . . . . . . . . . . . . . 11 2.2. Eventos y artefactos en Scrum [83] . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Sistema de ramas en Git [26] ........................... 28 3.2. Guardando cambios en local con Git [44]..................... 28 3.3. Tablero GitLab Issue Board (parte1)....................... 31 3.4. Tablero GitLab Issue Board (parte2)....................... 31 3.5. Uso de fragmentos y su flexibilidad en tama˜nos distintos de pantallas [13] . . 34 3.6. Ciclo de vida de un fragmento [13] . . . . . . . . . . . . . . . . . . . . . . . . 35 3.7. Efecto del ciclo de vida de la actividad sobre el ciclo de vida de sus fragmentos [13].......................................... 35 3.8. Gr´afico de navegaci´on del componente Navigation [17] ............. 36 4.1. Modelo de dominio inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2. Modelo de dominio inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.1. Relaciones entre partes en el patr´on arquitect´onico MVVM [77] . . . . . . . . 53 5.2. Ciclo de vida de un ViewModel [10]........................ 54 5.3. Patr´onDAO/DTO[71] .............................. 55 5.4. Patr´onFactor´ıa[65] ................................ 56 5.5. Patr´on Adaptador [123] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 XV LISTA DE FIGURAS 5.6. Patr´onAdaptador[89]............................... 58 5.7. Vista principal de “Sitios” - Cliente ....................... 60 5.8. Establecimiento seleccionado - Cliente ...................... 60 5.9. Pedir cita (seleccionar d´ıa) - Cliente ....................... 60 5.10. Pedir cita (seleccionar franja horaria) - Cliente ................. 60 5.11. Pedir cita (detalles de la cita) - Cliente ..................... 61 5.12. Solicitudes de cita - Due˜no de negocio ...................... 61 5.13. Rechazo de cita - Due˜no de negocio ........................ 61 5.14. Confirmaci´on de cita - Cliente ........................... 61 5.15. Rechazo de cita - Cliente ............................. 62 5.16. Citas solicitadas - Cliente ............................. 62 5.17. Vista principal de “Agenda” - Due˜no de negocio ................ 62 5.18. Mis citas (calendario) - Due˜no de negocio .................... 62 5.19. Mis citas (horas) - Due˜no de negocio ....................... 63 5.20. Mis citas (detalles de una cita) - Due˜no de negocio ............... 63 5.21. A˜nadir nueva cita - Due˜no de negocio ...................... 63 5.22. Hacer pedido (seleccionar d´ıa) - Cliente ..................... 63 5.23. Hacer pedido (seleccionar franja horaria) - Cliente ............... 64 5.24. Hacer pedido (detalles del pedido) - Cliente ................... 64 5.25. Solicitudes de pedido - Due˜no de negocio .................... 64 5.26. Rechazo de pedido - Due˜no de negocio ...................... 64 5.27. Confirmaci´on de pedido - Cliente ......................... 65 5.28. Rechazo de pedido - Cliente ............................ 65 5.29. Pedidos solicitados - Cliente ............................ 65 5.30. Mis pedidos (calendario) - Due˜no de negocio .................. 65 5.31. Mis pedidos (horas) - Due˜no de negocio ..................... 66 XVI LISTA DE FIGURAS 5.32. Mis pedidos (detalles de una franja horaria) - Due˜no de negocio ........ 66 5.33. A˜nadir nuevo pedido - Due˜no de negocio ..................... 66 5.34. Vista principal de “Mapa” - Cliente ....................... 66 5.35. Vista principal de “Mapa” - Due˜no de negocio ................. 67 5.36. Vista principal de ”Tabl´on” - Cliente ....................... 67 5.37. Vista principal de “Tabl´on” - Due˜no de negocio ................. 67 5.38. Crear nuevo anuncio - Due˜no de negocio ..................... 67 5.39. Login de la app - Usuario no identificado .................... 68 5.40. Elecci´on de registro - Usuario no identificado .................. 68 5.41. Registro de nuevo cliente - Usuario no identificado ............... 68 5.42. Registro de nuevo establecimiento - Usuario no identificado .......... 68 5.43. Solicitudes de registro de nuevos establecimientos - Administrador ...... 69 5.44. Rechazo de nuevo establecimiento - Administrador ............... 69 5.45. Gesti´on de establecimientos - Administrador ................... 69 5.46. Gesti´on de un establecimiento - Administrador ................. 69 5.47. Logo de AppGenda ................................ 70 5.48.Iconodelaapp................................... 70 5.49. Avatar de usuario por defecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.50. Imagen de anuncio por defecto . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.51. Arquitectura general de la aplicaci´on . . . . . . . . . . . . . . . . . . . . . . . 72 5.52. Decomposition&Uses style del paquete views .................. 73 5.53. Decomposition&Uses style del paquete viewmodels .............. 74 5.54. Decomposition&Uses style del paquete daos ................... 74 5.55. Decomposition&Uses style del paquete entities ................. 75 5.56. Diagrama de secuencia principal de la HU02 .................. 77 5.57. Diagrama de secuencia de “Encontrar vistas, argumentos y crear ViewModel” 78 XVII LISTA DE FIGURAS 5.58. Diagrama de secuencia de “Obtener citas ViewModel” . . . . . . . . . . . . . 80 5.59. Diagrama de secuencia de “Obtener citas DAO” . . . . . . . . . . . . . . . . 81 5.60. Diagrama de secuencia de “Obtener citas onSuccess” ............. 83 5.61. Diagrama de secuencia de “Obtener citas VMCallback” . . . . . . . . . . . . 84 5.62. Decomposition&Uses style de la HU02 ...................... 85 5.63. Diagrama de despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 6.1. Resultado de la ejecuci´on de los tests unitarios . . . . . . . . . . . . . . . . . 97 6.2. Resultado de la ejecuci´on de los tests de IU . . . . . . . . . . . . . . . . . . . 98 A.1.Men´ulateral .................................... 146 A.2.Iniciarsesi´on .................................... 146 A.3.Registro....................................... 146 A.4.Secci´on“Agenda”.................................. 147 A.5.Selecci´onded´ıa................................... 147 A.6.Horariodecitas................................... 147 A.7.Detallesdeunacita ................................ 147 A.8.Crearnuevacita .................................. 147 A.9.Horariodepedidos................................. 148 A.10.Listadepedidos .................................. 148 A.11.Crearnuevopedido................................. 148 A.12.Men´u lateral de due˜no de negocio . . . . . . . . . . . . . . . . . . . . . . . . . 149 A.13.Solicitudesdecita ................................. 149 A.14.Rechazo de solicitud de cita . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 A.15.Secci´on“Mapa”................................... 149 A.16.Secci´on“Tabl´on”.................................. 149 A.17.Crearnuevoanuncio ................................ 149 XVIII LISTA DE FIGURAS A.18.Secci´on“Sitios”................................... 150 A.19.Ficha de establecimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 A.20.Solicitarunacita.................................. 151 A.21.Solicitarunpedido................................. 151 A.22.Men´u lateral de cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 A.23.Citassolicitadas .................................. 152 A.24.Pedidossolicitados ................................. 152 XIX LISTA DE FIGURAS XX LISTA DE TABLAS Lista de Tablas 2.1. Planificaci´on inicial de sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2. Riesgo R01: Ausencia temporal del estudiante por enfermedad . . . . . . . . . 16 2.3. Riesgo R02: Fallos t´ecnicos en el equipo de trabajo del estudiante . . . . . . . 17 2.4. Riesgo R03: Ausencia temporal de la tutora por enfermedad . . . . . . . . . . 17 2.5. Riesgo R04: Confinamiento domiciliario debido a COVID-19 . . . . . . . . . . 18 2.6. Riesgo R05: Mala estimaci´on de tiempo y trabajo de algunas actividades . . . 18 2.7. Riesgo R06: Desconocimiento del manejo de las herramientas que hay que utilizar........................................ 19 2.8. Riesgo R07: Menor tiempo empleado que el previsto debido a otros asuntos acad´emicos ..................................... 19 2.9. Riesgo R08: Cambio en los requisitos del proyecto . . . . . . . . . . . . . . . . 20 2.10. Riesgo R09: Necesidad de aprendizaje de nuevas herramientas debido a actualizaciones en las tecnolog´ıas utilizadas . . . . . . . . . . . . . . . . . . . . . . 20 2.11.Presupuestosimulado ............................... 22 2.12.Presupuestoreal .................................. 23 2.13. Product Backlog inicial............................... 24 2.14. Product Backlog final................................ 25 4.1. Historias de usuario de la ´epica EP01 ...................... 42 4.2. Historias de usuario de la ´epica EP02 ...................... 42 4.3. Historias de usuario de la ´epica EP03 ...................... 42 XXI LISTA DE TABLAS 4.4. Historias de usuario de la ´epica EP04 ...................... 43 4.5. Historias de usuario de la ´epica EP05 ...................... 43 4.6. Historias de usuario de la ´epica EP06 ...................... 43 4.7. Historias de usuario de la ´epica EP07 ...................... 43 4.8. Historias de usuario de la ´epica EP08 ...................... 44 4.9. Historias de usuario de la ´epica EP09 ...................... 44 4.10. Historias de usuario de la ´epica EP10 ...................... 44 4.11. Requisitos de informaci´on como historias de usuario . . . . . . . . . . . . . . 45 4.12. Requisitos no funcionales como historias de usuario . . . . . . . . . . . . . . . 46 4.13. Restricciones como historias de usuario . . . . . . . . . . . . . . . . . . . . . . 46 6.1. Resultados del test de usabilidad en due˜nos de negocio . . . . . . . . . . . . . 100 6.2. Resultados del test de usabilidad en clientes . . . . . . . . . . . . . . . . . . . 101 7.1. Tareasdelsprint1 ................................. 108 7.2. Tareasdelsprint2 ................................. 110 7.3. Tareasdelsprint3 ................................. 111 7.4. Tareas de la ampliaci´on del sprint 3 . . . . . . . . . . . . . . . . . . . . . . . 112 7.5. Tareasdelsprint4 ................................. 114 7.6. Tareasdelsprint5 ................................. 115 7.7. Tareasdelsprint6 ................................. 118 7.8. Tareasdelsprint7 ................................. 120 7.9. Tareasdelsprint8 ................................. 122 7.10. Tareas del sprint extra 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 7.11. Tareas del sprint extra 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 7.12.Costesimuladofinal ................................ 129 7.13.Costerealfinal ................................... 130 XXII CAP´ ITULO 1. INTRODUCCI ´ ON Cap´ıtulo 1 Introducci´on 1.1. Contexto Actualmente, las tecnolog´ıas m´oviles est´an en pleno auge. En concreto, a fecha de enero de 2021, en el mundo existen 5,22 mil millones de usuarios de dispositivos m´oviles, representando al 66,6 % de la poblaci´on mundial. Es decir, 2 de cada 3 personas en el mundo tienen a su disposici´on un dispositivo m´ovil. Asimismo, del total de usuarios de Internet, 91,5 % de ellos acceden desde un tel´efono inteligente o smartphone [127]. En un pa´ıs como Espa˜na, las cifras se disparan hasta un 97,8 % de ciudadanos desde los 16 hasta los 64 a˜nos con un dispositivo m´ovil inteligente en su posesi´on, a fecha de enero de 2021, y siendo un 92,1 % los usuarios que acceden a Internet desde un tel´efono inteligente [126]. Ambas cifras van en aumento cada a˜no, lo que refleja el gran uso cotidiano que se da a estas tecnolog´ıas. Por otro lado, cada vez existen m´as innovaciones tecnol´ogicas en el mundo de las empresas, lo que fomenta la introducci´on de nuevas tecnolog´ıas en las mismas, entre ellas, los smartphones, un elemento cada vez m´as habitual en cada uno de los aspectos del d´ıa a d´ıa como acabamos de ver, y por tanto cada vez m´as accesible a un p´ublico m´as general. Adem´as, la situaci´on actual provocada por el COVID-19 ha impulsado a utilizar a´un m´as ampliamente las tecnolog´ıas para facilitar la vida de las personas, que se ha visto muy afectada por las restricciones que este contexto sanitario implica. Las peque˜nas y medianas empresas han sido uno de los sectores de la econom´ıa m´as afectados, y aunque est´an en proceso de recuperaci´on, todav´ıa queda un largo camino por recorrer, en el que todo apoyo es bien recibido. AppGenda nace en medio de toda esta situaci´on para aprovechar la extendida utilizaci´on de la tecnolog´ıa m´ovil y constituir una herramienta de utilidad tanto para negocios y servicios como para los clientes de los mismos, permitiendo gestionar conjuntamente citas y pedidos y ofreciendo otras funcionalidades que una agenda de papel no podr´ıa llevar a cabo. 1 1.6. ESTRUCTURA DE LA MEMORIA continua que se ha llevado a cabo y las distintas pruebas que se han realizado para la aplicaci´on. Tambi´en se expondr´an las principales dificultades en la implementaci´on surgidas a lo largo del proyecto. Cap´ıtulo 7: Seguimiento del proyecto. En este cap´ıtulo se presenta c´omo ha avanzado el proyecto, qu´e incidencias y eventos han ocurrido y un detalle de los distintos pasos seguidos para el desarrollo del mismo. Cap´ıtulo 8: Conclusiones. En este cap´ıtulo se expondr´an las conclusiones finales obtenidas, y algunas propuestas que se podr´ıan llevar a cabo en el futuro del proyecto. Finalmente, se incluyen unos anexos con otro contenido como el manual de usuario, despliegue, y otros enlaces de inter´es. 8 CAP´ ITULO 2. PLANIFICACI ´ ON Y REQUISITOS Cap´ıtulo 2 Planificaci´on y requisitos 2.1. Scrum El marco de trabajo elegido para la realizaci´on de este proyecto ha sido Scrum. Scrum se enmarca dentro de los procesos ´agiles de desarrollo de software, que tal y como se declar´o en 2001 en el Manifiesto ´agil [69], se caracterizan por cuatro valores fundamentales: Individuos e interacciones por encima de procesos y herramientas. Software funcionando por encima de documentaci´on extensiva. Colaboraci´on con el cliente por encima de negociaci´on de contrato. Respuesta ante el cambio por encima de seguir un plan. M´as a fondo, Scrum [29] es un marco de referencia en el que un equipo ´unico y reducido desarrolla, entrega y mantiene productos complejos a trav´es de un enfoque iterativo e incremental en bloques temporales cortos y fijos, gestionando en lo posible la incertidumbre y por tanto el riesgo asociado a la misma. El proceso se basa en tres pilares [68]: Transparencia. El trabajo debe ser visible para los que lo realizan as´ı como para los que lo reciben, dado que muchas decisiones importantes se basan en la percepci´on del mismo. Inspecci´on. El progreso del trabajo y el cumplimiento de objetivos debe ser revisado frecuentemente, para evitar problemas o sesgos indeseados en el producto Adaptaci´on. Si el trabajo, tanto el proceso en s´ı como el producto, se desv´ıa de lo deseado, se debe ajustar tan pronto como sea posible para evitar m´as desviaci´on. 9 2.1. SCRUM Es por ello que Scrum es adecuado para proyectos con un car´acter exploratorio y/o con una alta incertidumbre, es decir, que pueden ser propensos a sufrir muchos cambios, y que requieren de continua retroalimentaci´on por tratarse de proyectos complejos. Estos proyectos suelen implicar tambi´en equipos multifuncionales altamente cualificados, un entorno de desarrollo hipercompetitivo y que se est´e trabajando con productos tecnol´ogicos de vanguardia. Dentro de Scrum, existen tres componentes esenciales para su desarrollo, que se explicar´an en las siguientes subsecciones: roles,eventos yartefactos. 2.1.1. Roles El equipo Scrum es un grupo peque˜no auto-organizado (internamente eligen la mejor forma de realizar su trabajo) y multifuncional (disponen de todas las habilidades necesarias para crear valor, sin depender de alguien externo al equipo). Dentro del equipo, se distinguen tres roles [68]: Product Owner. Es el propietario de la iniciativa y el responsable de maximizar el valor del producto. Toda la organizaci´on debe respetar sus decisiones, que se reflejan en el Product Backlog, artefacto que se explicar´a en la subsecci´on correspondiente (Secci´on 2.1.3). Scrum Master. Es el que se encarga de impulsar todas las pr´acticas Scrum en el equipo y el responsable de la eficacia del mismo. Adem´as, es el punto de comunicaci´on entre el equipo y toda la organizaci´on. Equipo de desarrollo. Son el resto de personas del equipo Scrum, responsables de desarrollar el producto para aportar valor en cada incremento, artefacto que se explicar´a en la Secci´on 2.1.3, dedicada a los artefactos. En la Figura 2.1 se puede observar de manera m´as gr´afica los distintos roles involucrados en el equipo Scrum y las relaciones entre ellos. 2.1.2. Eventos En el marco de trabajo de Scrum existen diversos eventos, que tienen lugar con el objetivo de cumplir con los tres pilares principales explicados anteriormente. Estos eventos, de periodicidad y duraci´on definida, tratan de minimizar la necesidad de reuniones adicionales no definidas en el marco original. Son los siguientes [68]: Sprint. Es el contenedor para el resto de eventos de Scrum. Los sprints son per´ıodos de tiempo de duraci´on fijada, entre 1 y 4 semanas, que ocurren secuencialmente uno 10 CAP´ ITULO 2. PLANIFICACI ´ ON Y REQUISITOS Figura 2.1. Roles en el equipo Scrum y sus relaciones [129] tras otro a lo largo de todo el proceso de desarrollo del proyecto. Durante un sprint, los requisitos no se deben cambiar, pero pueden servir para aprender y hacer cambios en sprints futuros. El artefacto resultante del desarrollo de un sprint es un incremento (Secci´on 2.1.3). Sprint Planning. Es el evento que da comienzo a un sprint y en el que se planifica cu´al ser´a el contenido y los objetivos del sprint. En esta reuni´on participan todos los componentes del equipo Scrum, y se seleccionan los ´ıtems del Product Backlog (Secci´on 2.1.3), ya priorizados, que se pretender´an realizar en el sprint que se est´a planificando. Para ello, a las distintas tareas se les asigna una estimacion basada en puntos de historia, que a su vez se traduce en tiempo estimado de trabajo. El resultado de este evento es el Sprint Backlog (Secci´on 2.1.3). Daily Scrum. Es una reuni´on diaria de alrededor de 15 minutos en la que cada componente del equipo de desarrollo informa a los dem´as sobre su progreso desde la ´ultima reuni´on Daily Scrum, y el plan de trabajo hasta la pr´oxima Daily Scrum. El objetivo es mejorar la comunicaci´on y solventar cualquier impedimento que pueda ocurrir a los miembros del equipo de desarrollo. Sprint Review. Es una reuni´on que ocurre al final del sprint, en la que el equipo Scrum al completo y los clientes discuten sobre los objetivos que se han cumplido en el sprint, para poder decidir qu´e hacer en el siguiente. Si es necesario, puede haber ajustes en el Product Backlog (Secci´on 2.1.3). Sprint Retrospective. Es el evento que finaliza el sprint. En ´el, se eval´ua el sprint al que dar´a fin, de manera que se saquen conclusiones sobre qu´e ha ido bien, qu´e problemas se han encontrado y qu´e cambios se pueden hacer para mejorar en sprints futuros. 11 2.2. ADAPTACI ´ ON DE SCRUM AL PROYECTO 2.1.3. Artefactos El resultado de las distintas actividades en Scrum se materializa en artefactos, que representan trabajo o valor. El objetivo de los mismos es maximizar la transparencia de la informaci´on clave para todas las partes involucradas. Los artefactos considerados en Scrum son [68]: Product Backlog. Es una lista ordenada por prioridad de las caracter´ısticas y mejoras que se desean a˜nadir al producto, en forma de historias de usuario. El principal responsable del mismo es el Product Owner, como ya se ha visto, y es variable a lo largo del proyecto. El objetivo que se persigue es el Product Goal, que define un estado futuro del producto al que se desea llegar. Sprint Backlog. Es la lista de historias de usuario pertenecientes al Product Backlog en las que el equipo de desarrollo pretende trabajar en un sprint. Los responsables de este artefacto son los componentes del equipo de desarrollo, y es el que utilizan para actualizar su situaci´on en las Daily Scrum. La meta a alcanzar en este artefacto es el Sprint Goal, que define el objetivo a cumplir en el sprint, pero que a su vez es flexible en t´erminos del trabajo realizado para conseguirlo. Incremento. Es el resultado del trabajo realizado en un sprint. Cada incremento es acumulativo con los incrementos de sprints anteriores, fusionando todos ellos para acercarse al objetivo final actual del proyecto, el Product Goal. Los responsables del mismo son los miembros del equipo de desarrollo. El incremento debe cumplir con las condiciones establecidas para ser utilizable, dado que ser´a lo que se entregue al cliente al final del sprint. Estas condiciones conforman la Definition of Done oDefinici´on de Hecho, que es el objetivo a perseguir con la realizaci´on de cada incremento. En la Figura 2.2 aparece un resumen gr´afico de los eventos y artefactos involucrados en el proceso de Scrum. 2.2. Adaptaci´on de Scrum al proyecto La decisi´on de utilizar Scrum como marco de trabajo para este proyecto se basa en varios factores. Primero, como se trata de un proyecto que surge de una idea con unos requisitos no muy definidos desde el principio, la flexibilidad que proporciona Scrum es ideal para los cambios que puedan producirse a lo largo del mismo. Tambi´en, el seguimiento del proyecto por parte de la tutora ser´a constante semanalmente, asegurando una retroalimentaci´on que permitir´a mejorar seg´un se progrese. Por otro lado, Scrum es ahora mismo una de las formas de desarrollo ´agil m´as aplicadas en las empresas del sector, por lo que aplicarlo tambi´en a este proyecto permitir´a poner en pr´actica y aprender una de las formas de trabajo m´as demandadas en la actualidad. 12 CAP´ ITULO 2. PLANIFICACI ´ ON Y REQUISITOS Figura 2.2. Eventos y artefactos en Scrum [83] La flexibilidad de Scrum tambi´en permite aplicarlo como marco de referencia en diversos contextos, poni´endose de manifiesto su adaptabilidad. En este proyecto, debido a sus caracter´ısticas especiales (como la limitaci´on de personal), se ha tenido que aplicar una adaptaci´on de Scrum. En cuanto a roles, dado que s´olo dos miembros estar´an involucrados en el desarrollo del proyecto (estudiante autor del TFG y tutora), la adaptaci´on ha sido la siguiente: el estudiante cumplir´a simult´aneamente con los papeles de Product Owner y equipo de desarrollo, mientras que la tutora cumplir´a con el papel de Scrum Master. De esta manera, el estudiante se encargar´a de la idea del producto y la priorizaci´on de sus caracter´ısticas, as´ı como del desarrollo del mismo, y la tutora se encargar´a de revisar que se cumple con las pr´acticas Scrum de forma correcta y de asesorar al estudiante en distintos aspectos. En cuanto a eventos, los sprints del proyecto tendr´an una duraci´on de 2 semanas. Las reuniones de Sprint Planning,Sprint Review ySprint Retrospective tendr´an lugar cada 2 semanas, justo en el d´ıa en el que se termina un sprint y se comienza el siguiente. El d´ıa elegido para hacerlo han sido los mi´ercoles. Las reuniones Daily Scrum se han convertido en Weekly Scrum, que se realizar´an una vez por semana, en las semanas que no se empiece ni finalice un sprint. Es decir, todos los mi´ercoles se celebrar´a una reuni´on entre el estudiante y la tutora, y dependiendo del punto temporal del sprint en el que se encuentre, dicha reuni´on tendr´a un prop´osito u otro. En cuanto a artefactos, tanto Product Backlog como Sprint Backlog como incremento, estar´an a cargo del estudiante, ya que asume todos los roles responsables de los mismos. 13 2.3. PLANIFICACI ´ ON INICIAL 2.3. Planificaci´on inicial Se ha establecido una planificaci´on inicial con un calendario de sprints. Dada la fecha de inicio del proyecto y que seg´un la gu´ıa docente [115] la realizaci´on del Trabajo de Fin de Grado se corresponde con 12 ECTS, es decir, 300 horas, se ha decidido elaborar un plan inicial basado en 8 sprints. Como cada sprint tiene una duraci´on fija (2 semanas) pero la carga de trabajo asociada al mismo puede ser variable entre sprints, se prev´e dedicar aproximadamente de 15 a 25 horas semanales, lo que resulta en sprints de 30 a 50 horas, en funci´on del tiempo disponible debido a otros motivos acad´emicos. Esto se decide en la reuni´on Sprint Planning de preparaci´on de cada sprint, y el m´etodo que se ha utilizado para ello son los puntos de historia. A cada historia de usuario perteneciente al Product Backlog se le asignar´a una estimaci´on de puntos de historia para poder ajustar el Sprint Backlog correspondiente al tiempo disponible. En este caso, la equivalencia utilizada ha sido de 1 punto de historia ≃5 horas. La planificaci´on inicial incluye un sprint 0, que se diferencia de los dem´as por tener una duraci´on distinta. El objetivo de este sprint es dedicar las primeras semanas del proyecto a labores de preparaci´on y planificaci´on, para en el sprint 1 dar paso al desarrollo del proyecto como tal. Asimismo, se incluyen al final 2 sprints extra de refuerzo, a modo de ofrecer un margen en caso de que el trabajo deseado no se haya podido completar en el transcurso de los 8 sprints principales, y para hacer retoques finales tanto en documentaci´on como en material presentado (c´odigo, modelos, etc.). Dado que los sprints tendr´an una carga de trabajo de 30 a 50 horas, dependiendo de las circunstancias en el sprint, si tomamos como promedio que los sprints tendr´an una carga de 40 horas cada uno, en total se sumar´ıan 320 horas. A˜nadiendo adem´as el tiempo empleado en el sprint 0, que es en el que se ha desarrollado esta planificaci´on y por tanto se sabe que tuvo una carga de alrededor de 20 horas, la estimaci´on inicial queda en 340 horas, que satisfar´ıa las 300 horas requeridas. En caso de necesidad, se utilizar´ıa uno o los dos sprints extra de refuerzo, que considerando tambi´en un promedio de 40 horas para cada uno, elevar´ıa la estimaci´on inicial a 380 horas en caso de utilizar uno y a 420 horas en caso de utilizar los dos, cumpliendo con creces con la cantidad de horas requeridas y dejando un margen muy amplio para los inconvenientes que puedan surgir a lo largo del proyecto. En la Tabla 2.1 se puede observar una calendarizaci´on de los sprints y eventos planificados para el transcurso del proyecto. 2.4. Plan de riesgos En la fase de planificaci´on, tambi´en se ha elaborado un plan de riesgos. Como en todo proyecto, tras hacer un plan inicial, hay un componente de incertidumbre que hay que gestionar, pues todo se basa en suposiciones y pueden darse situaciones que hagan que esas suposiciones se vuelvan incorrectas. Un riesgo [29] es un suceso relacionado con el futuro que involucra causa y efecto. En este contexto, la ocurrencia del riesgo afectar´a al desarrollo del proyecto. Es por ello que es 14 CAP´ ITULO 2. PLANIFICACI ´ ON Y REQUISITOS NºSprint/Evento Fecha inicio Fecha fin Anotaciones Sprint 0 19/01/2021 10/02/2021 Sprint Review,Sprint Retrospective &Sprint Planning 10/02/2021 Sprint 1 10/02/2021 24/02/2021 Scrum Weekly 17/02/2021 Sprint Review,Sprint Retrospective &Sprint Planning 24/02/2021 Sprint 2 24/02/2021 10/03/2021 Scrum Weekly 03/03/2021 Sprint Review,Sprint Retrospective &Sprint Planning 10/03/2021 Sprint 3 10/03/2021 24/03/2021 Scrum Weekly 17/03/2021 Sprint Review,Sprint Retrospective &Sprint Planning 24/03/2021 - 24/03/2021 06/04/2021 Per´ıodo de vacaciones de Semana Santa Sprint 4 06/04/2021 21/04/2021 Scrum Weekly 14/04/2021 Sprint Review,Sprint Retrospective &Sprint Planning 21/04/2021 Sprint 5 21/04/2021 05/05/2021 Scrum Weekly 28/04/2021 Sprint Review,Sprint Retrospective &Sprint Planning 05/05/2021 Sprint 6 05/05/2021 19/05/2021 Scrum Weekly 12/05/2021 Sprint Review,Sprint Retrospective &Sprint Planning 19/05/2021 Sprint 7 19/05/2021 02/06/2021 Scrum Weekly 26/05/2021 Sprint Review,Sprint Retrospective &Sprint Planning 02/06/2021 Sprint 8 02/06/2021 16/06/2021 Scrum Weekly 09/06/2021 Sprint Review & Sprint Retrospective 16/06/2021 Tambi´en se realizar´a Sprint Planning en caso de utilizar el pr´oximo sprint Sprint extra 1 16/06/2021 30/06/2021 Scrum Weekly 23/06/2021 L´ımite solicitud defensa convocatoria ordinaria 28/06/2021 Los tribunales se realizar´an antes del 12/07/2021 Sprint Review & Sprint Retrospective 30/06/2021 Se podr´a adelantar en caso de presentar el TFG en convocatoria ordinaria. Tambi´en se realizar´a Sprint Planning en caso de utilizar el pr´oximo sprint Sprint extra 2 30/06/2021 14/07/2021 Scrum Weekly 07/07/2021 Sprint Review & Sprint Retrospective 14/07/2021 L´ımite solicitud defensa convocatoria extraordinaria 19/07/2021 Los tribunales se realizar´an antes del 28/07/2021 Tabla 2.1. Planificaci´on inicial de sprints 15 2.4. PLAN DE RIESGOS importante la elaboraci´on de un plan de riesgos, cuyo objetivo es controlar en lo posible la ocurrencia y las consecuencias de los mismos. En este caso, para la identificaci´on y an´alisis de los riesgos, se han tenido en cuenta cuatro elementos asociados a cada riesgo: Probabilidad. Se trata de la posibilidad de que el riesgo se pueda materializar. Se le asigna uno de los siguientes valores: {baja, media, alta}. Impacto. Se trata del nivel del efecto que producir´ıa el riesgo en caso de materializarse. Se le asigna uno de los siguientes valores: {bajo, medio, alto}. Plan de mitigaci´on. Se trata de una serie de acciones que se pueden llevar a cabo para reducir la probabilidad de que el riesgo ocurra. Plan de contingencia. Se trata de una serie de acciones que se pueden llevar a cabo una vez que el riesgo se presenta, para minimizar en lo posible su impacto. De esta manera, adem´as de identificar cada riesgo, se dispone de una lista de acciones a llevar a cabo a priori y a posteriori para gestionar la ocurrencia de los mismos y as´ı minimizar el efecto final que puedan producir en el correcto desarrollo del proyecto. Los riesgos identificados se han dividido en dos categor´ıas: riesgos generales, que podr´ıan ocurrir en cualquier contexto, independientemente del proyecto que se llevar´a a cabo, y riesgos particulares, que tienen en cuenta las caracter´ısticas espec´ıficas de este proyecto. Los riesgos generales se presentan en las Tablas 2.2 a 2.8, y los riesgos particulares en las Tablas 2.9 a 2.10. Riesgo R01 T´ıtulo Ausencia temporal del estudiante por enfermedad Descripci´on El estudiante no puede dedicar tiempo a trabajar en el TFG durante un per´ıodo determinado debido a causas m´edicas que le impidan trabajar con normalidad Probabilidad Media Impacto Bajo Plan de mitigaci´on Llevar una vida saludable Evitar actividades que supongan un riesgo para la salud Plan de contingencia Si la duraci´on de la ausencia es unos d´ıas, tratar de recuperar el tiempo perdido distribuy´endolo entre los siguientes d´ıas Si la duraci´on es m´as prolongada, pasar tareas al siguiente sprint Si ocurre en los ´ultimos sprints y las dos anteriores no se pueden realizar, hacer uso de los sprints extra de refuerzo Tabla 2.2. Riesgo R01: Ausencia temporal del estudiante por enfermedad 16 CAP´ ITULO 2. PLANIFICACI ´ ON Y REQUISITOS Riesgo R02 T´ıtulo Fallos t´ecnicos en el equipo de trabajo del estudiante Descripci´on El equipo de trabajo del estudiante sufre alg´un fallo t´ecnico y no se puede continuar trabajando con normalidad Probabilidad Baja Impacto Medio Plan de mitigaci´on Hacer una copia de seguridad de los documentos importantes cada poco tiempo Mantener una copia de los documentos importantes en alg´un repositorio online Trabajar en lo posible de forma online con los documentos (Overleaf, Microsoft Teams...) Plan de contingencia Si se ha realizado copias de seguridad de los documentos, recuperarlos desde otro dispositivo para seguir trabajando Si no se ha realizado copias de seguridad, tratar de recuperar los documentos con los mecanismos de recuperaci´on que ofrecen los propios programas Tabla 2.3. Riesgo R02: Fallos t´ecnicos en el equipo de trabajo del estudiante Riesgo R03 T´ıtulo Ausencia temporal de la tutora por enfermedad Descripci´on La tutora no puede continuar con el seguimiento del TFG durante un per´ıodo determinado debido a causas m´edicas que le impidan trabajar con normalidad Probabilidad Media Impacto Bajo Plan de mitigaci´on Tener contacto asiduamente para poder saber si el riesgo se materializa en alg´un momento Plan de contingencia Seguir trabajando en el TFG hasta poder tener la siguiente reuni´on con la tutora, e ir apuntando dudas o problemas que surjan Si es posible comunicarse mediante otros medios que no sean videoconferencia (chats, emails...), enviar dudas o un resumen del contenido que se ver´ıa en la reuni´on Tabla 2.4. Riesgo R03: Ausencia temporal de la tutora por enfermedad 17 2.7. PRODUCT BACKLOG FINAL N´umero ´ Epica 1 Como due˜no de negocio quiero gestionar las citas de los clientes en mi establecimiento para poder tener una gesti´on centralizada del mismo junto a los pedidos en un solo sitio 2 Como due˜no de negocio quiero gestionar los pedidos de los clientes en mi establecimiento para poder tener una gesti´on centralizada del mismo junto a las citas en un solo sitio 3 Como cliente quiero hacer solicitudes de citas a los establecimientos registrados para facilitar la tarea de pedir cita y poder tener centralizados todos los establecimientos en un solo sitio 4 Como cliente quiero hacer solicitudes de pedidos a los establecimientos registrados para facilitar la tarea de hacer pedidos y poder tener centralizados todos los establecimientos en un solo sitio 5Como cliente quiero ver si mis solicitudes de cita o pedido han sido confirmadas por el establecimiento para poder asegurar el servicio que he solicitado 6Como due˜no de negocio quiero poder publicar en el mapa interactivo de establecimientos la ubicaci´on del m´ıo para permitir a los usuarios encontrarlo m´as f´acilmente 7Como cliente quiero ver en el mapa interactivo los distintos establecimientos registrados y su ubicaci´on para poder llegar a ellos m´as f´acilmente 8Como due˜no de negocio quiero poder hacer publicaciones sobre mi negocio en el tabl´on de anuncios para proporcionar informaci´on a los clientes 9Como cliente quiero consultar anuncios publicados por los establecimientos en el tabl´on de anuncios para recibir distintas informaciones de los mismos 10 Como due˜no de negocio quiero notificar a los clientes con citas previas si existe alg´un retraso para evitar esperas innecesarias de los clientes y aglomeraciones o saturaci´on en el establecimiento 11 Como cliente quiero que se me notifique cuando exista un retraso en mis citas en los establecimientos para evitar esperas innecesarias 12 Como administrador quiero aprobar las solicitudes de registro de nuevos establecimientos para incluir nuevos negocios a la app 13 Como administrador quiero gestionar establecimientos para ofrecerles todas las funcionalidades de la app Tabla 2.13. Product Backlog inicial 2.7. Product Backlog final Tras diversos cambios durante el transcurso de los sprints del proyecto, y como bien permite Scrum modificar el Product Backlog inicial entre sprint y sprint, el aspecto final del Product Backlog es el que se muestra en la Tabla 2.14. En este caso se ha asignado un c´odigo identificativo a las ´epicas para poder referenciarlas m´as tarde en el documento, ya que son las que se utilizar´an durante el desarrollo del proyecto. Uno de los cambios llevados a cabo consiste en la introducci´on de una nueva ´epica (EP06), ya que previamente no exist´ıa una que se dirigiera expresamente a la gesti´on de usuarios y se decidi´o que era mejor tratarlo como un requisito independiente en lugar de considerarlo impl´ıcito en otras ´epicas. El otro cambio consiste en el cambio de prioridad de las ´epicas relativas al tabl´on de 24 CAP´ ITULO 2. PLANIFICACI ´ ON Y REQUISITOS anuncios y al mapa interactivo (EP07-10). En el Product Backlog inicial, se dio m´as importancia a la caracter´ıstica del mapa, pero en el Product Backlog final se decidi´o dar m´as prioridad al tabl´on de anuncios, dado que si al final hubiera que recortar funcionalidad, era preferible ofrecer el tabl´on de anuncios antes que el mapa, ya que es m´as complejo y da m´as valor a la app. Asimismo, entre las dos ´epicas dedicadas a cada una de esas caracter´ısticas, tambi´en se ha cambiado el orden de prioridad para facilitar el desarrollo: primero se llevar´a a cabo la tarea desde el lado del cliente y despu´es desde el lado del due˜no de negocio, ya que esta segunda tarea consiste en a˜nadir funcionalidades a la primera, por lo que se trata de un orden m´as coherente. Dado el contexto acad´emico del proyecto y la limitaci´on de tiempo, se decidi´o limitar el alcance del mismo al desarrollo de las ´epicas desde EP01 aEP10. C´odigo ´ Epica EP01 Como due˜no de negocio quiero gestionar las citas de los clientes en mi establecimiento para poder tener una gesti´on centralizada del mismo junto a los pedidos en un solo sitio EP02 Como due˜no de negocio quiero gestionar los pedidos de los clientes en mi establecimiento para poder tener una gesti´on centralizada del mismo junto a las citas en un solo sitio EP03 Como cliente quiero hacer solicitudes de citas a los establecimientos registrados para facilitar la tarea de pedir cita y poder tener centralizados todos los establecimientos en un solo sitio EP04 Como cliente quiero hacer solicitudes de pedidos a los establecimientos registrados para facilitar la tarea de hacer pedidos y poder tener centralizados todos los establecimientos en un solo sitio EP05 Como cliente quiero ver si mis solicitudes de cita o pedido han sido confirmadas por el establecimiento para poder asegurar el servicio que he solicitado EP06 Como usuario quiero iniciar sesi´on en la app para identificarme como cliente o due˜no de negocio y poder acceder a las caracter´ısticas disponibles en funci´on de mi rol EP07 Como cliente quiero consultar anuncios publicados por los establecimientos en el tabl´on de anuncios para recibir distintas informaciones de los mismos EP08 Como due˜no de negocio quiero poder hacer publicaciones sobre mi negocio en el tabl´on de anuncios para proporcionar informaci´on a los clientes EP09 Como cliente quiero ver en el mapa interactivo los distintos establecimientos registrados y su ubicaci´on para poder llegar a ellos m´as f´acilmente EP10 Como due˜no de negocio quiero poder publicar en el mapa interactivo de establecimientos la ubicaci´on del m´ıo para permitir a los usuarios encontrarlo m´as f´acilmente EP11 Como due˜no de negocio quiero notificar a los clientes con citas previas si existe alg´un retraso para evitar esperas innecesarias de los clientes y aglomeraciones o saturaci´on en el establecimiento EP12 Como cliente quiero que se me notifique cuando exista un retraso en mis citas en los establecimientos para evitar esperas innecesarias EP13 Como administrador quiero aprobar las solicitudes de registro de nuevos establecimientos para incluir nuevos negocios a la app EP14 Como administrador quiero gestionar establecimientos para ofrecerles todas las funcionalidades de la app Tabla 2.14. Product Backlog final 25 2.7. PRODUCT BACKLOG FINAL 26 CAP´ ITULO 3. TECNOLOG´ IAS UTILIZADAS Cap´ıtulo 3 Tecnolog´ıas utilizadas 3.1. GitLab GitLab [50] es un servicio web de c´odigo abierto utilizado para el desarrollo de software colaborativo. Entre sus principales objetivos se encuentra integrar m´ultiples funcionalidades para que sea la ´unica aplicaci´on necesaria durante el ciclo de vida completo del desarrollo de software, mejorando as´ı la eficiencia y la velocidad en el trabajo. Es por ello que en este proyecto GitLab ha cumplido una triple funci´on: sistema de control de versiones, herramienta de gesti´on del proyecto y herramienta de integraci´on continua. 3.1.1. Git El n´ucleo de funcionamiento de GitLab se basa en Git.Git [44] es un sistema de control de versiones distribuido de c´odigo abierto y gratuito, cuyo prop´osito es llevar un registro de los cambios que se producen en los ficheros de c´odigo fuente y configuraci´on de un proyecto, principalmente software. Git se basa en un sistema de repositorio y ramas. Los repositorios son espacios de almacenamiento virtuales para los distintos ficheros de un proyecto. Las ramas son copias exactas de todo el proyecto que se crean desde otra rama, en el estado que se encontrase dicho punto de creaci´on al momento de crearla. De esta manera, si tenemos un c´odigo base de nuestro proyecto y queremos a˜nadir una nueva caracter´ıstica al mismo, Git nos permite crear una nueva rama en nuestro repositorio (es decir, hacer una copia del proyecto) y a˜nadir la nueva funcionalidad ah´ı, asegurando as´ı que siempre tenemos una rama con una versi´on estable del proyecto. Esta rama original y estable se suele denominar master. En la Figura 3.1 se puede observar de manera m´as gr´afica. 27 3.1. GITLAB Figura 3.1. Sistema de ramas en Git [26] Las operaciones b´asicas con ramas consisten en crear nuevas ramas y, una vez que se ha terminado de trabajar en ellas, fusionarlas de nuevo con la rama de la que se han originado. Esta fusi´on se denomina merge en t´erminos de Git. Adem´as, Git permite trabajo en local, aparte de en remoto. Para ello, existe la posibilidad de clonar repositorios en el almacenamiento local, realizar cambios sobre ellos (incluida la gesti´on de ramas), y grabar lo que se ha trabajado en local en el repositorio remoto. De esa manera, los cambios estar´an disponibles para otros miembros si se trata de trabajo colaborativo, o para poder acceder desde cualquier otro entorno local, en definitiva. Las operaciones utilizadas para ello son: pull, que trae los ´ultimos cambios producidos en el repositorio remoto al local; commit, que guarda los cambios realizados en el proyecto en el repositorio local; y push, que lleva los ´ultimos commits del repositorio local al remoto. Algo que hace diferente a Git sobre esto, es que dispone de una zona de preparaci´on o staging area [44], que supone una zona intermedia donde los cambios realizados en local se pueden supervisar y corregir en caso de necesidad antes de completar la operaci´on de commit. Aqu´ı entra la operaci´on add, que pasa los cambios locales seleccionados al staging area. En la Figura 3.2 se puede observar el proceso de grabaci´on de cambios en el repositorio local pasando por el staging area. Figura 3.2. Guardando cambios en local con Git [44] 28 CAP´ ITULO 3. TECNOLOG´ IAS UTILIZADAS Las ramas que se han utilizado en este proyecto, su nomenclatura y usos han sido: master: rama original y con una versi´on estable de la app. Como hasta que no se termine con el desarrollo de los objetivos del TFG no se considera que la app est´e en una versi´on inicial estable candidata a entrar en producci´on, solamente se fusionar´a el contenido de develop en esta rama al final de la realizaci´on del TFG. Si despu´es se quisiera seguir a˜nadiendo m´as funcionalidades a la app, se realizar´ıa una fusi´on a master por cada nueva caracter´ıstica que se a˜nadiera. develop: rama secundaria creada a partir de master y con una versi´on generalmente estable de la app, en proceso de desarrollo. Si se detecta alg´un bug en el c´odigo contenido en esta rama, se sacar´a una nueva rama a partir de ´esta para solucionarlo y fusionarla de nuevo. <n´umero HU>-<resumen HU>: cada una de las ramas creadas a partir de develop dedicadas a a˜nadir nueva funcionalidad. Se crear´a una por cada historia de usuario siguiendo dicho formato. Por ejemplo, si la historia de usuario fuera “HU01: Como usuario quiero introducir mis credenciales para iniciar sesi´on en mi cuenta”, entonces su funcionalidad se a˜nadir´ıa en la rama 1-introducir-credenciales. refactor-<resumen refactorizaci´on>: si es necesario realizar en alg´un punto del proyecto una refactorizaci´on del c´odigo, se crear´a una rama a partir de develop con dicho formato. Por ejemplo, si hubiera que hacer una refactorizaci´on para cambiar una librer´ıa X utilizada actualmente en el proyecto por una librer´ıa Y, la rama que se crear´ıa para ello ser´ıa refactor-cambio-libreria-x-por-libreria-y. bug-<resumen bug>: si se encuentra alg´un bug o fallo en la app, se crear´a una rama a partir de develop con esta nomenclatura. Por ejemplo, si no funciona un click sobre un bot´on .eliminar”, la rama creada ser´ıa bug-click-boton-eliminar. 3.1.2. GitLab Issue Board GitLab Issue Board [48] es una herramienta para gesti´on de proyectos software, constituida por tableros en los que se pueden encontrar varias columnas de tarjetas que representan issues. Una issue es una incidencia que debe llevarse a cabo en el proyecto. Las tarjetas de las issues llevan asociadas informaci´on como: el nombre de la incidencia, una descripci´on de la misma, archivos multimedia asociados, usuario de GitLab al que se asigna la incidencia para trabajar en ella, un seguimiento del tiempo en el que se indica el tiempo estimado para la incidencia y el tiempo realmente empleado en ella, una lista de incidencias relacionadas y un n´umero que representa el peso de la incidencia. Las tarjetas de GitLab poseen m´as campos con otra informaci´on distinta relacionada, pero en el caso de este proyecto, los campos utilizados son los que se acaban de enumerar. De esta manera, para la gesti´on del proyecto y para facilitar el seguimiento del mismo por parte de la tutora, pudiendo acceder en cualquier momento para ver el estado exacto del proyecto, se ha utilizado un tablero ´unico dividido en 6 columnas distintas, que son: 29 3.1. GITLAB Product Backlog. En esta columna entrar´an todas las tarjetas que representan las distintas historias de usuario en las que se dividen las ´epicas del Product Backlog. Sprint Backlog. A esta columna se mover´an todas las tarjetas de historias de usuario de la columna “Product Backlog” que se decide que se van a desarrollar en el presente sprint en la reuni´on de planificaci´on. Es decir, esta columna representa, como su propio nombre indica, al Sprint Backlog del sprint actual. Doing. En esta columna se encontrar´an las tarjetas de las issues que est´en en progreso, las cuales se ir´an cogiendo de la columna “Sprint Backlog” seg´un se empiece a trabajar en ellas. Under review. En esta columna aparecer´an las tarjetas de las incidencias ya finalizadas y que est´an esperando a ser revisadas en la pr´oxima reuni´on con la tutora. Por tanto, las tarjetas aqu´ı presentes provienen de la columna “Doing”. Done. Las tarjetas de las incidencias que ya hayan sido revisadas y aprobadas por la tutora, pasar´an de la columna “Under review” a esta columna. Si todas las tarjetas relacionadas con una historia de usuario (se explicar´a su organizaci´on a continuaci´on) est´an en esta columna, entonces se proceder´a a cerrar cada una de ellas. Closed. En esta columna aparecer´an cada una de las tarjetas que se han ido cerrando en el transcurso del proyecto. Para poder identificar m´as f´acilmente la naturaleza de cada tarjeta del tablero, se ha decidido seguir una peque˜na gu´ıa de estilo aplicada a los t´ıtulos de las tarjetas: si se trata de una historia de usuario, el t´ıtulo seguir´a el formato “[<n´umero HU>]<descripci´on HU>”; si se trata de una tarea de refactorizaci´on, el t´ıtulo ser´a de la forma “[REFACTOR] <descripci´on refactorizaci´on>”; y si se trata de una tarea de documentaci´on, el t´ıtulo seguir´a la plantilla “[DOC] <descripci´on documentaci´on>”. Adem´as, para cada tarjeta de historia de usuario, se crean otras 5 tarjetas a mayores para especificar las distintas tareas de dicha historia de usuario (que se explicar´an m´as a fondo en el Cap´ıtulo 7 de seguimiento del proyecto), en concreto: “[<n´umero HU>-AN] <descripci´on HU>”. Tarea de an´alisis. “[<n´umero HU>-DIS] <descripci´on HU>”. Tarea de dise˜no. “[<n´umero HU>-IMPL] <descripci´on HU>”. Tarea de implementaci´on. “[<n´umero HU>-REV IU] <descripci´on HU>”. Tarea de revisi´on de interfaz de usuario. “[<n´umero HU>-TEST] <descripci´on HU>”. Tarea de testeo. En la tarjeta general de historia de usuario ser´a en la que se listen estas 5 tarjetas como incidencias relacionadas, y tambi´en ser´a la ´unica en la que se establezca un peso, concordando con los puntos de historia que se ha decidido dar a dicha historia de usuario. 30 CAP´ ITULO 3. TECNOLOG´ IAS UTILIZADAS En las Figuras 3.3 y 3.4 se muestra como ejemplo el estado del tablero en medio de un sprint. Figura 3.3. Tablero GitLab Issue Board (parte 1) Figura 3.4. Tablero GitLab Issue Board (parte 2) 31 3.2. ANDROID 3.1.3. GitLab CI/CD GitLab CI/CD [47] es una herramienta integrada en GitLab, que se ha utilizado para la integraci´on continua en este proyecto. Su funcionamiento consiste en que con cada operaci´on de push, se ejecuta un script almacenado en el proyecto (com´unmente con el nombre gitlab-ci.yml) que pone en marcha trabajos organizados en pipelines, con el objetivo de compilar, testear y desplegar todos los cambios realizados. Esto es muy ´util a la hora de evaluar si los cambios que se han introducido en nuevas ramas siguen manteniendo el c´odigo en una versi´on estable, y por tanto se pueden fusionar con su rama de origen. En el Cap´ıtulo 6, donde se detallar´a la implementaci´on realizada, se explicar´a m´as a fondo el contenido del archivo gitlab-ci.yml empleado en este proyecto. 3.2. Android Android [118] es un sistema operativo propiedad de Google basado en una versi´on modificada del kernel Linux, dirigido principalmente a dispositivos m´oviles inteligentes. Actualmente, es el sistema operativo m´ovil m´as utilizado en el mundo, con m´as de 2500 millones de dispositivos que lo utilizan [1]. En este proyecto, la app objetivo se construir´a para dispositivos Android. Para ello, se ha utilizado la API 26 de Android, lo cual quiere decir que la versi´on m´ınima de Android que deben tener los dispositivos para poder ejecutar la app es Android 8.0 Oreo. En el momento de creaci´on del proyecto, la utilizaci´on de dicha versi´on cubre el 60,8 % de dispositivos del mercado [22]. La decisi´on sobre el nivel de API a utilizar se bas´o en varios factores. Por una parte, se quer´ıa utilizar una versi´on no muy antigua, para poder hacer uso de los componentes m´as nuevos de Android y darle un aspecto moderno a la app. Por otra parte, uno de los objetivos principales de la app es que sea accesible, por lo que tampoco se pod´ıa elegir la versi´on m´as nueva disponible, dado que el porcentaje de dispositivos que podr´ıan ejecutarla ser´ıa relativamente bajo. Por ello, hab´ıa que encontrar una versi´on que cumpliera estas dos premisas de manera equilibrada. Como factor decisivo se decidi´o hacer una peque˜na investigaci´on en el entorno cotidiano, y preguntar sobre la versi´on Android de sus dispositivos a due˜nos de negocio que posiblemente constituyeran potenciales candidatos a participar en una futura fase de testing en el proyecto. De los resultados obtenidos, la versi´on m´as antigua utilizada era Android 8.0 Oreo, por lo que comprobando el dato de distribuci´on de versiones mencionado anteriormente (la API 26 funciona en el 60,8 % de dispositivos), se consider´o una versi´on adecuada para utilizar en el proyecto. Como lenguaje de programaci´on se ha utilizado Java, con el JDK 8. Actualmente, en Android, los principales lenguajes de programaci´on utilizados son Java y Kotlin, cada vez migr´andose m´as a este segundo. Dada la pr´actica adquirida a lo largo de todo el grado con Java y su aplicaci´on en dise˜no, se decidi´o utilizar este para que la curva de aprendizaje en este aspecto fuera baja. 32 CAP´ ITULO 3. TECNOLOG´ IAS UTILIZADAS El entorno de desarrollo oficial para Android, y el que se ha utilizado en el proyecto, es Android Studio [11], en su versi´on 4.1.2, que era la ´ultima versi´on estable en el momento de creaci´on del proyecto. El gestor de automatizaci´on y de dependencias utilizado en Android es Gradle [62]. Gradle es una herramienta de c´odigo abierto que se encarga de ejecutar las tareas necesarias para compilar una aplicaci´on de forma eficiente, puesto que s´olo ejecuta los pasos necesarios (aquellos en los que haya habido cambios), y de forma flexible, puesto que puede compilar cualquier tipo de software al realizar pocas suposiciones sobre qu´e es lo que se quiere compilar o c´omo hacerlo. Android supone un framework completo para el desarrollo de apps m´oviles, pero dentro del mismo, se han utilizado diversos componentes y estilos. Los m´as importantes se detallar´an en las siguientes subsecciones. 3.2.1. Material Design Material Design [74] es un sistema de gu´ıas de estilo, componentes y herramientas que utiliza las mejores pr´acticas (best practices) del dise˜no de interfaz de usuario (IU). Entre las principales caracter´ısticas del dise˜no presentado en estas gu´ıas, se busca que los elementos de la interfaz de usuario simulen papel real, y se fomenta la utilizaci´on de tarjetas y sombras para representar y organizar informaci´on en pantalla. Fue creado por Google, y comenz´o siendo utilizado en sus aplicaciones y webs, pero m´as tarde se puso a disposici´on de todos los desarrolladores para poder utilizarlo en todas las aplicaciones que se deseara. Aunque principalmente es una filosof´ıa dirigida a las apps Android, tambi´en es extrapolable a las aplicaciones web. En este proyecto se hace uso de este sistema de dise˜no, pues es una forma completa y atractiva de seguir buenas pr´acticas a la hora de dise˜nar interfaces de usuario, y adecuada, ya que el objetivo es una app Android, justo para lo que fue originalmente desarrollado Material Design. Asimismo, todos los iconos que se han utilizado en la app tambi´en pertenecen a Material Design, de c´odigo abierto y uso libre para cualquier usuario [76]. 3.2.2. Fragments Los componentes principales de la l´ogica de una app Android son las Activities o actividades y los Fragments o fragmentos. Una Activity [15] se puede entender como una pantalla de la app. Como la mayor´ıa de las apps contienen varias pantallas, por lo general suele haber varias actividades presentes, una de ellas la actividad principal, con la que arranca la app. Un Fragment [13] es una parte de la interfaz de usuario de la app. Los fragmentos siempre deben estar alojados en una actividad, y aunque poseen ciclo de vida propio, ´este se ve directamente afectado por el ciclo de vida de la actividad anfitriona. Una actividad puede contener varios fragmentos, y cada fragmento se puede reutilizar en actividades distintas, permitiendo as´ı modularizar la IU. 33 3.5. HERRAMIENTAS PARA LA COMUNICACI ´ ON 3.5.3. Jitsi Jitsi [67] es una aplicaci´on de videoconferencia, tambi´en de c´odigo abierto, utilizada a trav´es de la web. Mediante esta herramienta se han realizado las reuniones de los distintos eventos Scrum con la tutora, y se pretende que sea la herramienta de videoconferencia con la que se realice la defensa ante el tribunal del TFG. 3.5.4. Vysor Vysor [117] es una aplicaci´on que permite visualizar y controlar en la pantalla del ordenador la pantalla de un dispositivo m´ovil f´ısico conectado mediante cable. En este proyecto, se ha utilizado la herramienta para mostrar a la tutora en las reuniones semanales los avances y el aspecto de la app Android en desarrollo, pues consume muchos menos recursos que un emulador y permite un mejor funcionamiento del resto de programas abiertos en el ordenador. Tambi´en se pretende utilizar en la defensa del TFG para realizar una “demo” completa de la app desarrollada. 40 CAP´ ITULO 4. AN ´ ALISIS Cap´ıtulo 4 An´alisis Como parte de la fase de an´alisis del proyecto, llevada a cabo parcialmente tanto en el sprint 0 como tambi´en una de las tareas de cada una de las historias de usuario desarrolladas, se han desglosado los requisitos del proyecto como historias de usuario, para posteriormente dar lugar a un modelo de dominio inicial y un modelo de proceso de negocio. Los modelos y sus diagramas se han representado ´ıntegramente en ingl´es, de manera que se respeta el requisito no funcional de desarrollar la documentaci´on interna en ingl´es, que tambi´en se presentar´a en este Cap´ıtulo. 4.1. Requisitos funcionales como historias de usuario Los requisitos funcionales se han obtenido desglosando las ´epicas que se especifican en el Product Backlog final (Tabla 2.14) en distintas historias de usuario. En este caso, tambi´en se les ha asignado un c´odigo a cada una de ellas para poder referenciarlas m´as tarde de manera m´as f´acil. Asimismo, como parte de la planificaci´on del proyecto, otra tarea que se ha hecho es asignar a cada historia un n´umero de puntos de historia, tal y como se explica en el Cap´ıtulo 2. Esta estimaci´on aparece tambi´en junto a cada historia de usuario. Como en el alcance del proyecto se desarrollar´an las ´epicas desde EP01 hasta EP10, s´olo se han dividido ´estas en distintas historias de usuario. En el caso de las ´epicas que s´olo se han desglosado en una, el objetivo es especificar m´as y crear una historia de usuario que est´e al mismo nivel que el resto, para poder tratar a todas de la misma manera. En las Tablas 4.1 a 4.10 se muestran las historias de usuario divididas por su ´epica de origen. 41 4.1. REQUISITOS FUNCIONALES COMO HISTORIAS DE USUARIO C´odigo Historia de usuario Puntos HU01 Como due˜no de negocio quiero seleccionar que deseo consultar mis citas para s´olo ver en pantalla citas y no pedidos. 5 HU02 Como due˜no de negocio quiero seleccionar el d´ıa del que quiero consultar las citas en un calendario para s´olo ver las citas de dicho d´ıa. 2 HU03 Como due˜no de negocio quiero seleccionar una franja horaria ocupada en un horario dividido en franjas de 15 minutos para ver los detalles de la cita ya establecida en esa franja. 5 HU04 Como due˜no de negocio quiero seleccionar una o un conjunto de franjas horarias libres en un horario dividido en franjas de 15 minutos para a˜nadir una nueva cita que ocupe el per´ıodo de franjas horarias seleccionado. 4 HU05 Como due˜no de negocio quiero eliminar una cita de las registradas actualmente. 2 Tabla 4.1. Historias de usuario de la ´epica EP01 C´odigo Historia de usuario Puntos HU06 Como due˜no de negocio quiero seleccionar que deseo consultar mis pedidos para s´olo ver en pantalla pedidos y no citas. 1 HU07 Como due˜no de negocio quiero seleccionar el d´ıa del que quiero consultar los pedidos en un calendario para s´olo ver los pedidos de dicho d´ıa. 2 HU08 Como due˜no de negocio quiero seleccionar una franja horaria en un horario dividido en franjas de 15 minutos para ver todos los pedidos ya registrados para esa franja. 2 HU09 Como due˜no de negocio quiero a˜nadir un nuevo pedido en la franja horaria que me encuentro actualmente para registrarlo en la app y gestionarlo junto con los dem´as pedidos. 2 HU10 Como due˜no de negocio quiero eliminar un pedido de los registrados actualmente. 1 Tabla 4.2. Historias de usuario de la ´epica EP02 C´odigo Historia de usuario Puntos HU11 Como cliente quiero seleccionar uno de los establecimientos de la lista para poder interactuar con ´el. 2 HU12 Como cliente quiero ver los detalles del establecimiento seleccionado y seleccionar que deseo pedir una cita para realizar una solicitud de cita al mismo. 1 HU13 Como cliente quiero seleccionar el d´ıa para el que quiero pedir una cita a un establecimiento para ver las posibilidades de reserva de ese d´ıa. 1 HU14 Como cliente quiero ver las franjas horarias en las que es posible solicitar una cita y los huecos disponibles actualmente en un horario dividido en franjas de 15 minutos para informarme sobre la disponibilidad del establecimiento. 1 HU15 Como cliente quiero seleccionar una o un conjunto de franjas horarias libres en un horario dividido en franjas de 15 minutos para pedir una cita que ocupe el per´ıodo de franjas seleccionado y que el establecimiento reciba mi solicitud de cita. 1 Tabla 4.3. Historias de usuario de la ´epica EP03 42 CAP´ ITULO 4. AN ´ ALISIS C´odigo Historia de usuario Puntos HU16 Como cliente quiero ver los detalles del establecimiento seleccionado y seleccionar que deseo hacer un pedido para realizar una solicitud de pedido al mismo. 0,5 HU17 Como cliente quiero seleccionar el d´ıa para el que quiero hacer un pedido a un establecimiento para ver las posibilidades de reserva de ese d´ıa. 0,5 HU18 Como cliente quiero ver las franjas horarias en las que es posible solicitar un pedido en un horario dividido en franjas de 15 minutos para informarme sobre la disponibilidad del establecimiento. 1 HU19 Como cliente quiero seleccionar una franja horaria disponible en un horario dividido en franjas de 15 minutos para hacer un pedido en la franja horaria seleccionada y que el establecimiento reciba mi solicitud de pedido. 1 Tabla 4.4. Historias de usuario de la ´epica EP04 C´odigo Historia de usuario Puntos HU20 Como due˜no de negocio quiero ver la lista de solicitudes de cita que se han realizado a mi establecimiento para poder dar una respuesta al cliente. 2 HU21 Como due˜no de negocio quiero aceptar una de las solicitudes de cita que se han realizado a mi establecimiento para informar al cliente solicitante. 0,5 HU22 Como due˜no de negocio quiero rechazar una de las solicitudes de cita que se han realizado a mi establecimiento para informar al cliente solicitante. 0,5 HU23 Como cliente quiero ver la lista de solicitudes de cita pendientes, aceptadas, rechazadas y confirmadas que he realizado a los distintos negocios. 2 HU24 Como cliente quiero confirmar la asistencia a una cita solicitada y aceptada por un establecimiento. 0,5 HU25 Como due˜no de negocio quiero ver la lista de solicitudes de pedido que se han realizado a mi establecimiento para poder dar una respuesta al cliente. 1 HU26 Como due˜no de negocio quiero aceptar una de las solicitudes de pedido que se han realizado a mi establecimiento para informar al cliente solicitante. 1 HU27 Como due˜no de negocio quiero rechazar una de las solicitudes de pedido que se han realizado a mi establecimiento para informar al cliente solicitante. 0,5 HU28 Como cliente quiero ver la lista de solicitudes de pedido pendientes, aceptadas y rechazadas que he realizado a los distintos negocios. 2 Tabla 4.5. Historias de usuario de la ´epica EP05 C´odigo Historia de usuario Puntos HU29 Como usuario quiero acceder a la pantalla de inicio de sesi´on e introducir mis credenciales para entrar en mi cuenta de cliente o de due˜no de negocio. 2 HU30 Como usuario quiero acceder a la pantalla de registro para crear una nueva cuenta de cliente. 1 Tabla 4.6. Historias de usuario de la ´epica EP06 C´odigo Historia de usuario Puntos HU31 Como cliente quiero acceder a la secci´on de “Tabl´on” para ver el conjunto de anuncios publicados hasta la fecha. 1 Tabla 4.7. Historias de usuario de la ´epica EP07 43 4.2. REQUISITOS DE INFORMACI ´ ON COMO HISTORIAS DE USUARIO C´odigo Historia de usuario Puntos HU32 Como due˜no de negocio quiero tener una opci´on de a˜nadir un nuevo anuncio al tabl´on para ver el formulario que tengo que rellenar. 0,5 HU33 Como due˜no de negocio quiero a˜nadir un nuevo anuncio al tabl´on para publicar informaci´on sobre mi negocio que puedan ver los clientes. 1 Tabla 4.8. Historias de usuario de la ´epica EP08 C´odigo Historia de usuario Puntos HU34 Como cliente quiero acceder a la secci´on de “Mapa” para ver las ubicaciones de los distintos establecimientos registrados en la app. 1 Tabla 4.9. Historias de usuario de la ´epica EP09 C´odigo Historia de usuario Puntos HU35 Como due˜no de negocio quiero proporcionar mi ubicaci´on en el momento del registro para poder ver mi ubicaci´on en el mapa interactivo. 0,5 Tabla 4.10. Historias de usuario de la ´epica EP10 4.2. Requisitos de informaci´on como historias de usuario Aunque los requisitos de informaci´on forman parte de los requisitos funcionales, se ha decidido tratarlos por separado, ya que a partir de ´estos es de donde se obtendr´a el modelo de dominio inicial. En la Tabla 4.11 se observan los requisitos de informaci´on en forma de historias de usuario. 4.3. Requisitos no funcionales como historias de usuario De la misma manera que hay requisitos funcionales, en todo proyecto software existen unos requisitos no funcionales que hay que cumplir de manera transversal. Para su obtenci´on, se ha seguido la gu´ıa FURPS [120], que recorriendo cada una de las categor´ıas que describe el acr´onimo ingl´es (funcionalidad -que se ha cubierto con los requisitos funcionales-, usabilidad, fiabilidad, rendimiento y soporte), se garantiza que se cubren los aspectos b´asicos que deben cumplir los requisitos no funcionales. En la Tabla 4.12 se pueden observar los requisitos no funcionales en forma de historias de usuario. En este caso tambi´en se les ha asignado un c´odigo, para poder referirnos a ellas a lo largo del documento. 44 CAP´ ITULO 4. AN ´ ALISIS Historia de usuario Como equipo de desarrollo quiero guardar los siguientes datos de un cliente: nombre, email, contrase˜na, fecha de nacimiento, localidad y foto de perfil, para manejar la informaci´on b´asica necesaria en la app. Como equipo de desarrollo quiero guardar los siguientes datos de un establecimiento: nombre, email, contrase˜na, categor´ıa, descripci´on, n´umero de tel´efono, ubicaci´on, los servicios que ofrece entre “citas” y “pedidos”, el m´aximo de clientes que recibe para citas por franja horaria y foto de perfil, para manejar la informaci´on b´asica necesaria en la app. Como equipo de desarrollo quiero guardar los siguientes datos de una cita: d´ıa, franja horaria, motivo, cliente solicitante si es que lo hay o nombre del cliente solicitante en caso contrario, establecimiento al que va dirigida la cita, estado de la cita, si el cliente ha confirmado su asistencia despu´es de aceptar la cita, minutos de retraso estimados en caso de que lo haya y respuesta del establecimiento si se rechaza la cita, para manejar la informaci´on b´asica necesaria en la app. Como equipo de desarrollo quiero guardar los siguientes datos de un pedido: d´ıa, hora, detalle, cliente solicitante si es que lo hay o nombre del cliente solicitante en caso contrario, establecimiento al que va dirigido el pedido, estado del pedido, minutos de retraso estimados en caso de que lo haya y respuesta del establecimiento si se rechaza el pedido, para manejar la informaci´on b´asica necesaria en la app. Como equipo de desarrollo quiero guardar los siguientes datos de un anuncio: t´ıtulo, descripci´on, imagen, categor´ıa, fecha de publicaci´on y establecimiento que lo ha publicado, para manejar la informaci´on b´asica necesaria en la app. Como equipo de desarrollo quiero guardar los siguientes datos de una solicitud de registro de nuevo establecimiento: nombre, email, categor´ıa, descripci´on, ubicaci´on, los servicios que ofrece entre “citas” y “pedidos”, el m´aximo de clientes que recibe por franja horaria, foto de perfil y respuesta del administrador si se rechaza la solicitud, para manejar la informaci´on b´asica necesaria en la app. Tabla 4.11. Requisitos de informaci´on como historias de usuario 45 4.4. RESTRICCIONES COMO HISTORIAS DE USUARIO C´odigo Historia de usuario HUNF01 Como usuario quiero que la aplicaci´on de gesti´on de citas y pedidos se materialice en una app Android para poder tenerla siempre a mano en mi dispositivo m´ovil y hacer uso de ella cuando lo necesite. HUNF02 Como usuario quiero que la interfaz de usuario de la app tenga un aspecto atractivo, haciendo que sus elementos simulen en lo posible papel real, y que sea intuitiva y f´acil de utilizar, de manera que todo usuario que maneje apps similares sea capaz de hacer una tarea en menos de 1 minuto, para dotar a la app de buenos atributos de usabilidad. HUNF03 Como usuario quiero que la transici´on entre las distintas pantallas de la app sea fluida y animada para poder disfrutar de una buena experiencia de usuario. HUNF04 Como usuario quiero que la app muestre un mensaje de error gen´erico cuando ocurra un fallo interno en la app, pero que ´esta siga funcionando, para que la app sea robusta y posea buen manejo de errores. HUNF05 Como equipo de desarrollo quiero que la app genere logs durante su ejecuci´on en caso de que ocurra un fallo interno, indicando en qu´e punto del c´odigo ha ocurrido y la raz´on del fallo, para poder depurar y corregir el c´odigo de manera mucho m´as f´acil. HUNF06 Como usuario quiero recibir actualizaciones de los datos de la app en tiempo real y con una latencia menor a 1 segundo, para que la realizaci´on de tareas en la app sea fluida. HUNF07 Como usuario quiero que la interfaz de usuario se muestre en espa˜nol para poder comprender adecuadamente toda la informaci´on mostrada. HUNF08 Como equipo de desarrollo quiero que el c´odigo y su documentaci´on interna se desarrolle en ingl´es para poder internacionalizarlo m´as f´acilmente. HUNF09 Como usuario quiero tener mi propia cuenta en la app para que los datos que se almacenan relacionados conmigo (informaci´on personal, solicitudes, citas y pedidos si soy due˜no de negocio) no sean visibles por cualquier otro usuario. Tabla 4.12. Requisitos no funcionales como historias de usuario 4.4. Restricciones como historias de usuario En el sistema a construir tambi´en se ha decidido incluir algunas restricciones que la aplicaci´on tendr´a que respetar, basadas en los objetivos principales a cumplir. En la Tabla 4.13 se puede ver la lista de restricciones en forma de historias de usuario. Historia de usuario Como usuario quiero que la app sea gratuita para poder utilizarla libremente sin tener que realizar ninguna inversi´on econ´omica. Como equipo de desarrollo quiero distribuir la app a trav´es de un archivo APK o si se llega a desplegar, a trav´es de Google Play, para hacer llegar la app a los usuarios finales de manera sencilla. Como usuario quiero que mis datos se traten acorde al RGPD para poder garantizar la privacidad de los mismos. Tabla 4.13. Restricciones como historias de usuario 46 CAP´ ITULO 4. AN ´ ALISIS 4.5. Modelo de dominio inicial A partir de los requisitos funcionales de informaci´on (Tabla 4.12), se ha elaborado un modelo de dominio inicial, que se representa en el diagrama de clases que se puede observar en la Figura 4.1. Figura 4.1. Modelo de dominio inicial Las clases y atributos que aparecen en rojo son los que no entran dentro del alcance del proyecto, aunque al formar parte del sistema y sus requisitos, deben aparecer en el modelo de dominio. En concreto, estos son: las clases enum que indican la categor´ıa de establecimientos y anuncios y que en un futuro se podr´ıa utilizar para filtrarlos; la imagen de los anuncios, ya que no se ha llegado a incluir en la versi´on de la app desarrollada en el proyecto; los minutos de retraso en una reserva de cita o pedido, que est´a dentro del contexto de las ´epicas EP11 y EP12 y por tanto fuera del alcance del proyecto; y los atributos relacionados con la solicitud de registro de un establecimiento, que pertenece a la funcionalidad de las ´epicas EP13 y EP14, tambi´en fuera del alcance del proyecto. 47 4.6. MODELO DE PROCESO DE NEGOCIO 4.6. Modelo de proceso de negocio Para completar el an´alisis del sistema, se ha realizado un diagrama de actividades mostrando el principal proceso de negocio que se llevar´a a cabo a trav´es de la app: pedir cita a un establecimiento. En la Figura 4.2 se puede observar dicho diagrama. Figura 4.2. Modelo de dominio inicial Como se observa, son dos actores los implicados en el proceso de negocio: cliente y due˜no de negocio. El proceso es comenzado por el cliente, de tal manera que introduce los par´ametros de la cita que desea solicitar (a qu´e establecimiento va dirigida, fecha y hora y detalles de la cita), y la env´ıa. Si no hay espacio en la franja horaria y d´ıa seleccionados, se informa al cliente y el flujo de la actividad termina, y si hay espacio libre, se crea una nueva cita en estado “pendiente”. El due˜no de negocio comenzar´a la actividad de revisar las solicitudes de cita pendientes, y puede o bien rechazar la solicitud de cita escribiendo una respuesta 48 CAP´ ITULO 4. AN ´ ALISIS al cliente, lo que genera una notificaci´on de rechazo para el cliente y pasa la cita a estado “rechazada”, o bien aceptarla, donde se mostrar´a un mensaje en caso de que no haya espacio libre para la cita y terminar´a el flujo de la actividad, o se registrar´a la nueva cita generando una notificaci´on de confirmaci´on para el cliente y pasando la cita a estado “aceptada” en caso contrario. Finalmente, el cliente iniciar´a la actividad de revisar sus solicitudes de cita aceptadas y confirmar´a su asistencia a la cita ya aceptada por el establecimiento, pasando el estado de la misma a “confirmada”. En el sistema, como se define en sus objetivos principales, se desea gestionar las citas y pedidos de los establecimientos. Es por ello que el otro proceso de negocio principal de la app es hacer pedido a un establecimiento, pero se ha prescindido de su diagrama de actividades ya que es completamente an´alogo al ya presentado, eliminando la parte de la confirmaci´on de cita, por lo que el pedido solamente podr´ıa pasar por los estados “pendiente”, “rechazado” y “aceptado”. 49 5.3. PATRONES DE DISE ˜ NO UTILIZADOS setters y constructores). Este paquete supone una capa transversal accesible por todos los dem´as paquetes, ya que estas entidades funcionan como DTO y son la manera en la que se transmite la informaci´on entre todas las capas. Desde el momento en que se recupera informaci´on de la base de datos a trav´es de los DAO, ´esta es transformada en un objeto de una clase del paquete entities, y viaja como DTO hasta los fragmentos y actividades, pasando por los ViewModels correspondientes. 5.3.2. M´etodo Factor´ıa El m´etodo Factor´ıa [91] [125] es un patr´on de dise˜no creacional (destinado a la creaci´on de objetos) cuya intenci´on es definir una interfaz para crear un objeto mediante un m´etodo f´abrica, en lugar de utilizar el operador new. El objetivo es crear el tipo adecuado de objeto (una de las subclases de la clase f´abrica) a trav´es de una ´unica interfaz (la superclase o clase f´abrica) cuando no se pueda anticipar el tipo de objeto que se quiere crear. En la Figura 5.4 se puede ver la estructura general del patr´on. En este caso, la clase factor´ıa es “Creador”, que contiene un m´etodo f´abrica o factor´ıa, y que a su vez tiene una subclase “CreadorConcreto” que se encarga de crear el tipo adecuado de objeto, en este caso “ProductoConcreto”. Figura 5.4. Patr´on Factor´ıa [65] Uso en el proyecto En Android, puesto que para ser seguros ante los cambios del ciclo de vida de su controlador de IU los ViewModels se deben crear a trav´es de una clase ViewModelProvider, proporcionada por Android tambi´en, y mediante esta clase s´olo se pueden crear ViewModels con su constructor por defecto (sin par´ametros), para crear ViewModels con datos inicializados desde su creaci´on es necesario utilizar el m´etodo factor´ıa. 56 CAP´ ITULO 5. DISE ˜ NO La soluci´on que ofrece Android se basa en crear una subclase que herede de la clase ViewModelProvider.Factory, en la que se crear´a mediante un m´etodo factor´ıa el ViewModel correspondiente con sus par´ametros en el constructor. Esta nueva clase factor´ıa se pasar´a ahora al ViewModelProvider, y Android se encargar´a internamente de instanciar el ViewModel con los datos iniciales indicados. 5.3.3. Patr´on Adaptador El patr´on Adaptador [90] [125], tambi´en llamado envoltorio o wrapper, tiene como objetivo convertir la interfaz de una clase en otra esperada por los clientes. Un adaptador envuelve un objeto para ocultar la complejidad de las conversiones necesarias para adaptar una interfaz a otra, de manera que un cliente que quiera utilizar una interfaz no compatible, lo pueda hacer a trav´es del mencionado adaptador. En la Figura 5.5 se puede observar la estructura del patr´on Adaptador. La clase “Target” har´ıa referencia a la interfaz esperada por el cliente, mientras que la clase “Adapter” es el adaptador, que permite utilizar los m´etodos de la clase “Adaptee”, los que realmente se desean utilizar. Figura 5.5. Patr´on Adaptador [123] Uso en el proyecto Junto con el componente Android RecyclerView, utilizado para mostrar una lista de elementos que se a˜naden din´amicamente, las clases clave que se han de crear son: un contenedor de vistas, clase que extiende RecyclerView.ViewHolder, que representar´a cada uno de los elementos de la lista din´amica, y un adaptador que extiende RecyclerView.Adapter. Esta ´ultima clase es la que aplica el patr´on Adaptador, ya que su funci´on es convertir la lista de objetos entidades que se le pasa por par´ametro a objetos ViewHolder que se mostrar´an por 57 5.3. PATRONES DE DISE ˜ NO UTILIZADOS pantalla, y adaptar los m´etodos que se quieran realizar sobre estos elementos. El procedimiento es tan simple como crear un adaptador y asign´arselo al RecyclerView, Android se encargar´a internamente del resto. 5.3.4. Patr´on Proxy El patr´on Proxy [92] proporciona un objeto que act´ua como sustituto de otro objeto o servicio real utilizado por un cliente. Este objeto proxy recibe solicitudes del cliente, realiza parte del trabajo y finalmente pasa la solicitud al objeto o servicio real que corresponde. Al poseer la misma interfaz que el objeto o servicio real, ´estos son totalmente intercambiables. En la Figura 5.6 se observa la estructura que sigue el patr´on. La clase “Proxy” es la que act´ua como sustituto y delega algunas tareas en “RealSubject”, que es el objeto o servicio real. Ambas poseen la misma interfaz, “Subject”, que es la conocida por el cliente. Figura 5.6. Patr´on Adaptador [89] Uso en el proyecto Debido a la asincron´ıa que proporciona la base de datos en Firebase y la estructura dada a los datos en los nodos de la base de datos, era dif´ıcil poder obtener de forma completa objetos entidades que a su vez tuvieran dependencia con otras entidades, dado que hab´ıa que consultar en varios nodos distintos y la asincron´ıa complicaba este trabajo. Por ejemplo, una cita est´a relacionada con un establecimiento pero tambi´en puede estarlo con un cliente, por lo que al recuperar una cita tambi´en habr´ıa que consultar los nodos de establecimiento y probablemente de cliente. La soluci´on que se propuso a este problema para simplificarlo, es una adaptaci´on del patr´on Proxy, de manera que cuando se recupere un objeto que tenga atributos entidades, s´olo 58 CAP´ ITULO 5. DISE ˜ NO se pase a los ViewModel estos atributos con contenedores vac´ıos, excepto por su ID, a modo de objeto proxy. Por ejemplo, al consultar una cita, sus atributos de tipo Establishment y Client ser´an contenedores vac´ıos que simplemente contengan el ID de esos objetos, ninguna informaci´on m´as. Esta forma de uso del patr´on Proxy se aplica en contextos donde se busca una recuperaci´on perezosa. El patr´on, sin embargo, s´olo se aplica entre los paquetes viewmodels ydaos, puesto que con los contenedores vac´ıos que llegan a los ViewModels se realiza una nueva consulta con el ID que contengan para obtener la entidad de tipo correspondiente. As´ı, cuando desde un ViewModel se hace una consulta de cita y se recibe un objeto Appointment con sus proxys establecimiento y cliente, posteriormente se realizar´an dos consultas a los DAO correspondientes, primero al de Establishment y despu´es al de Client, en cada caso con el ID del proxy correspondiente. De esta manera, se garantiza que en la capa de interfaz de usuario (paquete views) los objetos lleguen en su estado natural, con sus dependencias completas, puesto que todo el trabajo para ello se ha realizado en capas inferiores. 5.4. Dise˜no de la interfaz de usuario Previo al comienzo de la implementaci´on de las historias de usuario, se realizaron durante la fase de planificaci´on inicial en el sprint 0 (se explicar´a el seguimiento del proyecto en el Cap´ıtulo 7) varios mockups o prototipos que muestran un boceto de las distintas pantallas de la app. El objetivo era facilitar la fase de elicitaci´on de requisitos, mostrando a los clientes potenciales entrevistados prototipos de la aplicaci´on para dar una visi´on m´as representativa de la idea, y posteriormente durante el desarrollo de las historias de usuario, tener una base sobre la que comenzar el desarrollo de la interfaz de usuario. Las Figuras 5.7 a 5.46 muestran los mockups que se realizaron. El pie de foto de cada uno de ellos sigue el formato: “Descripci´on de la pantalla - Rol de usuario”. 59 5.4. DISE ˜ NO DE LA INTERFAZ DE USUARIO Figura 5.7. Vista principal de “Sitios” - Cliente Figura 5.8. Establecimiento seleccionado - Cliente Figura 5.9. Pedir cita (seleccionar d´ıa) - Cliente Figura 5.10. Pedir cita (seleccionar franja horaria) - Cliente 60 CAP´ ITULO 5. DISE ˜ NO Figura 5.11. Pedir cita (detalles de la cita) -Cliente Figura 5.12. Solicitudes de cita - Due˜no de negocio Figura 5.13. Rechazo de cita - Due˜no de negocio Figura 5.14. Confirmaci´on de cita - Cliente 61 5.4. DISE ˜ NO DE LA INTERFAZ DE USUARIO Figura 5.15. Rechazo de cita - Cliente Figura 5.16. Citas solicitadas - Cliente Figura 5.17. Vista principal de “Agenda” -Due˜no de negocio Figura 5.18. Mis citas (calendario) - Due˜no de negocio 62 CAP´ ITULO 5. DISE ˜ NO Figura 5.19. Mis citas (horas) - Due˜no de negocio Figura 5.20. Mis citas (detalles de una cita) - Due˜no de negocio Figura 5.21. A˜nadir nueva cita - Due˜no de negocio Figura 5.22. Hacer pedido (seleccionar d´ıa) - Cliente 63 5.4. DISE ˜ NO DE LA INTERFAZ DE USUARIO Figura 5.23. Hacer pedido (seleccionar franja horaria) - Cliente Figura 5.24. Hacer pedido (detalles del pedido) - Cliente Figura 5.25. Solicitudes de pedido - Due˜no de negocio Figura 5.26. Rechazo de pedido - Due˜no de negocio 64 CAP´ ITULO 5. DISE ˜ NO Figura 5.27. Confirmaci´on de pedido - Cliente Figura 5.28. Rechazo de pedido - Cliente Figura 5.29. Pedidos solicitados - Cliente Figura 5.30. Mis pedidos (calendario) - Due˜no de negocio 65 5.5. DISE ˜ NO ARQUITECT ´ ONICO Figura 5.51. Arquitectura general de la aplicaci´on En las Figuras 5.52 a 5.55 aparecen los diagramas Decomposition&Uses style de cada uno de los paquetes principales. Para no aumentar la complejidad de estos diagramas, se ha optado por realizar un diagrama Decomposition&Uses style por cada historia de usuario que utilice componentes de m´as de un paquete para mostrar las relaciones entre ellos. Asimismo, se ha realizado un diagrama de este tipo tambi´en para mostrar las relaciones entre distintos paquetes de la actividad principal y de la clase AuthUtils. Los diagramas mencionados se encuentran en el repositorio cuyo enlace se puede encontrar en el Ap´endice B, y no se mostrar´an en este documento por brevedad, excepto el de la HU02, que es la historia de usuario que se desarrollar´a en la siguiente secci´on, y cuyo diagrama Decomposition&Uses style se muestra en la Figura 5.62 a modo de ejemplo. 72 CAP´ ITULO 5. DISE ˜ NO Figura 5.52. Decomposition&Uses style del paquete views 73 5.5. DISE ˜ NO ARQUITECT ´ ONICO Figura 5.53. Decomposition&Uses style del paquete viewmodels Figura 5.54. Decomposition&Uses style del paquete daos 74 CAP´ ITULO 5. DISE ˜ NO Figura 5.55. Decomposition&Uses style del paquete entities 75 5.6. DISE ˜ NO DE LA COMUNICACI ´ ON ENTRE OBJETOS 5.6. Dise˜no de la comunicaci´on entre objetos Para explicar el dise˜no de comunicaci´on entre objetos, se desarrollar´a y explicar´a el diagrama de secuencia de la HU02: Como due˜no de negocio quiero seleccionar el d´ıa del que quiero consultar las citas en un calendario para s´olo ver las citas de dicho d´ıa. Alguno de los subdiagramas de secuencia menos importantes que se omitir´an por brevedad en este documento se pueden encontrar en el archivo Astah del repositorio que se puede encontrar en el Ap´endice B. Tambi´en, con el objetivo de reducir la complejidad, se obviar´a la obtenci´on de ciertas variables como el contexto de la actividad principal y el uso de algunos componentes de IU como progressBarTimetable. Se recomienda observar el mockup correspondiente (Figura 5.19) para visualizar el resultado que se desea conseguir con el siguiente desarrollo, que puede resultar un poco complejo debido a la cantidad de clases de distintos paquetes utilizadas y la variedad de t´ecnicas aplicadas. En la siguiente explicaci´on, se utilizar´a informalmente el nombre de las clases en castellano para facilitar la comprensi´on por parte del lector, aunque en los diagramas ´estas aparezcan con su nombre original, en ingl´es. El diagrama de la secuencia principal de dicha historia de usuario se puede ver en la Figura 5.56. En el comienzo del diagrama vemos como el actor (due˜no de negocio) primero ha realizado la HU01. Una vez en la pantalla del calendario, el usuario elige una fecha (en este ejemplo 14 de marzo del 2021) y el objeto listenerDatePickerCalendar, que es de una clase activa porque est´a esperando a que ocurra un evento, realiza las operaciones correspondientes englobadas en el nodo ref “Seleccionar una fecha del calendario” (desarrollado en el archivo Astah). La principal operaci´on ejecutada es navegar hacia el fragmento AgendaAppointmentsTimetableFragment, tras lo que Android crea autom´aticamente dicho fragmento. El primer m´etodo ejecutado, seg´un el ciclo de vida de los fragmentos, es onCreate, que en este caso simplemente invoca al mismo m´etodo de la clase padre. El segundo m´etodo se trata de onCreateView, donde suceder´a todo lo restante del diagrama a partir de ahora. En este m´etodo, la primera operaci´on realizada es crear una referencia a las vistas del XML correspondiente, obtener los argumentos del fragmento y crear el ViewModel correspondiente, englobado bajo el nodo ref “Encontrar vistas, argumentos y crear ViewModel”. En la Figura 5.57 se desarrollan estas operaciones. Primero, la vista que se devolver´a se “infla” desde su XML correspondiente (R.layout.fragment timetable), y despu´es, para encontrar los componentes de IU en esa vista, se invoca sobre ella el m´etodo findViewById, pasando el ID correspondiente de la vista buscada. Tras encontrar los tres componentes buscados en este caso (y por tanto creados como objetos), se obtendr´an los argumentos recibidos en el fragmento mediante la clase generada mediante SafeArgs AgendaAppointmentsTimetableFragmentArgs, en este caso d´ıa, mes, a˜no y un boolean que indicar´a si hay que mostrar en rojo las franjas del horario completamente llenas. Finalmente, para crear el ViewModel, se crea un objeto factor´ıa al que se le pasan los par´ametros necesarios para su inicializaci´on (d´ıa, mes y a˜no), y creando un ViewModelProvider al que se le pasa en su constructor la factor´ıa ViewModel que se acaba de crear, se obtiene finalmente el objeto de tipo AppointmentsTimetableViewModel. 76 CAP´ ITULO 5. DISE ˜ NO Figura 5.56. Diagrama de secuencia principal de la HU02 77 5.6. DISE ˜ NO DE LA COMUNICACI ´ ON ENTRE OBJETOS Figura 5.57. Diagrama de secuencia de “Encontrar vistas, argumentos y crear ViewModel” Volviendo a la Figura 5.56, vemos que, como resultado de las acciones ocultas por el interaction use (nodo ref) desarrollado, se crean (mediante el estereotipo ((create))) los tres componentes de IU y el ViewModel. Lo siguiente que se hace es pedirle al ViewModel la fecha en formato DD/MM/AAAA para establec´ersela al texto del t´ıtulo de la pantalla. El siguiente paso es obtener el usuario actual en la sesi´on, que al encontrarse en esta pantalla, s´olo se puede tratar de un usuario tipo Establecimiento. Para ello, se invoca al m´etodo getCurrentUser de la clase de utilidades AuthUtils. En este punto ocurre algo importante, puesto que se trata de la manera que se ha manejado la asincron´ıa que proporciona Firebase, tanto en esta parte de la aplicaci´on como en todas las dem´as que as´ı lo requieran. La soluci´on aplicada se basa en callbacks, que no son m´as que interfaces de un ´unico m´etodo que devuelve void y posee un par´ametro de tipo Object. El funcionamiento se basa en pasar a los m´etodos as´ıncronos como argumento un callback, (authCallback en este caso), 78 CAP´ ITULO 5. DISE ˜ NO que al ser una interfaz, hay que implementar. Desde el m´etodo as´ıncrono, una vez que se han terminado todas las tareas y se est´e preparado para devolver el control a la clase que lo ha invocado, en lugar de hacer return como se har´ıa t´ıpicamente en m´etodos s´ıncronos, se invoca al m´etodo del callback recibido por par´ametro con el resultado que se quiera devolver. Como el par´ametro del m´etodo del callback es de tipo Object, se podr´a hacer casting a cualquier tipo. La implementaci´on del m´etodo del callback se desarrollar´a en la propia clase que se invoca al m´etodo as´ıncrono mediante una funci´on lambda (de ah´ı el estereotipo ((by lambda function))), por tanto como clase interna o inner class. La ejecuci´on de este c´odigo comenzar´a cuando desde el m´etodo as´ıncrono se invoque al m´etodo del callback, asegurando de esta manera que el m´etodo as´ıncrono ha terminado de ejecutarse y el resultado del mismo est´a en el argumento de tipo Object, al que se har´a casting al tipo que proceda. Por ello, tras la invocaci´on del m´etodo getCurrentUser y lo que ocurre en su interior (que no se desarrollar´a puesto que se ver´a m´as tarde con otro ejemplo), se invoca de manera as´ıncrona al m´etodo onCallbackAuth de la clase interna inner AuthCallback, que corresponde a la implementaci´on del callback pasado por par´ametro a getCurrentUser, y desde donde ocurrir´an el resto de operaciones a partir de este momento. La primera comprobaci´on corresponde a si el par´ametro recibido en el m´etodo del callback es null, puesto que por la decisi´on de dise˜no tomada (Secci´on 5.1), significar´a que ha ocurrido un error, y se imprimir´a un mensaje y se parar´a el flujo de ejecuci´on (de ah´ı el bloque break, que parar´ıa el bloque seq que engloba todo el diagrama de secuencia). De no ser null, entonces se har´a un casting del par´ametro a tipo Establishment, resultando en el objeto currentUser. Lo siguiente que ocurre son dos bucles anidados, que llenan el horario de tarjetas libres (WhiteTimetableCardUI) en todas las casillas del mismo. Esto se hace un total de rows (n´umero de filas del tablero) x maxClients (m´aximo de clientes por franja del establecimiento) veces, para llenar el horario completamente. Posteriormente, se sustituyen las tarjetas libres correspondientes con las citas ya registradas. Para ello, se invoca el m´etodo getAppointments del ViewModel pasando como par´ametro el ID del usuario actual. Como llegar´a hasta el DAO (donde las operaciones se realizan contra la base de datos de Firebase), se realiza de manera as´ıncrona, por lo que se vuelve a utilizar de nuevo un callback, en este caso vmCallback. El contenido de este interaction use (nodo ref) “Obtener citas ViewModel” se desarrollar´a en otro diagrama de secuencia. En la Figura 5.58 se observa el desarrollo del interaction use mencionado. Tras hacer unas comprobaciones iniciales sobre los par´ametros, se invoca al m´etodo getAcceptedAppointmentsForDateAndEstablishment de DAOAppointment, cuyo desarrollo se puede ver en la Figura 5.59. Tras otras comprobaciones iniciales, se crea una lista de Appointments que servir´a para ir guardando las citas que se obtengan de la base de datos. Como resultado de la consulta, se obtiene un objeto de tipo Task<DataSnapshot>, al que se asocian dos listeners, uno en caso de que no haya errores (OnSuccessListener) y otro en caso de que ocurra alg´un error (OnFailureListener). Aqu´ı nace la ra´ız de la asincron´ıa, pues estos listeners son invocados de manera as´ıncrona, y por eso pertenecen a clases activas. Una vez se recuperan los datos de la base de datos correctamente, se invoca de manera as´ıncrona el listener OnSuccessListener (Figura 5.60) 79 5.6. DISE ˜ NO DE LA COMUNICACI ´ ON ENTRE OBJETOS Figura 5.58. Diagrama de secuencia de “Obtener citas ViewModel” En dicho listener, se recorren todos los nodos hijos del nodo appointments de la base de datos. Convirtiendo la fecha, ID del establecimiento asociado y estado de cada una de las citas a los tipos necesarios, se comparan con los recibidos como argumento en el m´etodo del DAO, y en caso de coincidir tanto en fecha como en ID de establecimiento y estar en estado “aceptado”, se construye el objeto Cita correspondiente que funcionar´a como DTO, seteando 80 CAP´ ITULO 5. DISE ˜ NO sus atributos con los datos del nodo de la base de datos, y creando contenedores vac´ıos (con el ID) para los atributos de tipo Establecimiento y Cliente, aplicando as´ı el patr´on Proxy (nodo ref “Construir cita”, desarrollado en el archivo Astah), tras lo que se a˜nadir´a a la lista creada para almacenar las citas resultantes de la consulta. Una vez recorridos todos los nodos de la base de datos y finalizado el bucle, se invocar´a al m´etodo del callback onCallbackDAO pas´andole como argumento la lista de citas, lo que nos lleva de vuelta al diagrama de la Figura 5.58, en la parte de la invocaci´on as´ıncrona a onCallbackDAO. Tras realizar la comprobaci´on de si resultDAO (el resultado de la consulta en el DAO, en este caso la lista de citas) es null, en cuyo caso habr´ıa ocurrido un error y se devolver´ıa al callback del ViewModel otro null, se comprueba si la lista de citas (ya casteada a su tipo correspondiente) est´a vac´ıa, en cuyo caso se devolver´ıa al callback del ViewModel. En caso contrario, para cada cita de la lista, se obtendr´a su atributo de tipo Establecimiento mediante el ID que nos ha proporcionado el objeto proxy, invocando al m´etodo getEstablishmentById de DAOEstablishment, que no se desarrollar´a ya que sigue el mismo mecanismo que la obtenci´on de citas. En caso de que el atributo de tipo Cliente no sea null (la cita est´a asociada a un cliente), se seguir´a el mismo procedimiento, invocando a getClientById de DAOClient. Tras setear a la cita su atributo Establecimiento (y Cliente si se ha realizado la consulta) en un nuevo nivel de callback que se puede ver a la derecha del diagrama, se devuelve el control al fragmento invocando al m´etodo onCallbackVM de vmCallback, volviendo a la Figura 5.56. Figura 5.59. Diagrama de secuencia de “Obtener citas DAO” 81 6.1. GU´ IA DE ESTILO PERSONAL icon (descripci´on):iconos que se utilicen en la app. En la descripci´on puede aparecer la secci´on a la que representan o su significado. Por ejemplo: icon board para el icono de la secci´on de “Tabl´on” de la barra de navegaci´on inferior, o icon add para el icono “+”que representa la acci´on de a˜nadir. activity (nombre):layout de una actividad, que conservar´a el mismo nombre que su respectivo archivo de c´odigo. Por ejemplo: activity main para la clase MainActivity. fragment (descripci´on):layout de un fragmento, que conservar´a el mismo nombre que su respectivo archivo de c´odigo. Por ejemplo: fragment board new announcement para la clase BoardNewAnnouncementFragment. item recycler (descripci´on):layout de uno de los elementos de un RecyclerView, que posteriormente se inflar´a en su correspondiente ViewHolder (Secci´on 5.3.3). Por ejemplo: item recycler request para uno de los elementos de una lista din´amica de solicitudes. En algunas ocasiones, si se ha utilizado uno de los archivos para m´as de un caso (un mismo XML de layout de fragmento para varias clases de fragmento distintas), se le ha dado excepcionalmente un nombre m´as general que pueda abarcar todos los sitios donde se utiliza, siempre manteniendo un nombre descriptivo. Por ejemplo: el layout fragment new order se utiliza tanto para la clase AgendaNewOrderFragment como para PlacesRequestOrderFragment. Para los ID de los elementos de los archivos de recursos: label (ID elemento donde aparece):cadena de texto que aparece en otro componente de IU. Por ejemplo: en el bot´on button login aparece una cadena de texto cuyo ID es label button login. snackbar (descripci´on):cadena de texto que aparecer´a mostrada en un Snackbar. Por ejemplo: para mostrar un error en el registro, se muestra en un Snackbar un mensaje con ID snackbar error sign in. (descripci´on) (color):color que se utiliza con cierto prop´osito en la app. Por ejemplo: para mostrar franjas horarias llenas de citas, se utilizar´a el color no space red. item (nombre secci´on):item contenido en un men´u. Por ejemplo: item map para el item de la barra de navegaci´on inferior que representa la secci´on “Mapa”. action (ID salida) to (ID destino):en el grafo de navegaci´on, acci´on que permite navegar desde el fragmento ID salida hacia el fragmento ID destino. Por ejemplo: la acci´on que permite navegar desde el fragmento principal de la secci´on “Agenda” hacia el fragmento de calendario es action item agenda to fragment agenda calendar. (tipo componente) (descripci´on) (ID fragmento sin ’fragment’):para el resto de componentes de IU de Android, su nomenclatura se basa en el nombre del tipo del componente, una descripci´on y el fragmento al que pertenece, para evitar confusiones entre IDs de elementos de distintos fragmentos muy similares. Por ejemplo: para el componente de texto editable del email en la pantalla de login, el ID es edit text email login. 88 CAP´ ITULO 6. IMPLEMENTACI ´ ON Y PRUEBAS Java La otra parte diferenciada en Android es la parte del c´odigo. En este caso, se ha utilizado Java como lenguaje de programaci´on, e incluye todas las clases y sus m´etodos y variables. En este caso, para hacer una distinci´on con el XML, se ha decidido dar a los nombres el formato CamelCase [119]. La nomenclatura para el c´odigo Java de la gu´ıa de estilo es: Para el nombre de las clases: (Descripci´on)Activity:actividad de la app. Por ejemplo: para la actividad principal, el nombre es MainActivity. (Secci´on)(Descripci´on)Fragment:fragmento de la app. Para especificar con el propio nombre de que fragmento se trata, se incluir´a la “ruta” o secci´on en la que se encuentra el fragmento. Por ejemplo: para el fragmento que muestra un horario con los pedidos en la secci´on “Agenda”, el nombre es AgendaOrdersTimetableFragment. (Descripci´on)UI:componente Android creado program´aticamente en lugar de con XML. Por ejemplo: el nombre de la clase de las tarjetas que representar´an citas en el horario es AppointmentTimetableCardUI. AdapterRecycler(Descripci´on):adaptadores para los RecyclerView (Secci´on 5.3.3). Por ejemplo: el adaptador del RecyclerView para la lista din´amica de anuncios del tabl´on es AdapterRecyclerAnnouncements. (NombreFragmentoSinFragment)ViewModel:ViewModel de uno de los fragmentos de la app. Por ejemplo: el ViewModel del fragmento BoardFragment es BoardViewModel. (NombreViewModel)Factory:factor´ıa del ViewModel al que hace referencia, cuando es necesario inicializarlo con par´ametros iniciales. Por ejemplo: la clase factor´ıa de NewAppointmentViewModel es NewAppointmentViewModelFactory. DAO(NombreEntidad):DAO que contiene m´etodos para operar con datos de la base de datos de la entidad a la que hace referencia. Por ejemplo: el DAO que opera con datos de clientes es DAOClient. (NombreClase)Test:clase de tests que testea la clase referenciada en el nombre. Sirve tanto para tests unitarios como para tests de IU. Por ejemplo: para los tests unitarios de la clase PlacesViewModel, se crea la clase PlacesViewModelTest, y para los tests de IU del fragmento AgendaNewOrderFragment, se crea AgendaNewOrderFragmentTest. Para el nombre de variables y m´etodos: idDelComponenteXml:variables que referencian componentes de IU presentes en los XML. Como el XML ya proporciona un nombre explicativo, se mantiene el mismo nombre, de manera que se hace la correspondencia f´acilmente. Por ejemplo: para el bot´on con ID button add board new announcement, el nombre de la variable ser´a buttonAddBoardNewAnnouncement. 89 6.2. CI/CD test(NombreM´etodo)Ok:test unitario que prueba un caso correcto del m´etodo referenciado. Por ejemplo: el m´etodo testGetStringOrderHourOk test(NombreM´etodo)(Raz´onDeError):test unitario que prueba un caso incorrecto del m´etodo referenciado. Por ejemplo: el m´etodo testCreateNewOrderClientNameIsNull, que espera que el m´etodo lance una excepci´on debido a que el nombre del cliente que se pasa por par´ametro es null. test(Descripci´on):test de IU que prueba el caso explicado en el nombre del test. Por ejemplo: el m´etodo testAddNewAppointmentWithSpace testea la acci´on de a˜nadir una nueva cita a la agenda cuando hay espacio. 6.2. CI/CD Para la integraci´on continua de la aplicaci´on, a lo largo de todo el proyecto se ha desarrollado un pipeline en GitLab CI/CD con distintos trabajos que se ejecutan en cada push de c´odigo al repositorio. La intenci´on inicial era a˜nadir tres trabajos al pipeline: compilaci´on, tests unitarios y tests de IU, divididos en dos etapas o stages: compilaci´on, a la que pertenecer´ıa el primer trabajo, y tests, a la que pertenecer´ıan los dos ´ultimos. Finalmente, s´olo fue posible incluir los dos primeros trabajos, puesto que a lo largo del proyecto se han presentado m´ultiples dificultades y limitaciones para el trabajo de tests de IU, las cuales se expondr´an en la Secci´on 6.2.2. El contenido del fichero gitlab-ci.yml, encargado de la ejecuci´on del pipeline de integraci´on continua, tras varias optimizaciones, se presenta a continuaci´on: image: androidsdk/android-30:latest before_script: # Not necessary, but just for surety - chmod +x ./gradlew stages: - build - test # Make Project assembleDebug: interruptible: true stage: build script: - ./gradlew assembleDebug artifacts: paths: - app/build/outputs/ 90 CAP´ ITULO 6. IMPLEMENTACI ´ ON Y PRUEBAS # Run all unit tests, if any fails, interrupt the pipeline (fail it) runUnitTests: interruptible: true stage: test script: - ./gradlew app:testDebug artifacts: paths: - app/tests/unit/ 6.2.1. Explicaci´on del pipeline Abordando l´ınea a l´ınea el contenido del fichero, se puede realizar una descripci´on de las operaciones realizadas. Preparaci´on image: androidsdk/android-30:latest ... En esta l´ınea, se define la imagen que se va a utilizar en el contenedor Docker creado en el runner. En este caso, puesto que se trata de un proyecto Android, la imagen elegida es la ´ultima versi´on de androidsdk/android-30 [33]. Esta imagen cuenta con herramientas pre-instaladas para poder ejecutar trabajos de Android en su versi´on SDK 30 (con la que se compila el proyecto), incluyendo la compilaci´on y los tests, por lo que es muy adecuada para este prop´osito. Adem´as, dado que las herramientas y comandos b´asicos vienen ya instalados en la imagen, se puede prescindir totalmente de una fase before script. ... before_script: # Not necessary, but just for surity - chmod +x ./gradlew ... Aunque como se ha mencionado, esta fase de preparaci´on es totalmente prescindible, para evitar errores en la ejecuci´on que a veces no indican su causa, se ha decidido otorgar permisos de ejecuci´on al fichero ./gradlew, que es el encargado de ejecutar todos los comandos relacionados con trabajos de Android. Gradle es el sistema de automatizaci´on en la compilaci´on de c´odigo Android, y por tanto tambi´en el responsable de este tipo de operaciones. 91 6.2. CI/CD ... stages: - build - test ... El bloque stages indica las distintas etapas por las que est´a compuesto un pipeline. En este caso, como ya se ha explicado, el proceso est´a compuesto por dos etapas: build, donde se ejecutar´a el trabajo de compilaci´on, y test, donde se ejecutar´an los trabajos de tests. Compilaci´on ... # Make Project assembleDebug: interruptible: true stage: build script: - ./gradlew assembleDebug artifacts: paths: - app/build/outputs/ ... El primer trabajo que se ejecutar´a en el pipeline se denomina assembleDebug. El objetivo del mismo es compilar la app Android en versi´on debug o de depuraci´on, de manera que se genere un archivo .apk para instalar la app en un dispositivo m´ovil compatible. La l´ınea interruptible: true indica que si ocurre alg´un error durante la ejecuci´on de este trabajo, el pipeline se dar´a por fallido y finalizar´a. La siguiente l´ınea nos indica que este trabajo se ejecutar´a en la etapa build, la primera de las dos definidas. El bloque script constituye el bloque realmente interesante, pues aqu´ı es donde se ve realmente qu´e operaciones se van a ejecutar. Cada una de las l´ıneas de este bloque son los comandos que se deber´an ejecutar sobre el contenedor Docker que aloja este pipeline. En este caso, para compilar la app solamente es necesario un comando, ./gradlew assembleDebug. Gradle se encargar´a por debajo de todo lo dem´as. Finalmente, el bloque artifacts indica la ruta (paths) donde se deber´an guardar los artefactos generados por el trabajo y que se podr´an descargar m´as tarde desde el repositorio de GitLab, en este caso el apk de la app en versi´on de depuraci´on. Se ha decidido no restringir este trabajo a unas ramas espec´ıficas (como podr´ıan ser master odevelop) mediante directivas only oexcept, puesto que debido al m´etodo de planificaci´on del proyecto explicado en el Cap´ıtulo 2, las nuevas caracter´ısticas se desarrollan en ramas nuevas (Secci´on 3.1.1), y puede ser interesante conseguir un fichero .apk de la app con la nueva caracter´ıstica antes de fusionar la rama con develop. 92 CAP´ ITULO 6. IMPLEMENTACI ´ ON Y PRUEBAS Tests unitarios ... # Run all unit tests, if any fails, interrupt the pipeline (fail it) runUnitTests: interruptible: true stage: test script: - ./gradlew app:testDebug artifacts: paths: - app/tests/unit/ El segundo y ´ultimo trabajo presente en el pipeline se trata de runUnitTests. El objetivo del mismo es ejecutar todos los tests unitarios del proyecto, de manera que se comprueba autom´aticamente si con el nuevo c´odigo a˜nadido en el push realizado, todos los tests siguen pasando correctamente. Los elementos de este trabajo son los mismos que en el anterior, de manera que con la l´ınea interruptible: true se indica que el pipeline detendr´a su ejecuci´on y fallar´a si la ejecuci´on del trabajo falla en alg´un punto. El trabajo pertenece a la etapa test, como se indica en la siguiente l´ınea. El bloque script s´olo contiene un comando nuevamente, ./gradlew app:testDebug, pues gracias a Gradle las dependencias del comando son gestionadas internamente. Los artefactos generados en el trabajo se almacenar´an en la ruta indicada en el bloque artifacts. En este caso, si la ejecuci´on es correcta, el trabajo no genera ning´un artefacto, pero si falla en alg´un punto, se generar´a un reporte con las causas del fallo o los tests fallidos. Este trabajo tampoco se ha querido restringir a s´olo algunas ramas en concreto, pues se considera que es importante conocer si los tests siguen pasando correctamente en cualquier rama donde se haga un push. Adem´as, el tiempo de ejecuci´on de este trabajo es relativamente bajo (alrededor de 2 minutos), y al ser el ´ultimo no entorpecer´a al resto de trabajos. 6.2.2. Limitaciones con tests de IU Para comenzar esta secci´on, quiero expresar mis agradecimientos a Fernando Javier Rodr´ıguez Aparicio, t´ecnico de la Escuela de Ingenier´ıa Inform´atica de la Universidad de Valladolid, y a Samuel Alfageme Sainz, antiguo alumno de la Escuela y actualmente ingeniero de software en el CERN (Organizaci´on Europea para la Investigaci´on Nuclear), con gran conocimiento sobre GitLab y sus herramientas, entre ellas GitLab CI/CD. Durante todo el proceso de investigaci´on del trabajo de tests de IU me han ayudado proporcion´andome fuentes de informaci´on ´utiles y consejos y en el caso de Javier, configurando la m´aquina virtual que act´ua de runner para GitLab CI/CD en mi proyecto. Como se ha mencionado, la intenci´on inicial era introducir en el pipeline un trabajo de tests de IU en la etapa test para complementar a los tests unitarios ya presentes. Sin embargo, a lo largo del proyecto han surgido diversas complicaciones y limitaciones al respecto. 93 6.2. CI/CD Aunque no se incluye en el pipeline presente en el repositorio del proyecto, el aspecto final del trabajo de tests de IU que se ha conseguido es el siguiente: # Run all UI tests, if any fails, interrupt the pipeline (fail it) runUITests: interruptible: true stage: test script: - echo no | avdmanager create avd -n VirtualDevice -k "system-images;android30;google_apis;x86_64" --force - emulator -avd VirtualDevice -no-window -no-audio -debug-init & - adb wait-for-device - adb devices - ./gradlew connectedAndroidTest artifacts: paths: - app/tests/ui El trabajo no es funcional en el runner del proyecto de GitLab que contiene el c´odigo de la app. En el bloque script del trabajo, lo que se hace es crear un emulador mediante un AVD (Android Virtual Device), arrancarlo e intentar ejecutar los tests de IU en el mismo. El problema ra´ız proviene de la documentaci´on inexistente en Internet al respecto, junto con la falta de conocimiento sobre el tema. A lo largo de todo el proyecto se visitaron numerosas p´aginas web con explicaciones y ejemplos acerca de tests de IU de Android en integraci´on continua, ninguna de las cuales ha servido para poder poner en marcha este trabajo. Tras intentarlo haciendo avances sin pr´acticamente ayuda de documentaci´on ´util, las principales dificultades que han ido surgiendo y su estado son: Falta de espacio en el dispositivo - RESUELTO. En los primeros intentos de ejecuci´on del trabajo, puesto que consume muchos recursos ya que hay que crear un emulador completo con su propia imagen de sistema, los runners compartidos de GitLab se quedaron sin espacio en el dispositivo, denegando tambi´en la ejecuci´on de otros trabajos que previamente s´ı funcionaban. Se avis´o a Javier sobre esto, y duplic´o el espacio de 10 GB que poseen normalmente estos runners para permitir el espacio de m´as trabajos, con lo que se solucion´o. Aceleraci´on de hardware no permitida porque la virtualizaci´on est´a desactivada - RESUELTO. Para ejecutar los tests de IU, es necesaria tener activada la aceleraci´on de hardware en la BIOS del sistema. Se contact´o de nuevo con Javier, y tras informar de que los runners est´an alojados en m´aquinas virtuales, aplic´o la virtualizaci´on anidada para salvar este error. Aceleraci´on de hardware no permitida porque no est´a cargado el m´odulo KVM - RESUELTO. Tras activar el soporte anidado de virtualizaci´on en la m´aquina virtual del runner, a´un no permit´ıa la aceleraci´on de hardware, en este caso por falta 94 CAP´ ITULO 6. IMPLEMENTACI ´ ON Y PRUEBAS del m´odulo KVM del kernel del sistema. Javier comprob´o que efectivamente el m´odulo est´a cargado en la m´aquina virtual, y en teor´ıa los contenedores Docker creados poseen las propiedades de la m´aquina en la que se alojan por defecto. Tras realizar algunas pruebas, se descubri´o que era problema de los permisos del dispositivo de aceleraci´on KVM en la m´aquina virtual. Se otorgaron los permisos de ejecuci´on necesarios y se continu´o haciendo pruebas. Falta de espacio en el dispositivo de nuevo - RESUELTO. Al tratarse de runners compartidos con todos los proyectos de GitLab de la instancia de la Escuela, el hecho de realizar pruebas volvi´o a sobrecargar el sistema y a quedarse de nuevo sin espacio. Por tanto, se opt´o por solicitar a Javier una m´aquina virtual personal para establecerla como runner privado en el proyecto, de manera que tambi´en fuera m´as sencillo hacer pruebas desde la m´aquina directamente. Se cre´o una nueva m´aquina virtual con 50 GB para evitar nuevos problemas de falta de espacio y se estableci´o como runner dedicado del proyecto, deshabilitando los runners compartidos. Aceleraci´on de hardware no permitida por no arrancar en modo privilegiado - RESUELTO. Cuando se consigui´o realizar pruebas de nuevo, se comprob´o que a pesar de haber otorgado permisos al m´odulo KVM, la aceleraci´on hardware segu´ıa sin funcionar. Samuel me inform´o sobre el arranque en modo privilegiado de los contenedores Docker para la ejecuci´on del pipeline. Tras realizar algunos cambios en el fichero de configuraci´on de Docker en la m´aquina virtual del proyecto, el contenedor arrancaba ahora en modo privilegiado y la aceleraci´on por fin funcionaba. Comandos del script no encontrados - RESUELTO. A pesar de que la aceleraci´on ya se pon´ıa en marcha, llegado a cierto punto del script del trabajo, algunos de los comandos (como adb) no se encontraban en la variable PATH del sistema. La soluci´on que se tom´o fue cambiar la imagen del contenedor Docker que se estaba utilizando de openjdk:8-jdk aandroidsdk/android-30. Esto fue una gran decisi´on, puesto que a partir de este punto se pudo prescindir del bloque before script, foco de problemas, y al tener dicha imagen algunas herramientas Android pre-instaladas, los comandos se encontraban sin problema. Daemon de Gradle desaparece de forma inesperada - RESUELTO. Cuando por fin se pudo empezar a poner en marcha el trabajo, en medio de la ejecuci´on del ´ultimo comando, el que realmente ejecuta los tests de IU (./gradlew connectedAndroidT est), surg´ıa una excepci´on en tiempo de ejecuci´on que informaba sobre que el proceso odaemon de Gradle desaparec´ıa de forma inesperada. Tras investigar sobre esto, se dedujo que pod´ıa ser problema de la RAM de la m´aquina virtual. Informando a Javier sobre esto ´ultimo, subi´o la RAM de 2 GB a 6 GB, solventando el problema. InstallException: Unknown failure - NO RESUELTO. Al ejecutar finalmente el comando de tests de IU con aceleraci´on de hardware y espacio de sobra tanto en el dispositivo como en RAM, la ejecuci´on se deten´ıa tras unos minutos con la excepci´on mencionada. Tras esto, Samuel intent´o imitar la secuencia de comandos utilizada para un trabajo de tests de IU de Android del repositorio GitLab de F-Droid [46], muy complejo aunque visiblemente funcional en sus ejecuciones, pero sin ´exito de nuevo. Por la limitaci´on de tiempo del TFG, se decidi´o no llevarlo m´as all´a y concluirlo aqu´ı, no incluyendo este trabajo en el pipeline. 95 6.3. PRUEBAS Como conclusi´on, y haciendo una valoraci´on t´ecnica, se puede decir que quiz´as no merece la pena incluir tests de IU en el pipeline de GitLab CI/CD debido a todos los problemas y p´erdidas de tiempo que esto supone, as´ı como la gran cantidad de recursos que consume s´olo la preparaci´on del trabajo, y el aumento de tiempo que supondr´ıa para la ejecuci´on completa del pipeline, pues s´olo este trabajo tiene una duraci´on aproximada de 30 minutos, dependiendo de las caracter´ısticas del runner. La manera de proceder entonces ser´a ejecutar los tests de IU de manera local. 6.3. Pruebas Junto a la implementaci´on de la aplicaci´on, se han incluido pruebas para testear el c´odigo realizado y el funcionamiento de la app a m´as alto nivel. Se han realizado tests automatizados, como son los tests unitarios y los tests de IU, y tests con usuarios, como son los tests de usabilidad. 6.3.1. Tests unitarios El primer tipo de tests automatizados realizados se trata de tests unitarios. Los tests unitarios [116] verifican el funcionamiento de cierto componente de la aplicaci´on en aislamiento. En este caso, con tests unitarios, nos referimos a tests que se pueden ejecutar en la JVM (Java Virtual Machine), sin necesidad de tener que ejecutarlos en un dispositivo Android. El framework utilizado para crear los tests (y el que se utiliza en Java por defecto) ha sido JUnit 4. En este proyecto, los tests unitarios realizados se han empleado para probar todas las clases ViewModel, por eso se encuentran en el paquete es.appgenda.viewmodels del m´odulo test. Se ha realizado un total de 173 tests unitarios. No se han realizado tests unitarios de las clases del subpaquete entities puesto que al tratarse de clases POJO, s´olo cuentan con getters ysetters. Por otro lado, la intenci´on inicial era realizar tests unitarios de las clases del subpaquete daos, pero surgi´o un problema al respecto. Al intentar realizar tests en aislamiento de las mismas, independientes del uso de la API de Firebase (puesto que los DAO son el punto de acceso a la base de datos), se utiliz´o Mockito, el framework recomendado oficialmente por Android para realizar mocks u objetos simulados, con el fin de simular las entidades relacionadas con Firebase y suplantar el resultado que sus m´etodos devuelven. El problema surge debido a la t´ecnica de manejo de la asincron´ıa utilizada en la aplicaci´on: los callbacks, como se explica en la Secci´on 5.6. Dado que los m´etodos as´ıncronos son de tipo void, y el resultado se devuelve mediante la llamada al m´etodo del callback que reciben por par´ametro en lugar de con un return como tradicionalmente, esto hace que haya que implementar el m´etodo de la interfaz callback in-situ, mediante una clase interna. Para poder simular clases internas, hay que utilizar la caracter´ıstica mockito-inline del framework, pero una vez que se intenta ejecutar el test, se produce un error y se informa de que la caracter´ıstica mockito-inline no est´a disponible para Android, por lo que resulta imposible realizar pruebas de este tipo. 96 CAP´ ITULO 6. IMPLEMENTACI ´ ON Y PRUEBAS Por esa misma raz´on, los m´etodos de los ViewModel que tengan dependencias con m´etodos de los DAO no se han podido testear, limit´andose a realizar tests para el resto de m´etodos en sus casos v´alidos y no v´alidos, y tambi´en tests para los casos no v´alidos de los m´etodos con dependencias de los DAO, puesto que en estos casos no se llega a ejecutar la invocaci´on al m´etodo del DAO. En cuanto a la cobertura de estos tests, debido a la condici´on especial explicada, se ha decidido que no ser´ıa realmente representativa en este caso, por lo que no se ha medido. Los casos no v´alidos de los m´etodos de los ViewModel (y los v´alidos en los m´etodos que no invocan m´etodos de los DAO) tienen una cobertura del 100 %, pero la cobertura global es m´as baja por los casos que no es posible testear, y adem´as en cada ViewModel esta cobertura ser´a distinta, en funci´on del n´umero de m´etodos no testeables y su longitud en l´ıneas. En la Figura 6.1 se puede observar el resultado de ejecuci´on de los tests unitarios, indicando que se ha tardado un total de 167 ms en ejecutarlos. Figura 6.1. Resultado de la ejecuci´on de los tests unitarios 6.3.2. Tests de IU Los tests de IU o tests instrumentados son el segundo tipo de tests automatizados realizados. Los tests de IU [116] permiten comprobar el funcionamiento de la aplicaci´on considerando tanto los componentes Android como el ciclo de vida de las actividades y fragmentos anfitriones. Por ello, estos tests requieren ser ejecutados en un sistema Android (emulador o dispositivo f´ısico), de manera que se tenga acceso a sus recursos. El framework utilizado para crear los tests ha sido Espresso, el oficial de Android. Este framework ofrece soporte para simular de forma autom´atica interacciones del usuario con la app instalada en el dispositivo. En este proyecto, los tests de IU realizados se han empleado como tests de aceptaci´on, para verificar el aspecto inicial de los componentes IU, su comportamiento, y los casos de interacci´on con la app correctos e incorrectos de cada uno de los fragmentos. Por ello, los tests se localizan en el paquete es.appgenda.views.fragments del m´odulo androidTest. Se ha realizado un total de 75 tests de IU. Puesto que en estos tests se simula una interacci´on real con la app, se testean indirectamente los casos v´alidos de los m´etodos de los DAO y de los ViewModel que dependen de 97 6.5. LICENCIA 6.5. Licencia Se ha dotado al proyecto de una licencia Creative Commons Atribuci´on-NoComercialSinDerivadas 4.0 Internacional (CC BY-NC-ND 4.0) [32]. Esto significa que el material se puede compartir y distribuir mediante cualquier medio, pero se debe dar cr´edito debidamente e indicar si se han realizado modificaciones, junto con un enlace a la licencia. Adem´as, no se puede hacer uso del material con prop´ositos comerciales, y no se podr´a distribuir material derivado del presente proyecto (remezclado, transformado o creado a partir de ´el). El texto legal de esta licencia se encuentra en el repositorio GitLab del proyecto del Ap´endice B. 104 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO Cap´ıtulo 7 Seguimiento del proyecto 7.1. Introducci´on En este Cap´ıtulo se presentar´a el seguimiento del proyecto realizado sprint a sprint. Los sprints est´an compuestos de distintas tareas, principalmente relacionadas con las historias de usuario, aunque tambi´en hay tareas de otra´ındole que se han llevado a cabo en los mismos. Es por ello que para cada sprint, se presentar´a una tabla compuesta por las siguientes columnas: Historia de usuario, que indicar´a el c´odigo de la historia de usuario con la que se relacionan las tareas de la siguiente columna; Tareas, que enumerar´a las actividades a realizar para dicha historia de usuario; Tiempo estimado, que indicar´a el tiempo que previsiblemente se ha asignado a la historia de usuario, traducido en puntos de historia en la fase de planificaci´on; Tiempo empleado, que registrar´a el tiempo que se ha dedicado realmente al desarrollo de la historia de usuario; y Estado, que indicar´a la situaci´on en la que se encuentra la historia de usuario en el momento de finalizaci´on del sprint entre “no comenzado”, “en progreso” y “finalizado”. Para las tareas que no est´an relacionadas con ninguna historia de usuario (como pueden ser tareas de documentaci´on, refactorizaci´on, etc.), en la columna de Historia de usuario aparecer´a un “-”, en la columna Tareas la descripci´on de la tarea a realizar y en la columna Tiempo estimado el tiempo que se ha planificado para llevarla a cabo. El resto de columnas seguir´an cumpliendo con la misma funci´on. La realizaci´on de cada historia de usuario supone completar cinco tareas distintas (correspondientes con las cinco tarjetas creadas en el tablero GitLab Issue Board, como se explica en el Cap´ıtulo 3). Estas tareas son: An´alisis. En esta tarea, se comprobar´a si es necesario hacer alg´un cambio en el modelo de dominio inicial para poder desarrollar correctamente la historia de usuario en cuesti´on. Tambi´en, se podr´an desglosar ´epicas del Product Backlog en historias de usuario, que puede ser adecuado en ciertos momentos debido al conocimiento ya adquirido. 105 7.2. SEGUIMIENTO DE LOS SPRINTS REALIZADOS Dise˜no. En esta tarea, se completar´an los distintos diagramas existentes actualmente con los nuevos elementos y detalles que se introduzcan en el desarrollo de la historia de usuario. Implementaci´on. En esta tarea, se escribir´a el c´odigo correspondiente al dise˜no creado para a˜nadir a la app la funcionalidad descrita por la historia de usuario. Revisi´on de IU. En esta tarea, se revisar´a si el dise˜no de interfaz de usuario desarrollado se ajusta a lo planeado previamente en los mockups o prototipos. Testeo. En esta tarea, se desarrollar´an tests unitarios y tests de IU para las nuevas caracter´ısticas a˜nadidas con la historia de usuario. 7.2. Seguimiento de los sprints realizados 7.2.1. Sprint 0 (19/01/21 - 10/02/21) Como ya se comentaba en el Cap´ıtulo 2 de planificaci´on, este primer sprint es algo diferente respecto al resto. El objetivo es dedicar unas semanas a labores de preparaci´on y planificaci´on del proyecto, para en el sprint 1 poder dar comienzo al desarrollo de las historias de usuario. Tambi´en, la duraci´on del sprint es distinta a la duraci´on del resto, habiendo dedicado al mismo finalmente un total de 3 semanas y 1 d´ıa. Puesto que en este sprint a´un no se desarrollan tareas relacionadas con las historias de usuario, en lugar de presentarlas en forma de tabla, se enumerar´an y explicar´an las tareas desarrolladas: Elaboraci´on del Product Backlog inicial. Partiendo de la idea inicial, se cre´o una versi´on preliminar del Product Backlog, que se completar´ıa m´as tarde mediante entrevistas a posibles usuarios de la app. Para ello, se escribieron los requisitos de usuario u objetivos de la app en forma de ´epicas, dedicando un tiempo a formaci´on en elaboraci´on de historias de usuario mediante una gu´ıa sobre c´omo escribirlas correctamente y ejemplos reales [82]. Creaci´on de mockups de la app. Se crearon diversos mockups o prototipos de bajo coste que muestran el aspecto de las distintas pantallas que habr´a en la app. Tambi´en, en funci´on de las sugerencias de la tutora y de las entrevistas con los usuarios potenciales, se realizaron varias iteraciones de refinamiento de los mismos. Estos dise˜nos son los que se han presentado en el Cap´ıtulo 5. Realizaci´on de entrevistas a posibles usuarios potenciales. Para darle al proyecto un aspecto m´as real, se decidi´o hacer parte de la elicitaci´on de requisitos con entrevistas a due˜nos de peque˜nos negocios reales y al alcalde de un ayuntamiento. El objetivo de estas entrevistas era, una vez propuesta la idea inicial y ense˜nados los mockups a modo de prototipo, recoger ideas que hicieran de la app m´as ´util para ellos, y concluir en l´ıneas generales si consideran el proyecto viable para utilizar la app en un futuro. Las entrevistas que se realizaron y los resultados obtenidos fueron: 106 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO •Taller de coches. No se han propuesto nuevas funcionalidades para el sistema. El due˜no de negocio s´ı considera viable la idea y utilizar´ıa la app. •Peluquer´ıa. Se han propuesto nuevas caracter´ısticas que se traducen en las siguientes historias de usuario: - Como due˜no de negocio quiero tener la posibilidad de a˜nadir m´as de un cliente por franja horaria en la gesti´on de citas para mejorar la eficiencia de mi trabajo - Como due˜no de negocio quiero que las franjas horarias est´en divididas en 15 minutos para poder gestionar mejor el tipo de citas que mi negocio ofrece La due˜na de negocio s´ı considera viable la idea y utilizar´ıa la app. •Confiter´ıa. No se han propuesto nuevas funcionalidades para el sistema. El due˜no de negocio s´ı considera viable la idea y utilizar´ıa la app. •Ayuntamiento. En este caso, no se trata de un negocio, pero su funci´on de gesti´on de citas para servicios a la ciudadan´ıa es an´aloga a la gesti´on de citas de un establecimiento. Se ha propuesto una nueva caracter´ıstica que se traduce en la siguiente historia de usuario: - Como due˜no de negocio quiero desglosar mi establecimiento en distintos departamentos para saber en qu´e ´area est´an interesados en pedir cita los clientes El ayuntamiento s´ı considera viable la idea y utilizar´ıa la app. En el caso de la caracter´ıstica sugerida por el ayuntamiento, una alternativa que se le propuso se basa en crear distintas cuentas de establecimiento en la app, una por departamento, que se acept´o como soluci´on a su necesidad. Todas las ideas propuestas fueron recogidas y a˜nadidas a la lista de requisitos iniciales, dando como resultado el Product Backlog inicial, que se puede ver en la Tabla 2.13. Descripci´on de requisitos de informaci´on y modelo de dominio inicial. Se escribieron y refinaron los requisitos funcionales de informaci´on del sistema en forma de historias de usuario, resultando en los mostrados en la Tabla 4.11. A partir de ellos, se elabor´o el modelo de dominio inicial, mostrado en la Figura 4.1. Calendarizaci´on inicial. Como parte de la planificaci´on inicial del proyecto, se realiz´o un calendario con las fechas de inicio y fin de los sprints del proyecto y de los eventos importantes a lo largo del proyecto (eventos Scrum, fechas l´ımite de entrega, etc.). Este calendario es el que se puede ver en la Tabla 2.1. Plan de riesgos. Se realiz´o el plan de riesgos ya presentado en la Secci´on 2.4. Plan de presupuestos. Para culminar con la planificaci´on inicial, tambi´en se realiz´o y refin´o el plan de presupuestos mostrado en la Secci´on 2.5. B´usqueda de informaci´on inicial. Para poder empezar el desarrollo del proyecto, se dedic´o tiempo a la b´usqueda de informaci´on y a la formaci´on de algunas de las tecnolog´ıas y herramientas que se iban a utilizar, como GitLab CI/CD para proyectos Android [49] y tests en Android [18]. Arquitectura inicial. Para tener una base sobre la que comenzar la arquitectura de la aplicaci´on, se realiz´o un diagrama Decomposition&Uses style que muestra la arquitectura general inicial del sistema. Este diagrama se mostr´o en el Cap´ıtulo 5, dedicado al dise˜no. 107 7.2. SEGUIMIENTO DE LOS SPRINTS REALIZADOS Preparativos iniciales. Finalmente, se llevaron a cabo otros preparativos iniciales como la creaci´on del tablero de GitLab Issue Board con sus distintas columnas, y la elaboraci´on de un listado de versiones de los programas y herramientas que se utilizar´an a lo largo del proyecto y que ya se han enumerado en el Cap´ıtulo 3. En este sprint, el total de tiempo empleado entre todas las tareas asciende a 20 horas aproximadamente. 7.2.2. Sprint 1 (10/02/21 - 24/02/21) Este sprint es el que da comienzo al desarrollo del proyecto y sus historias de usuario. En un principio, se decidi´o establecer la carga de trabajo por sprint en 40 horas, tal y como sugiere la planificaci´on inicial (20 horas/semana), cantidad que ser´a ajustable en pr´oximos sprints en funci´on de c´omo se trabaje en este. En la primera historia de usuario del Product Backlog, incluida en el Sprint Backlog de este sprint, se ha incluido una tarea extra respecto a las dem´as historias de usuario, consistente en formaci´on y b´usqueda inicial de informaci´on, de manera que se complemente lo necesario con la tarea de la misma ´ındole llevada a cabo en el sprint 0. En la Tabla 7.1 se pueden consultar las tareas llevadas a cabo en el sprint 1. Historia de usuario Tareas Tiempo estimado Tiempo empleado Estado HU01 Formaci´on y b´usqueda inicial de informaci´on An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 25 horas 30 horas 15 minutos Formaci´on, an´alisis, implementaci´on y revisi´on de IU finalizados, dise˜no en progreso, testeo no comenzado HU02 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 10 horas 4 horas An´alisis, implementaci´on y revisi´on de IU finalizados, dise˜no en progreso, testeo no comenzado HU03 An´alisis 5 horas 0 horas No comenzado Tabla 7.1. Tareas del sprint 1 Finalmente, el tiempo empleado al sprint fue de 34 horas 15 minutos, debido a dificultades para conllevarlo con la asignatura que se cursaba este cuatrimestre y sobre todo con las pr´acticas de empresa, comenzadas en la primera semana de este sprint. 108 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO En la tarea de formaci´on incluida en la HU01, se consult´o diversa documentaci´on sobre estilos y colores de Material Design [75] [73] [76], que se aplic´o a la app desde el principio del desarrollo, y sobre algunos componentes de Android que se introdujeron, como la navegaci´on inferior [72] y el componente Navigation [17]. Las tareas de dise˜no de las historias de usuario no fueron finalizadas por dudas que se consultaron a la tutora. Tras consultarlo, se decidi´o que el dise˜no de las clases de actividades y fragmentos de Android se importar´ıa desde Astah tras implementarlos por comodidad, ya que parte del c´odigo de los mismos es auto-generado y supondr´ıa una gran p´erdida de tiempo hacerlo para todos los fragmentos que se creen a lo largo del proyecto. El testeo no se pudo comenzar en ninguno de los casos por formaci´on insuficiente a´un, por lo que se seguir´a trabajando sobre ello en el pr´oximo sprint. Debido a la falta de tiempo, la tercera historia de usuario tampoco se pudo comenzar. Por ello, pasan al siguiente sprint las tareas de dise˜no y testeo de las HU01 yHU02, y la tarea de an´alisis de la HU03. 7.2.3. Sprint 2 (24/02/21 - 10/03/21) A pesar de que en el sprint anterior no se pudo lograr dedicar el tiempo estimado por falta de tiempo por otros motivos acad´emicos, en este sprint se volvi´o a intentar cumplir con las 40 horas estimadas. Como a´un quedaban varias tareas pendientes del sprint anterior y la HU03 se estim´o en 5 puntos (25 horas) debido a que ser´ıa la primera en la que hab´ıa que introducir t´ecnicas como el uso de la arquitectura MVVM o herramientas como Firebase, que servir´ıa de “plantilla” de aqu´ı en adelante, se decidi´o no a˜nadir nuevas historias de usuario en el Sprint Backlog. Adem´as, en la implementaci´on de las historias de usuario ya realizadas, se decidi´o hacer un cambio para convertir todas las pantallas a fragmentos y seguir la arquitectura single-activity [84] en lugar de utilizar m´ultiples actividades. El desglose de tareas del sprint se puede observar en la Tabla 7.2. De la misma manera que en el sprint anterior, no se pudieron alcanzar las horas propuestas para el sprint por falta de tiempo, dedicando un total de 34 horas 45 minutos. Para completar la formaci´on sobre diversos componentes de Android, sobre todo Navigation y la arquitectura MVVM, se realizaron algunas partes de dos cursos oficiales de Android [5] [6]. En el caso de la HU01, el tiempo empleado fue mayor de lo estimado debido a problemas con el framework de pruebas en la tarea de testeo, que finalmente fueron subsanados. De la misma manera, en la HU02, el tiempo iba a ser menor al estimado, pero tras varios problemas con los tests de IU en GitLab CI/CD, no se pudo reducir. De momento, en el pipeline de GitLab CI/CD no se incluye el trabajo de ejecuci´on de tests de IU, solamente se ejecutar´an los trabajos de compilaci´on de la app y de ejecuci´on de tests unitarios. 109 7.2. SEGUIMIENTO DE LOS SPRINTS REALIZADOS Historia de usuario Tareas Tiempo estimado Tiempo empleado Estado HU01 Cambios en la implementaci´on Dise˜no Testeo 7 horas 30 minutos 9 horas Finalizado HU02 Cambios en la implementaci´on Dise˜no Testeo 7 horas 30 minutos 7 horas 30 minutos Finalizado HU03 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 25 horas 18 horas 15 minutos An´alisis finalizado, implementaci´on en progreso, dise˜no, revisi´on de IU y testeo no comenzados Tabla 7.2. Tareas del sprint 2 Un error desconocido relacionado con el componente Navigation fue resuelto mediante las respuestas a una pregunta de Stack Overflow [108]. Para elaborar la vista del horario de citas, hab´ıa dos componentes Android adecuados: GridView yTableLayout. Vista la anatom´ıa y las caracter´ısticas de cada uno [14] [21], se escogi´o TableLayout. Tambi´en se investig´o sobre c´omo dibujar bordes alrededor de la tabla del horario, dando con la soluci´on de nuevo en Stack Overflow [102]. El problema m´as grande que se encontr´o en este sprint era que las vistas que se a˜nad´ıan din´amicamente a la tabla no eran visibles. Tras horas de investigaci´on, se dio con el problema, que consist´ıa en el tipo de par´ametros que se asignaba a las vistas a a˜nadir [98] [99]. Finalmente, pasan al siguiente sprint las tareas de dise˜no, implementaci´on, revisi´on de IU y testeo de la HU03. 7.2.4. Sprint 3 (10/03/21 - 24/03/21) A partir de este sprint, y tras hablarlo con la tutora, se ha hecho un reajuste en las horas planificadas por sprint para evitar la sobrecarga de trabajo. Desde este momento, los sprints en principio constar´an de una carga de 30 horas en lugar de 40. Puesto que existen sprints de refuerzo, se recuperar´an m´as adelante esas horas, a partir del momento que se finalicen las pr´acticas en empresa. Dado que se pretende realizar el diagrama de secuencia de las HU03 yHU04, y es algo que lleva bastante tiempo, se ha decidido incluir solamente estas historias de usuario en el sprint, para completar todas sus tareas y dejar hecha la parte m´as trabajosa de dise˜no del proyecto. 110 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO En la Tabla 7.3 se puede consultar el conjunto de tareas que se han llevado a cabo en este sprint. Historia de usuario Tareas Tiempo estimado Tiempo empleado Estado HU03 Dise˜no Implementaci´on Revisi´on de IU Testeo 10 horas 21 horas 45 minutos Implementaci´on y revisi´on de IU finalizadas, dise˜no y testeo en progreso HU04 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 20 horas 15 minutos An´alisis finalizado, implementaci´on y revisi´on de IU en progreso, dise˜no y testeo no comenzados Tabla 7.3. Tareas del sprint 3 A pesar de la reducci´on en el n´umero de horas estimadas, no se ha conseguido llegar al objetivo debido a la carga de trabajo impuesta por la asignatura de este cuatrimestre, que requer´ıa una pr´actica con fecha de entrega en medio de este sprint. Por ello, se ha incluido un nuevo riesgo al plan de riesgos que se ha materializado y no estaba presente en la lista, el R07 (Tabla 2.8). El total de tiempo empleado en este sprint fue de 22 horas. Como en la HU03 se ha introducido el uso de Firebase como base de datos, se ha dedicado tiempo a realizar un cuestionario sobre cu´al de los dos tipos de base de datos que ofrece Firebase utilizar [38], tambi´en a leer documentaci´on sobre consejos de la estructura de los datos en la base de datos, que es NoSQL [39], y sobre c´omo utilizar en Android la base de datos elegida, Realtime Database [43]. En esta historia de usuario tambi´en se ha dedicado m´as tiempo del estimado debido a un bloqueo surgido durante la implementaci´on del primer DAO. Al crear el proyecto en Firebase, se decidi´o que el servidor de la base de datos est´e alojado en Europa y no en Estados Unidos como lo est´a por defecto, con el fin de reducir la latencia lo m´aximo posible (aunque sea pr´acticamente inapreciable). Resulta que si se aloja en otro sitio que no sea Estados Unidos, hay que especificar la URL de la base de datos a la hora de obtener la instancia en el c´odigo, y ese detalle s´olo lo menciona en algunos apartados de la documentaci´on, no en todos los que deber´ıa, por lo que esta inconsistencia en la documentaci´on ha hecho dedicar un exceso de tiempo en investigar sobre el problema. Para terminar con la implementaci´on de esta historia de usuario, ha sido necesario tambi´en consultar informaci´on sobre c´omo dar formato a los recursos de cadenas de caracteres en Android [19]. Por ´ultimo, se ha intentado a˜nadir de nuevo el trabajo de ejecuci´on de tests de IU a GitLab CI/CD durante la tarea de testeo de la HU03 mediante un ejemplo encontrado [45], pero no se ha conseguido por problemas durante la ejecuci´on. 111 7.2. SEGUIMIENTO DE LOS SPRINTS REALIZADOS 7.2.5. Sprint 3 (ampliaci´on) (24/03/21 - 06/04/21) A pesar de que en la planificaci´on inicial este periodo estaba reservado para vacaciones de Semana Santa, se ha decidido realizar una ampliaci´on del sprint 3 para recuperar las horas que no se hab´ıan podido dedicar en los ´ultimos sprints. Al tratarse de una ampliaci´on y no de un sprint como tal, no se ha estimado tiempo para las tareas, y tampoco se han incluido m´as tareas que las que quedaron pendientes al final del sprint 3. La ´unica diferencia, es que ahora se ha a˜nadido la tarea de dise˜no de la HU02 porque resulta que el diagrama de secuencia que se estaba elaborando correspond´ıa en realidad a esa historia de usuario y no a la HU03, en la que no existe un acceso a la base de datos. Por tanto, las tareas son las mismas, pero ahora correctamente asignadas a su historia de usuario correspondiente. En la Tabla 7.4 se pueden consultar las tareas llevadas a cabo en esta ampliaci´on del sprint 3. Historia de usuario Tareas Tiempo estimado Tiempo empleado Estado HU03 Dise˜no Testeo - 6 horas Finalizado HU04 Dise˜no Implementaci´on Revisi´on de IU Testeo -14 horas 45 minutos Implementaci´on, revisi´on de IU y testeo finalizados, dise˜no en progreso HU02 Dise˜no - 45 minutos En progreso Tabla 7.4. Tareas de la ampliaci´on del sprint 3 El total de tiempo dedicado a esta ampliaci´on de sprint ha sido de 21 horas 30 minutos. Como parte de la tarea de testeo de la HU03, se sigui´o intentando a˜nadir los tests instrumentados o de IU al pipeline de GitLab CI/CD, sin ´exito. En este punto se decidi´o solicitar a los t´ecnicos de la Escuela una m´aquina virtual para que funcione como runner en el proyecto de este TFG en GitLab, con el objetivo de tener m´as espacio y no entorpecer las ejecuciones de los runners compartidos con los dem´as proyectos, adem´as de poder hacer pruebas en la propia m´aquina virtual, por lo que de momento las tareas de testeo no incluir´an la ejecuci´on de los tests de IU en integraci´on continua. Durante la realizaci´on de la HU04, la implementaci´on tuvo que a˜nadir un detalle respecto al mockup realizado para esta pantalla, dado que en un principio se plane´o poder a˜nadir una cita seleccionando varias tarjetas libres disponibles pero finalmente, por simplicidad, se har´a click en una sola tarjeta, por lo que el formulario de nueva cita ahora tambi´en contendr´a un campo “Hora de finalizaci´on”. Este formulario contiene selectores para elegir fecha y hora, por 112 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO lo que se consult´o la documentaci´on de Android correspondiente [20]. Dadas las restricciones de las horas a seleccionar (en franjas de 15 minutos y de 8:00 a 23:00), se intent´o crear un selector personalizado, pero debido a la complejidad de crearlo, ya que es un componente que ofrece Android y no es f´acilmente customizable [111] [107], de momento se ha optado por mostrar un mensaje de retroalimentaci´on al usuario cuando la selecci´on sea incorrecta. Para los tests de esta misma historia de usuario, se a˜nadi´o un matcher customizado obtenido de una pregunta en Stack Overflow [100], y se busc´o informaci´on sobre c´omo comprobar que se muestra un Snackbar con el mensaje requerido por pantalla [110]. Las tareas que pasan al siguiente sprint son las de dise˜no de las HU03 yHU04, de las que se planea realizar diagramas de secuencia. 7.2.6. Sprint 4 (06/04/21 - 21/04/21) Para este sprint, en lugar de 30 horas, se ha estimado que se podr´ıa dedicar un total de 25 horas, debido a un examen que tendr´a lugar en la primera semana y a la entrega de una pr´actica planificada para la segunda semana del mismo, de tal manera que no ocurra como en los sprints anteriores y no se pueda alcanzar el tiempo estimado. A parte de continuar con las tareas pendientes del anterior sprint, se han introducido las dos historias de usuario siguientes del Product Backlog. En la Tabla 7.5 se puede observar el desglose de tareas del sprint. Esta vez, s´ı que se ha cumplido con la estimaci´on e incluso se ha rebasado m´ınimamente, con 25 horas 15 minutos empleadas en total. En las tareas de testeo, se han podido solucionar finalmente los “problemas” en los tests de IU relacionados con la asincron´ıa de los m´etodos de la base de datos, que obligaban a introducir una espera arbitraria con Thread.sleep hasta que se crearan las nuevas entradas para el test. Esto no es considerado una buena pr´actica, por lo que la soluci´on ideada se basa en una t´ecnica similar a una espera activa, con variables de tipo boolean de acceso at´omico. Adem´as, para poder crear un entorno de test m´as f´acilmente, ahora los m´etodos “create” de los DAO devuelven el ID del objeto creado, para poder eliminarlos por ID al finalizar el test. Tambi´en en relaci´on con los tests, tras numerosos intentos por testear los m´etodos de los ViewModel que usan m´etodos del DAO, se ha llegado a la conclusi´on de que no es posible, dado que en Android no es posible mockear o simular mediante mocks un m´etodo est´atico que a su vez utiliza un callback, t´ecnica que se est´a utilizando en la aplicaci´on para manejar la asincron´ıa, como se ha explicado en el Cap´ıtulo 5. Mockito [81], que es el framework de mocks recomendado por Android, imprime un mensaje en el log informando de que la funcionalidad de mock inline, la necesaria para simular callbacks, no est´a soportada en Android. Durante el tiempo que se ha dedicado investigando sobre ello antes de llegar a esta conclusi´on, se ha le´ıdo diversa documentaci´on y preguntas [66] [109] [97] [106]. Tras comentarlo con la tutora en la reuni´on Scrum weekly, se ha acordado no realizar tests de los m´etodos de los DAO, dado que indirectamente ya se testean con los tests de IU. 113 7.2. SEGUIMIENTO DE LOS SPRINTS REALIZADOS Historia de usuario Tareas Tiempo estimado Tiempo empleado Estado -Documentaci´on del Cap´ıtulo 2 15 horas 19 horas 30 minutos Finalizado HU15 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 5 horas 6 horas Finalizado HU16 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 2 horas 30 minutos 35 minutos Finalizado HU17 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 2 horas 30 minutos 50 minutos Finalizado HU18 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 5 horas 1 hora 20 minutos Finalizado HU19 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 5 horas 2 horas Finalizado HU20 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 10 horas 7 horas 25 minutos Finalizado -Refactorizaci´on de c´odigo - 9 horas Finalizado Tabla 7.8. Tareas del sprint 7 120 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO 7.2.10. Sprint 8 (02/06/21 - 16/06/21) Puesto que la asignatura del cuatrimestre fue finalizada en el sprint anterior y la memoria de pr´acticas tambi´en, a partir de este sprint se puede dar dedicaci´on completa a la realizaci´on del TFG, planificando un sprint de 50 horas para compensar con los de 30 horas durante la realizaci´on de pr´acticas en empresa. Adem´as de incluir las siguientes historias de usuario, se ha planificado 20 horas para avanzar en la documentaci´on y 2 horas 30 minutos para incluir los tests de IU en el pipeline de integraci´on continua. La Tabla 7.9 muestra las tareas llevadas a cabo en este sprint. El tiempo total dedicado al sprint fue de 53 horas 30 minutos, sobrepasando las 50 horas planificadas. Como la tarea de documentaci´on del Cap´ıtulo 3 se finaliz´o sin consumir todas las horas planificadas para ello, se a˜nadi´o al sprint una nueva tarea para continuar con la memoria del TFG, en este caso con el Cap´ıtulo 4. En cuanto a la mejora de GitLab CI/CD, puesto que se llevaba varios meses intentando incluir los tests de IU en el pipeline sin ´exito, se decidi´o recurrir a Samuel Alfageme, antiguo alumno de la Escuela con gran conocimiento sobre GitLab. La tarea no fue finalizada puesto que se qued´o pendiente una reuni´on y m´as pruebas para una fecha perteneciente al sprint siguiente. En la HU21 se ha invertido m´as tiempo del estimado dado que en un principio se pensaba incluir la funcionalidad de notificaciones push. Tras unas horas de investigaci´on a fondo, se ha llegado a la conclusi´on de que para poder gestionar notificaciones debidas a cambios en nodos de la base de datos, es necesario un script Node.js para el backend, por lo que acord´andolo con la tutora se ha decidido dejar las notificaciones push fuera del alcance del proyecto. Tambi´en, en la HU22 se ha dedicado m´as tiempo del planificado debido a problemas con el formato del texto editable de la ventana de di´alogo personalizada de respuesta de rechazo. Tras un tiempo investigando y probando por qu´e todo el texto aparec´ıa en una sola l´ınea y no en varias, se ha deducido con ayuda de una pregunta de Stack Overflow [95] y m´as pruebas, que se trata de un bug de Android, ya que estableciendo como tipo de entrada InputType.TYPE CLASS TEXT funciona, pero si se establece InputType.TYPE TEXT VARIATION LONG MESSAGE, que es una variaci´on del anterior y deber´ıa funcionar igual (en el XML lo hace), no funciona. En la tarea de revisi´on de IU de la HU23, se ha decidido simplificar la interfaz de usuario a base de incluir en la pantalla de “Citas solicitadas” tambi´en las pantallas de respuesta de rechazo de cita y la confirmaci´on de cita, puesto que muestran la misma informaci´on y tiene sentido agruparlas. Lo mismo se har´a con las historias de usuario an´alogas de pedidos. Asimismo, se ha decidido en esta versi´on de la app no ofrecer la opci´on de cancelar la cita, sino que sea el propio due˜no de negocio el que tenga que eliminarla de la agenda para cancelarla. Para comenzar con la implementaci´on de esta historia de usuario, se ha hecho una refactorizaci´on para a˜nadir un atributo a la clase Order (y por tanto a Appointment que 121 7.2. SEGUIMIENTO DE LOS SPRINTS REALIZADOS Historia de usuario Tareas Tiempo estimado Tiempo empleado Estado -Documentaci´on del Cap´ıtulo 3 20 horas 15 horas 5 minutos Finalizado -Mejora de GitLab CI/CD 2 horas 30 minutos 5 horas 50 minutos En progreso HU21 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 2 horas 30 minutos 6 horas 15 minutos Finalizado HU22 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 2 horas 30 minutos 3 horas 35 minutos Finalizado HU23 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 10 horas 13 horas 10 minutos Finalizado HU24 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 2 horas 30 minutos 2 horas 55 minutos Finalizado HU25 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 5 horas 1 hora 45 minutos Finalizado HU26 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 5 horas 0 horas No comenzado -Documentaci´on del Cap´ıtulo 4 -4 horas 55 minutos En progreso Tabla 7.9. Tareas del sprint 8 122 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO hereda de ella) de tipo Client, para asociar cada cita y pedido con un cliente si este atributo no es null (puede ocurrir que no est´e asociado con ninguno si es el propio due˜no de negocio el que registra la cita o pedido, en cuyo caso tendr´a s´olo el atributo que indica el nombre del cliente). Tambi´en, se ha creado una nueva clase IdentifiedUser que generalizar´a a las clases Client yEstablishment, las cuales tienen atributos en com´un. Pasan al siguiente sprint todas las tareas de la HU26, que no se ha podido comenzar, y las tareas de documentaci´on del Cap´ıtulo 4 y de mejora de GitLab CI/CD, ambas en progreso. 7.2.11. Sprint extra 1 (16/06/21 - 30/06/21) Con este sprint se comienzan los dos sprints de margen que se hab´ıan establecido en la planificaci´on inicial. Como a´un quedan tareas por hacer, se har´a uso de ellos. El objetivo de este sprint es finalizar la implementaci´on de la app con todas las historias de usuario restantes, por lo que se ha estimado para el mismo unas 55 horas, que seg´un los puntos de historia restantes y la tarea de mejora de la integraci´on continua, es el tiempo que puede llevar finalizarlo. En este caso, como lo prioritario consiste en acabar el desarrollo de las historias de usuario, la tarea de documentaci´on proveniente del sprint anterior se ha dejado como tarea extra por si sobra tiempo. En la Tabla 7.10 se pueden ver todas las tareas realizadas en este pen´ultimo sprint. El tiempo total dedicado al sprint fue de 61 horas 15 minutos, superando lo planificado incluso aunque se estimara por lo alto. La tarea de a˜nadir los tests de IU a la integraci´on continua sigue en progreso una vez acabado el sprint, pues se han realizado diversas pruebas y durante el curso del siguiente sprint se tendr´a una reuni´on final con Samuel para concluir si se puede y si merece la pena a˜nadir finalmente estos tests al pipeline o no, puesto que da muchos problemas durante la ejecuci´on. En las historias HU26 yHU28 parece que se ha sobreestimado el tiempo planificado, ya que se dispon´ıa del c´odigo base desarrollado en historias de usuario anteriores, lo que ha permitido acelerar considerablemente el ritmo limitando las tareas a realizar algunas adaptaciones. De la misma manera, el contenido de la base de datos ya estaba adaptado desde historias de usuario anteriores y no ha hecho falta manipularlo en estos casos. Para la implementaci´on del sistema de autenticaci´on en la HU29, se ha introducido al proyecto Firebase Authentication, consultando su documentaci´on para aprender a utilizarlo [41]. A pesar de la estimaci´on de 10 horas de esta historia de usuario, se ha empleado un n´umero considerablemente mayor de horas dado que se tuvo que probar con varias soluciones distintas. Finalmente, se decidi´o crear una clase de utilidad AuthUtils con los m´etodos necesarios para la gesti´on de usuarios y sesiones. Despu´es de esto, hubo que adaptar el resto del c´odigo del proyecto y sus tests al nuevo sistema de autenticaci´on, que supon´ıa una gran cantidad de c´odigo dado que toda la parte de gesti´on de citas y pedidos ya estaba implementada. 123 7.2. SEGUIMIENTO DE LOS SPRINTS REALIZADOS Historia de usuario Tareas Tiempo estimado Tiempo empleado Estado -Mejora de GitLab CI/CD 2 horas 30 minutos 3 horas En progreso HU26 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 5 horas 50 minutos Finalizado HU27 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 2 horas 30 minutos 50 minutos Finalizado HU28 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 10 horas 2 horas Finalizado HU29 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 10 horas 21 horas 55 minutos Finalizado HU30 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 5 horas 2 horas 30 minutos Finalizado HU31 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 5 horas 4 horas 45 minutos Finalizado HU32 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 2 horas 30 minutos 55 minutos Finalizado (Contin´ua en la p´agina siguiente) 124 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO (Empieza en la p´agina anterior) Historia de usuario Tareas Tiempo estimado Tiempo empleado Estado HU33 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 5 horas 2 horas Finalizado HU34 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 5 horas 4 horas 40 minutos Finalizado HU35 An´alisis Dise˜no Implementaci´on Revisi´on de IU Testeo 2 horas 30 minutos 25 minutos Finalizado -Mejora de IU - 15 horas En progreso -Revisi´on de la documentaci´on de los Cap´ıtulos 1-3 -2 horas 10 minutos Finalizado -Documentaci´on del Cap´ıtulo 4 - 15 minutos En progreso Tabla 7.10. Tareas del sprint extra 1 Adem´as, en los tests de IU surgieron problemas al introducir esta nueva caracter´ıstica, ya que la t´ecnica utilizada hasta ahora de espera activa para manejar la asincron´ıa no se pod´ıa usar, puesto que no se puede hacer un seguimiento del proceso de inicio de sesi´on ejecutado por Firebase y no ocurre ning´un evento que indique que se ha iniciado sesi´on para poder continuar con el test. La soluci´on adoptada ha sido introducir una espera, en este caso establecida en 1 segundo, que ha sido el m´ınimo tiempo que se ha comprobado emp´ıricamente que tarda aproximadamente en iniciar sesi´on el servidor, de tal manera que no perjudique significativamente al tiempo total de ejecuci´on de los tests. Para la HU34 se ha introducido al proyecto la API de Google Maps, para lo que se ha consultado su documentaci´on oficial [51]. En la fase de testeo, se ha observado que Espresso, el framework oficial para tests de IU en Android, no posee funcionalidades para testear marcadores dentro de un mapa interactivo, por lo que los tests de IU de esta historia y la siguiente se han limitado a comprobar que efectivamente se muestra correctamente el mapa 125 7.2. SEGUIMIENTO DE LOS SPRINTS REALIZADOS por pantalla. Con el desarrollo de esta historia de usuario, la mayor parte de la HU35 tambi´en queda hecha, por lo que habr´a que dedicar tiempo solamente a retocar algunos detalles en implementaci´on y tests. Como se consigui´o finalizar el desarrollo de las historias de usuario antes de lo previsto, se a˜nadieron al sprint una tarea de mejora de IU y tareas de documentaci´on. En la tarea de mejora de IU se introdujo Firebase Cloud Storage para almacenar en la nube las im´agenes de perfil de los usuarios identificados. Para ello, se consult´o su documentaci´on oficial [37]. Tambi´en se a˜nadi´o la funcionalidad de explorar en el almacenamiento interno del dispositivo para elegir la foto de perfil en el registro de un cliente. Para ello es necesario empezar una nueva actividad, y como startActivityForResult (el m´etodo tradicional) ha sido deprecado hace relativamente poco, se ha utilizado el nuevo m´etodo recomendado por Android, registerForActivityResult [8]. Pasan al siguiente sprint las tareas de mejora de IU y de GitLab CI/CD por reuniones pendientes que tendr´an lugar durante las pr´oximas semanas, y la tarea de documentaci´on. 7.2.12. Sprint extra 2 (30/06/21 - 14/07/21) En este ´ultimo sprint, de duraci´on de 2 semanas tambi´en, se ha decidido no estimar tiempo para las tareas pendientes para finalizar el proyecto, dado que se dedicar´a todo lo necesario para darlas por finalizadas. Tambi´en es posible que el proyecto se finalice antes de la fecha de fin de sprint, por lo que lo m´as l´ogico era no dar una estimaci´on. Las tareas que se incluyen en el sprint son las pendientes del sprint anterior y todo el resto de la documentaci´on. En la Tabla 7.11 se muestra el desglose de tareas llevadas a cabo en el sprint. El tiempo total dedicado a este sprint finalmente fue de 64 horas 40 minutos. Adem´as, no se ha tenido en cuenta la preparaci´on de la presentaci´on para la defensa del TFG, puesto que la presente memoria se debe entregar antes de elaborar dicha presentaci´on. En la tarea de mejora de IU, para darla por finalizada, se tuvo una reuni´on con Alejandra Mart´ınez, docente de la Escuela de Ingenier´ıa Inform´atica de la Universidad de Valladolid con especialidad en interacci´on persona-computadora, para hacer una revisi´on final de la interfaz de usuario de la app y recibir sugerencias sobre c´omo hacer m´as usable la app u otros comentarios. Algunas de las sugerencias fueron aplicadas y otras, que se explicar´an en el Cap´ıtulo 8, quedar´an como l´ıneas futuras de trabajo para una nueva iteraci´on de mejora de IU. Para concluir con la tarea de mejora de GitLab CI/CD, se tuvo una ´ultima conversaci´on con Samuel, en la que se decidi´o finalmente no incluir los tests de IU al pipeline de integraci´on continua en GitLab. Las distintas limitaciones encontradas y conclusiones aparecen documentadas en la Secci´on 6.2.2. 126 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO Historia de usuario Tareas Tiempo estimado Tiempo empleado Estado -Mejora de GitLab CI/CD - 30 minutos Finalizado -Mejora de IU -1 hora 45 minutos Finalizado -Documentaci´on del Cap´ıtulo 4 -3 horas 5 minutos Finalizado -Documentaci´on del Cap´ıtulo 5 -17 horas 45 minutos Finalizado -Documentaci´on del Cap´ıtulo 6 - 10 horas 45 minutos horas Finalizado -Documentaci´on del Cap´ıtulo 7 -13 horas 15 minutos Finalizado -Documentaci´on del Cap´ıtulo 8 -1 hora 10 minutos Finalizado -Documentaci´on de Anexos -5 horas 10 minutos Finalizado -Revisi´on de toda la documentaci´on -6 horas 15 minutos Finalizado -Preparaci´on de tests de usabilidad - 45 minutos Finalizado -Realizaci´on de tests de usabilidad -2 horas 30 minutos Finalizado -Soluci´on de algunos bugs -1 hora 45 minutos Finalizado Tabla 7.11. Tareas del sprint extra 2 Para completar la documentaci´on del Cap´ıtulo 6 (Implementaci´on y pruebas), se han realizado tests de usabilidad a 3 de los usuarios potenciales de la app entrevistados al principio del proyecto, y a 2 usuarios con rol de cliente, por lo que se a˜nadieron dos tareas relacionadas con esto: una de preparaci´on y otra de realizaci´on de los tests. Realizando los tests de usabilidad se descubrieron algunos peque˜nos bugs, por lo que se abri´o una nueva tarea en el sprint para solventarlos. Finalmente, tras terminar la documentaci´on y su revisi´on, el proyecto se dio por finalizado dos d´ıas antes de terminar el sprint, el 12 de julio. 127 7.3. RESUMEN DE LA EJECUCI ´ ON DEL PROYECTO 7.3. Resumen de la ejecuci´on del proyecto Una vez finalizado el proyecto, es interesante hacer un contraste entre la planificaci´on del mismo y c´omo se ha desarrollado realmente, por lo que en esta secci´on se comparar´an diversos aspectos. 7.3.1. Calendarizaci´on planificada y real La calendarizaci´on inicial, que se puede ver en la Tabla 2.1, ha sido en su mayor parte respetada. Finalmente se ha hecho uso de los dos sprints extra, con su duraci´on planificada, y la gran mayor´ıa los eventos planificados han tenido lugar con normalidad. La carga de trabajo de los sprints ha sido adaptada a las circunstancias del momento, pero eso ya se tuvo en cuenta en la planificaci´on inicial, y el total de horas requeridas se ha podido cumplir, como se ver´a en la siguiente subsecci´on. Entre los detalles a destacar, se pueden mencionar dos Scrum Weekly, que por diversos motivos como por ejemplo una semana de trabajo intensivo (periodo de correcci´on de ex´amenes y pr´acticas antes del cierre de actas), la tutora no tuvo disponibilidad para realizar la reuni´on por videoconferencia y se hizo la reuni´on por escrito. Se redactaron los puntos principales a mencionar en la reuni´on, dejando para la siguiente semana la presentaci´on en directo de nuevas caracter´ısticas en la app, y cuando la tutora tuvo disponibilidad, se realizaron tambi´en por escrito los comentarios necesarios sobre ello. Esto no supuso ning´un problema puesto que en realidad la esencia de la reuni´on (informar sobre avances y preguntar dudas importantes) sigui´o siendo la misma, s´olo que en lugar de realizarla de manera s´ıncrona, se realiz´o por escrito y de manera as´ıncrona. Otro detalle es que, a modo de recuperaci´on de horas de trabajo, el per´ıodo de vacaciones de Semana Santa planificado inicialmente, se convirti´o en una ampliaci´on del sprint 3 (el que estaba en curso en ese momento). Finalmente, en el ´ultimo sprint del proyecto (sprint extra 2), a pesar de haber mantenido la duraci´on de 2 semanas establecida, se pudo finalizar antes, y por tanto los ´ultimos d´ıas del sprint no se trabaj´o sobre ello. En conclusi´on, el proyecto se desarroll´o desde el 19 de enero hasta el 12 de julio del 2021, resultando en una duraci´on aproximada de 6 meses. 7.3.2. Tiempo estimado y empleado El tiempo requerido para la realizaci´on del TFG seg´un la gu´ıa docente son 300 horas (explicado en la Secci´on 2.3), y para tener un margen amplio por posibles retrasos en la fecha de finalizaci´on, se planific´o un total de 340 horas de trabajo con los 8 sprints principales y el sprint 0 de preparaci´on, y un total de 420 horas con los sprints extra. 128 CAP´ ITULO 7. SEGUIMIENTO DEL PROYECTO Realizando la suma del tiempo dedicado de cada uno de los sprints desarrollados en la secci´on anterior de este Cap´ıtulo, el c´omputo total de tiempo dedicado al proyecto es de 448 horas 30 minutos, por lo que se ha cumplido con creces las 300 horas requeridas para la elaboraci´on del TFG. 7.3.3. Costes finales Teniendo en cuenta una duraci´on aproximada de 6 meses para el proyecto, y 448 horas de dedicaci´on al mismo, se recalcular´a el coste total y se contrastar´a con los presupuestos simulados y reales planificados en la Secci´on 2.5. Coste simulado final Los elementos son los mismos ya explicados en el prespuesto simulado. Con el tiempo y duraci´on dedicados realmente al proyecto, el c´alculo del coste simulado final queda como se ve en la Tabla 7.12. Concepto Precio unitario Cantidad Total Hora de trabajo de desarrollador Android 13,07e/hora 448 horas 5855,36e Seguridad Social del empleado 6,55e/hora 448 horas 2934,40e Equipo del empleado (MacBook Pro 2020) 44,35e/mes 6 meses 266,10e Smartphone de pruebas (Samsung Galaxy S10+) 13,52e/mes 6 meses 81,12e Espacio de trabajo coworking 165e/mes 6 meses 990e Licencia Microsoft 365 Empresa B´asico 4,12e/mes 6 meses 24,72e Licencia Balsamiq Cloud 7,42e/mes 6 meses 44,52e Licencia Astah Professional 11,67e/mes 6 meses 70,02e TOTAL 10266,24e Tabla 7.12. Coste simulado final Con la normalizaci´on del 25 % que se hab´ıa aplicado al presupuesto simulado a modo de colch´on, la estimaci´on era de un coste total simulado de 9878,46e, que al final ha resultado ser de 10266,24e, por lo que la estimaci´on inicial se ha quedado relativamente cerca, pero no habr´ıa cubierto todo el coste simulado final, debido al mayor n´umero de horas empleado en el proyecto y el sobrecoste que esto supone. Coste real final En este caso los elementos tambi´en son los mismos que los explicados en el presupuesto real. Con la cantidad de tiempo y duraci´on que se han dedicado realmente al proyecto, el c´alculo del coste real final es el que se muestra en la Tabla 7.13. Como el consumo medio de un port´atil en 1 hora es de 0,11 kWh (como se explica en el presupuesto real), en las 448 horas dedicadas ha sido de 49,28 kWh. 129