Sport administration: gestor de reservas para instalaciones deportivas

UNIVERSIDAD DE VALLADOLID ESCUELA DE INGENIERÍA INFORMÁTICA (SEGOVIA) GRADO EN INGENIERÍA INFORMÁTICA DE SERVICIOS Y APLICACIONES AUTOR: FERNANDO DE LA CALLE RODRÍGUEZ TUTOR: FERNANDO DÍAZ GÓMEZ SPORT ADMINISTRATION GESTOR DE RESERVA DE INSTALACIONES DEPORTIVAS 2 AGRADECIMIENTOS En primer lugar agradecer a toda mi familia por todo el cariño y apoyo que me han dado durante estos años y en especial a mi novia por leer este documento en infinitas ocasiones para mejorar la redacción. También agradecer a todos los profesores que durante estos años han puesto todo de su parte para formarme lo mejor posible, y un agradecimiento especial a Fernando Díaz Gómez por prestarse a ser el tutor de mi proyecto y guiarme en todo el desarrollo del mismo. Por último pero no menos importante, gracias a todos los compañeros que me han echado una mano en los momentos más duros y me han hecho reír cuando más lo necesitaba. 4 RESUMEN El objetivo de este Trabajo Final de Grado es la creación un sistema de gestión de instalaciones deportivas para todos los usuarios. El principal propósito es aportar una herramienta con la cual todo usuario que lo considere pueda reservar una instalación de forma sencilla y rápida. En resumen, con la realización de este proyecto se busca facilitar la experiencia de los usuarios a la hora de reservar instalaciones deportivas. Palabras clave: Desarrollo web, Android, Firebase, gestión de reservas, instalaciones deportivas ABSTRACT The objective of this Final Degree project is the creation of a sports facilities management system for all users. The main purpose is a tool for any user to book quickly and easily. In summary, the realization of this project seeks to facilitate the user experience when booking sports facilities. Keywords: Web development, Android, Firebase, booking, sports facilities 6 CONTENIDO 1. INTRODUCCIÓN .................................................................................................. 16 1.1 Motivación: ........................................................................................................... 18 1.2 Objetivos y Alcance: ............................................................................................. 18 1.3 Estructura de la documentación: ........................................................................... 20 1.4 Contenido del disco: ............................................................................................. 21 2. ESTADO DEL ARTE ............................................................................................. 22 3. PLANIFICACIÓN Y PRESUPUESTO .................................................................. 28 3.1 Metodología de Trabajo: ....................................................................................... 30 3.2 Planificación temporal .......................................................................................... 30 3.3 Presupuestario ....................................................................................................... 32 3.3.1 Coste de componentes Hardware: .................................................................. 32 3.3.2 Coste de componentes Software: ................................................................... 33 3.3.3 Coste de personal: .......................................................................................... 33 3.3.4 Método de puntos de función ......................................................................... 34 3.3.5 Estimación por COCOMO ............................................................................. 37 3.3.6 Comparativa de estimaciones ......................................................................... 39 3.4 Presupuesto Final .................................................................................................. 40 4. ANÁLISIS ............................................................................................................... 42 4.1 Actores del sistema: .............................................................................................. 44 4.2 Requisitos de usuario: ........................................................................................... 44 4.2.1 Lista de requisitos de usuario: ........................................................................ 45 4.2.2 Casos de uso: .................................................................................................. 45 4.3 Requisitos de información: ................................................................................... 52 4.3.1 Modelo Conceptual de datos: ......................................................................... 52 4.3.2 Diccionario de datos ....................................................................................... 53 4.4 Requisitos Funcionales: ........................................................................................ 55 4.5 Requisitos no Funcionales: ................................................................................... 57 5. DISEÑO .................................................................................................................. 58 5.1 Arquitectura lógica ............................................................................................... 60 5.2 Arquitectura Física ................................................................................................ 61 5.3 Diagrama de clases ............................................................................................... 62 7 5.4 Modelo lógico de la base de datos ........................................................................ 63 5.5 Diseño de la interface............................................................................................ 66 5.5.1 Diseño aplicación móvil: ................................................................................ 66 5.5.2 Diseño aplicación web ................................................................................... 72 6. IMPLEMENTACIÓN ............................................................................................. 78 6.1 Herramientas utilizadas: ....................................................................................... 80 6.1.1 Herramientas de soporte: ................................................................................ 80 6.1.2 Herramientas para el desarrollo móvil ........................................................... 80 6.1.3 Herramientas para el desarrollo web .............................................................. 81 6.2 Tecnologías utilizadas: ......................................................................................... 81 6.2.1 Tecnologías para el desarrollo móvil: ............................................................ 81 6.2.2 Tecnologías para el desarrollo web: ............................................................... 81 6.3 Implementación: ................................................................................................... 81 6.3.1 Crear proyecto Firebase ................................................................................. 82 6.3.2 Integración de Firebase en las aplicaciones ................................................... 83 6.3.3 Administrar usuarios en Firebase ................................................................... 86 6.3.4 Funciones principales de acceso a Firebase ................................................... 89 6.3.5 Desarrollo de la aplicación móvil................................................................... 94 6.3.6 Desarrollo de la aplicación web: .................................................................. 105 7. PRUEBAS ............................................................................................................. 112 7.1 Pruebas de caja blanca: ....................................................................................... 114 7.1.2 Aplicación móvil: ......................................................................................... 114 7.1.1 Aplicación Web: ........................................................................................... 114 7.2 Pruebas de caja negra: ......................................................................................... 114 7.2.2 Aplicación móvil: ......................................................................................... 115 7.2.1 Aplicación Web: ........................................................................................... 117 8. MANUALES ......................................................................................................... 120 8.1 Manual de despliegue ......................................................................................... 122 8.2 Manual de administrador .................................................................................... 123 8.3 Manual de usuario ............................................................................................... 126 8.4 Manual de gestor de pistas .................................................................................. 134 9. CONCLUSIONES ................................................................................................ 136 9.1 Conclusiones ....................................................................................................... 138 9.2 Futuras Mejoras .................................................................................................. 138 REFERENCIAS ........................................................................................................... 140 8 ANEXO A – Firebase ................................................................................................... 144 ¿Qué es Firebase? ..................................................................................................... 144 ¿Por qué elegimos utilizar Firebase? ........................................................................ 145 ¿Qué servicios de Firebase se utilizarán? ................................................................. 145 Arquitectura lógica de firebase ................................................................................. 145 ANEXO B- Desarrollo detallado de la especificación ................................................. 146 16 1. INTRODUCCIÓN 18 1.1 Motivación: La idea de realizar este proyecto surge de lo inadecuado que es el sistema de gestión de reservas de las pistas de pádel de San Cristóbal de Segovia. La única forma de realizar las reservas es presentándote en el Ayuntamiento y solicitar la hora que quieres reservar, siempre que se encuentre disponible. En caso de estar disponible es necesario realizar una transferencia, ya sea vía online o acudiendo a la entidad bancaria más cercana y, por último, será necesario presentar el resguardo del pago a la persona encargada de las pistas. Este sistema de reservas conlleva muchísimos problemas como son: fallos humanos a la hora de apuntar la fecha de la reserva, pérdidas de tiempo al tener que acudir al Ayuntamiento a realizar la reserva. Al realizar este proyecto se ha pensado especialmente en proporcionar una herramienta que todo el mundo tenga al alcance de la mano y permita realizar reservas a cualquier usuario, sin perder mucho tiempo. 1.2 Objetivos y Alcance: Así pues, el principal objetivo de Sport Administration será facilitar y agilizar las reservas de instalaciones deportivas para los usuarios. Para ello, este sistema contará con dos plataformas: la aplicación móvil y la aplicación web. La aplicación móvil permitirá a los usuarios acceder fácilmente a toda la información sobre las instalaciones y, en caso de requerirlo, reservarlas. Esto evitará que para reservar una instalación tenga que desplazarse físicamente al lugar donde se realicen las reservas o realizar las reservas a través de llamadas telefónicas. Al evitar esto, ya no será necesario contar con una persona encargada de recibir las peticiones de reservas y también se facilitará el sistema de pago de las reservas, ya que la aplicación contaría con una pasarela online de pago, que evitará que los usuarios tengan que hacer una transferencia, ya sea online o en alguna sucursal bancaria. En el siguiente diagrama de árbol de características, se pueden observar las diferentes características principales de la aplicación móvil. Figura 1: Árbol de características de la aplicación móvil 19 Como puede verse en el diagrama anterior, las principales características de la aplicación móvil son:  Gestión de usuarios: donde el sistema debe ser capaz de identificar a cada usuario y en caso de que el usuario no se encuentre en el sistema, proporcionarle la posibilidad de que se registre. También contamos con la funcionalidad de dar de baja a un usuario en caso de que lo solicite.  Ajustes: permitirá a los usuarios modificar el idioma en el que quieran que se encuentre la aplicación.  Gestión de reservas: esta es la característica principal de la aplicación móvil. Proporcionará la posibilidad de realizar reservas de una instalación deportiva, incluyendo el pago. También proporcionará la posibilidad de cancelar la reserva si surge un imprevisto y de visualizar todas las reservas que se han realizado en el sistema. A la aplicación web únicamente podrá acceder el administrador. Esta persona será la encargada de introducir toda la información respecto a las instalaciones de forma que, posteriormente, los usuarios de la aplicación móvil puedan realizar reservas. Las principales características de la aplicación web se muestran en el árbol de características que se encuentra a continuación. Figura 2: Árbol de características de la aplicación web Este segundo árbol de características cuenta con 4 grupos:  Gestión de Pistas: esta característica permitirá que se puedan crear nuevas instalaciones en el sistema y modificar o eliminar instalaciones que ya se encuentren en el sistema.  Gestión de Horarios: permitirá asignar horarios a una pista en función de distintos parámetros. Esta característica también permitirá realizar modificaciones o eliminar horarios.  Gestión de Tipos de Pista: esta característica permitirá gestionar distintos tipos de pista para que el usuario pueda filtrar las instalaciones cuando quiera realizar una reserva.  Gestión de usuarios: esta característica puede parecer similar a la del árbol de características de la aplicación móvil pero no lo es, ya que esta funcionalidad 20 permite que el administrador gestione a los distintos usuarios que pueden utilizar la aplicación móvil, pudiendo llegar a eliminar o crear usuarios si lo considera oportuno. 1.3 Estructura de la documentación: En este apartado se describe la organización en capítulos que conformará la memoria. La memoria consta de nueve capítulos, dos anexos y las referencias. A continuación se realizará una breve descripción de cada apartado.  Capítulo 1: Introducción. En este capítulo se explican las circunstancias que han llevado a la elección de este proyecto y se definirán los objetivos y el alcance del proyecto.  Capítulo 2: Estado del arte. En este capítulo se expone un estudio realizado sobre aplicaciones similares y sobre el entorno tecnológico que rodea al proyecto.  Capítulo 3: Planificación y presupuesto. En este capítulo se realiza un estudio detallado de la metodología que se llevará a cabo para la planificación y estimación del proyecto. Además se presentará un presupuesto del desarrollo del proyecto.  Capítulo 4: Análisis. En este capítulo se exponen todas las características que conformarán cada uno de los sistemas, describiendo aspectos tan importantes como los usuarios y los requisitos funcionales que deben cumplir.  Capítulo 5: Diseño. En este capítulo se definen las arquitecturas y las interfaces de usuario que tendrán los productos software desarrollados.  Capítulo 6: Implementación. En este capítulo se incluyen aquellos aspectos reseñables del proceso de implementación, desde las herramientas utilizadas durante el proceso hasta las restricciones que presenta cada sistema.  Capítulo 7: Pruebas. En este capítulo se recogen todas las pruebas que se realizan en ambos sistemas.  Capítulo 8: Manuales. En este capítulo se detallan las guías que permitirán a los usuario seguir los pasos necesarios desde la instalación y configuración hasta del uso de las aplicaciones.  Capítulo 9: Conclusiones. En este capítulo se realizará un resumen sobre todas las dificultades encontradas durante el desarrollo del proyecto y se analizarán los resultados que presenta el proyecto.  Referencias. En este apartado se recogen todas las referencias webgráficas utilizadas a lo largo del proyecto. 21  Anexo A: Firebase. En este anexo se explica qué es y por qué se ha utilizado esta tecnología a lo largo del proyecto.  Anexo B: Desarrollo detallado del análisis. Contiene el resto de las especificaciones de casos de uso que no han sido expuestos en el capítulo de análisis. 1.4 Contenido del disco: Acompañando a este documento, se adjunta el CD-ROM del proyecto estructurado de esta manera:  Memoria.pdf: documento en formato pdf que contiene la memoria del proyecto.  BBDD.txt: archivo en formato txt con la información de los datos registrados en la base de datos.  Proyecto: carpeta del proyecto Android con la aplicación móvil.  Proyecto.apk: instalador de la aplicación para dispositivos Android.  webSPORT: carpeta del proyecto web que contiene todos los ficheros necesarios para desplegarla.  Instaladores: carpeta que contiene los ejecutables para instalar los servicios necesarios para la aplicación web. 22 2. ESTADO DEL ARTE 24 En la actualidad, dentro del domino de aplicación del presente proyecto, existen múltiples aplicaciones para la reserva de instalaciones deportivas, aunque en Segovia hemos encontrado únicamente aplicaciones que permiten reservar instalaciones de pádel. A continuación, se van a mostrar distintas aplicaciones, ya sean reservas de instalaciones multideportivas o para un único deporte. Pádel Four y Pádel Zone: En este caso, se van a comentar dos aplicaciones iguales de dos instalaciones deportivas de pádel de Segovia. Aunque en Play Store se pueden encontrar como dos aplicaciones distintas, en realidad son la misma aplicación. Como se puede ver en las figuras 3 y 4, sus únicas diferencias son el color y el logo, ya que las funcionalidades y características son las mismas. Figura 3: Capturas aplicación móvil Pádel Zone Figura 4: Capturas aplicación móvil Pádel Four Esta aplicación cuenta con varias similitudes con la desarrollada aquí, como son que permite registrarse en el sistema y reservar la pista. Así mismo, cuenta con geolocalización de Google Maps para facilitar su acceso. Sin embargo, no cuenta con un sistema de pago y esto puede provocar que los usuarios realicen reservas, pero no se presenten ya que no tienen forma de penalizarlo. 31 Figura 8: Planificación temporal inicial 32 Figura 9: Diagrama de Gantt planificación inicial 3.3 Presupuestario 3.3.1 Coste de componentes Hardware: En la Tabla 2 se muestran los costes de todos los componentes hardware que han sido utilizados para el desarrollo de las aplicaciones. También, se ha tenido en cuenta el tiempo de uso que se dará a los componentes en función del tiempo de vida estimado. De esta forma se calcula el coste real de cada componente respecto al desarrollo del proyecto. HARDWARE PRECIO VIDA ÚTIL % USO COSTE REAL Ordenador 500,00 € 4 años 25 % 125,00 € Pantalla 100,00 € 5 años 20 % 20,00 € Ratón 10,00 € 5 años 20 % 2,00 € Móvil 120,00 € 2 años 50 % 60,00 € Conexión Internet 40,00 €/mes 9 meses - 360,00 € TOTAL: 567,00 € Tabla 2: Costes componentes hardware 33 3.3.2 Coste de componentes Software: En la Tabla 3 se muestran los costes de todos los componentes software que han sido necesarios para desarrollar las aplicaciones y la elaboración de la documentación. Para el cálculo del coste real de cada componente se ha utilizado el mismo método que en el apartado anterior. SOFTWARE PRECIO VIDA ÚTIL % USO COSTE REAL Windows 10 80,00 € 4 años 25 % 20,00 € Draw.io 0,00 € - - 0,00 € Microsoft Office 2013 50,00 € 5 años 20 % 10,00 € StarUml 0,00 € - - 0,00 € GanttProject 0,00 € - - 0,00 € Sublime Text 0,00 € - - 0,00 € Photoshop 30,00 € 4 meses 120,00 € Android Studio 0,00 € - - 0,00 € Acrobat Reader DC 15,00€/mes 2 meses 30,00 € TOTAL: 190,00 € Tabla 3: Costes componentes software 3.3.3 Coste de personal: El proyecto ha sido realizado por una única persona pero durante el desarrollo del proyecto, ha empleado distintos roles: analista, desarrollador y tester, en relación con las tareas que se debían utilizar. En la Tabla 4 se puede observar los distintos costes en función del número de horas y del coste por horas, basado en la planificación temporal inicial. SOFTWARE TIEMPO(HORAS) COSTE/HORAS COSTE REAL Analista 250 13,20 € 3.300,00 € Desarrollador 350 11,50 € 4.025,00 € Tester 88 10,50 € 924,00 € TOTAL: 8.249,20 € Tabla 4: Costes de personal 34 3.3.4 Método de puntos de función La estimación por puntos de función realiza una estimación del coste del proyecto software a través de la evaluación de todas sus funciones, ya que como es lógico, cuanto más compleja sea la función, mayor será el coste de su desarrollo. Para establecer los puntos de función de la aplicación se divide en cinco grupos. En cada uno de ellos se pueden encontrar los diferentes componentes a implementar y, en función del grupo, se les asignará una complejidad. Los grupos son los siguientes:  Entradas de usuario: son los datos que el usuario aporta al sistema.  Salidas de usuario: son los datos que el sistema aporta.  Consultas externas: son peticiones del usuario a un sistema externo el cual interactúa con la aplicación.  Ficheros lógicos internos: es la base de datos propia de la aplicación.  Ficheros lógicos externos: son bases de datos externas de las que la aplicación hace uso. Una vez repartidas las funciones entre los grupos, se hará uso de la tabla que se muestra a continuación para establecer la complejidad de cada una de las funcionalidades. Tabla 5: Complejidad de los componentes A continuación se van a definir las funcionalidades en función de los grupos: Entradas de usuario: ENTRADAS COMPLEJIDAD Información y datos de registro Media Formulario de inicio de sesión Media Información de registro de pistas Baja Información de registro de tipos de pistas Baja Información de registro de horarios Baja Información para la reserva de una pista Alta Formulario de actualización de pista Baja Formulario de actualización de tipo de pista Baja Formulario de actualización de horario Baja Formulario de actualización de información del perfil del usuario Media Selección del idioma Baja Tabla 6: Entradas de usuario 35 Salidas de usuario: SALIDAS COMPLEJIDAD Listado de las pistas Baja Información de una pista Baja Listado de tipos de pistas Baja Información de una pista Baja Listado de horarios Media Información de un horario Baja Listado de usuario Baja Información del perfil del usuario Media Listado de reservas Baja Información de una reserva Baja Listado de idioma Baja Tabla 7: Salidas de usuario Consultas externas: CONSULTAS COMPLEJIDAD Pago de la reserva (PayPal) Alta API de Google Maps Alta Tabla 8: Consultas de usuario Ficheros lógicos internos: FICHEROS LÓGICOS INTERNOS COMPLEJIDAD Cache de las aplicaciones Baja Tabla 9: Ficheros lógicos internos Ficheros lógicos externos: FICHEROS LÓGICOS EXTERNOS COMPLEJIDAD Real Time Database (Firebase) Alta Authentication Firebase Alta Tabla 10: Ficheros lógicos externos 36 Una vez establecidos los puntos de función sin ajustar, es necesario realizar la suma de ellos con ayuda de una ponderación en función del tipo de punto de función y de su complejidad. Peso de la complejidad baja x nº Peso de la complejidad media x nº Peso de la complejidad alta x nº Entradas 3x7 = 21 4x3 = 12 6x1 = 6 Salidas 3x9 = 27 4x2 = 8 6x0 = 0 Consultas externas 4x0 = 0 5x0 =0 7x2 = 14 Ficheros internos 7x1 = 7 10x0 = 0 15x0 = 0 Ficheros externos 5x0 = 0 7x0 = 0 10x2 = 20 TOTAL: 55 + 20 + 40 = 115 PFNA Tabla 11: Total de puntos de función Una vez obtenido el total de los puntos de función sin ajustar (PFNA), es necesario calcular el Factor de Ajuste (FA). Para ello, el factor de ajuste se basa en 14 factores que miden la funcionalidad general y complejidad del sistema. Por lo tanto, es necesario medir cada uno de los factores en una escala del cero al cinco, donde cero es lo más bajo y cinco lo más alto. Factores de ajuste Complejidad 1. Comunicación de datos 4 2. Funciones distribuidas 2 3. Prestaciones 3 4. Gran uso de la configuración 1 5. Velocidad de las transacciones 3 6. Entrada on-line de datos 4 7. Diseño para la eficiencia del usuario final 2 8. Actualización de datos on-line 4 9. Complejidad proceso lógico internos de la aplicación 3 10. Reusabilidad del código. 1 11. Facilidad de instalación 2 12. Facilidad de operación 2 13 Localizaciones múltiples 3 14. Facilidad de cambios 2 TOTAL: 36 Tabla 12: Factores de ajuste 37 Para calcular el factor de ajuste debemos utilizar la siguiente fórmula: FA = 0,65 + 0,01 * total del factor de ajuste FA =0,65 + 0,01 * 36 FA = 0,65 + 0,36 FA = 1.01 Por lo tanto, con un factor de ajuste de 1,01, podremos calcular los puntos de función ajustados obtenidos: PFA = PFNA * FA PFA = 115 * 1,01 PFA = 116,15 Por último, es necesario realizar el cálculo de la estimación de tiempo. Para ello asumimos que un punto de función ajustado equivale a cuatro horas de trabajo. Tiempo = PFA * Nº horas x PFA Tiempo = 116,15 * 4 horas Tiempo = 464.6 horas de duración del proyecto Con el tiempo de duración del proyecto es necesario dividirlo entre los distintos roles que se llevaran a cabo. La estimación temporal por cada rol que se utilizará será la misma que se ha utilizado en la estimación temporal inicial de forma que las estimaciones queden de la forma más ajustada posible. Las estimaciones serán 36% el analista, 52% el desarrollador y un 12% el tester. SOFTWARE TIEMPO(HORAS) COSTE/HORAS COSTE REAL Analista 167 13,20 € 2.204,40 € Desarrollador 242 11,50 € 2.530,00 € Tester 56 10,50 € 588,00 € TOTAL: 5.322,40 € Tabla 13: Costes de personal PF 3.3.5 Estimación por COCOMO El modelo de estimación por COCOMO realiza el presupuesto del proyecto en función del número de líneas de código, el cual se obtendrá a partir de los puntos de función anteriormente obtenidos. Antes de que se realice el cálculo de número de líneas de código, es necesario elegir uno de los modelos de COCOMO en base a las características de nuestro proyecto. Los modelos de COCOMO son:  Orgánico: es para proyectos de pequeño tamaño y sin gran complejidad, desarrollados por un equipo pequeño y con requisitos poco rígidos.  Empotrado: es para proyectos de gran complejidad, con unos requisitos muy rígidos.  Semiempotrado: es un modelo intermedio entre los dos anteriores, en los que los equipos se coordinan para su desarrollo. 38 Tras analizar cada uno de los modelos, se establece que el proyecto se adapta más al modelo Semiempotrado. Una vez establecido el modelo, lo primero es estimar el número de líneas de código. Ya que los lenguajes que vamos a usar son Java para Android y JavaScript para la web, se estiman unas 53 líneas de código por cada punto de función y, por lo tanto, el número de líneas del proyecto son: LDC = PF * estimación de líneas LDC = 115* 53 LDC = 6095 Tabla 14: Clasificación de factores de ajuste de COCOMO A continuación, es necesario aplicar un factor de esfuerzo basado en los atributos de la tabla anterior. Atributos Factor Valor Fiabilidad requerida Alto 1,15 Tamaño de la base de datos Bajo 0,94 Complejidad del software Alto 1,15 Restricciones de tiempo de ejecución Medio 1,00 Restricciones de memoria Medio 1,00 Volatilidad del hardware Medio 1,15 Restricciones de tiempo de repuesta Alto 1,07 Calidad de los analistas Medio 1,00 Experiencia con el tipo de aplicación Alto 0,91 Experiencia con el hardware Alto 0,90 Experiencia con el lenguaje de programación Alto 0,95 Calidad de los programadores Medio 1,00 Técnicas modernas de programación Alto 0,91 Empleo de herramientas Alto 0,91 Restricciones a la duración del proyecto Medio 1,00 Total de la media = 1,002 Tabla 15: Factores de ajuste de COCOMO 39 A continuación, se deben tener en cuenta el conjunto de factores de ajustes de la Tabla 16, para el cálculo del esfuerzo a través de las siguientes formulas: MODELO A B C D SEMIACOPLADO 3,00 1,12 2,50 0,35 Tabla 16: Ponderaciones de COCOMO Factor de ajuste =1,15*0,94*1,15*1*1*1,15*1,07*1*0,91*0,90*0,95*1*0,91*0,91 * 1 Factor de ajuste = 0,9855 E = a * (KLDC)^b * factor de ajuste E = 3,00 * (6,095)^1,12 *0,9855 E = 22,38 personas/mes Tdev = c * E^d Tdev = 2,5* 22,38^0,35 Tdev = 7,42 meses Una vez calculados el esfuerzo y el tiempo, obtenemos el esfuerzo nominal (N). N = E / Tdev N = 22,38 / 7,42 N = 2,97 Por lo tanto, necesitaríamos tres personas en siete meses y medio para la realización del proyecto. Como en este caso el proyecto es realizado por una única persona serían necesarios 22 meses y medio para la realización del proyecto, que equivaldría a 1980 horas. Como en el caso de la estimación inicial temporal y en puntos de función, las estimaciones temporales serán 36% el analista, 52% el desarrollador y un 12% el tester. Con todos los datos obtenidos vamos a calcular el coste del personal: SOFTWARE TIEMPO(HORAS) COSTE/HORAS COSTE REAL Analista 713 13,20 € 9.411,60 € Desarrollador 1030 11,50 € 11.845,00 € Tester 238 10,50 € 2.499,00 € TOTAL: 23.755,60 € Tabla 17: Costes de personal COCOMO 3.3.6 Comparativa de estimaciones Una vez finalizadas las estimaciones a través de los métodos de puntos de función y COCOMO, el que realiza una estimación más real es el de puntos de función, ya que la estimación por COCOMO es muy excesiva para este proyecto. Esto es debido a que este método está pensado para lenguajes de programación de bajo nivel y no para lenguajes de alto nivel como es el caso. 40 Además de comparar los dos métodos de estimación, también vamos a comparar el método de puntos de función con la planificación inicial temporal. De esta comparación podemos obtener que existe una gran diferencia presupuestaria y eso puede ser debido a una mala planificación por un cálculo de horas excesivo. 3.4 Presupuesto Final Para la realización del presupuesto del proyecto debemos seguir los pasos que realizamos en el presupuestario, pero con los datos obtenidos a través de la nueva estimación. Por lo tanto, los componentes hardware y software se mantiene debido a que la estimación de tiempo será la misma, lo único que sólo se desempeñaran 2,65 horas diarias de lunes a viernes. Sin embargo, en el coste del personal se tendrá en cuenta el tiempo que más se asemeja a la realización del proyecto y por lo tanto, haremos uso del coste de personal a través del método de puntos de función (5.322,40€). Para el cálculo del presupuesto del proyecto es necesario realizar la suma de todos los costes: Presupuesto = Coste del SW + Coste del HW + Coste del personal Presupuesto = 567, 00 + 190,00 +5.322,40€ Presupuesto = 6.079,40 € 47 Aplicación web: Como puede verse en la siguiente figura, para la aplicación web únicamente se tendrá un actor. El Administrador, el cual se encargará de gestionar a los usuarios y todo lo relacionado con las pistas: su propia definición, sus horarios y los tipos de pista. Figura 12: Casos de uso de Aplicación web Como puede verse se tienen dos aplicaciones, aparentemente sin ningún tipo de relación entre ellas, pero que de algún modo tendrán que interactuar, dejando esta información para más adelante, concretamente, para el capítulo de diseño. Especificación de casos de uso: En este apartado se realizará la especificación de tres casos de uso para cada una de las aplicaciones. El resto de los casos de uso están incluidos en el Anexo B al final del documento. 48 Aplicación móvil: CU-01 Registrarse Versión 1.0 Fecha 08/03/2019 Dependencias RF-01,RF-39 Actor Usuario no autenticado. Descripción El usuario no autenticado podrá crear un usuario desde la aplicación móvil. Precondiciones Secuencia normal 1. El usuario no autenticado solicita al sistema la creación de un usuario. 2. El sistema solicita los datos del nuevo usuario. 3. El usuario no autenticado envía los datos. 4. El sistema registra al nuevo usuario en el sistema y redirige la vista a la pantalla inicial. Postcondicones El sistema registra un nuevo usuario. El usuario no autenticado pasa a convertirse a usuario común. Excepciones 4.EX-01 Los datos introducidos no son válidos, volviendo al paso 2 de la secuencia normal. 4.EX-02 El correo electrónico ya está utilizado, volviendo al paso 2 de la secuencia normal. Frecuencia Media. Importancia Alta Comentarios Tabla 18: CU-01 Registrarse Figura 13: Diagrama de secuencia CU-01. 49 CU-09 Realizar reserva Versión 1.0 Fecha 08/03/2019 Dependencias RF-09,RF-10,RF-11,RF-12 Actor Usuario común. Descripción El usuario común podrá realizar una reserva en la aplicación móvil. Precondiciones 1. El usuario debe estar autenticado como usuario común en la aplicación móvil. Secuencia normal 1. El usuario solicita realizar una reserva. 2. El sistema solicita la fecha y el tipo de pista a reservar. 3. El usuario le envía la información. 4. El sistema comprueba los datos y le muestra las pistas y la los horarios disponibles. 5. El usuario le envía las horas y la pista a reservar. 6. El sistema agrupa toda la información y le muestra un resumen y solicita la confirmación de la reserva. 7. El usuario confirma la reserva y envía la información de pago. 8. El sistema comprueba la confirmación e informa al sistema de cobro de los datos. 9. El sistema de cobro confirma el pago. 10. El sistema registra la reserva y notifica al usuario que la reserva se realizó de forma exitosa. Postcondicones El sistema registra una nueva reserva. Excepciones 4.EX-01 Los datos introducidos no son válidos, volviendo al paso 2. 6.EX-02 Los datos introducidos no son válidos, volviendo al paso 4. 8.EX-03 Los datos introducidos no son válidos, volviendo al paso 6. 10.EX-04 El sistema de cobro no confirma el pago, volviendo al paso 8. Frecuencia Alta. Importancia Alta. Comentarios Tabla 19: CU-09 Realizar reserva. 50 Figura 14: Diagrama de secuencia CU-09. CU-03 Cambiar el idioma de la plataforma. Versión 1.0 Fecha 08/03/2019 Dependencias RF-03 Actor Usuario autenticado. Descripción El usuario autenticado podrá cambiar el idioma de la aplicación móvil. Precondiciones 1. El usuario debe estar autenticado en la aplicación móvil. Secuencia normal 1. El usuario solicita acceder a los ajustes. 2. El sistema muestra las opciones de ajustes. 3. El usuario solicita el idioma que desea. 4. El sistema cambia el idioma de la aplicación. Postcondicones El idioma de la aplicación se verá modificado. Excepciones 4.EX-01 El idioma seleccionado ya estaba activado, volviendo al paso 2 de la secuencia normal. Frecuencia Baja. Importancia Media. Comentarios Tabla 20: CU-03 Cambiar el idioma de la plataforma. 51 Aplicación web: CU-17 Crear Pista Versión 1.0 Fecha 08/03/2019 Dependencias RF-20,RF-21 Actor Administrador. Descripción El administrador podrá crear pistas desde la aplicación web. Precondiciones 1. El administrador debe estar autenticado en la aplicación web. Secuencia normal 1. El administrador solicita al sistema la creación de una nueva pista. 2. El sistema solicita los datos de la nueva pista. 3. El administrador envía los datos. 4. El sistema registra la nueva pista en el sistema y redirige al usuario al listado de pistas. Postcondicones El sistema registra una nueva pista. Excepciones 4.EX-01 Los datos introducidos no son válidos, volviendo al paso 2 de la secuencia normal. 4.EX-02 Ya existe una pista con el mismo nombre, volviendo al paso 2 de la secuencia normal. Frecuencia Media. Importancia Alta. Comentarios Tabla 21: CU-17 Crear Pista CU-25 Eliminar tipo de pista Versión 1.0 Fecha 08/03/2019 Dependencias RF-30 Actor Administrador. Descripción El administrador podrá eliminar un tipo de pista registrado en el sistema. Precondiciones 1. El administrador se habrá autenticado en la aplicación web. 2. El administrador habrá solicitado visualizar el listado de tipos de pista CU-23. Secuencia normal 1. El usuario solicita eliminar un tipo de pista. 2. El sistema elimina el tipo de pista del sistema. Postcondicones Se elimina el tipo de pista del sistema. Excepciones Frecuencia Media. Importancia Media. Comentarios Tabla 22: CU-25 Eliminar tipo de pista 52 CU-32 Autenticarse en la plataforma web Versión 1.0 Fecha 08/03/2019 Dependencias RF-36 Actor Administrador. Descripción El Administrador podrá autenticarse desde la aplicación web. Precondiciones Secuencia normal 1. El usuario solicita al sistema autenticarse. 2. El sistema solicita los datos necesarios para autenticarle. 3. El usuario envía los datos. 4. El sistema autentica al usuario en el sistema y redirige la vista a la pantalla inicial. Postcondicones Excepciones 4.EX-01 Los datos introducidos no son válidos, volviendo al paso 2 de la secuencia normal. 4.EX-02 El usuario no está registrado en el sistema, volviendo al paso 2 de la secuencia normal. Frecuencia Alta. Importancia Alta. Comentarios Tabla 23: CU-32 Autenticarse en la plataforma web 4.3 Requisitos de información: En este apartado se establecen todos aquellos del sistema en relación a los datos almacenados o procesados por el mismo. o RI-01: El sistema almacenará la información del usuario que se registre en el sistema. o RI-02: El sistema almacenará la información de las pistas que se creen. o RI-03: El sistema almacenará la información de las reservas. o RI-04: El sistema almacenará la información de los horarios de las pistas. o RI-05: El sistema almacenará la información del tipo de pista. 4.3.1 Modelo Conceptual de datos: Para una mayor legibilidad de todos los requisitos de información se mostrará el diagrama de entidad relación que utilizarán ambas aplicaciones y en el cual se identificarán las entidades y las relaciones entre ellas. Figura 15: Modelo de datos 53 4.3.2 Diccionario de datos Hasta ahora se han definido los diferentes requisitos de información que tendrá nuestro sistema, pero no se han especificado qué información debe almacenarse. Para detallar esta información, en este apartado se define el diccionario de datos que contendrán el tipo de requisito del que se trata (entidad o relación), una descripción, los atributos que tendrá cada requisito. En los atributos de los requisitos se indicará el nombre del atributo, el tipo de dato a guardar, si este atributo puede ser nulo, si es único y una descripción adicional del tipo. Entidad usuario DESCRIPCIÓN Representa a un usuario del sistema ATRIBUTOS NOMBRE TIPO NULO ÚNICO DESCRIPCIÓN Id_usario Cadena de caracteres No Si Caracteres alfanuméricos de longitud máxima 20 nombre Cadena de caracteres No No Caracteres alfanuméricos de longitud máxima 20 apellidos Cadena de caracteres No No Caracteres alfanuméricos de longitud máxima 40 password Cadena de caracteres No No Caracteres alfanuméricos de longitud máxima 20 teléfono Número No No Número de hasta 10 cifras email Cadena de caracteres No Si Caracteres alfanuméricos de longitud máxima 40 tipo Número No No  -1 administrador  0 Encargado de pista  1 común Tabla 24: Entidad usuario 54 Entidad horario DESCRIPCIÓN Representa a un horario de la pista ATRIBUTOS NOMBRE TIPO NULO ÚNICO DESCRIPCIÓN Id_horario Cadena de caracteres No Si Caracteres alfanuméricos de longitud máxima 20 título Cadena de caracteres No No Caracteres alfanuméricos de longitud máxima 20 hora_inicio Fecha No No Hora: Minutos slots Número No No Número de hasta 2 cifras fecha_inicio Fecha No No Año/Mes/Día fecha_fin Fecha No No Año/Mes/Día fin_de_sem ana Número No No  0 en caso de no ser fin de semana  1 en caso de ser fin de semana especial Número No No  0 en caso de no ser especial  1 en caso de ser especial Tabla 25: Entidad horario Entidad pista DESCRIPCIÓN Representa una pista ATRIBUTOS NOMBRE TIPO NULO ÚNICO DESCRIPCIÓN Id_pista Cadena de caracteres No Si Caracteres alfanuméricos de longitud máxima 20 título Cadena de caracteres No No Caracteres alfanuméricos de longitud máxima 20 precio Número No No Número con decimales duración Número No No Número de hasta 2 cifras longitud Número No No Sistema de coordenadas latitud Número No No Sistema de coordenadas Tabla 26: Entidad pista 55 Entidad reserva DESCRIPCIÓN Representa cada reserva ATRIBUTOS NOMBRE TIPO NULO UNICO DESCRIPCIÓN Id_reserva Cadena de caracteres No Si Caracteres alfanuméricos de longitud máxima 20 duración Número No No Número de hasta 2 cifras usuario Cadena de caracteres No No Caracteres alfanuméricos de longitud máxima 20 precio Número No No Número con decimales hora_inicio Fecha No No Hora: Minutos slot_inicio Número No No Número de hasta 2 cifras fecha Fecha No No Año/Mes/Día Tabla 27: Entidad reserva Entidad tipo_pista DESCRIPCIÓN Representa cada tipo de pista ATRIBUTOS NOMBRE TIPO NULO UNICO DESCRIPCIÓN Id_tipo_pista Cadena de caracteres No Si Caracteres alfanuméricos de longitud máxima 20 Nombre Cadena de caracteres No NO Caracteres alfanuméricos de longitud máxima 20 Descripción Cadena de caracteres No NO Caracteres alfanuméricos de longitud máxima 40 Tabla 28: Entidad tipo de pista 4.4 Requisitos Funcionales: A pesar de que ya se definieron las especificaciones de casos de uso en las cuales se indicaba lo que debía hacer el sistema, y para completar esta información a continuación se incluye la especificación de los requisitos funcionales, que tiene como único objetivo, establecer todas aquellas acciones que el sistema debe desempeñar. 56  Aplicación móvil: RF-01: El sistema permitirá al usuario no autenticado registrarse en el sistema. RF-02: El sistema permitirá a los usuarios autenticarse en la plataforma. RF-03: El sistema permitirá a los usuarios cambiar el idioma de la plataforma. RF-04: El sistema permitirá a los usuarios cerrar sesión en la plataforma RF-05: El sistema permitirá a los usuarios darse de baja de la plataforma. RF-06: El sistema permitirá a los usuarios visualizar los datos de una reserva. RF-07: El sistema permitirá al usuario común visualizar el listado de pistas. RF-08: El sistema permitirá al usuario común visualizar los datos de una pista. RF-09: El sistema permitirá al usuario común realizar una reserva en el sistema. RF-10: El sistema comprobará las reservas ya registradas en el sistema. RF-11: El sistema comprobará el horario respectivo de la posible reserva. RF-12: El sistema permitirá al usuario común visualizar el listado de sus reservas. RU-13: El sistema permitirá al usuario común cancelar una reserva.  Aplicación web: RF-14: El sistema permitirá al administrador crear nuevos usuarios. RF-15: El sistema permitirá al administrador visualizar un listado de los usuarios. RF-16: El sistema permitirá al administrador visualizar la información de un usuario. RF-17: El sistema permitirá al administrador eliminar usuarios. RF-18: El sistema permitirá al administrador modificar usuarios. RF-19: El sistema permitirá al administrador crear una nueva pista. RF-20: El sistema comprobará si no existe ninguna pista con el mismo nombre al de la nueva pista. RF-21: El sistema permitirá al administrador visualizar un listado de las pistas. RF-22: El sistema permitirá al administrador visualizar la información de una pista. RF-23: El sistema permitirá al administrador eliminar pistas. RF-24: El sistema permitirá al administrador modificar pistas. RF-25: El sistema permitirá al administrador crear un nuevo tipo de pista. RF-26: El sistema comprobará si no existe ningún tipo de pista con el mismo nombre al del nuevo tipo de pista. RF-27: El sistema permitirá al administrador visualizar un listado de los tipos de pista. RF-28: El sistema permitirá al administrador visualizar la información de un tipo de pista. RF-29: El sistema permitirá al administrador eliminar tipos de pista. RF-30: El sistema permitirá al administrador modificar tipos de pista. RF-31: El sistema permitirá al administrador crear un nuevo horario para una pista. RF-32: El sistema permitirá al administrador visualizar un listado de los horarios de la pista. RF-33: El sistema permitirá al administrador visualizar la información de un horario. 63 En la Figura 20 se puede observar el diagrama de clases de la aplicación web que como en el caso de la aplicación móvil permite visualizar las entidades con sus atributos y sus operaciones. Figura 20: Diagrama de clases de aplicación web. 5.4 Modelo lógico de la base de datos En este apartado se presenta el diseño de la base de datos. A través de este diseño se muestran las diferentes entidades que componen las bases de datos. Para explicar cómo es la base de datos, primero es necesario explicar que es Firebase ya que la base de datos es una de sus herramientas. Firebase una plataforma de desarrollo en la nube de Google. Se trata de una plataforma disponible para diferentes plataformas (Android, iOS, web). La herramienta para el almacenamiento de datos que se ha usado es Real Time Database que es una base de datos NoSQL, es decir, no relacional, por lo que no cuentan con una estructura de tablas. Para saber más sobre qué es y todas sus herramientas este documento contiene el Anexo A donde se explica todo de una forma detallada. La base de datos almacena la información en formato JSON. A continuación se muestra un ejemplo de cómo se almacena la información a través de la herramienta Real Time. 64 Figura 21: Base de datos Firebase 1. Como se puede ver en esta figura, la estructura es en forma de árbol donde el nodo principal es sport-administration que es el nombre de la base de datos y después está dividido en las cinco entidades que conforman la base de datos. Dentro de cada entidad se tiene una serie de elementos donde se puede ver un conjunto de letras y números que conforman el identificador único de cada elemento. Una vez visto cómo se estructura la base de datos también es importante conocer cómo se relacionan las entidades entre ellas, es decir, cómo saber que un horario pertenece a una pista. Figura 22: Base de datos Firebase 2. 65 Para ver cómo se relacionan las entidades, nos vamos a ayudar de la Figura 21. Ahora se puede ver únicamente las entidades horarios y pistas. Dentro de estas entidades se muestra un elemento desglosado con todos sus atributos. En el atributo pista de la entidad Horarios se observa un identificador único que, si se presta atención en la entidad Pistas, corresponde con el identificador único de uno de sus elementos. Esto quiere decir que el horario pertenece a esa pista. A pesar de contar con una base de datos no relacional se va a añadir el modelo relacional del sistema debido a que permite entender la base de datos de una forma mucho más rápida y clara. Figura 23: Modelo relacional. En el modelo relacional se pueden ver todas las entidades que conformaban el modelo de datos y además también se muestra la relación reserva, debido a que contaba con una cardinalidad N:M. Esta nueva entidad registrará las reservas que realicen los usuarios sobre una pista en una fecha y duración determinada. 66 5.5 Diseño de la interface 5.5.1 Diseño aplicación móvil: Inicio de sesión: Pantalla inicial que se presenta al iniciar la aplicación por primera vez. Se muestra el formulario con los datos necesarios para la autenticación y un link para acceder a la pantalla de registro por si fuera necesario. Figura 24: Diseño inicio de sesión aplicación móvil. Registro: Pantalla a través de la cual se permite realizar el registro en el sistema como usuario común. Se muestra el formulario con los datos necesarios para el registro y un link a la pantalla de inicio de sesión por si ya estuvieras registrado. Figura 25: Diseño registro aplicación móvil. 67 Inicio: Pantalla de inicio una vez que el usuario ya se encuentra autenticado. Se muestra un listado con algunas de las pistas registradas en el sistema y se muestra un pequeño resumen de su información más relevante. Figura 26: Diseño inicio aplicación móvil. Menú: Añadido al que se puede acceder en cualquier momento una vez el usuario esté autenticado. En el menú se muestran las principales funciones que tiene la aplicación y te permite acceder a cada una de ellas. Figura 27: Diseño menú aplicación móvil. 68 Pista: Pantalla que muestra el desglose de la información de la pista y que se accede a través de la selección de una pista, desde la pantalla de inicio. Figura 28: Diseño pista aplicación móvil. Reservas: Pantalla a través de la cual se puede ver el listado de reservas que tienes realizadas a través de la aplicación. Permite ver toda la información detallada de cualquiera de las reservas. Figura 29: Diseño reservas aplicación móvil. 69 Reserva: Pantalla que muestra el desglose de la información de la reserva y que se accede a través de la selección de una reserva en la pantalla de reservas. Figura 30: Diseño reserva aplicación móvil. Diseño realizar reserva: Como la acción de realizar una reserva está formada por distintas pantallas a modo de asistente, vamos a explicarlas de forma independiente. La primera pantalla permite seleccionar la fecha y el tipo de pista de la reserva. Figura 31: Diseño reserva 1 aplicación móvil. 70 La siguiente pantalla nos muestra un desplegable con las distintas pistas disponibles y, por cada pista, el listado de horas disponibles para que seleccionemos la que mejor nos venga. Figura 32: Diseño reserva 2 aplicación móvil. La última pantalla de esta acción muestra un desglose de la reserva para verificar que todos los datos son correctos y, en caso afirmativo, confirmar la reserva. Figura 33: Diseño reserva 3 aplicación móvil. 71 Diseño cerrar sesión: Pantalla que se muestra cuando en el menú se selecciona la opción cerrar sesión. Sirve para confirmar si se quiere cerrar sesión o únicamente se había dado a esa opción por equivocación. Figura 34: Diseño cerrar sesión aplicación móvil. Ajustes: Pantalla que muestra las opciones de cambiar el idioma de la aplicación y la opción de dar de baja al usuario del sistema. Figura 35: Diseño ajustes aplicación móvil. 72 5.5.2 Diseño aplicación web El diseño de la aplicación está optimizado para un navegador web de un ordenador de sobremesa. Sin embargo, el diseño de esta aplicación es adaptativo, por lo que le permite ser usado desde otros dispositivos que cuenten con un navegador. A continuación, se detallan solo algunas de las interfaces de la aplicación, ya que éstas, bien sean de tipos de pista, como de pista, como de horario, como de usuario, son prácticamente iguales y soportan básicamente las mismas funciones. Por este motivo se ha decidido describir únicamente, las relacionadas con el tipo de pistas, aparte del inicio de sesión y del área de inicio. Inicio de sesión: Pantalla inicial que se muestra al acceder a la web. Se muestra el formulario con los datos necesarios para la autenticación. Figura 36: Diseño inicio sesión aplicación web. Inicio: 80 6.1 Herramientas utilizadas: 6.1.1 Herramientas de soporte:  Draw.io: es una aplicación online de Google Drive que permite la realización de distintos diagramas. Para acceder a ella únicamente debe accederse a la dirección https://www.draw.io/.  StarUml: es una aplicación de escritorio que permite el modelado de diagramas en los estándares UML. Ha sido utilizado para la realización de los diagramas de casos de usos entre otros.  Microsoft Word 2013: es una herramienta de ofimática utilizada para el desarrollo de la memoria del proyecto  Acrobat Reader DC: es una herramienta utilizada para la lectura y edición de documentos en formato PDF.  Photoshop: es una aplicación de escritorio utilizada para la edición de imágenes, sobre todo para la unión de las distintas capturas de pantalla.  GanttProject: es un programa de código abierto con licencia GPL escrito en Java con la biblioteca Swing, su objetivo es la administración de proyectos usando el diagrama de Gantt.  Ninjamock: es una herramienta de nivel intermedio para la creación de bocetos para móviles como iOS, Android y Windows Phone, y también para diseño web. 6.1.2 Herramientas para el desarrollo móvil  Android Studio: es el entorno de desarrollo integrado oficial para la plataforma Android desde el año 2014, el año en el que reemplazó a Eclipse. A parte de ser el entorno de desarrollo también proporciona la posibilidad de emular el uso de la aplicación desarrollada en cualquier dispositivo móvil.  API Google Maps para Android: es un servicio externo utilizado para mostrar los mapas de google en las pantallas de nuestra aplicación.  PayPal: es un sistema de pagos en línea que soporta transferencias de dinero entre usuarios y sirve como una alternativa electrónica a los métodos de pago tradicionales.  Firebase: es una plataforma que pertenece a Google y es usada para ayudar en el desarrollo de aplicaciones tanto web como móviles. En nuestro caso hizo la función de base de datos entre otras. 81 6.1.3 Herramientas para el desarrollo web  Sublime Text 3: es un editor de texto y de código fuente. Se desarrolló originalmente como una extensión de Vim. Ha sido utilizado durante la implementación de la aplicación para toda la edición de código de los lenguajes PHP, HTML, CSS y JavaScript.  WampServer 3.1.4: es una herramienta que dispone de un servidor Apache, un gestor de bases de datos MySQL y el lenguaje de programación PHP.  Firefox: es el navegador principalmente utilizado para el desarrollo de la aplicación web.  Google Chrome: es otro navegador que ha sido utilizado para probar la aplicación asegurando que funciona en distintos navegadores.  Firebase: es una plataforma que pertenece a Google y es usada para ayudar en el desarrollo de aplicaciones tanto web como móviles. En nuestro caso hizo la función de base de datos entre otras. 6.2 Tecnologías utilizadas: 6.2.1 Tecnologías para el desarrollo móvil:  Java: Lenguaje de programación orientada a objetos para la realización de las tareas de la aplicación móvil.  XML: Lenguaje de marcado utilizado para la definición de las vistas de la aplicación móvil. 6.2.2 Tecnologías para el desarrollo web:  PHP: Lenguaje de programación interpretado diseñado para la creación de páginas web dinámicas.  JavaScript: Lenguaje de programación interpretado, orientado a objetos, dinámico y ligeramente tipado.  HMTL 5: Lenguaje de marcado creado para la elaboración de definición de la estructura y el contenido de las páginas web.  CSS 3: Lenguaje de diseño gráfico para la definición y creación de la presentación de las páginas web. 6.3 Implementación: En este apartado se explicará el desarrollo de los dos sistemas implementados, explicando su organización y la funcionalidad de cada una de sus partes. 82 6.3.1 Crear proyecto Firebase Para la implementación de ambas aplicaciones es necesario primero crear el proyecto en Firebase. Para ello, accederemos a https://firebase.google.com/?hl=es y dirigirnos al botón de la parte superior derecha donde pone “Ir a la consola”. Una vez dentro, iniciamos sesión con la cuenta. Al iniciar sesión se mostrará una imagen similar a la que podemos ver a continuación. Figura 41: Creación proyecto Firebase. En nuestro caso, como se puede ver la cuenta ya tiene disponible un proyecto. Para crear un nuevo proyecto simplemente hay que pulsar sobre “Añadir proyecto” y, una vez pulsado, se mostrará una pantalla donde se configurarán aspectos del proyecto como el nombre, el país etc… Figura 42: Configuración proyecto Firebase. 83 Una vez rellenados todos los datos se finaliza la creación del proyecto. Se mostrará la interface principal de Firebase, la cual se va a explicar a continuación. Figura 43: Panel principal Firebase. Dentro de un proyecto en Firebase, la interface principal se compone de dos partes: un menú lateral en el margen izquierdo de la pantalla y el panel principal, donde se mostrarán cada una de las pantallas que selecciones del menú antes comentado. Dentro del menú podemos encontrar tres partes bien diferenciadas: - Desarrollo: donde se encuentran las principales funcionalidades como son Authentication y Database, que son las funciones que más se usarán a lo largo del desarrollo de las aplicaciones. - Calidad: un apartado muy importante de Firebase donde te permite mantenerte informado de posibles errores que ocurran de las aplicaciones. - Analíticas: es un apartado de Firebase que muestra un montón de información del uso de las aplicaciones sobre Firebase. 6.3.2 Integración de Firebase en las aplicaciones Una vez creado el proyecto en Firebase es necesario integrarlo en ambas aplicaciones. A continuación se va a explicar cómo se desarrolla este proceso. 6.3.2.1 Aplicación móvil Como en el caso de la aplicación web, nos encontramos en la pantalla principal del proyecto en Firebase en la que pulsaremos sobre el botón “Añadir aplicación” y en este caso, se seleccionará la aplicación de tipo Android. Esto llevará a otra pantalla donde en una primera fase se tendrá que rellenar una serie de datos. 84 Figura 44: Integrar aplicación Android Firebase Una vez rellenado el nombre del paquete del proyecto y el resto de datos llega la fase de descargar el archivo de configuración. Para ello se seguirán las instrucciones y se pulsará sobre “Descargar googleservicer.json”. Una vez descargado el archivo se acude a nuestro proyecto. Se cambia la vista del panel izquierdo y se mueve el fichero desde la carpeta donde se descargará al directorio root de la aplicación. Una vez realizado todo esto, el proceso aún no ha finalizado. Para terminar la integración será necesario añadir las dependencias correspondientes y activar los Google services. Para ello, hay que incluir en el archivo build.gradle del proyecto el siguiente código: dependencies { classpath 'com.google.gms:google-services:4.0.1' } También es necesario añadir el siguiente código en el fichero buil.gradle, pero esta vez de la aplicación: apply plugin: 'com.google.gms.google-services' Además, posteriormente es necesario añadir las dependencias de Firebase y sus funcionalidades en la aplicación Android. Para ello es necesario añadir el siguiente código al archivo build.gradle de la aplicación: implementation 'com.google.firebase:firebase-core:16.0.5' implementation 'com.google.firebase:firebase-database:16.0.5' implementation 'com.google.firebase:firebase-auth:16.0.5' Con todo este proceso se ha finalizado la integración del proyecto de Firebase con ambas aplicaciones. 85 6.3.2.2 Aplicación web Como en la otra aplicación en el panel principal de Firebase se pulsa sobre el botón “Añadir aplicación”. Figura 45: Integrar aplicación Firebase. Una vez pulsado el botón, se selecciona el tipo de aplicación que se quiere añadir y se muestra una pantalla indicando como se debe proceder. Figura 46: Integrar aplicación web Firebase. En nuestro caso se incluye el código en el fichero cabecera.php que como se verá posteriormente, irá incluido en todas las páginas de las que dispone la aplicación. Una vez finalizado este proceso nuestra aplicación web ya dispone de la posibilidad de conectarse con el nuevo proyecto que se ha creado. 86 6.3.3 Administrar usuarios en Firebase En este apartado se explica cómo se gestiona el control de los usuarios en ambas aplicaciones, es decir, como se controla el registro y autenticación de usuarios en las aplicaciones. 6.3.3.1 Aplicación móvil Para realizar cualquier función sobre el sistema Authentication de Firebase es necesario instanciar un objeto FirebaseAuth. Para ello se usará el siguiente código: private FirebaseAuth firebaseAuth; Creación de usuario Para crear un nuevo usuario en el proyecto de Firebase se hará a través de la llamada al método CreateUserWithEmailAndPassword. Está función permite crear usuarios para que se autentiquen en Firebase con su dirección de correo electrónico y contraseña. El código utilizado por la aplicación para la creación de usuarios es el siguiente: firebaseAuth.createUserWithEmailAndPassword(email,password) .addOnCompleteListener(this,new OnCompleteListener<AuthResult>(){ @Override public void onComplete(@NonNull Task<AuthResult> task){ //control de que todo fue correcto if(task.isSuccessful()){ Toast.makeText(RegistroActivity.this,getString(R.string.registrado),To ast.LENGTH_LONG).show(); RegistrarRestoUsuario(); updateUI(); }else{ //Excepciones controladas con mensaje if(task.getException() instanceof FirebaseAuthUserCollisionException){//Si el usuario ya existe Toast.makeText(RegistroActivity.this,getString(R.string.registrado_ok) ,Toast.LENGTH_LONG).show(); }else if(task.getException() instanceof FirebaseAuthInvalidCredentialsException){ Toast.makeText(RegistroActivity.this,getString(R.string.email_invalido ),Toast.LENGTH_LONG).show(); }else{ Toast.makeText(RegistroActivity.this,getString(R.string.registrado_ko) ,Toast.LENGTH_LONG).show(); } } progressDialog.dismiss(); } }); 87 En el código se puede ver como intenta crear un usuario con email y contraseña y si la creación da error, la aplicación trata de informar cual ha sido el motivo por el cual no se ha creado el usuario, como puede ser que el sistema ya cuente con un usuario con ese mismo correo electrónico. Autenticación de usuario Como se ha dicho en el apartado anterior la autenticación se realizará a través del correo electrónico y la contraseña. La función utilizada para realizar la autenticación es signInWithEmailAndPassword y el código del proyecto: firebaseAuth.signInWithEmailAndPassword(email,password) .addOnCompleteListener(this,new OnCompleteListener<AuthResult>(){ @Override public void onComplete(@NonNull Task<AuthResult> task){ //control de que todo fue correcto if(task.isSuccessful()){ Toast.makeText(LoginActivity.this,getString(R.string.bienvenido),Toast .LENGTH_LONG).show(); FirebaseUser currentUser = firebaseAuth.getCurrentUser(); updateUI(currentUser); }else{ Toast.makeText(LoginActivity.this,getString(R.string.error_aut),Toast. LENGTH_LONG).show(); SharedPreferences.Editor editor = prefs.edit(); editor.remove("email"); editor.remove("pass"); editor.apply(); updateUI(null); } progressDialog.dismiss(); } }); Otras funciones En este apartado se van a comentar otras funciones sobre el usuario que se han usado durante el desarrollo de la aplicación. o Obtener los datos del usuario FirebaseUser user = firebaseAuth.getCurrentUser(); o Cerrar sesión FirebaseAuth.getInstance().signOut(); 88 o Eliminar usuario FirebaseUser user = firebaseAuth.getCurrentUser(); user.delete().addOnCompleteListener(new OnCompleteListener<Void>() { @Override public void onComplete(@NonNull Task<Void> task) { if(task.isSuccessful()){ Log.d(TAG,"Usuario borrado correctamente"); Intent i = new Intent(GestorActivity.this, LoginActivity.class); startActivity(i); finish(); } } }); 6.3.3.2 Aplicación web Para realizar cualquier función sobre el sistema Authentication de Firebase es necesario instanciar un objeto firebase.auth. Para ello se usará el siguiente código: var auth = firebase.auth(); Creación de usuario Para crear un nuevo usuario en el proyecto de Firebase se hará a través de la llamada al método CreateUserWithEmailAndPassword. Está función te permite crear usuarios para que se autentiquen en Firebase con su dirección de correo electrónico y contraseña. El código utilizado por la aplicación para la creación de usuarios es el siguiente: firebase.auth().createUserWithEmailAndPassword(email, password) .then(function(result) { console.log('Encargado registrado'); var user = firebase.auth().currentUser; var uid; if (user != null) { uid = user.uid; console.log(uid); var refResultados = database.ref("Usuarios/" + uid); refResultados.set(objResultado); }else { // No user is signed in. } }).catch(function(error) { var errorCode = error.code; console.log(errorCode); var errorMessage = error.message; console.log(errorMessage); }); En el código se puede ver como intenta crear un usuario con email y contraseña y si la creación da error, la aplicación trata de informar cual ha sido el motivo por el cual no se ha creado el usuario, como puede ser que el sistema ya cuente con un usuario con ese mismo correo electrónico. 95 Aunque en la figura anterior se pueden ver numerosos directorios, todo el código de la aplicación se encuentra en la carpeta:  ~/Proyecto/app/src Una vez dentro de este directorio podemos encontrar numerosos subdirectorios.  ~/Proyecto/app/src/androidTest  ~/Proyecto/app/src/debug  ~/Proyecto/app/src/main  ~/Proyecto/app/src/reléase  ~/Proyecto/app/src/test Pero de todos estos directorios el principal es el main, ya que es el directorio que contiene todo el código de la aplicación. Dentro del directorio main podemos diferenciar:  Java: esta carpeta contiene el código fuente de la aplicación. Los ficheros java se almacenan en carpetas según el nombre de su paquete. Dentro de los archivos java podemos diferenciar cuatro tipo: o Clases: estos archivos están compuestos por un constructor con cada uno de sus atributos y los métodos getter y setter de cada uno de los atributos. o Activity: son las pantallas principales de nuestra aplicación. Son seis: inicio de sesión, registro, principal usuario común, principal de usuario gestor, ajustes y SplashScreen. o Fragment: son pantallas cargadas desde un activty, pero muy importantes en la aplicación ya que son las que contiene la mayor parte de la lógica. o Auxiliares: son ficheros de distintos usos como pueden ser adaptadores o ficheros de configuración para acceder a servicios como Paypal. Posteriormente se procederá a explicar de una forma más detalla la función de cada uno de los ficheros java.  Res: esta carpeta contiene los recursos usados por la aplicación. o Drawable: en esta carpeta se almacenan los ficheros de imágenes y descriptores de imágenes en xml. o Layout: contiene los ficheros xml con vistas de la aplicación. Estas vistas son las que conforman cada una de las pantallas de la aplicación. o Menú: contiene los archivos xml del menú de la aplicación. o Mipmap: es la carpeta donde se guarda el icono de la aplicación. Este recurso se ha añadido en seis versiones diferentes, de forma que, por ejemplo, el hdpi sólo se cargará cuando el dispositivo de la aplicación disponga de una densidad grafica alta. o Values: este directorio se usa para indicar valores usados durante la aplicación como puede ser el estilo o tener la aplicación en varios idiomas. o Xml: son otros archivos xml requeridos por la aplicación como los del SettingsActivity. 96 Figura 50: Estructura de la carpeta res.  AndroidMAnifest.xml: este fichero describe la aplicación Android. Se define su nombre, paquete, icono, estilos, etc. Se indican las actividades, las intenciones, los servicios y los proveedores de contenido de la aplicación. También se declararán los permisos que requerirá la aplicación. Una vez explicado cómo se organiza toda la estructura del proyecto se va a explicar cómo funciona cada una de las partes de la aplicación. Al iniciar la aplicación se cargará el activity SplashScreenActivity, el cual tiene como función acceder a las preferencias compartidas y ver si desde esa aplicación ya ha accedido algún usuario. Figura 51: SplashScreenActivity. 97 Cómo será la primera vez que se acceda a la aplicación se le redirigirá a LoginActivity. Desde aquí tendrá dos opciones: iniciar sesión en caso de que ya se encuentre registrado en la aplicación o dirigirse a RegistroActivity a través de un enlace situado en la parte inferior de la pantalla como es el caso, ya que no se encontrará registrado. Figura 52: LoginActivity. En este punto, se rellenarán los datos del formulario y se enviará la información. Hecho esto la aplicación registrará al usuario en el servicio de authenticacion de Firebase, iniciará sesión y redirigirá directamente a la pantalla principal. Figura 53: RegistroActivity 98 Este redireccionamiento podrá llevar a dos pantallas distintas en función del tipo de usuario. En este caso al realizar el registro a través de la aplicación eres un usuario común y te llevará al MainActivity, pero si fuera el usuario de tipo gestor, el redireccionamiento lo habría llevado a GestorActivity. Figura 54: MainActivity con InicioFragment. Cuando se haya iniciado sesión y se encuentre en el MainActivity, el activity cargará el fragment InicioFragment, el cual mostrará un recycler view con el listado de pistas que se encuentren registradas en la base de datos. Desde cualquier fragment del MainActivity se podrá acceder al menú navigation drawer que mostrará todas las funcionalidades de las que dispone la aplicación. Figura 55: NavigationDrawer. 99 El menú de la aplicación mostrará las siguientes opciones: 1. Inicio: Mostrado por InicioFragment desde esta pantalla se podrá acceder a visualizar cualquiera de las pistas que cargará el fragment DetallePistaFragment, el cuál mostrará la información de la pista incluido un mapa de Google Maps con su localización. Figura 56: DetallePistaFragment. 2. Mi perfil: Esta opción mostrará el fragment PerfilFragment, el cual se basa en un formulario donde podrá ver y actualizar la información del perfil del usuario. Figura 57: PerfilFragment. 100 3. Ajustes: Es la única pantalla una vez iniciado sesión que no es un fragment, ya que esta funcionalidad llevaría al activity SettingsActivity. Dentro de este activity se tienen varias opciones como son cambiar el idioma, dar de baja el usuario de la aplicación, informarnos de la versión de la aplicación, etc. Figura 58: SettingsActivity. 4. Reserva: La opción más importante. Una vez se pulse la opción, se mostrará ReservaFragment donde da a elegir el día de la reserva y el tipo de pista que se desea. Figura 59: ReservaFragment. 101 Una vez elegidas las dos opciones, se presionará el botón continuar y se redirigirá a ElegirHoraFragment. En la parte superior se mostrará un desplegable con todas las pistas que hay disponibles para el tipo de pista seleccionado y, por la pista seleccionada se mostrará un listado de horas con un check para que se seleccionen las horas a reservar. Figura 60: ElegirHoraFragment. Cuando se hayan seleccionado las horas, continuará y se dirigirá a FinalizarReservaFragment, donde mostrará un resumen de la reserva donde se podrá ver la hora de reserva, duración, precio, etc. Figura 61: FinalizarReservaFragment. 102 Una vez se asegure que todos los datos son correcto, se pulsará sobre finalizar la reserva y esto redireccionará fuera de la aplicación a PayPal para que realice el pago de la reserva. Figura 62: Captura Paypal. Al finalizar el pago de la reserva esté volverá a redirigirse a la aplicación, la cual indicará si la reserva se finalizó de forma exitosa o no. Figura 63: Captura Confirmación de reserva. 103 5. Mis Reservas: Al acceder se redirigirá a ListadoReservasFragment donde se podrán ver tanto las reservas que ya han finalizado como las próximas. Figura 64: ListadoReservasFragment. También se podrá acceder a cada una de las reservas, lo cual llevaría a DetallesReservaFragment donde en el caso de que queden más de 24h para que comience se pueda cancelar la reserva. Figura 65: DetallesReservaFragment. 104 6. Cerrar sesión: La cual llevará a LoginActivty y borrará las preferencias que se guardaron al iniciar sesión. Figura 66: Cerrar Sesión. Anteriormente se han explicado todas las funcionalidades en caso de acceder a la aplicación como usuario común, pero no se ha explicado que ocurre al acceder como gestor. Simplemente se comentó que se accede a un activity distinto como es GestorActivity el cual cargará el fragment GestorFragment que mostrará un listado con las reservas. Este activity también cuenta con un menú pero no es el mismo, ya que únicamente cuenta con dos opciones, por lo que se consideró mejor realizar un menú desplegable sencillo en el que las opciones sean cerrar sesión y darse de baja de la aplicación. Figura 67: GestoActivity con GestorFragment. 111 112 7. PRUEBAS 114 En este capítulo se indicarán las pruebas que se han realizado al sistema para asegurar que tiene un funcionamiento correcto en caso de recibir un comportamiento no esperado. Para ello se realizarán dos tipos de pruebas: 7.1 Pruebas de caja blanca: Las pruebas de caja blanca consisten en realizar de forma manual que cada una de las funcionalidades de las que disponen las aplicaciones funcionen de forma correcta, es decir, que el flujo de las aplicaciones sea el esperado. Estas pruebas se realizarán durante el periodo de implementación y son: 7.1.2 Aplicación móvil:  Comprobación de la validación de entrada de datos de todos los formularios.  Comprobación de comportamiento en caso de pérdida de conexión puntual.  Comprobación de comunicación con los distintos servicios externos.  Comprobación de la actualización de datos en tiempo real.  Comprobación del funcionamiento de las operaciones. 7.1.1 Aplicación Web:  Comprobación de la validación de entrada de datos de todos los formularios.  Comprobación de comportamiento en caso de pérdida de conexión puntual.  Comprobación de comunicación con Firebase.  Comprobación del control de sesiones.  Comprobación de la actualización de datos en tiempo real.  Comprobación de control de acceso a la base de datos.  Comprobación del funcionamiento de las operaciones. 7.2 Pruebas de caja negra: Estas pruebas sirven para comprobar la funcionalidad deseada de las aplicaciones desarrollada. Las pruebas se realizarán de forma que no sea necesario tener ningún conocimiento sobre el funcionamiento y la estructura de las aplicaciones. A continuación, se detallarán algunas de las pruebas que se han realizado. 115 7.2.2 Aplicación móvil: PCN-01: Registro de usuario Objetivo Comprobar que se puede crear un usuario en el sistema como usuario común Precondiciones Ninguna Datos de entrada Email: [email protected] Contraseña: ferky19 Nombre de usuario: Fernando Apellidos: de la Calle Rodríguez Nº de teléfono: 625478596 Acción esperada Al pulsar sobre “acceder” el sistema redirigirá a la pantalla de inicio del usuario común Resultado Correcto Tabla 29: PCN-01 Registro de usuario. PCN-02: Iniciar sesión como usuario común Objetivo Comprobar que se puede acceder a la aplicación móvil como usuario común Precondiciones El usuario esté registrado como usuario común Datos de entrada Email: [email protected] Contraseña: ferky19 Acción esperada Al pulsar sobre “acceder” el sistema redirigirá a la pantalla de inicio del usuario común Resultado Correcto Tabla 30: PCN-02 Iniciar sesión como usuario común. PCN-03: Iniciar sesión como gestor Objetivo Comprobar que se puede acceder a la aplicación móvil como gestor Precondiciones El usuario esté registrado como gestor Datos de entrada Email: [email protected] Contraseña: ferky27 Acción esperada Al pulsar sobre “acceder” el sistema redirigirá a la pantalla de inicio del gestor Resultado Correcto Tabla 31: PCN-03 Iniciar sesión como gestor. 116 PCN-04: Modificar información de perfil Objetivo Comprobar que se puede modificar la información de perfil como usuario común Precondiciones El usuario común debe haber iniciado sesión en la aplicación móvil Datos de entrada Email: [email protected] Contraseña: ferky19 Nombre de usuario: Fernando Apellidos: Calle Nº de teléfono: 669854759 Acción esperada Al pulsar sobre “actualizar” el sistema actualizará la información del perfil del usuario Resultado Correcto Tabla 32: PCN-04 Modificar información de perfil. PCN-05: Listado de reservas Objetivo Comprobar que se puede visualizar el listado de reservas que están registradas en el sistema Precondiciones El usuario común debe haber iniciado sesión en la aplicación móvil Datos de entrada Ninguno Acción esperada Al acceder a la pantalla de listado de reservas se mostrará un listado con todas las reservas registradas en el sistema Resultado Correcto Tabla 33: PCN-05 Listado de reservas. PCN-06: Visualizar información de pista Objetivo Comprobar que se puede visualizar la información de una pista Precondiciones El usuario común debe haber iniciado sesión en la aplicación móvil Datos de entrada Ninguno Acción esperada Al acceder a la pantalla de detalles de una pista verá toda la información de la pista y un mapa con la ubicación de la misma Resultado Correcto Tabla 34: PCN-06 Listado de reservas. PCN-07: Realizar reserva Objetivo Comprobar que se puede realizar una reserva Precondiciones El usuario común debe haber iniciado sesión en la aplicación móvil Datos de entrada Fecha: 02/05/2019 Tipo de pista: Pádel Pistas: Pista 1 Horas: 9:00-10:00 Acción esperada Al finalizar la reserva visualizará en listado de reservas que la reserva se ha registrado de forma exitosa Resultado Correcto Tabla 35: PCN-07 Listado de reservas. 117 PCN-08: Cambiar idioma Objetivo Comprobar que se puede cambiar de idioma a la aplicación Precondiciones El usuario común debe haber iniciado sesión en la aplicación móvil Datos de entrada Idioma: ingles Acción esperada Al seleccionar el idioma verá que toda la aplicación se mostrará en el idioma seleccionado Resultado Correcto Tabla 36: PCN-08 Cambiar idioma. PCN-09: Dar de baja al usuario Objetivo Comprobar que se puede eliminar un usuario de la aplicación Precondiciones El usuario común debe haber iniciado sesión en la aplicación móvil Datos de entrada Ninguno Acción esperada Al pulsar sobre “borrar” no podrá acceder a la aplicación con el usuario anterior Resultado Correcto Tabla 37: PCN-09 Dar de baja al usuario. PCN-10: Cerrar sesión Objetivo Comprobar que se puede cerrar sesión en la aplicación web Precondiciones El administrador debe haber iniciado sesión en la aplicación móvil Datos de entrada Ninguno Acción esperada Al pulsar sobre “Cerrar sesión” el sistema redirigirá a la pantalla de inicio de sesión Resultado Correcto Tabla 38: PCN-10 Cerrar sesión. 7.2.1 Aplicación Web: PCN-11: Iniciar sesión Objetivo Comprobar que se puede acceder a la aplicación web Precondiciones El usuario esté registrado como administrador Datos de entrada Email: [email protected] Contraseña: ferky27 Acción esperada Al pulsar sobre “acceder” el sistema redirigirá a la pantalla de inicio Resultado Correcto Tabla 39: PCN-11 Iniciar sesión. 118 PCN-12: Crear Gestor Objetivo Comprobar que se puede registrar un nuevo usuario de tipo gestor Precondiciones El administrador debe haber iniciado sesión en la aplicación web Datos de entrada Email: [email protected] Contraseña: ferky27 Nombre de usuario: Fernando Apellidos: de la Calle Rodríguez Nº de teléfono: 625478596 Acción esperada Al pulsar sobre “crear” el sistema registrará al usuario y aparecerá en el listado de usuarios Resultado Correcto Tabla 40: PCN-12 Crear Gestor. PCN-13: Crear Tipo de pista Objetivo Comprobar que se puede crear un nuevo tipo de pista Precondiciones El administrador debe haber iniciado sesión en la aplicación web Datos de entrada Nombre del tipo de pista: Pádel Descripción del tipo de pista: cubierta Acción esperada Al pulsar sobre “crear” el sistema registrará el tipo de pista y aparecerá en el listado de tipos de pista Resultado Correcto Tabla 41: PCN-13 Crear Tipo de pista. PCN-14 Modificar pista. Objetivo Comprobar que se puede modificar los datos de una pista Precondiciones El administrador debe haber iniciado sesión en la aplicación web Debe existir la pista en la base de datos Datos de entrada Nombre de la pista: Pista 1 Precio : 5 Tipo de pista: Pádel Duración: 30 Localización: 40.951629, -4.077633 Acción esperada Al pulsar sobre “modificar” el sistema registrará la nueva información de la pista y aparecerá en el listado pistas con la nueva información Resultado Correcto Tabla 42: PCN-14 Modificar pista. 119 PCN-15 Eliminar horario. Objetivo Comprobar que se puede eliminar un horario Precondiciones El administrador debe haber iniciado sesión en la aplicación web Debe existir el horario en la base de datos Datos de entrada Ninguno Acción esperada Al pulsar sobre “borrar” el sistema eliminará el horario y desaparecerá del listado de horarios Resultado Correcto Tabla 43: PCN-15 Eliminar horario. PCN-16: Cerrar sesión Objetivo Comprobar que se puede cerrar sesión en la aplicación web Precondiciones El administrador debe haber iniciado sesión en la aplicación web Datos de entrada Ninguno Acción esperada Al pulsar sobre “Cerrar sesión” el sistema redirigirá a la pantalla de inicio de sesión Resultado Correcto Tabla 44: PCN-16 Cerrar sesión. PCN-17: Listado de usuario Objetivo Comprobar que se puede visualizar el listado de usuarios que están registrados en el sistema Precondiciones El administrador debe haber iniciado sesión en la aplicación web Datos de entrada Ninguno Acción esperada Al acceder a la pantalla de gestión de usuarios se mostrará una tabla con todos los usuarios registrados en el sistema Resultado Correcto Tabla 45: PCN-17 Listado de usuarios. 120 8. MANUALES 127 Una vez rellenados los datos y pulsado sobre “Crear una cuenta”, la aplicación mostrará la pantalla inicial desde la que se puede acceder al menú, el cual proporciona todas las funcionalidades de la aplicación. Figura 84: Pantalla de registro. A continuación se van a explicar todas las funcionalidades del menú en orden descendente. Figura 85: Menú pantalla inicial. 128  Inicio: desde esta función se podrá visualizar el listado de pistas del que dispone el sistema. Figura 86: Listado de pistas. También se podrá ver la información detallada de las pistas al pulsar sobre ellas. Figura 87: Detalles de una pista. 129  Mi Perfil: desde esta función se podrá ver la información de tu perfil y modificarla en caso de que se considere necesario. Figura 88: Perfil del usuario.  Ajustes: desde esta opción se podrá realizar acciones como cambiar de idioma y dar de baja tu usuario. Figura 89: Ajustes. 130  Reserva online: desde esta función se permitirá realizar una reservar. Al pulsar sobre ella, el menú la aplicación te mostrará una pantalla donde se tendrá que seleccionar la fecha y el tipo de pista que desea reservar. Figura 90: Realizar reserva 1. Una vez seleccionado lo anterior la aplicación mostrará un desplegable con todas las pistas de ese tipo que tiene disponibles y el horario de disponibilidad. Figura 91: Realizar reserva 2. 131 En caso de que se tenga seleccionada la pista y las horas de reservas, al pulsar sobre “Reservar”, la aplicación mostrará un resumen de la reserva para que se confirme que todos los datos son correctos. Figura 92: Realizar reserva 3. Una vez confirmada la reserva, la aplicación redirigirá a Paypal para que se realice el pago. Figura 93: Pago Paypal. 132 Se tendrá que seleccionar la opción de pagar con tarjeta o a través de la cuenta de PayPAl y una vez se realice el pago, se volverá a la aplicación donde se confirmará que la reserva se realizó de forma exitosa. Figura 94: Confirmación de reserva.  Mis reservas: esta función permitirá visualizar las reservas que se hayan realizado a través del sistema, tanto si ya se han finalizado como las próximas reservas. Figura 95: Listado de reservas. 133 Esta funcionalidad también permitirá cancelar una reserva en caso de que queden más de 24 horas para que se inicie. Figura 96: Detalles de una reserva.  Cerrar sesión: esta función permitirá cerrar sesión y la aplicación mostrará la pantalla de inicio de sesión. Figura 97: Cerrar Sesión. 134 8.4 Manual de gestor de pistas Esta guía está elaborada con el fin de orientar al gestor en el uso de la aplicación móvil. Ya que la aplicación se encuentra en desarrollo, su instalación se deberá realizar de forma manual desde el archivo –apk del CD-ROM. Una vez se tenga la aplicación instalada, al iniciarla se le mostrará una pantalla de carga Figura 98: Pantalla de carga. Una vez que la aplicación este cargada la aplicación mostrará la pantalla de inicio de sesión. En esta pantalla será necesario que el gestor introduzca los datos con los que el administrador le creó la cuenta a través de la aplicación web. Una vez el gestor realice la autenticación, la aplicación mostrará la única pantalla de la que dispone el usuario. Figura 99: Pantalla de inicio de sesión. 135 Desde esta pantalla el gestor dispondrá de un menú con las opciones de cerrar sesión y darse de baja del sistema y también, dispondrá del listado de reservas en función de la fecha y la pista que seleccione. Figura 100: Pantalla principal del gestor. 136 9. CONCLUSIONES 143 - Trabaja con listas de datos en Android. Disponible en https://firebase.google.com/docs/database/android/lists-of-data?hl=es-419. Fecha de último acceso: 6 de febrero de 2019. - Autentica con Firebase mediante cuentas basadas en contraseña en Android. Disponible en https://firebase.google.com/docs/auth/android/passwordauth?hl=es. Fecha de último acceso: 18 de diciembre de 2018. Aplicación Web: - Instalación y configuración de Firebase en JavaScript. Disponible en https://firebase.google.com/docs/database/web/start?hl=es-419. Fecha de último acceso: 1 de noviembre de 2018. - Uso de promesas en JavaScript. Disponible en https://developer.mozilla.org/es/docs/Web/JavaScript/Guide/Usar_promesas. Fecha de último acceso: 12 de febrero de 2019. - Callbacks y asincronía en JavaScript. Disponible en https://medium.com/@jmz12/callbacks-promesas-y-async-await-que-alguien- me-explique-514137cb57e2. Fecha de último acceso: 13 de marzo de 2019. - Un sencillo datepicker para tu formulario. Disponible en https://www.anerbarrena.com/date-input-html5-2829/. Fecha de último acceso: 12 de febrero de 2019. - Lee y escribe datos en la Web. Disponible en https://firebase.google.com/docs/database/web/read-and-write?hl=es-419. Fecha de último acceso: 7 de abril de 2019. - Trabaja con listas de datos en la Web. Disponible en https://firebase.google.com/docs/database/web/lists-of-data?hl=es-419. Fecha de último acceso: 16 de ener de 2019. - Autentica con Firebase mediante cuentas basadas en contraseñas con JavaScript. Disponible en https://firebase.google.com/docs/auth/web/passwordauth?hl=es. Fecha de último acceso: 5 de noviembre de 2018. - Pasar variables por la URL con PHP. Disponible en https://desarrolloweb.com/articulos/317.php. Fecha de último acceso: 6 de diciembre de 2019. - Select dinámico en php y JavaScript. Disponible en https://es.stackoverflow.com/questions/202864/select-dinamicos-en-php-y-js- por-el-metodo-post. Fecha de último acceso: 12 de febrero de 2019. - Validación de formulario de datos. Disponible en https://developer.mozilla.org/es/docs/Learn/HTML/Forms/Validacion_formulari o_datos. Fecha de último acceso: 25 de abril de 2019. - Como enviar un correo electrónico desde Localhost con PHP. Disponible en https://obedalvarado.pw/blog/enviar-correo-electronico-desde-localhost-php/. Fecha de último acceso: 22 de mayo de 2019. - Firebase contar el número de registros en tiempo real. Disponible en https://rstopup.com/firebase-contar-el-numero-de-registros-en-tiempo-real.html. Fecha de último acceso: 22 de mayo de 2019. 144 ANEXO A – Firebase ¿Qué es Firebase? Firebase es un conjunto de herramientas orientadas a la creación de aplicaciones tanto móviles como web. Por lo tanto Firebase pertenece a la categoría software como servicio (SaaS, Software as a Servicie). Fue fundada en 2011 y posteriormente fue comprada por Google en 2014. En el año 2016 vivió su renovación más fuerte, ya que en 2015 Google adquirió Divshot el cual fusionó con Firebase, aunque posteriormente ha vivido actualizaciones muy importantes. Firebase tiene numerosas características que se pueden englobar en cuatro grupos:  Analíticas: Provee de una solución gratuita para tener todo tipo de información, para gestionarla toda desde un único panel.  Desarrollo: Permite construir aplicaciones mejoradas, permitiendo delegar determinadas operaciones en Firebase para poder ahorrar tiempo, evitar bugs y obtener un aceptable nivel de calidad. Entre sus características destacan el almacenamiento, testeo, configuración remota, mensajería en la nube o autenticación, entre otras.  Crecimiento: Permite gestionar los usuarios de las aplicaciones, pudiendo además captar nuevos usuarios. Para ello dispondremos de funcionalidades como las de invitaciones, indexación o notificaciones.  Monetización: Permite ganar dinero gracias a AdMob. Figura 101: Características de Firebase. 145 ¿Por qué elegimos utilizar Firebase? Me decidí por utilizar Firebase debido a que es una potente API que presenta la utilidad de almacenar y sincronizar datos en tiempo real. En definitiva estamos ante una base de datos de tipo No SQL que se presenta como un servicio, dirigido tanto a aplicaciones web como a aplicaciones móviles, desde las cuales se puede hacer una sincronización en tiempo real de todos los datos. Los principales motivos que me llevaron a utilizar este software como sistema de almacenamiento de información fueron:  Rapidez, ya que esta es una de sus características principales.  Evitar crear una infraestructura compleja.  Proporcionar una solución de análisis gratuita.  Tener soporte multiplataforma.  Proporcionar un sistema de notificaciones para los usuarios de la app móvil. ¿Qué servicios de Firebase se utilizarán? Los servicios de Firebase utilizados durante el desarrollo del proyecto serán:  Realtime database: Es el servicio que más se utilizará debido a que proporciona una API para mantener la información sincronizada y almacenada en la nube. Los datos se almacenarán en formato JSON y se pueden agregar reglas.  Autenticación: Es otro de los servicios más importante ya que nos simplifica el inicio de gestión de la misma en nuestra aplicación.  Almacenamiento: Muy útil para subir archivos como, por ejemplo, imágenes.  Informes sobre fallos y monitorización: Permite detectar errores que aparezcan y medir el rendimiento en nuestra aplicación Android.  Notificaciones Push: Permite gestionar el envío de notificaciones a nuestros usuarios con la diferencia de que estas podrán ser programadas. Arquitectura lógica de firebase Como este servicio es el encargado del almacenamiento de datos y del control de usuarios, para la comunicación de la aplicación con el API se hace uso del protocolo HTTP, el cual nos permite el uso de objetos JSON para facilitar la transmisión de información. Figura 102: Arquitectura lógica Firebase. 146 ANEXO B- Desarrollo detallado de la especificación CU-02 Autenticarse en la plataforma móvil Versión 1.0 Fecha 08/03/2019 Dependencias RF-02 Actor Usuario no autenticado. Descripción El usuario no autenticado podrá autenticarse desde la aplicación móvil. Precondiciones Secuencia normal 1. El usuario no autenticado solicita al sistema autenticarse como usuario. 2. El sistema solicita los datos necesarios para autenticarle. 3. El usuario envía los datos. 4. El sistema autentica al usuario en el sistema y redirige la vista a la pantalla inicial. Postcondicones El usuario no autenticado pasa a convertirse a usuario autenticado. Excepciones 4.EX-01 Los datos introducidos no son válidos, volviendo al paso 2 de la secuencia normal. 4.EX-02 El usuario no está registrado en el sistema, volviendo al paso 2 de la secuencia normal. Frecuencia Alta. Importancia Alta. Comentarios Tabla 46: Autenticarse en la plataforma móvil CU-04 Cerrar sesión en la aplicación móvil Versión 1.0 Fecha 08/03/2019 Dependencias RF-04 Actor Usuario autenticado. Descripción El usuario autenticado podrá cerrar la sesión de la aplicación móvil. Precondiciones 1. El usuario debe estar autenticado en la aplicación móvil. Secuencia normal 1. El usuario solicita cerrar la sesión. 2. El sistema cierra la sesión y redirige la vista a la pantalla de inicio de sesión. Postcondicones El usuario autenticado pasa a convertirse a usuario no autenticado. Excepciones Frecuencia Media. Importancia Media. Comentarios Tabla 47: CU-04 Cerrar sesión en la aplicación móvil. 147 CU-05 Darse de baja Versión 1.0 Fecha 08/03/2019 Dependencias RF-05 Actor Usuario autenticado. Descripción El usuario autenticado podrá darse de baja del sistema. Precondiciones 1. El usuario debe estar autenticado en la aplicación móvil. Secuencia normal 1. El usuario solicita acceder a los ajustes. 2. El sistema muestra las opciones de ajustes. 3. El usuario solicita darse de baja del sistema. 4. El sistema elimina al usuario y redirige la vista a la pantalla de registro. Postcondicones El usuario autenticado pasa a convertirse a usuario no autenticado. Excepciones Frecuencia Baja. Importancia Media. Comentarios Tabla 48: CU-05 Darse de baja. CU-06 Visualizar reservar Versión 1.0 Fecha 08/03/2019 Dependencias RF-06,CU-10 Actor Usuario autenticado. Descripción El usuario autenticado podrá visualizar los datos de una reserva. Precondiciones 1. El usuario debe estar autenticado en la aplicación móvil. 2. El usuario debe encontrarse visualizando el listado de reservas CU-09. Secuencia normal 1. El usuario solicita visualizar una reserva. 2. El sistema muestra la información detallada de la reserva. Postcondicones Excepciones Frecuencia Alta. Importancia Alta. Comentarios Tabla 49: CU-06 Visualizar reservar. 148 CU-07 Visualizar el listado de pistas Versión 1.0 Fecha 08/03/2019 Dependencias RF-07 Actor Usuario común. Descripción El usuario común podrá visualizar el listado de pistas. Precondiciones 1. El usuario debe estar autenticado como usuario común en la aplicación móvil. Secuencia normal 1. El usuario solicita visualizar el listado de pistas. 2. El sistema muestra el listado de pistas registradas en el sistema. Postcondicones Excepciones 2.EX-01 No existe ninguna pista registrada, el caso de uso finaliza mostrando un mensaje “No hay pistas disponibles”. Frecuencia Media. Importancia Media. Comentarios Tabla 50: CU-07 Visualizar el listado de pistas. CU-08 Visualizar pista Versión 1.0 Fecha 08/03/2019 Dependencias RF-08, CU-07 Actor Usuario común. Descripción El usuario común podrá visualizar los datos de una pista. Precondiciones 1. El usuario debe estar autenticado en la aplicación móvil. 2. El usuario debe encontrarse visualizando el listado de pistas CU-07. Secuencia normal 1. El usuario solicita visualizar una pista. 2. El sistema muestra la información detallada de la pista. Postcondicones Excepciones Frecuencia Media. Importancia Media. Comentarios Tabla 51: CU-08 Visualizar pista. 149 CU-10 Visualizar el listado de reservas Versión 1.0 Fecha 08/03/2019 Dependencias RF-13 Actor Usuario autenticado. Descripción El usuario autenticado podrá visualizar el listado de reservas. Precondiciones 1. El usuario debe estar autenticado en la aplicación móvil. Secuencia normal 1. El usuario solicita visualizar el listado de reservas. 2. El sistema muestra el listado de reservas registradas en el sistema. Postcondicones Excepciones 2.EX-01 No existe ninguna reservas registrada, el caso de uso finaliza mostrando un mensaje “No hay reservas disponibles”. Frecuencia Alta. Importancia Alta. Comentarios Tabla 52: CU-10 Visualizar el listado de reservas. CU-11 Cancelar una reserva Versión 1.0 Fecha 08/03/2019 Dependencias RF-14,CU-10,CU-06 Actor Usuario común. Descripción El usuario común podrá cancelar una reserva. Precondiciones 1. El usuario debe estar autenticado como usuario común en la aplicación móvil. 2. El usuario debe encontrarse visualizando la reserva CU-06. Secuencia normal 1. El usuario solicita cancelar la reserva. 2. El sistema cancela la reserva y redirige al usuario al listado de reservas CU-10. Postcondicones Se elimina la reserva del sistema. Excepciones 2.EX-01 La reserva no se puede cancelar y se finalizará el caso de uso mostrando un diciendo “No se puede cancelar la reserva ya que quedan menos de 24h”. Frecuencia Media. Importancia Media. Comentarios Tabla 53: CU-11 Cancelar una reserva. 150 CU-12 Crear un nuevo usuario Versión 1.0 Fecha 08/03/2019 Dependencias RF-15,RF-39 Actor Administrador. Descripción El administrado podrá crear usuarios con el rol de gestor de pistas desde la aplicación web. Precondiciones 1. El administrador debe estar autenticado en la aplicación web. Secuencia normal 1. El administrador solicita al sistema la creación de un usuario. 2. El sistema solicita los datos del nuevo usuario. 3. El administrador envía los datos. 4. El sistema registra al nuevo usuario en el sistema y redirige la vista a la pantalla de lista de usuarios. Postcondicones El sistema registra un nuevo gestor de pistas. Excepciones 4.EX-01 Los datos introducidos no son válidos, volviendo al paso 2. 4.EX-02 El correo electrónico ya está utilizado, volviendo al paso 2. Frecuencia Media. Importancia Alta. Comentarios Tabla 54: CU-12 Crear un nuevo usuario. CU-13 Visualizar listado de usuarios Versión 1.0 Fecha 08/03/2019 Dependencias RF-16 Actor Administrador. Descripción El administrador podrá visualizar todos los usuarios registrados en el sistema. Precondiciones 1. El administrador se habrá autenticado en la aplicación web. Secuencia normal 1. El usuario solicita visualizar el listado de usuarios. 2. El sistema muestra el listado de usuario. Postcondicones Excepciones 2.EX-0 No existe ningún usuario registrado en el sistema, terminándose el caso de uso. Frecuencia Media. Importancia Media. Comentarios Tabla 55: CU-13 Visualizar listado de usuarios. 151 CU-14 Visualizar usuario Versión 1.0 Fecha 08/03/2019 Dependencias RF-17 Actor Administrador. Descripción El administrador podrá visualizar la información detallada de un usuario. Precondiciones 1. El administrador se habrá autenticado en la aplicación web. 2. El administrador habrá solicitado visualizar el listado de usuarios CU-13. Secuencia normal 1. El usuario solicita visualizar la información detallada de un usuario. 2. El sistema muestra la información del usuario. Postcondicones Excepciones Frecuencia Baja. Importancia Baja. Comentarios Tabla 56: CU-14 Visualizar usuario. CU-15 Eliminar usuario Versión 1.0 Fecha 08/03/2019 Dependencias RF-18 Actor Administrador. Descripción El administrador podrá eliminar un usuario registrado en el sistema. Precondiciones 1. El administrador se habrá autenticado en la aplicación web. 2. El administrador habrá solicitado visualizar el listado de usuarios CU-13. Secuencia normal 1. El usuario solicita eliminar un usuario. 2. El sistema elimina al usuario del sistema. Postcondicones Se elimina al usuario del sistema. Excepciones Frecuencia Baja. Importancia Baja. Comentarios Tabla 57: CU-15 Eliminar usuario. 152 CU-16 Modificar un usuario. Versión 1.0 Fecha 08/03/2019 Dependencias RF-19 Actor Administrador. Descripción El administrado podrá modificar los datos de un usuario. Precondiciones 1. El administrador debe estar autenticado en la aplicación web. 2. El administrador debe encontrarse visualizando un usuarios CU-14. Secuencia normal 1. El usuario modifica la información y la envía. 2. El sistema registra la nueva información del usuario. Postcondicones La información del usuario se modifica. Excepciones 4.EX-01 Los datos introducidos no son válidos, volviendo al paso 2 de la secuencia normal. Frecuencia Baja. Importancia Baja. Comentarios Tabla 58: CU-16 Modificar un usuario. CU-18 Visualizar listado de pistas Versión 1.0 Fecha 08/03/2019 Dependencias RF-22 Actor Administrador. Descripción El administrador podrá visualizar todas las pistas registradas en el sistema. Precondiciones 1. El administrador debe estar autenticado en la aplicación web. Secuencia normal 1. El usuario solicita visualizar el listado de pistas. 2. El sistema muestra el listado de las pistas. Postcondicones Excepciones 2.EX-0 No existe ninguna pista registrada en el sistema, terminándose el caso de uso. Frecuencia Media. Importancia Media. Comentarios Tabla 59: CU-18 Visualizar listado de pistas.