Aplicación móvil de gestión de entrenamientos de un equipo de balonmano

Universidad de Valladolid Escuela Ingeniería Informática de Valladolid TRABAJO FIN DE GRADO Grado en Ingeniería Informática Mención en Tecnologías de la Información Aplicación móvil de gestión de entrenamientos de un equipo de balonmano Autor: D.ª Aida Rodríguez Zorrilla Tutor: D.ª Margarita Gonzalo Tasis 2 Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 3 Agradecimientos Me gustaría dedicar estas líneas para agradecer a todas las personas que han hecho posible que llevase a cabo este proyecto y toda mi formación hasta llegar a este momento. En primer lugar, a mis padres, por haber estado siempre ahí, ayudándome y apoyándome en los momentos difíciles, celebrando cada éxito como propio y animándome a afrontar siempre los nuevos retos que se han presentado en el camino. En segundo lugar, me gustaría dar las gracias a mis compañeros y a mis amigos, por todos los buenos momentos vividos a lo largo de estos años, dentro y fuera de la universidad. También quiero aprovechar estas líneas para agradecer su colaboración en este proyecto a otros entrenadores, muchos amigos; y a mis jugadoras, que me han sufrido en el día a día. Por último, me gustaría recordar a todos los profesores que han participado en mi formación a lo largo del tiempo, especialmente a Margarita, mi tutora, por darme la oportunidad de realizar este proyecto. 4 Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 5 Resumen En el presente documento se recoge el desarrollo de una aplicación móvil para gestionar equipos deportivos. Esta aplicación está especialmente orientada a entrenadores y jugadores, principalmente de balonmano, que deseen gestionar y consultar los datos de su equipo desde su dispositivo móvil. Este proyecto nace con el objetivo de dar respuesta a las problemáticas expuestas por muchos deportistas amateur; que lamentan los problemas derivados de la falta de organización para almacenar, acceder, consultar y modificar los datos generados a lo largo del tiempo. 6 Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 7 Abstract This document includes the development of a mobile application to manage sports teams. This application is especially aimed for coaches and players, mainly handball players, who wish to manage and consult their team data from their mobile device. This project was born with the aim of giving answer to the problems exposed by many amateur athletes, who are sorry about the problems arised from the lack of organization to store, access, consult and modify the data generated over time. 8 Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 9 Tabla de contenidos Capítulo 1. Introducción ..................................................................................................... 17 1.2. Contexto .....................................................................................................................18 1.3. Motivación .................................................................................................................18 1.4. Objetivos ....................................................................................................................19 1.5. Estado de la cuestión ..................................................................................................19 1.6. Terminología utilizada ................................................................................................23 1.7. Estructura de la memoria ...........................................................................................24 Capítulo 2: Requisitos ........................................................................................................ 25 2.1. Descripción de los actores y roles de la aplicación .....................................................26 2.2. Especificación de requisitos ........................................................................................26 2.2.1 Requisitos funcionales ...............................................................................................26 2.2.2 Requisitos de información .........................................................................................26 2.2.3 Requisitos no funcionales ..........................................................................................27 2.2.4 Restriciones ...............................................................................................................27 Capítulo 3: Plan Proyecto ................................................................................................... 31 3.1. Resumen del proyecto ................................................................................................32 3.1.1 Proposito, alcance y objetivos ...................................................................................32 3.1.2 Artefactos del proyecto .............................................................................................32 3.1.3 Evolución del plan .....................................................................................................32 3.2. Metodología de gestión del proyecto.........................................................................32 3.2.1 Ciclo de vida del proyecto .........................................................................................34 3.2.2 Plan de trabajo ..........................................................................................................34 3.2.3 Plan de gestión de riesgos .........................................................................................35 3.2.4 Presupuesto...............................................................................................................35 3.3. Seguimiento del plan ..................................................................................................43 3.3.1 Seguimiento de las fases y los riesgos .......................................................................43 Capítulo 4: Análisis ............................................................................................................ 45 4.1. Descripción del modelo de usuario ............................................................................46 4.2. Diagrama de casos de uso ..........................................................................................46 4.2.1 Usuario ......................................................................................................................47 4.2.2 Entrenador ................................................................................................................47 4.2.1 Jugador ......................................................................................................................48 16 Índice de figuras Figura 01: Capturas de pantalla de la aplicación miSquad ............................................................... 20 Figura 02: Capturas de pantalla de la aplicación MindPro ............................................................... 21 Figura 03: Capturas de pantalla de la aplicación Ejercicios de balonmano base ................................ 22 Figura 04: fases de la metodología UPEDU .................................................................................... 33 Figura 05: Diagrama de casos de uso: Usuario ............................................................................... 47 Figura 06: Diagrama de casos de uso: Entrenador .......................................................................... 47 Figura 07: Diagrama de casos de uso: Jugador ............................................................................... 48 Figura 08: Diagrama caso de uso CU-U01: Iniciar sesión ................................................................. 61 Figura 09: Diagrama caso de uso CU-U02: Cerrar sesión ................................................................. 62 Figura 10: Diagrama caso de uso CU-U03: Registrarse ................................................................... 62 Figura 11: Diagrama caso de uso CU-U04: Modificar datos perfil .................................................... 63 Figura 12: Diagrama caso de uso CU-EQ01: Registrar nuevo equipo ................................................ 63 Figura 13: Diagrama caso de uso CU-EQ02: Unirse a un equipo ....................................................... 64 Figura 14: Diagrama caso de uso CU-E01: Ver lista componentes equipo ......................................... 64 Figura 15: Diagrama caso de uso CU-E02: Ver datos individuales jugador ........................................ 65 Figura 16: Diagrama caso de uso CU-E03: Crear nueva convocatoria ............................................... 65 Figura 17: Diagrama caso de uso CU-E05: Consultar convocatorias equipo ...................................... 66 Figura 18: Diagrama caso de uso CU-E06: Insertar asistencia........................................................... 66 Figura 19: Diagrama caso de uso CU-E07: Abandonar equipo (rol ENT) ........................................... 67 Figura 20: Diagrama caso de uso CU-J01: Modificar datos deportivos ............................................. 67 Figura 21: Diagrama caso de uso CU-J02: Consultar asistencia ........................................................ 68 Figura 22: Diagrama caso de uso CU-J03: Consultar convocatorias jugador ..................................... 68 Figura 23: Diagrama caso de uso CU-J05: Abandonar equipo (rol JUG) ............................................ 69 Figura 24: Diagrama modelo de dominio (Análisis) ........................................................................ 70 Figura 25: Diagrama modelo de dominio (Análisis) ........................................................................ 75 Figura 26: Esquema del modelo MVC (Model View Controler) ......................................................... 79 Figura 27: Esquema del modelo MVP (Model View Presenter) ........................................................ 80 Figura 28: Esquema del patrón DAO (Data Access Object) .............................................................. 81 Figura 29: Diagrama de secuencia del patrón DAO (Data Access Object) ......................................... 81 Figura 30: Diagrama de clases del patrón DAO ............................................................................... 82 Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 17 Capítulo 1. Introducción 18 1.2. Contexto La motivación de este proyecto está estrechamente relacionada con la irrupción masiva del deporte en nuestra sociedad. Cada vez son más las tecnologías que se ponen a disposición de los deportistas de alto rendimiento, permitiéndoles llevar su cuerpo al límite con un alto grado de control, prestando atención a factores como el riesgo de lesión, la carga de trabajo o los picos de forma asociados al volumen de entrenamiento. En los últimos años estas herramientas también han llegado a la vida de los deportistas anónimos, siendo hoy día habitual que muchos deportistas no profesionales utilicen herramientas como pulsómetros y monitoricen sus entrenamientos gracias a las aplicaciones asociadas a estas. Muchas de las herramientas anteriormente mencionadas ya están incluidas en el trabajo diario de los primeros equipos de muchos clubes, proporcionando información valiosa a sus cuerpos técnicos que les permiten ajustar la programación dependiendo de los valores registrados. Sin embargo, las prestaciones de estas aplicaciones se escapan, en muchas ocasiones, del alcance de equipos amateur, que no cuentan con los medios técnicos ni humanos para hacer uso de estas “sofisticadas” herramientas. En el deporte base encontramos entrenadores altamente dedicados, que sin embargo no se dedican profesionalmente a esta tarea, lo que acaba generándoles algunas limitaciones. Uno de los problemas más importantes viene derivado del almacenamiento de la información, ya que a lo largo de la temporada se generan gran cantidad de datos que en muchas ocasiones acaba dispersa por distintos dispositivos, cuadernos… haciendo difícil el acceso a la misma, perdiéndola, o simplemente infrautilizando los datos recopilados. Por otro lado, los jugadores en muchas ocasiones no cuentan con información actualizada sobre los acontecimientos o se ven obligados a rellenar infinitas veces a lo largo de una temporada hojas con datos que ya se le habían solicitado antes, generando duplicados de información. De la unión de estos dos problemas de almacenamiento y consulta de información nace la idea de este proyecto. El contexto de este proyecto tiene como finalidad servir de Trabajo Fin de grado del Grado de Ingeniería informática. A lo largo de este documento se recoge toda la información relacionada con las distintas fases de desarrollo llevadas a cabo, así como un manual de usuario de la aplicación elaborada. 1.3. Motivación Desde pequeña siempre he estado relacionada con el deporte, a los 10 años comencé a jugar a balonmano y pocos años después comencé mi andadura como entrenadora. En estos últimos 10 años me he formado como entrenadora en diversos cursos, he continuado entrenando equipos y he formado parte del equipo técnico de distintas selecciones territoriales. Con el paso del tiempo he echado en falta aplicaciones dirigidas a equipos no profesionales. Cansada de utilizar infinitas hojas de cálculo para almacenar datos, enviar WhatsApp por los grupos del equipo solicitando información a mis jugadores y crear programaciones en documentos PDF que acababan acumulando cuantiosas versiones dadas las constantes modificaciones que surgen; había llegado el momento de trabajar en una aplicación que pudiera adaptarse y dar respuesta a estos equipos “no profesionales”, facilitando la vida a entrenadores y jugadores para los que el deporte es un hobby y no un trabajo. El principal objetivo al empezar a desarrollar esta aplicación es simplificar la vida de entrenadores y jugadores, haciendo que puedan disfrutar plenamente de la práctica deportiva. Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 19 1.4. Objetivos El objetivo principal de este proyecto es conseguir una aplicación Android que permita almacenar los datos deportivos de los jugadores, así como los datos correspondientes a la asistencia y las citaciones a entrenamientos y partidos, entre otros. Además, la aplicación permitirá consultar la información introducida desde distintas perspectivas. Objetivos de la aplicación • Ser fácilmente utilizable por jugadores y entrenadores. • Crear, almacenar y mostrar convocatorias • Introducir, almacenar y mostrar datos de los jugadores al entrenador del equipo • Mostrar la asistencia de cada jugador y del equipo en general • Almacenar valores correspondientes a distintos test físicos • Ser compatible con la mayoría de los dispositivos Android • Diseñar una interfaz gráfica agradable y sencilla de entender y utilizar Objetivos de la formación • Desarrollar una aplicación para dispositivos móviles. • Utilizar almacenamiento persistente para los datos. • Lograr que la aplicación desarrollada cumpla con los requisitos de funcionalidad y diseño establecidos. • Elaborar una memoria que detalle todo el proceso de realización de la aplicación, desde el análisis inicial hasta las pruebas finales, las conclusiones y las futuras mejoras que se pueden llevar a cabo. • Generar un manual de usuario y una guía de instalación. 1.5. Estado de la cuestión Para llevar a cabo esta aplicación se han analizado otras aplicaciones ya existentes en el mercado que pretenden cubrir alguno de los objetivos propuestos. En el análisis se ha pretendido conocer el funcionamiento de cada una de ellas y conocer aquellos aspectos deseables y aquellos puntos de mejora que se han podido detectar. Tras un cribado previo hemos detectado que muchas aplicaciones cubren de manera extensa un único aspecto de los que se desea incluir, permitiendo realizar gran cantidad de operaciones centradas en este. A continuación se muestra el análisis de algunas aplicaciones que comparten parte de los objetivos con nuestro proyecto: 20 miSquad Según la descripción que encontramos en la AppStore, “miSquad Entrenadores es la aplicación para la gestión de los equipos por parte de los entrenadores. Podrás acceder a las fichas de tu equipo, presentar los trípticos para cada competición, cambiar las distintas equipaciones, contactar con tus jugadores y gestionar la alineación de cada partido.” Figura 01: Capturas de pantalla de la aplicación miSquad Tras utilizar la aplicación hemos visto que: • Cuenta con varias interfaces según el rol (entrenador, jugador, arbitro, clubes…) • Actualmente es usada por las federaciones de balonmano para la gestión de todas las licencias y organización de competiciones oficiales. • Dispone de aplicación de escritorio y su homónima “mobile-friendly” • Bastante compleja y confusa de usar. • Aún se encuentra en desarrollo. Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 21 MindPro Según la descripción que encontramos en la AppStore, “Herramienta de ayuda a la planificación de la carga de entrenamiento mediante el reporte de los efectos fisiológicos en el deportista, utilizando cuestionarios intuitivos...” “Tiene un apartado para el seguimiento de equipos, siendo el deportista quien tiene total control sobre sus datos. El entrenador/responsable del equipo puede visualizar medias, tendencias…” La valoración de esta aplicación es, en general, bastante positiva por parte de los usuarios (4,4/5) Figura 02: Capturas de pantalla de la aplicación MindPro Tras utilizar la aplicación hemos visto que: • La aplicación esta únicamente orientada a la planificación y el análisis de la carga de entrenamiento y desarrollo de la fortaleza mental. • Muy completa. Realiza un análisis complejo con los numerosos datos introducidos por parte de los usuarios. • La cantidad de parámetros a introducir y el análisis generado resulta extremadamente complejo de asumir por parte de deportistas y entrenadores amateur. • Algunos usuarios reportan problemas a la hora de crear equipos. 22 Ejercicios de balonmano base Según la descripción que encontramos en la AppStore, “aplicación de consulta con más de 200 ejercicios de entrenamiento.” “Los ejercicios se encuentran clasificados por edad y categoría” “Cada ficha contiene un gráfico en movimiento que facilita la comprensión de este. A su vez incluye diferente información complementaria” A la vista de los comentarios y puntuaciones registradas en la AppStore, podemos decir que los usuarios se muestran muy conformes con el funcionamiento y el contenido de la aplicación. Figura 03: Capturas de pantalla de la aplicación Ejercicios de balonmano base Tras utilizar la aplicación hemos visto que: • La aplicación únicamente lista más de 200 ejercicios orientados a la práctica del balonmano. • La aplicación funciona sin ningún tipo de “login”, podemos decir que se trata de una “enciclopedia digital” de ejercicios de balonmano. • No permite la interacción entre usuarios. • Una de las críticas más repetidas es que la aplicación no cuenta con sección de favoritos, permitiendo así que cada usuario pueda almacenar aquellos ejercicios que más le interesen. • La interfaz es sencilla y amigable, siendo muy fácil y cómoda de utilizar. Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 23 Pasalista Según la descripción que encontramos en la AppStore, “Pasalista te permite llevar el control de asistencia y evaluaciones de tus grupos escolares…” “Pasalista también te permite acceder a las estadísticas de todos y cada uno de tus alumnos dentro del rango de fechas que selecciones.” “Con la versión gratuita puedes generar un máximo de 2 grupos. Si deseas crear más grupos debes adquirir la versión Premium, la cual libera a tu aplicación de toda restricción y elimina el contenido publicitario. Este pago es único y para siempre.” Los comentarios y puntuaciones registrados en la AppStore son muy positivos (4,5/5), además el servicio técnico se muestra muy accesible, respondiendo a la mayoría de las dudas planteadas en los comentarios. Tras utilizar la aplicación hemos visto que: • La aplicación está muy orientada al ámbito docente. • Ofrece la posibilidad de gestionar la asistencia, pero el resto de las funcionalidades se encuentran alejadas del ámbito deportivo. • Entre las sugerencias de mejora hemos encontrado la posibilidad de que los datos sean compartidos entre varios profesores. 1.6. Terminología utilizada Dado que la aplicación está pensada para utilizarse en el ámbito deportivo durante el desarrollo de esta se utilizará terminología especifica de este ámbito. Para ayudar a la comprensión de la aplicación a continuación se detallan algunos de los términos utilizados que pueden generar confusión. • Convocatoria: Citación para que un grupo de jugadores acudan a alguna actividad programada para el equipo (entrenamiento o partido) o Entrenamiento: sesión dedicada a la práctica y formación del deportista individualmente y del equipo o Partido: Evento deportivo en el que se enfrentan dos equipos • Sesión: Conjunto de ejercicios que se realizan en un entrenamiento determinado • Ejercicio: Cada una de las partes que componen una sesión 24 1.7. Estructura de la memoria La memoria se organizará conforme a los siguientes apartados: Capítulo 1: Introducción Ofrece una visión general sobre la aplicación que se pretende desarrollar, analizando además otras aplicaciones similares ya existentes. Capítulo 2: Requisitos Esta fase nos presenta todos los requisitos de la aplicación y las restricciones asociadas. Capítulo 3: Plan de proyecto En este capítulo se incluye toda la planificación del proyecto. Se describe la metodología utilizada en el proceso de desarrollo, se muestra la calendarización, las tareas a realizar, los riesgos existentes y el presupuesto. Capítulo 4: Análisis Esta fase nos presenta una descripción detallada del modelo de usuario y el modelo de dominio, el diagrama de casos de uso y la descripción detallada de estos. Capítulo 5: Diseño Esta fase nos mostrara la adaptación de los diagramas presentados en la fase de análisis de cara a su implementación. Además, incluirá la arquitectura del sistema, los patrones de desarrollo utilizados y algunos diagramas de diseño de caso de uso Capítulo 6: Implementación En este capítulo se abordará la implementación de la base de datos, se profundizará sobre el entorno de desarrollo elegido y se explicaran con mayor detalles algunos de los patrones utilizados. Además, se mencionarán algunos problemas que ha habido que enfrentar para sacar adelante la aplicación. Capítulo 7: Plan de pruebas y evaluación Se incluirá una breve descripción de las pruebas realizadas, así como los resultados obtenidos. También se verificarán los casos de error que la aplicación contempla. Capítulo 8: Conclusiones y trabajo futuro Esta sección pretende servir de valoración del trabajo realizado y mencionar aquellos aprendizajes que se han obtenido con la realización del proyecto desde un punto de vista personal. Además, hace mención de las líneas de trabajo que han quedado abiertas. Bibliografía Este capítulo muestra las referencias que han sido consultadas a lo largo del proyecto Anexos En esta sección se encuentran los manuales de la aplicación y otros documentos de interés que no tienen cabida en los capítulos anteriores Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 25 Capítulo 2: Requisitos 32 3.1. Resumen del proyecto Propósito, alcance y objetivos El propósito es conseguir una aplicación móvil dirigida a entrenadores y jugadores, principalmente de balonmano, pero adaptable a cualquier deporte de equipo. El objetivo principal es que el entrenador pueda registrar las convocatorias de su equipo y acceder a los datos (personales, deportivos y físicos) de aquellos jugadores dados de alta en el equipo. La aplicación también permitirá a los jugadores consultar las convocatorias asociadas a su equipo e introducir sus datos personales. Artefactos del proyecto Mas adelante se describe la metodología UPEDU (Proceso Unificado orientado al entorno educativo). Para la utilización de esta se necesita el desarrollo de los siguientes artefactos: • Plan de desarrollo de software • Requisitos • Análisis • Diseño • Implementación • Test Evolución del plan La presente memoria recoge el plan de desarrollo del proyecto. El plan se ira actualizando a medida que se completen las tareas asociadas a cada fase, además contara con una calendarización y la duración estimada asociada a cada tarea. Asimismo, el plan permitirá llevar a cabo un seguimiento de cada tarea; controlando factores como el tiempo de trabajo consumido por cada una, los riesgos asociados y, por ende, un plan de actuación para paliar los efectos de que alguno de estos riesgos se acabe materializando. 3.2. Metodología de gestión del proyecto Dada la duración y el ámbito de desarrollo del proyecto se ha decidido utilizar la metodología UPEDU (Proceso Unificado para Educación). La metodología UPEDU [3] es una simplificación del enfoque RUP 2000 (Proceso Racional Unificado) desarrollado por IBM, que proporciona pautas orientadas al desarrollo de un proyecto software de ámbito académico. Esta metodología define 4 fases que se desarrollan de manera iterativa: • Inicio • Elaboración • Construcción • Transición Al final de cada fase se obtienen entidades concretas y tangibles denominadas artefactos. Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 33 Ciclo de vida del proyecto A continuación se describen las fases del proyecto [4]: Figura 04: fases de la metodología UPEDU Fase de inicio En esta fase se busca conocer en detalle el problema a abordar, su ámbito y las tecnologías que se utilizaran. Se llevan a cabo las actividades de modelado de negocios, definición de requisitos, eliminación de riesgos críticos asociados a la implementación y se comienza a establecer la base de la arquitectura a utilizar. Fase de elaboración Se inicia la implementación de la arquitectura a utilizar. Los desarrolladores comienzan a enfrentar los requisitos anteriormente modelados, buscando combinar las peticiones del cliente con una solución informática. Fase de construcción Se comienza a implementar la solución conseguida en la fase anterior. Se llevan a cabo múltiples iteraciones, en las que se van introduciendo cambios o nuevos requisitos a medida que avanza el desarrollo. Fase de transición Esta fase es utilizada para realizar pruebas y garantizar que se tiene un producto preparado para ser entregado al cliente y funcional para sus usuarios objetivo. 34 Plan de trabajo A continuación, se describirán las tareas a desarrollar en cada una de las fases mencionadas anteriormente en la metodología de gestión del proyecto. Del mismo modo se procederá a su calendarización. Por comodidad se tomará la semana como unidad de referencia temporal. Fase Inicio Semana Fechas Tarea S1 5 oct 11 oct Búsqueda de información sobre la metodología de gestión (UPEDU) Análisis de requisitos iniciales S2 12 oct 18 oct Definición de las fases Calendarización Elaboración del documento de seguimiento S3 19 oct 25 oct Gestión de riesgos Cálculo de presupuestos y costes Preparar entorno y herramientas Tabla 08: Fase inicio Fase elaboración Semana Fechas Tarea S4 26 oct 1 nov Especificación detallada de requisitos Modelo de casos de uso S5 2 nov 8 nov Especificación completa de los casos de uso Diagramas casos de uso (Análisis) S6 9 nov 15 nov Modelo de dominio Diseño de la interfaz de usuario S7 16 nov 22 nov Diseño de la interfaz de usuario Pruebas con usuarios S8 23 nov 29 nov Investigación de la BD Diseño de la base de datos S9 30 nov 6 dic Investigación de las tecnologías a utilizar Investigación de las herramientas a utilizar S10 7 dic 13 dic Diseño de la arquitectura de la aplicación Diagrama de clases de diseño Tabla 09: Fase elaboración Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 35 Fase construcción Semana Fechas Tarea S11 14 dic 20 dic Diseño vistas “Entrenador” S12 21 dic 27 dic NAVIDAD S13 28 dic 3 ene NAVIDAD S14 4 ene 10 ene Diseño vistas “Jugador” S15 11 ene 17 ene Implementar casos de uso S16 18 ene 24 ene S17 25 ene 31 ene S18 1 feb 7 feb S19 8 feb 14 feb S20 15 feb 21 feb Tabla 10: Fase construcción Fase transición Semana Fechas Tarea S21 22 feb 28 feb Pruebas de la aplicación S21 1 mar 7 mar Elaborar manual de instalación Elaborar manual usuario S23 8 mar 14 mar Finalizar memoria proyecto Tabla 11: Fase transición 36 Plan de gestión de riesgos La gestión de riesgos es el proceso de valorar y controlar los riesgos que afectan al proyecto. Este proceso busca identificar los problemas que pueden ocurrir durante el desarrollo del proyecto y planificar qué medidas se tomaran en caso de producirse. Para llevar a cabo este proceso se realizan las siguientes tareas: 1. Identificar los posibles riesgos 2. Analizar la probabilidad de ocurrencia y el impacto de cada riesgo. 3. Elaborar el plan de actuación en caso de producirse algún riesgo 4. Realizar un seguimiento de los indicadores de riesgo a lo largo del desarrollo del proyecto. Este seguimiento pretende anticiparse a la ocurrencia de los riegos, y así, tomar las medidas necesarias con la mayor antelación posible. La tabla 12 muestra la exposición al riesgo en función de su impacto y su probabilidad de ocurrencia: p≥81% 80%≤p<60% 60%≤p<40% 40%≤p<20% p≤20% Catastrófico Alto Alto Moderado Moderado Bajo Crítico Alto Alto Moderado Bajo - Marginal Moderado Moderado Bajo - - Despreciable Moderado Bajo Bajo - - Tabla 12: Exposición al riesgo según impacto y probabilidad de ocurrencia Una vez identificados los riesgos y el grado de exposición, se procede a generar los planes de contingencia respectivos, prestando especial atención a aquellos con una alta exposición. Análisis de riesgos Las siguientes tablas recogen el análisis en profundidad de los riesgos identificados para el proyecto y los posibles planes de mitigación y contingencia asociados: R01 – Fallo en la planificación Descripción Los tiempos estimados en la planificación no son sufrientes para desarrollar las tareas, lo que se retrasa la ejecución del proyecto sobre la calendarización establecida Impacto Crítico Probabilidad 50% Exposición Moderada Plan de mitigación Analizar las tareas con la mayor precisión posible. Desarrollar las tareas cumpliendo con los plazos de tiempo establecidos en la planificación. Plan de contingencia Priorizar las tareas a desarrollar Realizar los cambios pertinentes en la planificación Replanificar la calendarización teniendo en cuenta el tiempo perdido con el fin de minimizar su impacto final Tabla 13: R01 – Riesgo de fallo en la planificación Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 37 R02 – Indisponibilidad del desarrollador Descripción El desarrollador no puede dedicar el tiempo suficiente a sus tareas, provocando una demora en los tiempos inicialmente planificados Impacto Crítico Probabilidad 65% Exposición Alto Plan de mitigación Planificar incluyendo un margen de seguridad teniendo en cuenta los factores controlables. Cumplir con la calendarización Plan de contingencia Replanificar las tareas, solapando algunas si fuera posible. Dedicar tiempo a mayores del inicialmente previsto Tabla 14: R02 – Riesgo de indisponibilidad del desarrollador R03 – Indisponibilidad del tutor Descripción El tutor no puede dedicar el tiempo suficiente a sus tareas, provocando una demora en los tiempos inicialmente planificados Impacto Crítico Probabilidad 25% Exposición Bajo Plan de mitigación Planificar incluyendo un margen de seguridad Cumplir con los tiempos planificados y las entregas establecidas Plan de contingencia Replanificar las tareas, solapando algunas si fuera posible. Tabla 15: R03 – Riesgo de indisponibilidad del tutor R04 – Problemas de comunicación Descripción Problemas y demoras asociadas a la comunicación entre el desarrollador y el tutor que frenan o detienen el avance del proyecto Impacto Crítico Probabilidad 50% Exposición Moderado Plan de mitigación Mantener contacto periódico Conocer los periodos en los que la comunicación entre ambos no será posible y planificar con antelación y detalle las tareas asociadas Plan de contingencia Replanificar las tareas, solapando algunas si fuera posible. Dedicar tiempo a mayores del inicialmente previsto Tabla 16: R04 – Riesgo de problemas de comunicación 38 R05 – Enfermedad Descripción No se cumple con el trabajo establecido o este avanza a menor ritmo debido a enfermedad o motivos personales del desarrollador. Impacto Marginal Probabilidad 30% Exposición Ninguno Plan de mitigación Planificar incluyendo un margen de seguridad. Cumplir con la calendarización Plan de contingencia Replanificar las tareas, solapando algunas si fuera posible. Dedicar tiempo a mayores del inicialmente previsto Tabla 17: R05 – Riesgo de enfermedad R06 – Perdida de información Descripción Se produce la pérdida de algún documento o de datos ya generados, lo que se traduce en una pérdida de tiempo empleado en el desarrollo del proyecto Impacto Catastrófico Probabilidad 10% Exposición Bajo Plan de mitigación Realizar copias de seguridad en la nube cada vez que se genere algún documento o se avance en el desarrollo del proyecto Plan de contingencia Evaluar el alcance de la perdida y replanificar en consecuencia Tabla 18: R06 – Riesgo de pérdida de información R07 – Fallo en la máquina Descripción Avería del hardware o software utilizado para el desarrollo producida por causas naturales Impacto Crítico Probabilidad 25% Exposición Bajo Plan de mitigación Cuidar el hardware y el software utilizado Atender a las posibles anomalías que vayan surgiendo y llevar un control temprano y riguroso de las mismas Plan de contingencia Arreglar el hardware y recuperar el entorno Obtener un nuevo hardware, montar nuevamente el entorno y recuperar la información de las copias de seguridad Tabla 19: R07 – Riesgo de fallo en la máquina Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 39 R08 – Curva de aprendizaje demasiado larga Descripción El tiempo planificado para investigar y aprender sobre las tecnologías y herramientas a utilizar no es suficiente para dominarlas al nivel que requiere el desarrollo de la aplicación Impacto Crítico Probabilidad 50% Exposición Moderado Plan de mitigación Realizar una investigación de las tecnologías antes de establecer el tiempo necesario para el aprendizaje Ir adelantando la investigación Plan de contingencia Replanificar las tareas y priorizar, solapando algunas si fuera posible. Dedicar tiempo a mayores del inicialmente previsto Tabla 20: R08 – Riesgo de curva de aprendizaje demasiado larga R09 – Mala elección de las tecnologías a utilizar Descripción Las tecnologías seleccionadas no permiten llevar a cabo los requisitos especificados Impacto Catastrófico Probabilidad 15% Exposición Bajo Plan de mitigación Estudiar concienzudamente las posibilidades que ofrecen las tecnologías antes de incluirlas en el proyecto Plan de contingencia Buscar una tecnología sustitutiva, que permita desarrollar los objetivos. Rehacer la calendarización del proyecto, adaptándose a las necesidades que provoque la nueva tecnología escogida (aprendizaje, desarrollo, integración…) Tabla 21: R09 – Riesgo de mala elección de las tecnologías a utilizar R10 – Fallos en la elaboración del diseño Descripción El diseño elaborado inicialmente no se ajusta a los requisitos deseados para el proyecto Impacto Crítico Probabilidad 45% Exposición Moderado Plan de mitigación Comprender cada requisito completamente antes de comenzar su implementación Plan de contingencia Corregir el error y replanificar las tareas Tabla 22: R10 – Riesgo de fallos en la elaboración del diseño 40 R11 – Modificación de los requisitos Descripción Durante el desarrollo del proyecto se encuentran requisitos que no han sido tenidos en cuenta en el análisis inicial Impacto Crítico Probabilidad 20% Exposición Bajo Plan de mitigación Trabajar siempre en base al análisis de requisitos. Identificar y resolver los conflictos en las primeras etapas del proyecto Al tratarse de un proyecto libre, tener claros los requisitos desde el comienzo. Plan de contingencia Evaluar el impacto del nuevo requisito en el desarrollo Replanificar las tareas y priorizar Tabla 23: R11 – Riesgo de modificación de los requisitos Presupuesto En esta sección se detalla el presupuesto estimado del proyecto, teniendo en cuenta todos los recursos necesarios para su desarrollo. Recursos de personal El proyecto será llevado a cabo por una única persona (el alumno), que ira desempañando diferentes roles a lo largo del mismo. Estos roles serán: • Cliente • Jefe de proyecto • Diseñador • Android developer • Probador Recursos materiales Para llevar a cabo el proyecto será imprescindible contar con los siguientes recursos materiales: • Equipos ▪ Telefono Android ▪ Ordenador portátil • Herramientas ▪ Astah UML ▪ Balsamiq ▪ Google Drive ▪ Microsoft Office 365 ▪ GitLab ▪ Android Studio ▪ SQLite ▪ Visual Studio Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 41 • Material de oficina • Lugar de trabajo ▪ Residencia del alumno • Servicios ▪ Conexión a Internet ▪ Conexión a la red eléctrica Estimación de costes reales del proyecto Dado que el ámbito del proyecto es la realización de un TFG y no se considera la posibilidad de invertir dinero en la realización de este, los costes van a ser nulos. Para que esto sea posible ha de tenerse en cuenta que: • Las herramientas que se utilicen serán de libre distribución o se utilizara la licencia proporcionada por la UVa. • Los servicios de red e internet que se utilizarán normalmente serán los existentes en el domicilio del alumno, de los que ya se disponía antes del comienzo del proyecto. También se usarán conexiones presentes en otros lugares (Escuela, Biblioteca…), todas ellas con coste cero. • Los equipos y materiales no informáticos no supondrán un coste, ya que se disponía de ellos antes de comenzar a desarrollar el proyecto. Simulación de un proyecto real En el siguiente apartado vamos a plantear una simulación como si este proyecto no fuera un TFG, si no un proyecto real que va a ser llevado a cabo por una empresa. Tomaremos como referencia una duración de proyecto aproximada de 300h., lo que en nuestro caso tomaremos una como 2 meses de trabajo a jornada completa (suponiendo que en cada mes hay una media de 20 días laborables). Para calcular los costes de personal contaremos con los servicios de un desarrollador Android, atendiendo a la media salarial para cada grupo profesional en España, el coste de este trabajador ascenderá a 10€/hora. Respecto a los costes materiales deberemos tener en cuenta la amortización de estos a lo largo del proyecto, ya que la inversión en dispositivos informáticos o servicios como el Internet no será únicamente para este proyecto. Sumando los costes humanos estimados y los costes de recursos materiales (teniendo en cuenta la amortización de estos en el tiempo), calcularemos el coste total estimado para llevar a cabo el proyecto. 48 4.2.3. Jugador Figura 07: Diagrama de casos de uso: Jugador Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 49 4.3. Casos de uso En las tablas que se muestran a continuación se recogen los casos de uso existentes en la aplicación. Estos representan las acciones que puede realizar el usuario en la aplicación. 4.3.1. Tabla de casos de uso Tabla 25: Requisitos casos de uso ID Nombre del caso de uso Prioridad USUARIO CU-U01 Iniciar sesión ALTA CU-U02 Cerrar sesión ALTA CU-U03 Registrarse ALTA CU-U04 Modificar datos personales ALTA EQUIPO CU-EQ01 Registrar nuevo equipo ALTA CU-EQ02 Unirse a un equipo ALTA ROL ENTRENADOR CU-E01 Ver lista de componentes del equipo ALTA CU-E02 Ver datos individuales jugador ALTA CU-E03 Crear nueva convocatoria ALTA CU-E04 Eliminar convocatoria MEDIA CU-E05 Consultar sus convocatorias equipo ALTA CU-E06 Insertar datos asistencia MEDIA CU-E07 Abandonar equipo MEDIA ROL JUGADOR CU-J01 Modificar datos deportivos ALTA CU-J02 Consultar su asistencia MEDIA CU-J03 Consultar sus convocatorias ALTA CU-J04 Insertar datos test físicos BAJA CU-J05 Abandonar equipo MEDIA 50 4.3.2. Descripción de los casos de uso Usuario CU-U01 INCIAR SESIÓN Versión 1.0 Descripción El actor “Usuario” inicia sesión en la aplicación Actores Todos los usuarios Dependencias Precondición El usuario deberá estar previamente registrado y haber accedido a la aplicación Secuencia Normal Paso Acción 1 El actor “Usuario” introduce usuario y contraseña 2 El sistema comprueba que ambos campos han sido completados correctamente y muestra la página principal del usuario Postcondición El usuario que ha iniciado sesión ve la página principal asociada al su rol en la aplicación (jugador o entrenador) Excepciones Paso Acción 1a El actor “Usuario” decide no continuar y el caso de uso queda sin efecto 2a El sistema detecta que los campos no se han introducido correctamente, muestra el error y el caso de uso vuelve al paso 1 2b El sistema detecta que el usuario introducido no tiene asociado un equipo. Según el rol del usuario: • Entrenador: Se ejecuta el CU-EQ01 (registrar nuevo equipo) desde el paso 2 • Jugador: Se ejecuta el CU-EQ02 (unirse a un equipo) desde el paso 2 Comentarios Tabla 26: CU-U01 Caso de uso “Iniciar Sesión” CU-U02 CERRAR SESIÓN Versión 1.0 Descripción El actor “Usuario” cierra su sesión en la aplicación Actores Todos los usuarios Dependencias Precondición El usuario debe estar previamente registrado y haber iniciado sesión. Secuencia Normal Paso Acción 1 El actor “Usuario” elige la opción “Cerrar sesión” 2 El sistema desconecta al “Usuario”, eliminando su autenticación e imposibilitando el acceso a la aplicación si no vuelve a iniciar sesión Postcondición Excepciones Paso Acción Comentarios Tabla 27: CU-U02 Caso de uso “Cerrar Sesión” Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 51 CU-U03 REGISTRARSE Versión 1.0 Descripción El actor “Usuario” crea una cuenta en la aplicación Actores Todos los usuarios Dependencias Precondición Secuencia Normal Paso Acción 1 El actor “Usuario” elige la opción “Registrarse” 2 El sistema muestra un mensaje avisando de las condiciones de uso de la aplicación (LOPD) 3 El actor “Usuario” acepta las condiciones de uso 4 El sistema muestra un formulario con los campos necesarios para registrarse: • Nombre • Apellidos • Fecha Nacimiento • D.N.I. • Teléfono • Correo electrónico • User • Contraseña • Comprobar contraseña 5 El actor “Usuario” completa los campos 6 El sistema comprueba que los campos han sido rellenados correctamente y muestra un nuevo formulario para seleccionar el rol que desea desempeñar en la aplicación 7 El actor “Usuario” selecciona una de las dos opciones 8a Si el actor “Usuario” selecciona el rol entrenador (CU-EQ01): El sistema muestra un formulario que permite crear un equipo: • Nombre del equipo • Código equipo (dado por el sistema) 8b Si el actor “Usuario” selecciona el rol jugador (CU-EQ02): El sistema muestra un formulario que permite unirse a un equipo: • Código del equipo Postcondición El usuario queda registrado en el sistema y asociado a un equipo Excepciones Paso Acción 2a El actor “Usuario” no acepta las condiciones, el sistema no permite el registro y el caso de uso queda sin efecto 5a El actor “Usuario” decide no continuar y el caso de uso queda sin efecto 6a El sistema detecta que alguno de los campos no se ha introducido correctamente, muestra el mensaje de error asociado y el caso de uso vuelve al paso 3 6b El sistema detecta que el “user” introducido ya ha sido utilizado, muestra esta información y el caso de uso continua en el paso 3 7 El actor “Usuario” decide no continuar y el caso de uso queda sin efecto Comentarios Tabla 28: CU-U03 Caso de uso “Registrarse” 52 CU-U04 MODIFICAR DATOS PERSONALES Versión 1.0 Descripción El actor “Usuario” desea modificar sus datos en el sistema. Actores Todos los usuarios Dependencias Precondición El usuario debe estar previamente registrado y haber iniciado sesión. Secuencia Normal Paso Acción 1 El actor “Usuario” elige la opción “Mi perfil” en el desplegable superior derecho 2 El sistema muestra un formulario con los datos del usuario prellenados: • Nombre • Apellidos • Fecha Nacimiento • D.N.I. • Teléfono • Correo electrónico • Contraseña • Comprobar contraseña 3 El actor “Usuario” modifica los campos que desee 4 El sistema comprueba que los campos han sido rellenados correctamente y modifica los datos en la aplicación Postcondición Los campos se registran en el sistema Excepciones Paso Acción 3a El actor “Usuario” decide no continuar y el caso de uso queda sin efecto 4a El sistema detecta que los campos no se han introducido correctamente, muestra el mensaje de error asociado y el caso de uso vuelve al paso 3 Comentarios Tabla 29: CU-U04 Caso de uso “Modificar Datos Personales” Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 53 Equipo CU-EQ01 REGISTRAR NUEVO EQUIPO Versión 1.0 Descripción El actor “Usuario Entrenador” registra un nuevo equipo en el sistema Actores Usuario Entrenador Dependencias CU-U03 Precondición El usuario deberá haber completado los dos primeros pasos del registro Secuencia Normal Paso Acción 1 Se ejecuta el caso de uso “Registrarse” (Rol: entrenador) 2 El actor “Usuario Entrenador” completa el campo con el nombre del equipo 3 El sistema comprueba que el campo ha sido rellenado correctamente y registra el nuevo equipo en el sistema Postcondición El equipo queda registrado en el sistema Excepciones Paso Acción 1a El actor “Usuario Entrenador” abandona un equipo 2a El actor “Usuario Entrenador” decide no continuar y el caso de uso queda sin efecto 3a El sistema detecta que el “Nombre de equipo” introducido ya ha sido utilizado, muestra esta información y el caso de uso continua en el paso 2 Comentarios Tabla 30: CU-EQ01 Caso de uso “Registrar Nuevo Equipo” CU-EQ02 UNIRSE A UN EQUIPO Versión 1.0 Descripción El actor “Usuario Jugador” se une a un equipo ya existente en el sistema Actores Usuario Jugador Dependencias CU-U03 Precondición El usuario deberá haber completado los dos primeros pasos del registro Secuencia Normal Paso Acción 1 Se ejecuta el caso de uso “Registrarse” (Rol: jugador) 2 El actor “Usuario Jugador” introduce el código del equipo al que desea unirse 3 El sistema comprueba que los campos han sido rellenados correctamente y registra al usuario en el equipo solicitado Postcondición El usuario jugador queda registrado en el equipo Excepciones Paso Acción 1a El actor “Usuario Jugador” abandona un equipo 2a El actor “Usuario Jugador” decide no continuar y el caso de uso queda sin efecto 3a El sistema detecta que el “Código de equipo” introducido no se encuentra en el sistema, muestra esta información y el caso de uso continua en el paso 2 Comentarios Tabla 31: CU-EQ02 Caso de uso “Unirse a un Equipo” 54 Entrenador CU-E01 VER LISTA DE COMPONENTES DEL EQUIPO Versión 1.0 Descripción El actor “Usuario Entrenador” accede a una lista con los jugadores registrados en el equipo, pudiendo ver su asistencia. Actores Usuario Entrenador Dependencias CU-U03 Precondición El usuario debe estar previamente registrado y haber iniciado sesión. Secuencia Normal Paso Acción 1 El actor “Usuario Entrenador” selecciona la opción “Datos Equipo” 2 El sistema le muestra una nueva pantalla de selección 3 El actor “Usuario Entrenador” selecciona la opción “Datos Componentes” 4 El sistema muestra una lista con los jugadores registrados en el equipo y su asistencia Postcondición El usuario entrenador obtendrá una lista de todos jugadores registrados en el equipo. A través de esta podrá consultar los datos de cada jugador de manera individual. Excepciones Paso Acción Comentarios Tabla 32: CU-E01 Caso de uso “Ver Lista de Componentes del Equipo” CU-E02 VER DATOS INDIVIDUALES JUGADOR Versión 1.0 Descripción El actor “Usuario Entrenador” accede a una lista con los jugadores registrados en el equipo. Al seleccionar un jugador accederá a su ficha deportiva. Actores Usuario Entrenador Dependencias CU-U03 Precondición El usuario debe estar previamente registrado y haber iniciado sesión. Secuencia Normal Paso Acción 1 El actor “Usuario Entrenador” ejecuta el CU-E01 (ver componentes equipo) 2 En actor “Usuario Entrenador” selecciona uno de los jugadores de la lista 3 El sistema muestra una ficha con los datos personales y deportivos del jugador Postcondición Excepciones Paso Acción Comentarios Tabla 33: CU-E02 Caso de uso “Ver Datos Individuales Jugador” Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 55 CU-E03 CREAR NUEVA CONVOCATORIA Versión 1.0 Descripción El actor “Usuario Entrenador” podrá crear convocatorias asociadas a su equipo. Actores Usuario Entrenador Dependencias Precondición El usuario debe estar previamente registrado y haber iniciado sesión. Secuencia Normal Paso Acción 1 El actor “Usuario Entrenador” selecciona la opción “Convocatorias” 2 El sistema le muestra una nueva pantalla de selección 3 El actor “Usuario Entrenador” selecciona la opción “Nueva convocatoria” 4 El sistema muestra un formulario con los campos necesarios para crear una nueva convocatoria: • Id • Tipo convocatoria • Fecha y hora convocatoria • Lugar • Rival • Hora partido • Observaciones 5 El actor “Usuario Entrenador” completa los campos 6 El sistema comprueba que todos los campos obligatorios han sido rellenados, almacena la convocatoria y confirma el registro. Postcondición La convocatoria quedara registrada en el sistema y asignada al equipo Excepciones Paso Acción 3a El actor “Usuario Entrenador” decide no continuar y el caso de uso queda sin efecto 5a El actor “Usuario Entrenador” decide no continuar y el caso de uso queda sin efecto Comentarios Tabla 34: CU-E03 Caso de uso “Crear Nueva Convocatoria” CU-E04 CONSULTAR CONVOCATORIAS EQUIPO Versión 1.0 Descripción El actor “Usuario Entrenador” puede revisar las convocatorias ya creadas asociadas a su equipo Actores Usuario Entrenador Dependencias Precondición El usuario debe estar previamente registrado y haber iniciado sesión. Secuencia Normal Paso Acción 1 El actor “Usuario Entrenador” selecciona la opción “Convocatorias” 2 El sistema le muestra una nueva pantalla de selección 3 El actor “Usuario Entrenador” selecciona la opción “Consultar Convocatorias” 4 El sistema muestra una lista con las convocatorias de su equipo Postcondición Excepciones Paso Acción Comentarios Tabla 35: CU-E04 Caso de uso “Consultar Convocatorias Equipo” 56 CU-E05 ELIMINAR CONVOCATORIA Versión 1.0 Descripción El actor “Usuario Entrenador” podrá eliminar una convocatoria que ha creado previamente Actores Usuario Entrenador Dependencias CU-E03 Precondición El usuario debe estar previamente registrado y haber iniciado sesión. El usuario solo puede eliminar las convocatorias creadas por él. Secuencia Normal Paso Acción 1 Se ejecuta el caso de uso “Consultar Convocatorias Equipo” (CU-E04) 2 El actor “Usuario Entrenador” selecciona la convocatoria que desea eliminar 3 El sistema muestra la opción “Eliminar convocatoria” junto con la lista de jugadores convocados 4 El actor “Usuario Entrenador” selecciona la opción “Eliminar convocatoria” 5 El sistema muestra una alerta informativa solicitando confirmación 6 El actor “Usuario Entrenador” confirma que desea eliminar la convocatoria 7 El sistema elimina la convocatoria seleccionada Postcondición La convocatoria eliminada desaparece de la lista de convocatorias para todos los miembros del equipo Excepciones Paso Acción 6a El actor “Usuario Entrenador” decide no continuar y el caso de uso queda sin efecto Comentarios Tabla 36:CU-E05 Caso de uso “Eliminar convocatoria” Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 57 CU-E06 INSERTAR DATOS ASISTENCIA Versión 1.0 Descripción El actor “Usuario Entrenador” podrá modificar el valor de la asistencia para cada jugador en cada convocatoria Actores Usuario Entrenador Dependencias CU-E3 Precondición El usuario debe estar previamente registrado y haber iniciado sesión. Secuencia Normal Paso Acción 1 Se ejecuta el caso de uso “Consultar Convocatorias Equipo” (CU-E04) 2 El actor “Usuario Entrenador” selecciona la convocatoria en la que desea insertar la asistencia 3 El sistema muestra una lista con los jugadores convocados para esa citación 4 El actor “Usuario Entrenador” selecciona el jugador en el que desea introducir su asistencia 5 El sistema muestra un desplegable con los distintos valores correspondientes a la asistencia 6 El actor “Usuario Entrenador” selecciona una de las opciones y pulsa aceptar 7 El sistema registra la asistencia y regresa al paso 3 Postcondición La asistencia quedara registrada en el sistema Excepciones Paso Acción 2a El actor “Usuario Entrenador” decide no continuar y el caso de uso queda sin efecto 6a El actor “Usuario Entrenador” decide no continuar y el caso de uso queda sin efecto Comentarios Tabla 37: CU-U06 Caso de uso “Insertar Datos Asistencia” CU-E07 ABANDONAR EQUIPO (rol entrenador) Versión 1.0 Descripción El actor “Usuario Entrenador” tendrá la posibilidad de abandonar el equipo y crear uno nuevo. Actores Usuario Entrenador Dependencias CU-EQ01 Precondición El usuario debe estar previamente registrado y haber iniciado sesión. Secuencia Normal Paso Acción 1 El actor “Usuario Entrenador” selecciona la opción “Abandonar Equipo” 2 El sistema muestra una alerta informativa que solicita confirmación 3 El actor “Usuario Entrenador” confirma que desea abandonar el equipo 4 El sistema elimina al “Usuario Entrenador” de ese equipo y ejecuta el caso de uso “Cerrar sesión” (CU-U02) Postcondición El entrenador perderá acceso a ese equipo y toda su información de manera permanente. La próxima vez que el usuario inicie sesión se le pedirá cree un nuevo equipo Excepciones Paso Acción 3a El actor “Usuario Entrenador” no confirma y el caso de uso queda sin efecto Comentarios Tabla 38: CU-007 Caso de uso “Abandonar Equipo (rol entrenador)” 64 CU-EQ02 Unirse a un equipo Figura 13: Diagrama caso de uso CU-EQ02: Unirse a un equipo 4.4.3. Entrenador CU-E01 Ver lista componentes equipo Figura 14: Diagrama caso de uso CU-E01: Ver lista componentes equipo Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 65 CU-E02 Ver datos individuales jugador Figura 15: Diagrama caso de uso CU-E02: Ver datos individuales jugador CU-E03 Crear nueva convocatoria Figura 16: Diagrama caso de uso CU-E03: Crear nueva convocatoria 66 CU-E05 Consultar convocatorias equipo Figura 17: Diagrama caso de uso CU-E05: Consultar convocatorias equipo CU-E06 Insertar asistencia Figura 18: Diagrama caso de uso CU-E06: Insertar asistencia Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 67 CU-E07 Abandonar equipo (rol ENT) Figura 19: Diagrama caso de uso CU-E07: Abandonar equipo (rol ENT) 4.4.4. Jugador CU-J01 Modificar datos deportivos Figura 20: Diagrama caso de uso CU-J01: Modificar datos deportivos 68 CU-J02 Consultar asistencia Figura 21: Diagrama caso de uso CU-J02: Consultar asistencia CU-J03 Consultar convocatorias jugador Figura 22: Diagrama caso de uso CU-J03: Consultar convocatorias jugador Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 69 CU-J05 Abandonar equipo (rol JUG) Figura 23: Diagrama caso de uso CU-J05: Abandonar equipo (rol JUG) 70 4.5. Modelado de dominio La Figura 24 muestra el diagrama de clases que representa el modelo conceptual obtenido en la fase de análisis. Este diagrama recoge las principales clases que representarán las entidades que se construirán en la fase de diseño. Además, este diagrama muestra la relación existente entre las distintas entidades. Figura 24: Diagrama modelo de dominio (Análisis) Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 71 Capítulo 5: Diseño 72 5.1. Diseño centrado en el usuario Antes de comenzar a tomar decisiones de diseño hemos prestado especial atención a la usabilidad de la aplicación. Una vez analizada, hemos llevado a cabo un boceto inicial de la interfaz en papel para mostrárselo a los usuarios. El objetivo de estas pruebas es conocer si algunos aspectos de los planteados inicialmente resultan complejos de llevar a cabo o si los usuarios proponen algún cambio que puede ser corregido, mejorado o añadido a la aplicación existente. Valoramos que este paso nos ayudara a llevar a cabo una implementación más exacta, evitando lo máximo posible tener que llevar a cabo cambios una vez se haya realizado la implementación “definitiva”. 5.1.1. Atributos de usabilidad [13] Jakob Nielsen es considerado el padre la usabilidad y define esta como el atributo de calidad que mide lo fáciles de usar que son las interfaces web. Es decir, un sitio web o aplicación usable es aquella en que los usuarios pueden interactuar de la forma más fácil, cómoda, segura e inteligente posible. A continuación, se muestran los 10 principios de Nielsen: 1. Visibilidad del estado del sistema El sistema debe mantener siempre informado al usuario de lo que está ocurriendo. 2. Relación entre el sistema y el mundo real El sitio web o aplicación tiene que utilizar el lenguaje conocido por el usuario. Además, la información debe aparecer en orden lógico. 3. Control y libertad del usuario. En caso de elegir alguna opción por error, el usuario debe poder deshacer o repetir una acción previamente realizada. 4. Consistencia y estándares Es importante establecer convenciones lógicas y mantenerlas en el tiempo. 5. Prevención de errores Ayudar al usuario a que no caiga en un error 6. Reconocimiento antes que recuerdo Debemos evitar que el usuario tenga que recordar información entre distintas secciones o partes de la aplicación 7. Flexibilidad y eficiencia de uso Los atajos de teclado facilitan y hacen más rápida la interacción, especialmente para usuarios expertos. De este modo logramos que la aplicación sea útil tanto para usuarios básicos como avanzados. 8. Estética y diseño minimalista Las paginas no deben contener información irrelevante. 9. Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de errores Los mensajes de error deben mostrarse en lenguaje claro y simple. Indicando siempre que sea posible el problema surgido y una posible solución a este 10. Ayuda y documentación Aunque siempre que se pueda se intentara que la aplicación pueda ser utilizada sin ayuda, puede ser necesario proveer cierto tipo de ayuda. La ayuda debe ser fácil de localizar, muy precisa y no ser muy extensa. Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 73 Teniendo en cuenta estos principios, la aplicación a desarrollar creemos que es importante que incluya: • Ubicación del usuario dentro de la aplicación en cada vista. • La aplicación contará con lenguaje natural (evitando incluir formulaciones que no se usen al hablar o escribir en cualquier otro ámbito). Además, utilizará palabras propias del lenguaje deportivo, siendo esta de fácil comprensión por los usuarios objetivo. • El usuario podrá acceder a su perfil desde cualquier punto de la aplicación. • La aplicación mostrará ventanas emergentes para notificar acciones realmente determinantes en el sistema, pero se evitará abusar de estas, ya que pueden confundir o saturar al usuario. • Se optará por un diseño minimalista, incluyendo en cada pantalla únicamente lo necesario. Respecto la gama cromática, se mantendrá homogénea en toda la aplicación y se buscará que resulte identificativa en cada sección de la aplicación, favoreciendo así el reconocimiento por parte del usuario. • Los mensajes de error mostrado se presentarán en lenguaje comprensible por el usuario y se tratara de ofrecer soluciones al mismo. Por otro lado, se tratará de que sean los menos posibles y su extensión se limite lo máximo posible. • La interacción estará basada en pulsaciones sobre botones. En aquellos casos en los que haya que introducir información, se mostraran desplegables con opciones siempre que sea posible, intentando con ello limitar errores mecanográficos y facilitando la introducción de datos. • El objetivo es que la aplicación sea completamente intuitiva y muestre en pantalla la información necesaria para interactuar. Al finalizar el proyecto se generará un breve manual de usuario en el que a través de imágenes se mostrará el funcionamiento de la aplicación y las distintas posibilidades de uso que esta ofrece. 5.1.2 Bocetaje Utilizamos la herramienta Balsamiq para generar el boceto. Este boceto queda recogido en el anexo “Bocetaje” El boceto generado fue enviado a varios usuarios (jugadores y entrenadores) para que lo testeasen, con el objetivo de obtener su opinión y algunas sugerencias de mejora. 5.1.3. Retroalimentación obtenida La mayoría de los entrenadores se muestran encantados con la idea, ya que creen que la aplicación permitirá tener agrupadas funcionalidades que normalmente se realizan en distintas plataformas no específicas. Además, también ven positivo que su equipo pueda acceder a este tipo de información de manera automática, evitando el “teléfono escacharrado” que se produce al transmitir la información por otras vías, como los grupos de “WhatsApp”. Los jugadores por su parte se muestran ilusionados con la facilidad de acceso a la información en cualquier momento, aunque reconocen que deberán acostumbrarse a utilizar una “app” para esta finalidad. Creen que el proceso de adaptación al uso de la aplicación será sencillo, pero no inmediato, ya que tendrían que familiarizarse con las funcionalidades ofrecidas. Del testeo del boceto dinámico en papel hemos obtenido las siguientes observaciones y sugerencias: 80 Figura 27: Esquema del modelo MVP (Model View Presenter) Las dos diferencias más notables entre ambos modelos son las siguientes: 1. En el MVC el modelo notifica cualquier cambio de su estado a la vista. En MVP la vista no sabe nada del modelo y es el presentador el que comunica a ambos, enlazando los datos contenidos en el modelo con la vista. 2. En el modelo MVC la vista es responsable de manejar las notificaciones del modelo y procesar los datos, lo que hace que su lógica sea más compleja. En MVP esa lógica se encuentra en el presentador y la única función de la vista es representar la información. Capas del patrón MVP • Modelo: Esta capa gestiona los datos. Son las clases denominadas lógica de negocio. Proveerá de datos al presentador y se actualizará con los datos recibidos de este. • Vista: Se encarga de mostrar los datos. • Presentador: Ubicado entre el modelo y la vista, permite conectar la interfaz gráfica con los datos y viceversa. MVP en Android Android no nos ofrece de manera nativa la posibilidad de desarrollar las aplicaciones bajo este patrón, de hecho, viola muchos de sus principios básicos. A pesar de esto, podemos llevar a cabo una aproximación al mismo, haciendo que nuestras aplicaciones sean más robustas, mantenibles y escalables. 5.3.2. Patrón DAO [25] El patrón DAO (Data Access Object) permite separar la lógica de acceso a datos de los objetos de negocio, de manera que el DAO encapsula toda la lógica de acceso de datos al resto de la aplicación. Este patrón propone separar completamente la lógica de negocio de la lógica para acceder a los datos, así el DAO se encargará de proporcionar los métodos necesarios para insertar, actualizar, borrar y consultar la información. De ese modo, la capa de negocio solo se preocupa por la lógica de negocio y utiliza el DAO para comunicarse con la fuente de datos. VISTA MODELO PRESENTADOR Responde Actualiza Actualiza Acciona Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 81 Figura 28: Esquema del patrón DAO (Data Access Object) Componentes de patrón DAO • BussinesObject: Objeto con la lógica de negocio • DataAccesssObject: Capa de acceso a datos. Esta capa oculta los detalles técnicos utilizados para recuperar los datos • TransferObject: Objeto que implementa el patrón Data Transfer Object (DTO), el cual permite transmitir la información entre el DAO y el Bussines Service. • DataSource: representa de forma abstracta la fuente de datos, en nuestro caso la base de datos. En la figura que se muestra a continuación podemos ver de forma secuencial como se ejecuta el patrón DAO: Figura 29: Diagrama de secuencia del patrón DAO (Data Access Object) 82 5.4. Diagrama de clases del patrón DAO La figura que se muestra a continuación muestra el contenido de las clases DAO que forman parte de la aplicación, así como los métodos que contienen cada uno. Figura 30: Diagrama clases del patrón DAO Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 83 Capítulo 6: Implementación 84 Este capítulo describe el proceso de implementación del proyecto. Esta fase consiste en poner en marcha y ejecutar las tareas previstas en la planificación; estas tareas suponen la gestión de los recursos de manera adecuada (en forma y tiempo) y la orientación a la consecución de los objetivos marcados. 6.1. Entorno de desarrollo Para desarrollar el proyecto se ha optado por utilizar el IDE Android Studio. Este IDE es gratuito y de fácil instalación, además ofrece una base de datos integrada y ha sido utilizada en la carrera, por lo que ya conocía su funcionamiento previamente. Para llevar a cabo la documentación se ha utilizado Microsoft Word, apoyado en el editor de texto ofrecido por Google Drive. Por último, para llevar a cabo los distintos diagramas y figuras que se han presentado a lo largo del proyecto, se han utilizado principalmente Astah y draw.io (editor on-line) 6.1.1. Android Studio [26] [27] Android Studio es, desde 2014 cuando reemplazo a ECLIPSE, el entorno de desarrollo integrado oficial para aplicaciones. Diseñado específicamente para el desarrollo de aplicaciones Android cuenta con todas las herramientas necesarias (editor de código, editor de vistas y emulador) para desarrollar una aplicación de principio a fin. Al tratarse del entorno de desarrollo oficial la integración con otras “APIs” y todo lo relativo a la implementación es mucho más sencillo. Otra de las grandes ventajas de este IDE es que desde el primer momento nos encontramos con un proyecto funcional sobre el que trabajar e ir integrando nuevos elementos de formar sencilla hasta conformar la aplicación final. Android Studio es soportado por multitud de sistemas operativos, destacando GNU/Linux, macOS y Microsoft Windows. En nuestro caso hemos desarrollado la aplicación sobre un entorno Windows ya que era el que teníamos en el PC y con qué suponíamos mayores prestaciones. (Cabe mencionar que Android Studio es un IDE altamente demandante de recursos del dispositivo físico para funcionar) Desde 2019 Kotlin es el lenguaje preferido por Google para el desarrollo de aplicaciones, aunque este también se encuentra disponible en Android Studio y cada vez es más utilizado, nuestra aplicación ha sido desarrollada en Java. (Android Studio soporta actualmente Kotlin, Java y C++) Al tratarse de un software libre se encuentra en permanente desarrollo, por lo que cada pocos meses encontramos nuevas actualizaciones. En nuestro caso hemos utilizado la versión de Android Studio 3.5, publicada en agosto de 2019, lo que actualmente la convierte en una versión muy estable, pero nada obsoleta. Otra de las decisiones que nos obliga a tomar el IDE antes de comenzar el desarrollo es la versión de Android para la que queremos desarrollar nuestra aplicación. Esta decisión de diseño es importante, ya que de ella dependerá, entre otras cosas, la cantidad de dispositivos en los que pueda ser ejecutada la aplicación. La aplicación ha sido desarrollada para Android 6.0 (Marshmallow). Esta versión nos ofrece tranquilidad respecto a las prestaciones ofrecidas sin descuidar a los usuarios (se puede utilizar casi en el 85% de los dispositivos Android) Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 85 Figura 31: Distribución API Level Android Studio 5.2. Implementación de la base de datos Como ya hemos mencionado anteriormente la base de datos utilizada ha sido la existente dentro del propio IDE Android Studio. Todas las decisiones de diseño e implementación se encuentran recogidas en el Capítulo 5 (Diseño) en el segundo punto (Diseño almacenamiento persistente) para cualquier consulta. Para llevar a cabo las pruebas pertinentes, dada la idiosincrasia del proyecto que se está llevando a cabo, se ha tratado de poblar la base de datos a través de un Script. Esto no ha sido posible ya que en el momento de ejecución el IDE se quedaba completamente bloqueado, siendo necesario reiniciar el ordenador para poder recuperar el control. Tras varios intentos fallidos e incapaces de conocer el origen del problema para poder solucionarlo, hemos optado añadir varios registros de forma manual a la base de datos. La estructura de las sentencias utilizadas para poblar cada una de las tablas es la que se muestra a continuación: "INSERT OR REPLACE INTO usuario VALUES ('1', 'alba', '1albaAA', '1', 'Alba', 'Álvarez Asenjo', '01-03-2000', '71123452T', '636214214', '[email protected]s', '1') " "INSERT OR REPLACE INTO jugador VALUES ('3', '167', '', '170', '0', '', '2', '', '', '18') " "INSERT OR REPLACE INTO entrenador VALUES ('1', '2') " "INSERT OR REPLACE INTO convocatoria VALUES ('1', '1, '1', '22-04-2021 11:21', 'Mariano Haro', '13:00', 'Burgos', '') " "INSERT OR REPLACE INTO equipo VALUES ('1', 'Palencia', '690398') " "INSERT OR REPLACE INTO asistencia VALUES ('3', '1', '1') " 86 5.3. Control de versiones Una vez se comenzó a desarrollar el proyecto se decidió usar Git para llevar a cobo el control de versiones de la aplicación a lo largo de su desarrollo. El principal motivo por el que se utilizó este software de control de versiones fue que ya lo había utilizado en mis prácticas en empresa y conocía su funcionamiento, lo que me ha facilitado mucho la gestión del repositorio. Respecto a la documentación se utilizó Google Drive para ir almacenando las modificaciones. Inicialmente se desarrolló cada capítulo en un documento separado para facilitar su modificación y distribución al minimizar su extensión. Por ultimo y como copia de seguridad, todos los viernes se realizaba una copia del proyecto Android y de todos los documentos en un disco duro externo. Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 87 Capítulo 7: Plan de Pruebas 88 En este apartado se muestra la batería de pruebas realizadas sobre la aplicación para comprobar que funciona correctamente. A continuación, se describen las pruebas de caja negra realizadas sobre los casos de uso más importantes. 7.1. Pruebas de caja negra Las pruebas de Caja Negra son una técnica de pruebas software en la cual se verifica la funcionalidad teniendo en cuenta las entradas y salidas del sistema, es decir, basándonos en las interacciones del usuario. Este tipo de pruebas no tienen en cuenta la estructura interna del código, los detalles de implementación o los escenarios de ejecución internos en el software. [28] Las pruebas que se muestran a continuación han sido diseñadas a partir de los casos de uso definidos anteriormente. En la realización de todas ellas se han tenido en cuenta las variaciones que se pueden dar en cada caso de uso, además se ha comprobado que se obtienen los resultados deseados. A continuación, se muestran algunas de las pruebas realizadas sobre la versión final. La aplicación ha sido testeada en su totalidad en su versión final y se han ido realizando baterías de pruebas similares en versiones anteriores que han permitido resolver los fallos que se han ido encontrando antes de finalizar el desarrollo. 7.2. Casos de prueba PR-01 Iniciar sesión Descripción El usuario introduce sus credenciales previamente registradas Entrada Desde la pantalla inicial se introduce: • Usuario: “aida” • Password: “aida12” Resultado esperado El sistema muestra un mensaje “Datos correctos” y abre la pantalla principal del usuario Resultado obtenido CORRECTO Tabla 44: PR-01 Caso de prueba “Iniciar sesión” PR-02 Iniciar sesión con datos incorrectos Descripción El usuario introduce unas credenciales no registradas Entrada Desde la pantalla inicial se introduce: • Usuario: “abcdef” • Password: “123455” Resultado esperado El sistema muestra un mensaje “Usuario y/o password incorrecto” Resultado obtenido CORRECTO Tabla 45: PR-02 Caso de prueba “Iniciar sesión con datos incorrectos” Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 89 PR-03 Iniciar sesión con campos vacíos Descripción El usuario deja el campo contraseña vacío Entrada Desde la pantalla inicial se introduce: • Usuario: “aida” • Password: “ ” Resultado esperado El sistema muestra un mensaje “Error campos vacíos” Resultado obtenido CORRECTO Tabla 46: PR-03 Caso de prueba “Iniciar sesión con campos vacíos” PR-04 Registrarse Descripción El usuario completa todos los campos del formulario de registro Entrada El usuario introduce los siguientes valores: • Nombre: “Aida” • Apellidos: “Rodríguez Zorrilla” • Fecha Nacimiento: “30-06-1995” • D.N.I: “71717171-R” • Telefono: “678876678” • Correo electrónico: “[email protected]” • User: “aida” • Contraseña: “aida12” • Volver a insertar contraseña: “aida12” Resultado esperado El sistema muestra un mensaje “Registro correcto” Resultado obtenido CORRECTO Tabla 47: PR-04 Caso de prueba “Registrarse” PR-05 Registrarse sin aceptar condiciones y términos de uso de la app Descripción El usuario cancela el mensaje de términos y condiciones de la aplicación Entrada Desde el “pop-up” de términos y condiciones el usuario selecciona “Cancelar” Resultado esperado El sistema regresa a la pantalla inicial, no permitiendo el registro Resultado obtenido CORRECTO Tabla 48: PR-05 Caso de prueba “Registrarse sin aceptar las condiciones y términos de uso de la app” 96 PR-29 Modificar datos deportivos Descripción El usuario modifica el valor de uno de los campos ya introducidos Entrada El usuario introduce como nuevo dorsal “19” en lugar del existente “10” Resultado esperado El sistema muestra un mensaje “Datos guardados” Resultado obtenido CORRECTO Tabla 72: PR-29 Caso de prueba “Modificar datos deportivos” 7.2. Resultado de las pruebas Como podemos observar el resultado obtenido en la mayoría de las pruebas ha sido correcto ya que, como hemos indicado, los errores se han ido corrigiendo a medida que se realizaban baterías de pruebas en versiones anteriores. La mayoría de los errores que se han detectado han sido: • Errores en la retroalimentación ofrecida por el sistema: En ocasiones los mensajes devueltos por el sistema no eran suficientemente explicativos, por lo que se han sustituido por otros que ofrecen mayor claridad al usuario. • Falta de retroalimentación: Al probar la aplicación se detectaban flujos en los que el sistema no ofrecía mensaje informativo al completar acciones que modificaban el estado de la aplicación. Para mejorar la usabilidad de la aplicación se incluyeron estos mensajes. • Errores ortográficos: En las pruebas se fueron descubriendo errores de escritura que se solventaron instantáneamente. • Errores en la validación de datos: En las pruebas se detectaron algunos errores al comprobar el tipo de datos que se permite introducir en determinados campos. Estos errores fueron solventados mejorando el sistema de validación. • Falta de información sobre la ubicuidad en la aplicación: Al probar la aplicación se detectó que en algunas pantallas el usuario podía perder la percepción de donde se encontraba y cuál era la funcionalidad de esa pantalla. Para mejorar esta situación se introdujeron títulos explicativos en todas aquellas pantallas que podían generar dudas, facilitando que el usuario sepa en todo momento donde se encuentra. Como se puede ver la mayoría de los errores no han afectado directamente al funcionamiento del sistema y se relacionan con la usabilidad de la aplicación. A la vista de los errores obtenidos, podemos decir que muchos de estos se deben a descuidos por parte del desarrollador al implementar la lógica. 7.3. Corrección de errores El error detectado en la batería de pruebas de la versión final, perteneciente al caso de uso “Insertar datos deportivos valores incorrectos”, se ha solventado incluyendo una validación del tipo de datos que se permite insertar en los campos del formulario de “Datos deportivos”. Tras esta última corrección se ha testeado nuevamente la aplicación al completo, no descubriéndose nuevos fallos. Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 97 Capítulo 8: Conclusiones y trabajo futuro 98 8.1. Consecución objetivos 8.1.1 Objetivos conseguidos • Se han conseguido cumplir todos los requisitos planteados inicialmente • Se ha adquirido mayor soltura en el uso de las herramientas utilizadas en el desarrollo • Se han descubierto nuevas tecnologías y patrones que han facilitado y mejorado la implementación • Se ha creado una aplicación móvil fácil de utilizar, intuitiva y con un lenguaje sencillo. • Se ha conseguido que todos los usuarios que han probado la aplicación, independientemente de su edad o su experiencia deportiva, quedasen satisfechos con la experiencia de uso obtenida. 8.1.2 Objetivos no conseguidos • No se ha conseguido mostrar la información relativa a los test físicos en el perfil del entrenador. • No se ha conseguido cumplir con los plazos inicialmente establecidos Aunque se ha desarrollado la parte de inserción de los valores asociados a los test físicos por parte de los jugadores, finalmente se decidió que estos fuesen mostrados en cada sesión aportando de esta manera una información de mayor calidad a los entrenadores. Como la parte de creación de sesiones no era objeto de desarrollo en este proyecto, estos valores no podrán ser consultados por el momento. Respecto a los plazos marcados en el plan de proyecto han sido ampliamente superados, ya que el tiempo empleado ha sido mucho mayor que el tiempo inicialmente estimado. A pesar de ello se ha logrado finalizar el proyecto antes de junio de 2021, lo que suponía el objetivo final. 8.2. Trabajo futuro Una vez finalizado el proyecto hay varios aspectos que por diversos motivos no se han llevado a cabo en toda su extensión. Además, y dado que las actualizaciones son vitales en el ámbito de las aplicaciones móviles, también se plantearán mejoras que pueden ser implementadas en el futuro. • Mejorar el aspecto general de la aplicación, por ejemplo, ofreciendo más soporte gráfico. • Añadir distintas posibilidades de filtrado, especialmente en el apartado de consulta de convocatorias. • Añadir más posibilidades de realización de test físicos y mejorar la consulta de todos ellos, ofreciendo así más prestaciones a los entrenadores • Implementar un método de recuperación de contraseña en caso de perdida. • Ampliar las funcionalidades de la aplicación ofreciendo la posibilidad de insertar sesiones de entrenamiento. • Ofrecer un gestor de ejercicios en el que se puedan crear, modificar… ejercicios que posteriormente puedan ser añadidos a las sesiones • Dotar de un servicio de mensajería dentro de la propia aplicación, permitiendo así que los usuarios se puedan comunicar entre ellos sin la necesidad de utilizar otras aplicaciones. Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 99 8.3. Valoración personal El desarrollo de este proyecto ha supuesto poner fin a mi etapa de formación universitaria. Llevarlo a cabo no ha sido fácil, ya que su desarrollo ha coincidido con la pandemia del covid-19, por lo que he tenido que adaptarme a las diversas situaciones que se iban dando en todos los ámbitos de la vida. El desarrollo de este proyecto me ha permitido poner en práctica muchos de los conocimientos adquiridos a lo largo de mi formación universitaria (desde el ámbito de la programación, la planificación y gestión de proyectos o la gestión de bases de datos). El mayor aprendizaje que obtengo tras la realización de este proyecto es que el conocimiento que hemos recibido no es tan determinante como la capacidad de investigación y resolución ante los problemas que van surgiendo. A lo largo del proyecto he tenido que ir adaptándome a los diversos contratiempos que han ido surgiendo, tratando de darles la solución que mejor se adaptaba a los requisitos que debía ofrecer la aplicación. Respecto a las herramientas utilizadas, considero que, si tuviera que volver a desarrollar una aplicación móvil, optaría por entornos de desarrollo más actuales (como Ionic), ya que permiten un desarrollo más ágil en todos los sentidos, además de facilitar el uso de bases de datos en servidores externos. Creo que la utilización de Android Studio como IDE para la realización de este proyecto no ha resultado todo lo optima que se presuponía al comenzar. Tras finalizar el proyecto puedo decir que estoy satisfecha con el resultado obtenido. He podido trabajar en una aplicación destinada a uno de los ámbitos en los que más disfruto en mi día a día, el balonmano; a la vez que ponía en práctica los conocimientos adquiridos a lo largo de estos últimos años durante mi formación universitaria. La realización del proyecto me ha permitido ganar autonomía, experiencia y nuevos conocimientos técnicos que estoy segura me serán muy útiles en el futuro cuando tenga que enfrentarme a proyectos “reales” en el ámbito laboral. 100 Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 101 BIBLIOGRAFÍA [1] IBM. (s. f.). IBM deveoloper. DevOps - IBM Developer. Recuperado 13 de mayo de 2021, de https://www.ibm.com/developerworks/rational/library/4706.html#N100A7 [2] Ingeniería Software. (2018, 29 noviembre). FURPS - Ingeniería Software. Recuperado 13 de mayo de 2021, de http://clases3gingsof.wikifoundry.com/page/FURPS [3] P. N. Robillard, P. Kruchten, and P. D’Astous, YOOPEEDOO (UPEDU): A process for teaching software process. 2001. [4] Colaboradores de Wikipedia. (2021, 9 febrero). Proceso Unificado de Rational. Wikipedia, la enciclopedia libre. https://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational [5] Astah Online Store. (s. f.). Astah. Recuperado 13 de mayo de 2021, de https://sites.fastspring.com/astah/product/online-store [6] Balsamiq Online Store - Get Pricing Info and Buy Balsamiq Wireframes | Balsamiq. (s. f.) Balsamiq. Recuperado 13 de mayo de 2021, de https://balsamiq.com/buy/#cloud [7] Microsoft. (s. f.). Comparar todas las ofertas de planes de 365. Recuperado 13 de mayo de 2021, de https://www.microsoft.com/es-es/microsoft-365/business/compare-allmicrosoft-365-business-products?&activetab=tab:primaryr2 [8] Microsoft. (2021, 5 mayo). Opciones de precios y compra | Visual Studio. Visual Studio. https://visualstudio.microsoft.com/es/vs/pricing/ [9] Pricing | Heroku. (s. f.). Heroku. Recuperado 13 de mayo de 2021, de https://www.heroku.com/pricing [10] Comparativo de tarifas de Internet. (2018, 25 septiembre). KillMyBill Espagne. https://www.killmybill.es/internet/#movistar [11] C. Larman, UML y patrones: una introducción al análisis y diseño orientado a objetos y al proceso unificado, 2nd ed. Prentice Hall, 2002 [12] M. Fowler, Patterns of Enterprise Application Architecture, 1st ed. Addison Wesley, 2002 [13] Maluenda, R. (2020, 5 mayo). Los 10 principios de usabilidad de Jakob Nielsen: be user friendly. Profile Software Services. https://profile.es/blog/los-10-principios-deusabilidad-web-de-jakob-nielsen/ [14] Android - SQLite Database - Tutorialspoint. (s. f.). Android - SQLite Database. Recuperado 13 de mayo de 2021, de https://www.tutorialspoint.com/android/android_sqlite_database.htm [15] Muradas, Y. (2020, 6 julio). SQLite para Android: La herramienta definitiva. OpenWebinars.net. https://openwebinars.net/blog/sqlite-para-android-laherramienta-definitiva/ [16] Lozano, E. (2018, 20 diciembre). Crea una base de datos que le encantará a la LOPD. Coregistros. https://www.coregistros.com/crea-una-base-de-datos-que-le-encantaraa-la-lopd/ [17] 403 Forbidden. (2016, 21 julio). 480 - CÓMO_CUMPLE_UNA_APP_CON_LA_LEY_DE_PROTECCIÓN_DE_DATOS. https://cuatroochenta.com/como-cumple-una-app-con-la-ley-de-proteccion-de-datos/ [18] Datos de menores en el RGPD. (2019, 29 noviembre). ClickDatos. https://clickdatos.es/datos-de-menores-en-el-rgpd/ 102 [19] Tablado, F. (2021, 10 mayo). Ley de Protección de Datos y Garantía de Derechos Digitales (LOPDGDD) 2018. Grupo Atico34. https://protecciondatoslopd.com/empresas/nueva-ley-proteccion-datos-2018/ [20] Cifrado y encriptación de datos para proteger contenido. (2019, 10 diciembre). Beck Destrucción Confidencial. https://abdc.es/blog/encriptacion-cifrado-datos-protegercontenido/ [21] Stack Overflow. (2016, 14 junio). ¿Cómo encriptar una base de datos SQLite? Stack Overflow en español. https://es.stackoverflow.com/questions/13956/c%C3%B3moencriptar-una-base-de-datos-sqlite [22] SQLite Encryption Extension. (s. f.). SQLite. Recuperado 13 de mayo de 2021, de http://www.hwaci.com/sw/sqlite/see.html [23] SQLCipher - Zetetic. (s. f.). Zetetic. Recuperado 13 de mayo de 2021, de https://www.zetetic.net/sqlcipher/ [24] Colaboradores de Wikipedia. (2021a, enero 10). Patrón de diseño. Wikipedia, la enciclopedia libre. https://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o#Objetivos_de_los_patr ones [25] O. Blanco (2018, 10 diciembre). Data Access Object (DAO) Pattern. Oscar Blancarte - Software Architecture. https://www.oscarblancarteblog.com/2018/12/10/dataaccess-object-dao pattern/#:%7E:text=Para%20esto%2C%20tenemos%20el%20patr%C3%B3n,al%20resto %20de%20la%20aplicaci%C3%B3n [26] Download Android Studio and SDK tools | Android Studio. (s. f.). Android Developers. Recuperado 13 de mayo de 2021, de https://developer.android.com/studio?hl=es&gclid=CjwKCAjwnPOEBhA0EiwA609ReRV 4V9XRK3iOTdn1Q7QepRC1wh6BRF8adeivkUsDUswea5bl3vVOdhoCF4sQAvD_BwE&gcl src=aw.ds [27] Colaboradores de Wikipedia. (2021c, marzo 28). Android Studio. Wikipedia, la enciclopedia libre. https://es.wikipedia.org/wiki/Android_Studio [28] Pruebas de Caja Negra y un enfoque práctico. (2017, 26 febrero). TestingBaires. https://testingbaires.com/2017/02/26/pruebas-caja-negra-enfoquepractico/#:%7E:text=Las%20Pruebas%20de%20Caja%20Negra,ejecuci%C3%B3n%20int ernos%20en%20el%20software. Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 103 ANEXOS 104 Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 105 Manual de instalación 112 1.2. Registro Para registrarse en la aplicación basta con rellenar un sencillo formulario y seleccionar el rol con el que se desea efectuar el registro (entrenador o jugador). Figura A03: Captura de las pantallas de alta nuevo usuario. Según el rol seleccionado se accedera a la pantalla de “Registrar Equipo” en el caso del Entrenador o la pantalla “Unirse a un equipo” para los Jugadores. Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 113 1.3. Registrar Equipo Para registrar un equipo basta con añadir el nombre del equipo y el sistema proporcionara un código de acceso. El entrenador deberá facilitar este código a sus jugadores para que pueden unirse al equipo. (Esta opción solo estará disponible para los Usuario con rol Entrenador.) Figura A04: Captura de la pantalla de registrar equipo. 1.4. Unirse a un Equipo Para unirse a un equipo bastara con introducir el código asociado al equipo. (Esta opción solo estará disponible para los Usuario con rol Jugador.) Figura A05: Captura de la pantalla de unirse a un equipo. 114 1.5. Menú del usuario Siempre que estemos registrados en la aplicación y hayamos accedido a nuestra cuenta, podemos desplegar el menú que se encuentra en la barra de herramientas (esquina superior derecha). Este menú permite acceder al perfil del usuario y cerrar la sesión de este. Figura A06: Captura del menú de usuario de la barra de herramientas. Perfil usuario Desde el perfil de usuario se pueden modificar los datos introducidos en el momento del registro introduciéndolos en un formulario que aparece prellenado con los datos introducidos por el usuario en el registro. El nombre de usuario no se puede modificar. Figura A07: Captura de la pantalla editar usuario. Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 115 Cerrar sesión Antes de cerrar sesión el sistema solicitara confirmación, si el usuario acepta se llevara a cabo la acción. Figura A08: Captura de la ventana de confirmación de cerrar sesión. 116 ROL ENTRENADOR Al acceder un usuario registrado como Entrenador se encontrará con la pantalla principal desde la que podrá acceder a las distintas funcionalidades disponibles. Figura A09: Captura de la pantalla principal rol entrenador. 1.6. Acceder a los datos del equipo Desde esta ventana se puede acceder a los datos de todos los jugadores que forman parte del equipo además de conocer el dato de asistencia media del equipo. En un futuro el botón “sesiones” permitirá acceder a un listado de las sesiones realizadas por el equipo, pero por el momento esa funcionalidad no se encuentra disponible. Figura A10: Captura de la pantalla datos del equipo. Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 117 Desde el botón “datos jugadores” acedemos a una lista que incluye a todos los jugadores que se encuentran registrados en el equipo. Esta lista nos permitirá conocer la asistencia de cada jugador, además, pulsando sobre cada jugador se pueden ver sus datos personales y deportivos. Figura A11: Captura de las pantallas de datas jugadores. 1.7. Convocatorias Desde esta ventana se puede crear una nueva convocatoria o consultar las convocatorias ya asociadas al equipo. En cada convocatoria el entrenador podrá actualizar la asistencia de cada jugador a la misma. Figura A12: Captura de la pantalla de convocatorias. 118 Nueva convocatoria Para incluir una nueva convocatoria en la programación de un equipo el entrenador deberá crear una nueva convocatoria, para ello simplemente tendrá que rellenar un sencillo formulario. Figura A13: Captura de la pantalla crear nueva convocatoria. Consultar convocatorias Desde esta pantalla podemos ver todas las convocatorias asociadas al equipo y conocer los datos de estas. Además, al pulsar sobre ella tendremos la opción de eliminarla y, mediante una lista de los jugadores convocados, podremos pulsar sobre cada uno e introducir la asistencia de este jugador a esa convocatoria. Figura A14: Captura de las pantallas de consultar convocatorias (rol entrenador). Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 119 Eliminar convocatoria Antes de eliminar una convocatoria el sistema solicitara confirmación, solo si el usuario acepta se eliminara la convocatoria de forma permanente. Figura A15: Captura de la ventana de confirmación de eliminar convocatoria. Insertar asistencia de un jugador La inserción de la asistencia se llevará a cabo seleccionando entre una lista de opciones en la que se pueden encontrar las causas más habituales para faltar a una sesión de entrenamiento. Figura A16: Captura de la pantalla de insertar asistencia jugador. 1.8. Crear sesión Por el momento esta funcionalidad no está disponible. En el futuro desde esta sección se espera poder crear sesiones de entrenamiento seleccionando entre los ejercicios disponibles. 120 1.9. Crear ejercicio Por el momento esta funcionalidad no está disponible. En el futuro desde esta sección se espera poder crear ejercicios de entrenamientos, especificando su temática, su desarrollo, material necesario… Estos ejercicios luego se podrán utilizar para crear sesiones de entrenamiento. 1.10. Abandonar equipo Esta opción permite al Entrenador abandonar el equipo para, si lo desea, unirse a otro. Antes de ejecutar la acción el sistema solicita confirmación al usuario, una vez este confirma su deseo de abandonar el equipo, pierde el acceso a todos los datos de este equipo. Figura A17: Captura de la ventana de confirmación de abandonar equipo (rol entrenador). 1.11. Añadir titulación En el menú de usuario disponible en las pantallas asociadas a un usuario registrado como entrenador, además de las funcionalidades ya mencionadas, se encuentra la opción de introducir la titulación deportiva que este posee. El entrenador puede modificar esta siempre que lo desee. Figura A18: Captura de la pantalla de modificar titulación. Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 121 ROL JUGADOR Al acceder un usuario registrado como Jugador se encontrará con la pantalla principal desde la que podrá acceder a las distintas funcionalidades disponibles. Figura A19: Captura de la pantalla principal rol jugador. 1.12. Insertar datos deportivos Para insertar o actualizar los datos deportivos bastara con rellenar un sencillo formulario. En caso de que ya haya algún dato introducido este se mostrara en el formulario, pudiendo ser modificado. Figura A20: Captura de la pantalla insertar datos deportivos. 128 Figura A26: Boceto “Pantalla principal rol entrenador” Figura A27: Boceto “Pantalla acceso a un equipo (rol jugador)” Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 129 Figura A28: Boceto “Pantalla principal rol jugador” Figura A29: Boceto “Pantalla introducción datos deportivos (rol jugador)” 130 Figura A30: Boceto “Pantalla consulta convocatoria e introducción RPE (rol jugador)” Figura A31: Boceto “Pantalla consulta asistencia (rol jugador)” Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 131 Figura A32: Boceto “Pantalla modificar titulación (rol entrenador)” Figura A33: Boceto “Pantalla crear nuevo equipo (rol entrenador)” 132 Figura A34: Boceto “Pantalla convocatorias (rol entrenador)” Figura A35: Boceto “Pantalla crear nueva convocatoria” Aplicación móvil de gestión de entrenamientos de un equipo de balonmano 133 Figura A36: Boceto “Pantalla introducir datos asistencia (rol entrenador)” Figura A37: Boceto “Pantalla consultar datos del equipo (rol entrenador)” 134 Figura A38: Boceto “Pantalla consultar datos componentes del equipo (rol entrenador)”