APP Gestión de partidos y jugadas de un equipo de balonmano

Escuela de Ingenier´ıa Inform´atica Trabajo fin de grado Grado en Ingenier´ıa Inform´atica (Menci´on en Ingenier´ıa de Software) APP Gesti´on de partidos y jugadas de un equipo de balonmano Autor: D. Miguel S´anchez Rueda Escuela de Ingenier´ıa Inform´atica Trabajo fin de grado Grado en Ingenier´ıa Inform´atica (Menci´on en Ingenier´ıa de Software) APP Gesti´on de partidos y jugadas de un equipo de balonmano Autor: D. Miguel S´anchez Rueda Tutora: D˜na. Mar´ıa Margarita Gonzalo Tasis AGRADECIMIENTOS Agradecimientos A mi tutora Margarita, por su trabajo y apoyo. A mis compa˜neros de carrera, con quienes aprend´ı el valor de trabajar en equipo. A mi familia y amigos, en especial a mis padres por apoyarme en todo momento. Gracias a todos I AGRADECIMIENTOS II RESUMEN Resumen El objetivo de este proyecto consiste en desarrollar una aplicaci´on para sistemas Android que sirva de apoyo para gestionar partidos de balonmano. Destinada a entrenadores y sus ayudantes, de todas las categor´ıas superiores a infantil. En la actualidad no existe una soluci´on integral para que los entrenadores de balonmano consigan llevar las t´acticas de su equipo a un nuevo nivel. Se busca, mediante la digitalizaci´on y uso de repeticiones dar m´as facilidades a los entrenadores para que puedan tener a su vez m´as tiempo durante el partido. El proyecto se ha desarrollado empleando el motor de videojuegos Unity y el leguaje C#, aplicando la metodolog´ıa RUP. III RESUMEN IV ABSTRACT Abstract The purpose of this project is to develop a software for Android devices which helps to prepare handaball games. Intended for coaches and their assistants, of all categories above infant. Currently there is no comprehensive solution for handball coaches to take their team’s tactics to a brand new level. It is sought, through digitization and the use of repetitions, to give more facilities to the coaches so that they can have more time during the game. The project has been developed using Unity, a videogame engine, and C# as programming language, following RUP metodology. V ´ INDICE DE FIGURAS 4.3. Estructura de Unity por paquetes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.4. Dise˜no detallado del paquete Scenes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.5. Dise˜no detallado del paquete Sprites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.6. Dise˜no detallado del paquete Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.7. Dise˜no detallado del paquete PreFabs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.8. Prototipo inicial del men´u principal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.9. Prototipo de icono de la aplicaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.10. Prototipo de jugadas din´amicas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.11.Prototipodelbal´ondejuego. ........................................ 64 4.12. Prototipo de la pizarra de dibujo libre. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.13. Prototipo de aviso de borrado en pizarra. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.14. Prototipo de un listado de jugadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.15. Prototipo de un listado de jugadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.16. Prototipo de creaci´on/ edici´on de un jugador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.17. Prototipo de los ajustes de color de equipo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.18. Realizaci´on en dise˜no del CU01: Gestionar jugadas din´amicas. . . . . . . . . . . . . . . . . . . . . . . 69 4.19. Realizaci´on en dise˜no del CU02: Crear jugada din´amica. . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.20. Realizaci´on en dise˜no del CU03: Guardar jugada din´amica. . . . . . . . . . . . . . . . . . . . . . . . 71 4.21. Realizaci´on en dise˜no del CU04: Reproducir una jugada. . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.22. Realizaci´on en dise˜no del CU05: Cargar jugada din´amica. . . . . . . . . . . . . . . . . . . . . . . . . 73 4.23. Realizaci´on en dise˜no del CU06: Listar jugadas guardadas. . . . . . . . . . . . . . . . . . . . . . . . . 74 4.24. Realizaci´on en dise˜no del CU07: Eliminar jugadas guardadas. . . . . . . . . . . . . . . . . . . . . . . 75 4.25. Realizaci´on en dise˜no del CU08: Dibujo libre en pizarra. . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.26. Realizaci´on en dise˜no del CU09: Guardar captura pantalla. . . . . . . . . . . . . . . . . . . . . . . . 77 4.27. Realizaci´on en dise˜no del CU10: Gestionar plantilla jugadores. . . . . . . . . . . . . . . . . . . . . . . 78 4.28. Realizaci´on en dise˜no del CU11: A˜nadir jugador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.29. Realizaci´on en dise˜no del CU12: Editar jugador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.30. Realizaci´on en dise˜no del CU13: Eliminar jugador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.31. Realizaci´on en dise˜no del CU14: Eliminar a todos los jugadores. . . . . . . . . . . . . . . . . . . . . . 82 XII ´ INDICE DE FIGURAS 4.32. Realizaci´on en dise˜no del CU16: Cambiar idioma de la aplicaci´on. . . . . . . . . . . . . . . . . . . . . 83 5.1. Ejemplo de tablero de Issues. Fuente: [16]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.2. GameObject que representa a un cubo. Fuente: [47] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 1. Consulta de versi´on Android. Fuente: NextPit.es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 2. Permisos de instalaci´on, Android 7 o inferior. Fuente: [14] . . . . . . . . . . . . . . . . . . . . . . . . 117 3. Instalaci´on de una apk, Android 7 o inferior. Fuente: [14] . . . . . . . . . . . . . . . . . . . . . . . . 117 4. Permisos de instalaci´on, Android 8 o superior. Fuente: [14] . . . . . . . . . . . . . . . . . . . . . . . . 118 5. Instalaci´on de una apk, Android 8 o superior. Fuente: [14] . . . . . . . . . . . . . . . . . . . . . . . . 118 6. EntrenaBal:Men´uprincipal.........................................121 7. EntrenaBal:Jugadasdin´amicas.......................................122 8. EntrenaBal: Botones de movimiento de equipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 9. EntrenaBal:Borradodepasos........................................123 10. EntrenaBal:Guardarjugada.........................................123 11. EntrenaBal:Cargarunajugada.......................................124 12. EntrenaBal:Salirsinguardar ........................................124 13. EntrenaBal:Listarjugadas .........................................125 14. EntrenaBal:Borrarjugada/s ........................................125 15. EntrenaBal: Pizarra interactiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 16. EntrenaBal:Borrardibujos .........................................127 17. EntrenaBal: Salir sin guardar captura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 18. EntrenaBal: Plantilla de jugadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 19. EntrenaBal: A˜nadir o editar un jugador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 20. EntrenaBal:Borrarunjugador .......................................129 21. EntrenaBal: Mensaje de aviso al editar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 22. EntrenaBal: Borrado de todos los jugadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 23. EntrenaBal:Ajustes .............................................131 24. EntrenaBal:Cambiodecolor ........................................132 XIII ´ INDICE DE FIGURAS XIV ´ INDICE DE TABLAS ´ Indice de tablas 2.1. Desglosederiesgos............................................... 15 2.2. Presupuestodelproyecto........................................... 16 2.3. Planificaci´oninicial. ............................................. 17 2.4. Distribuci´on inicial por secciones [54]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.5. Plan de trabajo de la fase de Inicio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.6. T-01: Toma de contacto inicial con el problema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.7. T-02:An´alisisderiesgos............................................ 19 2.8. T-03:An´alisisdecostes............................................ 19 2.9. T-04: B´usqueda de aplicaciones similares. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.10.T-05:Formaci´onenUnityyC#. ...................................... 19 2.11. T-06: Preparaci´on del entorno de trabajo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.12.T-07:Plandetrabajo............................................. 19 2.13.T-08:Redacci´ondelamemoria........................................ 20 2.14.T-09:Tutor´ıasonlineymails......................................... 20 2.15. Plan de trabajo de la fase de Elaboraci´on o An´alisis. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.16. T-10: Establecimiento de requisitos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.17.T-11:Modelodecasosdeuso......................................... 20 2.18. T-12: Especificaci´on de casos de uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.19.T-:13Modelodedominio. .......................................... 21 2.20. T-14: Diagramas de proceso/ flujo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.21. T-15: Dise˜no de la Interfaz de Usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.22. T-16: Investigaci´on de arquitecturas en Unity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.23. T-17: Arquitectura de la aplicaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 XV ´ INDICE DE TABLAS 2.24. Plan de trabajo de la fase de Construcci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.25. T-18: Implementaci´on del men´u principal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.26. T-19: Implementaci´on de la escena jugadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.27. T-20: Implementaci´on de la escena listar jugadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.28. T-21: Implementaci´on de la escena pizarra. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.29. T-22: Implementaci´on de la escena plantilla. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.30. T-23: Implementaci´on de la escena ajustes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.31. T-24: Implementaci´on del cambio de idiomas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.32. Plan de trabajo de la fase de Transici´on y Pruebas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.33. T-25: Pruebas personales de funcionalidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.34. T-26: Pruebas finales de funcionalidad con usuarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.35. T-27: Elaboraci´on del manual de instalaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.36. T-28: Elaboraci´on del manual de usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.37. T-29: Presentaci´on y preparaci´on de la defensa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.38.T-30:Revisi´ondelamemoria......................................... 25 2.39. Distribuci´on temporal inicial por fases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.40.Planificaci´onreal................................................ 26 2.41. Distribuci´on real por secciones (porcentajes en base a 300 horas). . . . . . . . . . . . . . . . . . . . . 26 2.42. Plan de trabajo real de la fase de Inicio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.43. Plan de trabajo real de la fase de Elaboraci´on o An´alisis. . . . . . . . . . . . . . . . . . . . . . . . . 27 2.44. Plan de trabajo real de la fase de Construcci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.45. Plan de trabajo real de la fase de Transici´on y Pruebas. . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.46. Distribuci´on temporal real por fases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.1. Requisitosfuncionales............................................. 32 3.2. Requisitosnofuncionales. .......................................... 33 3.3. Requisitos funcionales de informaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.4. Escenario del Caso de Uso CU-01: Gestionar jugadas din´amicas. . . . . . . . . . . . . . . . . . . . . 36 3.5. Escenario del Caso de Uso CU-02: Crear jugada din´amica. . . . . . . . . . . . . . . . . . . . . . . . . 37 3.6. Escenario del Caso de Uso CU-03: Guardar jugada din´amica. . . . . . . . . . . . . . . . . . . . . . . 38 XVI ´ INDICE DE TABLAS 3.7. Escenario del Caso de Uso CU-04: Reproducir una jugada. . . . . . . . . . . . . . . . . . . . . . . . . 38 3.8. Escenario del Caso de Uso CU-05: Cargar jugada din´amica. . . . . . . . . . . . . . . . . . . . . . . . 39 3.9. Escenario del Caso de Uso CU-06: Listar jugadas guardadas. . . . . . . . . . . . . . . . . . . . . . . 39 3.10. Escenario del Caso de Uso CU-07: Eliminar jugadas guardadas. . . . . . . . . . . . . . . . . . . . . . 40 3.11. Escenario del Caso de Uso CU-08: Dibujo libre en pizarra. . . . . . . . . . . . . . . . . . . . . . . . . 41 3.12. Escenario del Caso de Uso CU-09: Guardar captura pantalla. . . . . . . . . . . . . . . . . . . . . . . 41 3.13. Escenario del Caso de Uso CU-10: Gestionar plantilla jugadores. . . . . . . . . . . . . . . . . . . . . 42 3.14. Escenario del Caso de Uso CU-11: A˜nadir jugador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.15. Escenario del Caso de Uso CU-12: Editar jugador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.16. Escenario del Caso de Uso CU-13: Eliminar jugador. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.17. Escenario del Caso de Uso CU-14: Eliminar a todos los jugadores. . . . . . . . . . . . . . . . . . . . 45 3.18. Escenario del Caso de Uso CU-15: Gestionar el color de los jugadores. . . . . . . . . . . . . . . . . . 46 3.19. Escenario del Caso de Uso CU-16: Cambiar idioma de la aplicaci´on. . . . . . . . . . . . . . . . . . . 46 5.1. Entorno de desarrollo: MacBook Pro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.2. Entorno de desarrollo: Tablet Android. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.3. Entorno de desarrollo: PC Windows b´asico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.4. Entorno de desarrollo: PC Windows medio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 6.1. Descripci´on del CP-01: Crear una jugada din´amica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 6.2. Descripci´on del CP-02: Guardar una jugada din´amica. . . . . . . . . . . . . . . . . . . . . . . . . . . 98 6.3. Descripci´on del CP-03: Cargar una jugada din´amica. . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 6.4. Descripci´on del CP-04: Reproducir una jugada cargada. . . . . . . . . . . . . . . . . . . . . . . . . . 98 6.5. Descripci´on del CP-05: Reproducir una jugada en creaci´on. . . . . . . . . . . . . . . . . . . . . . . . 99 6.6. Descripci´on del CP-06: Movimiento r´apido de jugadores. . . . . . . . . . . . . . . . . . . . . . . . . . 99 6.7. Descripci´on del CP-07: Borrar pasos al crear una jugada. . . . . . . . . . . . . . . . . . . . . . . . . 99 6.8. Descripci´on del CP-08: Volver a men´u desde Jugadas. . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6.9. Descripci´on del CP-09: Listar jugadas existentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.10. Descripci´on del CP-10: Eliminar una jugada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.11. Descripci´on del CP-11: Eliminar todas las jugadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.12. Descripci´on del CP-12: Dibujo de t´acticas en pizarra. . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 XVII ´ INDICE DE TABLAS 6.13. Descripci´on del CP-13: Almacenar captura de pantalla. . . . . . . . . . . . . . . . . . . . . . . . . . 101 6.14. Descripci´on del CP-14: Borrado de trazos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 6.15. Descripci´on del CP-15: Regreso al men´u sin guardar la pizarra. . . . . . . . . . . . . . . . . . . . . . 101 6.16. Descripci´on del CP-16: Visualizar los jugadores de la plantilla. . . . . . . . . . . . . . . . . . . . . . 102 6.17. Descripci´on del CP-17: A˜nadir un jugador a la plantilla. . . . . . . . . . . . . . . . . . . . . . . . . . 102 6.18. Descripci´on del CP-18: Editar un jugador de la plantilla. . . . . . . . . . . . . . . . . . . . . . . . . . 103 6.19. Descripci´on del CP-19: Mensaje de error al crear un jugador. . . . . . . . . . . . . . . . . . . . . . . 103 6.20. Descripci´on del CP-20: Mensaje de aviso al editar un jugador. . . . . . . . . . . . . . . . . . . . . . . 103 6.21. Descripci´on del CP-21: Eliminar un jugador de la plantilla. . . . . . . . . . . . . . . . . . . . . . . . 104 6.22. Descripci´on del CP-22: Eliminar a todos los jugadores de la plantilla. . . . . . . . . . . . . . . . . . . 104 6.23. Descripci´on del CP-23: Cambiar el color de los equipos. . . . . . . . . . . . . . . . . . . . . . . . . . 104 6.24. Descripci´on del CP-24: Cambiar el color de los equipos sin guardar. . . . . . . . . . . . . . . . . . . 104 6.25. Descripci´on del CP-25: Cambiar el idioma de la aplicaci´on. . . . . . . . . . . . . . . . . . . . . . . . 105 6.26. Descripci´on del CP-26: Cambiar el idioma de la aplicaci´on al actual. . . . . . . . . . . . . . . . . . . 105 XVIII CAP´ ITULO 1. INTRODUCCI ´ ON Cap´ıtulo 1 Introducci´on Como introducci´on a este Trabajo Fin de Grado, en adelante TFG, abordar´e ciertos aspectos de relevancia para entender el mismo, como pueden ser los objetivos, las alternativas actuales al problema abordado o la estructura empleada. 1.1. Contexto En la actualidad los entrenadores de balonmano no disponen de una soluci´on software integral, completa, que les permita llevar las t´acticas de juego al siguiente nivel. Debido a esto, una gran mayor´ıa no emplea la inform´atica, esto implica desventajas como: volatilidad y falta de repeticiones, algo clave para el aprendizaje. Aunque existan algunas aproximaciones, no resultan ser suficientes. 1.2. Motivaci´on La motivaci´on para elegir este tema fue por tanto implementar un software capaz de ayudar en estas tareas a los entrenadores, simplificando su trabajo durante el partido, permiti´endoles as´ı seguirlo de cerca, y gestionarlo de manera m´as eficiente. Partiendo de la idea de la tutora, se establecen una serie de requisitos m´ınimos a lograr, los cuales se van complementado al analizar las diversas aplicaciones actuales, ampliando el alcance del proyecto. Todo ello en el marco de aprendizaje de una tecnolog´ıa actual de desarrollo (Unity), lo que es ´util en mi carrera profesional, ya que la programaci´on de videojuegos es una rama que ten´ıa inter´es en explorar, y esta ocasi´on era una buena oportunidad. 1.3. Objetivos El objetivo principal es desarrollar una App de gesti´on de partidos de balonmano, la cual permita dise˜nar y mostrar jugadas din´amicas (en las cuales los jugadores y el bal´on se desplazan por el terreno de juego), as´ı como dibujar en una pizarra convencional. Se valorar´an mejoras en la misma a medida que se consiguen los objetivos, siguiendo en todo momento la metodolog´ıa RUP. 1 1.4. ESTUDIO DE APLICACIONES EN EL MERCADO Las posibles tecnolog´ıas eran Kotlin, Ionic y Unity, decant´andome por esta ´ultima. El sistema objetivo es Android, pero se procurar´a dar servicio a los sistemas MacOS y Windows, ya que Unity lo permite (no habiendo mayor problema que asegurarse de que todo funciona en los diversos sistemas). 1.3.1. Objetivos personales Gesti´on de proyectos. Aprender de primera mano a gestionar un proyecto completo, desde cero, con metodolog´ıas ´agiles. Proyecto software al completo. Participar personalmente en todas las etapas de un proyecto software: especificaci´on de requisitos, creaci´on de diagramas UML, dise˜no de la interfaz de usuario y su implementaci´on, pruebas y creaci´on de memoria con manuales. Todo ello aplicando las teor´ıas y principios de la ingenier´ıa de software, garantizando la calidad y mantenibilidad del c´odigo, sin dejar de lado la eficiencia. Identificar y analizar necesidades y problemas. Ser capaz de valorar las necesidades de un proyecto, especificando los requisitos necesarios teniendo en cuenta las diversas limitaciones de tiempo y coste. A su vez, ser capaz de encontrar soluciones adecuadas a la teor´ıa y sobreponerse a las adversidades no contempladas en el an´alisis de riesgos, as´ı como los problemas de implementaci´on. Conocimiento t´ecnico. Formarme en C# y Unity [50], un potente motor de videojuegos, que tiene soporte de compilaci´on en diferentes plataformas (Android, WebGL [43], iOS, Windows, las principales consolas del momento, y muchos otros). 1.4. Estudio de aplicaciones en el mercado Inicialmente, se estudi´o el Reglamento de partidos y competiciones [38]. A continuaci´on se exploran las tecnolog´ıas que permitan realizar los objetivos. Posteriormente se analizan las aplicaciones presentes en el mercado, por lo que se realiza una b´usqueda en pro de detectar fortalezas y debilidades en el trabajo que otros ya han realizado, tratando de evitar as´ı los mismos errores. A su vez, algunas de las aplicaciones presentan funcionalidades no tenidas en cuenta, que se podr´ıan implementar en caso de tener tiempo. 1.4.1. TacticalPad Futsal & Handball [40]. Esta aplicaci´on Android (figura 1.1), permite usarse para balonmano y f´utbol sala. Presenta una versi´on de pago que implementa funcionalidades muy necesarias. Puntos a favor: Permite la creaci´on de jugadas est´aticas, con jugadores de ambos equipos dispuestos por el terreno de juego, diferentes l´ıneas para indicar acciones, y elementos de juego como balones, o utensilios de entrenamiento como conos, aros o banderines. Permite personalizar los equipos, con un nombre, color e imagen. Tambi´en se puede a˜nadir el nombre y posici´on de cada jugador (algo ´util, pero que sin mayores funcionalidades, no sirve de mucho). 2 CAP´ ITULO 1. INTRODUCCI ´ ON Puntos en contra: Al no tener ninguna explicaci´on, el aprendizaje recae en el usuario, y no es demasiado intuitivo. S´olo permite el uso de jugadas din´amicas si te suscribes a la app (26e/ a˜no). La traducci´on a espa˜nol es autom´atica, no siendo correcta en algunos puntos, pudiendo confundir al usuario. Figura 1.1: TacticalPad Futsal & Handball 1.4.2. Field Hockey Dood [32]. Tambi´en para dispositivos Android, es una app (figura 1.2), orientada a hockey hierba, pero se puede adaptar a las necesidades del balonmano, por el “parecido” del campo (respecto a las otras opciones del desarrollador: f´utbol, baloncesto, v´oleibol, etc.), es una app similar a la idea involucrada en este TFG. Puntos a favor: Permite situar jugadores, balones, texto, l´ıneas y conos en el campo y distribuirlos en ´este. Se pueden crear jugadas a˜nadiendo instantes de tiempo (situaci´on actual de la pantalla), estas transiciones tienen un tiempo de paso y pueden visualizarse mientras se componen las jugadas. Permite guardar formaciones, jugadas y v´ıdeos de las mismas (en el dispositivo). Puntos en contra: Solicita permiso para grabar audio cuando ´este no se emplea en ning´un momento, por lo que puede incurrir en falta de privacidad si se usa sin consentimiento. Al encontrarse en fase experimental, la grabaci´on de jugadas falla a veces. 3 2.1. PLAN DE DESARROLLO Asegurar la calidad. Los controles de calidad son realizados en todas las etapas del proyecto y no solo al final, evitando as´ı desavenencias futuras. En este TFG se cuenta con las revisiones de la tutora, en cada una de las etapas del proyecto. Planificaci´on de recursos. Al analizar los requisitos, tener en cuenta las restricciones y ser conscientes de lo que implica garantizar la calidad, se puede planificar el proyecto para garantizar que no haya retrasos por requisitos contradictorios, o la disputa de recursos finitos de manera simult´anea, no perdiendo tiempo. Colaboraci´on. Aunque no sea el punto principal en este TFG, esta metodolog´ıa facilita la comunicaci´on entre los miembros del equipo, que podr´an coordinar el an´alisis, dise˜no, implementaci´on y pruebas, siendo as´ı m´as eficientes. La metodolog´ıa RUP basa su ciclo de vida en las fases que dictamina el proceso unificado de negocio [1]. Se trata de un desarrollo iterativo e incremental, que consta de 4 fases: Inicio. El comienzo es la fase m´as corta de todas, en la cual se establece una visi´on preliminar del proyecto, una planificaci´on de tareas, y el presupuesto asociado a todo el trabajo. Tambi´en se analiza si el proyecto es factible, teniendo en cuenta el presupuesto y la dificultad t´ecnica (pudiendo comparar con aplicaciones similares existentes, as´ı como con el consejo de la tutora). Tambi´en es el momento en el que se decide entre comprar o desarrollar el software; en este caso, evidentemente, se desarrolla (empleando las bibliotecas que ya hayan sido implementadas y sean de utilidad). Elaboraci´on o An´alisis. Durante esta etapa, se identifican la mayor´ıa de los requisitos del sistema. Y tambi´en se toman en cuenta los riesgos potenciales que podr´ıan afectar a priori al proyecto. A su vez es com´un realizar los diagramas de casos de uso1y de clases2. Por ´ultimo se establece la arquitectura del sistema3lo que permite planificar la siguiente fase, teniendo en cuenta siempre los riesgos e informaci´on recopilada durante estas dos fases. Es decir, esta fase se compone, esencialmente, del an´alisis y dise˜no de la aplicaci´on. Construcci´on. Siendo la m´as extensa del proceso, es donde se implementan las funcionalidades propuestas en la fase de elaboraci´on. Al realizarse por etapas, cada una de ellas debe ser completamente funcional (para los objetivos establecidos), por lo que cada etapa implementa nuevas funcionalidades y/o corrije fallos detectados, tanto de funcionalidad como de usabilidad. Para ello se suelen escribir tests [57] completos, evitando as´ı errores desde fases tempranas. Debido a que la tecnolog´ıa de desarrollo empleada es Unity, que permite la exportaci´on a muy diversos sistemas operativos, se probar´a cada evoluci´on en todos los sistemas soporte: Android, macOS y Windows. Transici´on y pruebas. En esta ´ultima fase, se trata de encontrar errores en las funcionalidades, pudiendo para ello mostrar el sistema a usuarios, obteniendo retroalimentaci´on para mejorar el resultado final, por lo que es ventajoso realizarlo desde fases tempranas del desarrollo. Tambi´en se incluye en este momento ense˜nar a los usuarios a utilizar el sistema correctamente. Este proceso, ha sido aplicado por tanto, a˜nadiendo requisitos en el cap´ıtulo 3, An´alisis, a medida que el sistema iba avanzando en funcionalidad. Estos avances se pueden apreciar de manera detallada en la secci´on 2.6, Seguimiento, donde se comentan algunos sucesos de inter´es. 1Descripci´on de una actividad que puede realizar el usuario en el sistema. 2Diagrama UML que en dise˜no orientado al objeto, permite modelar relaciones entre las entidades implementadas. 3Conjunto de patrones, objetivos y restricciones que establece la estructuraci´on del software. 10 CAP´ ITULO 2. PLANIFICACI ´ ON A su vez, se presenta (figura 2.1), un diagrama de Gantt [55] [56] (una herramienta clave en la gesti´on de proyectos, que presenta una visi´on general de las tareas que componen el mismo y que permite a los miembros del equipo ser conscientes de plazos de entrega y estado actual de un proyecto).En dicha figura, se muestra el proceso del proyecto, detallando s´olo las fases. M´as adelante, en el subcap´ıtulo 2.5, Planificaci´on inicial, se presentar´an 4 diagramas de Gantt, uno por fase, m´as detallados. Figura 2.1: Diagrama de Gantt de las fases del proyecto. 2.2. Restricciones Se aplican una serie de restricciones al proyecto, que acotan su alcance. Requisitos de distribuci´on. La aplicaci´on ser´a soportada obligatoriamente en el sistema operativo Android, sin ning´un fallo. A su vez, se intentar´a que ning´un bug imposibilite su uso en las dem´as plataformas a las que se quiere dar acceso de manera secundaria: macOS y Windows. Contemplaci´on de riesgos. Se realizar´a de manera continuada el an´alisis y seguimiento de riesgos, apartado 2.3. Almacenamiento de datos. Los datos de la aplicaci´on ser´an almacenados en el propio dispositivo, evitando as´ı la necesidad de una conexi´on a internet, y acelerando la interfaz de usuario. Trabajo. El proyecto no deber´a exceder de las 300 horas hombre, respetando as´ı su asignaci´on de 12 ECTS. Fecha de entrega. La fecha temprana de entrega ser´a, como m´ınimo, el 31 de mayo de 2021, d´ıa en el que termino la ´ultima asignatura del grado (las pr´acticas en empresa). Contando unos d´ıas a mayores para su evaluaci´on. Tiempo. El proyecto debe finalizar en el mes de junio de 2021, teniendo tiempo suficiente para su defensa en la convocatoria ordinaria de TFG. 2.3. An´alisis de riesgos Seg´un se puede inferir de [20] el riesgo es un evento, o serie de eventos, que pueden o no ocurrir. En caso de que ocurran, tendr´a un efecto en los objetivos del proyecto, ya sea positivo (una oportunidad) o negativo (una amenaza). Es por tanto la posibilidad de exponerse a consecuencias adversas, o eventos futuros adversos. Los riesgos no son, por tanto, problemas actuales. En esta secci´on tratar´e los riesgos principales que pueden acontecer durante el desarrollo de este trabajo. Como pude aprender durante la asignatura Planificaci´on y Gesti´on de Proyectos [55] es una tarea imprescindible, puesto que el an´alisis de riesgos permite tener en cuenta aspectos externos o impl´ıcitos al trabajo, que pueden condicionar el ´exito o fracaso de cualquier proyecto, y condicionar en gran medida a la planificaci´on del mismo. Tras la tarea de identificaci´on y an´alisis de ´estos, no debemos dejarlos olvidados, hay que 11 2.3. AN ´ ALISIS DE RIESGOS monitorizarlos teniendo en cuenta c´omo avanzan, y si aparecen nuevos, o los existentes no han sido priorizados correctamente. Es, por tanto, una tarea iterativa durante el trabajo, por lo que se deben revisar y actualizar si fuera necesario. Los riesgos y su an´alisis brindan conocimiento acerca de las tareas que se realizan, y para no sufrirlos, es de vital importancia realizar una lista de errores con la cual tenerlos localizados; para esto, fue realmente ´util seguir la lista [9]. Existen diferentes tipos de riesgos, que son: Riesgos conocidos. Fruto de evaluar el proyecto y su alcance. Riesgos predecibles. Aquellos que la experiencia dicta que pueden volver a ocurrir. Riesgos impredecibles. Circunstancias como la pandemia, imposibles de predecir. Por tanto, nos debemos centrar en los riesgos reconocibles, teniendo en cuenta el impacto que supondr´an al proyecto. Los riesgos deben evaluarse durante todas las etapas de un proyecto: identificaci´on, an´alisis, control y monitorizaci´on. Los riesgos son tenidos en cuenta pero no siempre se pueden evitar, tambi´en se puede proteger del mismo procurando que afecte en menor medida en caso de producirse, o transferir el riesgo para que otros lo asuman. En cualquier caso, tambi´en puede llegar a aceptarse un riesgo, ya que si el esfuerzo y los costes implicados en evitarlo, superan los que generar´ıa en caso de que se d´e, no tendr´ıa sentido, y se acepta que pueda ocurrir. A continuaci´on, expongo los riesgos previstos en este trabajo. Con un identificador para referirse a ellos si fuera necesario, una descripci´on del mismo, la probabilidad de que ´este ocurra y su impacto en caso de que se d´e. Por otra parte, y derivado de la probabilidad-impacto, se toman en cuenta una serie de acciones para mitigar (tratar de reducir la probabilidad de ocurrencia del riesgo), as´ı como de contingencia (reducir, en caso de ocurrencia, los efectos en la planificaci´on). ID Categor´ıa Descripci´on del riesgo Probabilidad Impacto Acciones de Mitigaci´on Acciones de Contingencia R01 Planificaci´on y control Empeoramiento de la pandemia mundial por COVID-19. Medio Medio No procede. Adecuarse a una presentaci´on telem´atica caso de que no se permita de forma presencial. R02 Planificaci´on y control Inexperiencia en la gesti´on de proyectos. Alta Bajo 1.- Mantener una buena comunicaci´on con la tutora. 2.- Actualizar la lista de riesgos, y tenerla siempre presente. No procede. 12 CAP´ ITULO 2. PLANIFICACI ´ ON ID Categor´ıa Descripci´on del riesgo Probabilidad Impacto Acciones de Mitigaci´on Acciones de Contingencia R03 Planificaci´on y control Estimaci´on inadecuada de los recursos necesarios. Media Medio Tratar de aprovechar el tiempo al m´aximo y empezar con las actividades lo antes posible para mantener alta la flotabilidad4. Replanificar e informar a la tutora. R04 Planificaci´on y control Inexperiencia a la hora de abordar una tarea novedosa. Media Medio Dedicar parte del tiempo asignado a investigar el aspecto desconocido, aprovechando la flotabilidad. No procede. R05 Requisitos Cambio en los requisitos. Media Alto Aplicar la metodolog´ıa ´agil en el desarrollo software para reducir el impacto que supondr´ıan los cambios. En la reuni´on semanal, revisar el trabajo realizado y planificar una depuraci´on del software, as´ı como la implementaci´on de los cambios. R06 Requisitos Los requisitos establecidos no son correctos. Baja Medio En las reuniones con la tutora, confirmar que el desarrollo es acorde a los requisitos. Revisi´on de requisitos e inclusi´on de cambios en la planificaci´on. R07 Personal Ampliaci´on del horario de trabajo/ Cambio de trabajo. Baja Medio Llevar al d´ıa el TFG y el trabajo. Reestructurar el horario y la planificaci´on para tener en cuenta la nueva situaci´on y adaptarse al cambio lo antes posible. R08 Personal Contracci´on de la COVID-19. Media Alto 1.- Seguir a rajatabla las recomendaciones sanitarias de las autoridades en cada momento. 2.- No realizar acciones que favorezcan el contagio. 1.- Seguir las recomendaciones sanitarias, manteniendo el ritmo de trabajo que sea posible. 2.- Al recuperarse y retomar el ritmo habitual, replanificar en funci´on del tiempo perdido. 4La cantidad de tiempo que puede ser retrasada una tarea sin que cause un retraso al proyecto. 13 2.3. AN ´ ALISIS DE RIESGOS ID Categor´ıa Descripci´on del riesgo Probabilidad Impacto Acciones de Mitigaci´on Acciones de Contingencia R09 Personal Contracci´on de otras enfermedades. Media Medio 1.- Evitar exposiciones a grupos de contagio y las actividades de riesgo. 1.- Seguir las recomendaciones sanitarias, manteniendo el ritmo de trabajo que sea posible. 2.- Al recuperarse y retomar el ritmo habitual, replanificar en funci´on del tiempo perdido. R10 Equipo Falta de disponibilidad de los miembros del equipo de trabajo. Baja Medio No procede. Mayor trabajo y organizaci´on aut´onoma. R11 T´ecnico Aver´ıa del ordenador. Baja Medio Realizar un mantenimiento y uso del equipo adecuado. 1.- Si fuera necesario, adquirir un equipo nuevo. 2.- Instalaci´on de los programas de desarrollo necesarios. 3.- Reestructurar la planificaci´on en base al tiempo discurrido entre la aver´ıa y la puesta en marcha. R12 T´ecnico Cortes del suministro el´ectrico o de internet. Baja Bajo Realizar copias de seguridad accesibles. Realizar tareas que no requieran consumo el´ectrico/internet durante la ca´ıda del servicio. R13 T´ecnico Ca´ıda del sistema de almacenamiento externo. Baja Medio 1.- Tener copias locales actualizadas del trabajo en progreso, mediante GitLab. 2.- Tener un sistema alternativo de desarrollo que pueda sustituir al sistema ca´ıdo con una copia de seguridad peri´odica. Trabajar en local con el sistema alternativo hasta que se restablezca el almacenamiento externo. 14 CAP´ ITULO 2. PLANIFICACI ´ ON ID Categor´ıa Descripci´on del riesgo Probabilidad Impacto Acciones de Mitigaci´on Acciones de Contingencia R14 Complejidad Complejidad del proyecto. Baja Medio Dividir las tareas complejas en un mayor n´umero de subtareas simples y repartirlas en m´ultiples iteraciones. No procede. R15 Complejidad tecnol´ogica Uso de una tecnolog´ıa con la que no se ha trabajado anteriormente. Media Medio Tener presentes tecnolog´ıas que puedan usarse en ´ambitos similares. No procede. Tabla 2.1: Desglose de riesgos. 2.3.1. Observaciones sobre riesgos acontecidos Desde el principio se manifiesta el riesgo R14 (Nivel alto de complejidad t´ecnica), con la herramienta L A T EXlo cual retrasa el inicio del proyecto. Se siguieron tutoriales y se atajaba cada problema seg´un aparec´ıan a la hora de redactar la memoria. Por otra parte tambi´en se manifest´o el riesgo R15 (Uso de una tecnolog´ıa con la que no se ha trabajado anteriormente), como es el caso de Unity, incrementando el tiempo de formaci´on por tutoriales en pocas horas. 2.4. An´alisis de costes El enfoque para calcular el presupuesto del TFG ha sido el Real Decreto-ley 28/2020, la ley de teletrabajo espa˜nola [6], en el art´ıculo 12, establece que la empresa debe remunerar al trabajador por los gastos derivados del trabajo en casa, mediante el convenio colectivo del sector. Es decir, esta mec´anica aporta bastante flexibilidad, (debiendo contemplar todos los recursos empleados por el trabajador). En base a la realidad, emplear´e datos de mi caso particular. Los gastos ser´an imputables, referidos a mi domicilio actual, y tomados seg´un la media geom´etrica de los ´ultimos 12 meses. Todos los costes han sido calculados con la totalidad de los decimales, lo que explicar´ıa posibles peque˜nas variaciones en el c´omputo global. A continuaci´on, aparece un desglose de los mismos: Vivienda. Adem´as del precio del alquiler, se incluyen los gastos de comunidad (donde se incluye el agua corriente), el seguro del hogar, y el pago del IBI. Dando un valor acorde al mercado y ubicaci´on, teniendo en cuenta el valor actual seg´un [15] el coste es de 540e/ mes, seg´un las horas de uso respecto al d´ıa completo, el coste por hora ser´ıa de 0,75e. Y en las 300 horas de duraci´on, un total de 225e. Consumo el´ectrico. La factura de electricidad, incluyendo los impuestos, tasas, KWh, ... asciende a 55e/ mes tomando por referencia los 12 meses del a˜no 2020 y realizando su media. Se obtiene un coste de 0,075e/ hora. Lo que tras 300 horas, hace un total de 22,5e. 15 2.5. PLANIFICACI ´ ON INICIAL Factura de calefacci´on. El gasto medio de las facturas de calefacci´on de los 12 meses del a˜no 2020 es de 61e. Este c´alculo en horas resulta en 0,084e/ hora, y finalmente en 25,41een total. Proveedor de internet. La tarifa mensual de internet es de 48e/mes. Teniendo en cuenta que se usa 300 horas, el coste es de 19,98e(0,022e/ hora). Amortizaci´on del equipo inform´atico. El equipo utilizado es un MacBook Pro 13”de 2015. Con un precio de compra en 2015 de 1650e, y un valor actual de mercado que ronda los 650e, tras 5 a˜nos, el gasto anual de amortizaci´on es de (1650e- 650e) / 5 a˜nos = 200e/a˜no. Tras una peque˜na conversi´on, equivale a 0,023e/ hora, que, al utilizarlo durante 300 horas, se obtiene un total de 6,85e. Horas de trabajo. Seg´un [5] (p´agina 28) el salario bruto de un analista programador es de 1.438,08e/mes5 (cifra que incluye los impuestos correspondientes al trabajador: IRPF y SS, calculadas en [36] por un valor de 275,68e). Teniendo en cuenta que la jornada en dicho caso ser´ıa de 40 horas semanales (160 mensuales), obtenemos un salario de 8,99e/ hora. Al ser 300 horas de trabajo, el total asciende a 2.696,4e. Tras el detalle en los c´alculos, se presentan en la siguiente tabla (2.2), para facilitar al lector su interpretaci´on. Gasto Coste / hora Coste total (300h) Vivienda 0,75e225e Consumo el´ectrico 0,075e22,5e Calefacci´on 0,084e25,41e Internet 0,065e19,98e Amortizaci´on 0,023e6,85e Horas de trabajo 8,99e2.696,4e Total 9,98e2.996,14e Tabla 2.2: Presupuesto del proyecto 2.4.1. Costes finales Debido a los diversos problemas comentado en el an´alisis de riesgos acontecidos, se emplean 36 horas m´as de lo establecido. Esto redunda en los costes finales del proyecto. Tomando el coste por hora de la tabla 2.2, es decir 9,98e/ hora, el coste final asciende a los 3.355,63e, es decir, 359,53em´as que lo inicialmente presupuestado. 2.5. Planificaci´on inicial Teniendo en cuenta el calendario de dep´osito y defensa del TFG de este a˜no [22], se establece como fecha de fin de proyecto el 6 de junio de 2021. Comenzando el 16 de febrero de 2021, da como resultado 16 semanas para la elaboraci´on del proyecto. Esta fecha de fin ha sido estimada en base a varios motivos: Pr´acticas en Empresa. Tomando en consideraci´on la gran posibilidad de continuar empleado tras la finalizaci´on del contrato de pr´acticas, lo id´oneo ser´ıa poder incorporarse cuanto antes, una vez terminado este TFG. Alcance del proyecto. Debido a los requisitos iniciales del proyecto, secci´on 3.2, se estima que no habr´a problemas en implementar la funcionalidad requerida, y otras a mayores, por lo que 300 horas ser´an suficientes. 5Cifras del ´ultimo convenio, en 2018. 16 CAP´ ITULO 2. PLANIFICACI ´ ON Como se puede apreciar en la tabla 2.3, las dos primeras semanas son m´ınimamente reducidas, y las dem´as constan de 20 horas semanales. Se ha optado por una cantidad de horas semanales siguiendo el consejo de mi tutora, ya que permite una mayor flexibilidad horaria en el d´ıa a d´ıa, tratando de evitar que algunos imprevistos no interfieran en gran medida. As´ı como la ´ultima semana, destinada a la revisi´on de la memoria por completo, y la presentaci´on para la defensa. Finalmente, se presenta en la tabla 2.4 la distribuci´on inicial de las 300 horas, siguiendo la gu´ıa [54]. NºInicio Final Horas Observaciones/ Incidencias 1 16/02/2021 23/02/2021 14 2 23/02/2021 02/03/2021 18 3 02/03/2021 09/03/2021 20 4 09/03/2021 16/03/2021 20 5 16/03/2021 23/03/2021 20 6 23/03/2021 30/03/2021 20 7 30/03/2021 06/04/2021 20 8 06/04/2021 13/04/2021 20 9 13/04/2021 20/04/2021 20 10 20/04/2021 27/04/2021 20 11 27/04/2021 04/05/2021 20 12 04/05/2021 11/05/2021 20 13 11/05/2021 18/05/2021 12 Riesgo R10. 14 18/05/2021 25/05/2021 20 15 25/05/2021 01/06/2021 20 16 01/06/2021 06/06/2021 16 Revisi´on final y preparaci´on de defensa. Fin 06/06/2021 Total 300 El c´omputo total es de 300 horas. Tabla 2.3: Planificaci´on inicial. Secci´on Horas Porcentaje Investigaci´on, documentaci´on e implementaci´on. 200 66,7 % Redacci´on de la memoria y adecuaci´on a la plantilla. 75 25 % Tutor´ıas 20 6,6 % Evaluaci´on y defensa 5 1,6 % Total 300 100 % Tabla 2.4: Distribuci´on inicial por secciones [54]. 2.5.1. Plan de trabajo A continuaci´on, se detallan las tareas a abordar seg´un cada fase comentada en el apartado 2.1. De igual manera se presenta en cada fase un diagrama de Gantt (figuras 2.2, 2.3, 2.4 y 2.5), m´as detallado que el expuesto en el plan de desarrollo. ´ Estos se han redise˜nado, puesto que los diagramas generados con MS Project, no permit´ıan visualizar de una manera ´optima las tareas. 17 2.5. PLANIFICACI ´ ON INICIAL Fase de Inicio En las tablas sucesivas a la tabla 2.5 se describen en detalle las tareas de esta fase. Se realizar´a la plantilla de la memoria as´ı como toda la tarea de an´alisis de planificaci´on. Se estima como fecha de comienzo el 16/02/2021 y se espera finalizar el 14/03/2021. Nombre de la tarea Duraci´on T-01 Toma de contacto inicial con el problema. 5 horas T-02 An´alisis de riesgos. 2,5 horas T-03 An´alisis de costes. 2,5 horas T-04 B´usqueda de aplicaciones similares. 2 horas T-05 Formaci´on en Unity y C#. 20 horas T-06 Preparaci´on del entorno de trabajo. 3 horas T-07 Plan de trabajo. 3 horas T-08 Redacci´on de la memoria. 20 horas T-09 Tutor´ıas online y mails. 5 horas Total fase de Inicio. 63 horas Tabla 2.5: Plan de trabajo de la fase de Inicio. Figura 2.2: Diagrama de Gantt de la fase Inicio. Fase de Elaboraci´on o An´alisis En las tablas sucesivas a la tabla 2.15 se describen en detalle las tareas de esta fase. El an´alisis y dise˜no forman una parte clave del desarrollo software, pues es lo que dictamina c´omo ser´a la implementaci´on, gui´andola en todo aquello que pueda establecerse desde un inicio. 18 CAP´ ITULO 2. PLANIFICACI ´ ON T-01 Toma de contacto inicial con el problema. Descripci´on Lograr una idea general de las funcionalidades que dispondr´a la aplicaci´on, complementando con las siguientes acciones. B´usqueda y lectura de los reglamentos de juego de balonmano. Visionado de 2 partidos de balonmano para detectar posibles funcionalidades. Tabla 2.6: T-01: Toma de contacto inicial con el problema. T-02 An´alisis de riesgos. Descripci´on Detectar y analizar los posibles riesgos que incumben a este proyecto. Incluyendo la cuantificaci´on de los mismos as´ı como una descripci´on y el plan de contingencia en caso de que se produzca el riesgo. Tabla 2.7: T-02: An´alisis de riesgos. T-03 An´alisis de costes. Descripci´on Consiste en detectar los costes asociados al proyecto, calculando una estimaci´on de los gastos que supondr´ıa un proyecto de estas caracter´ısticas, en mi caso particular. Tabla 2.8: T-03: An´alisis de costes. T-04 B´usqueda de aplicaciones similares. Descripci´on Realizar una b´usqueda de aplicaciones existentes que atajen un paradigma similar. Se busca detectar fortalezas y debilidades en el trabajo previamente efectuado por otros, para intentar evitar fallos en el proyecto. Tabla 2.9: T-04: B´usqueda de aplicaciones similares. T-05 Formaci´on en Unity y C#. Descripci´on Consiste en el visionado de v´ıdeos, lecturas de manuales en p´aginas web y realizaci´on de ejemplos resueltos o tutoriales que ayuden a comprender la nueva tecnolog´ıa en la que se implementar´a el proyecto. Tabla 2.10: T-05: Formaci´on en Unity y C#. T-06 Preparaci´on del entorno de trabajo. Descripci´on Instalaci´on de Unity Hub, Unity y Visual Studio Code, as´ı como todos los preparativos para desarrollar la aplicaci´on. Preparaci´on del repositorio remoto. Tabla 2.11: T-06: Preparaci´on del entorno de trabajo. T-07 Plan de trabajo. Descripci´on Realizar un listado de tareas a desarrollar durante todo el proyecto (este apartado), incluyendo una estimaci´on temporal para cada una de ellas, estableciendo el m´aximo en 300 horas de trabajo. Tabla 2.12: T-07: Plan de trabajo. Se estima como fecha de comienzo el 15/03/2021 y se espera finalizar el 15/04/2021. 19 2.6. SEGUIMIENTO NºInicio Final Horas Observaciones/ Incidencias 1 16/02/2021 23/02/2021 14 2 23/02/2021 02/03/2021 18 3 02/03/2021 09/03/2021 0 Riesgo R10. 4 09/03/2021 16/03/2021 15 Riesgo R07 5 16/03/2021 23/03/2021 20 6 23/03/2021 30/03/2021 20 7 30/03/2021 06/04/2021 10 Riesgo R09. 8 06/04/2021 13/04/2021 20 9 13/04/2021 20/04/2021 10 Riesgo R09. 10 20/04/2021 27/04/2021 12 Riesgo R09. 11 27/04/2021 04/05/2021 20 12 04/05/2021 11/05/2021 20 13 11/05/2021 18/05/2021 12 Riesgo R10. 14 18/05/2021 25/05/2021 20 15 25/05/2021 01/06/2021 35 Finalizaci´on de pr´acticas en empresa. 16 01/06/2021 06/06/2021 35 17 07/06/2021 13/06/2021 30 18 14/06/2021 20/06/2021 25 Revisi´on final y preparaci´on de defensa. Fin 20/06/2021 Total 336 Se excede en 36 horas la planificaci´on inicial. Tabla 2.40: Planificaci´on real. Secci´on Horas Porcentaje Investigaci´on, documentaci´on e implementaci´on. 231 77 % Redacci´on de la memoria y adecuaci´on a la plantilla. 79 26,33 % Tutor´ıas 20 6,66 % Evaluaci´on y defensa 6 2 % Total 336 112 % Tabla 2.41: Distribuci´on real por secciones (porcentajes en base a 300 horas). 26 CAP´ ITULO 2. PLANIFICACI ´ ON 2.6.2. Plan de trabajo real Fase de Inicio Se estim´o como fecha de comienzo el 16/02/2021 y de fin el 14/03/2021. Finalmente esta fase estuvo comprendida entre el 16/02/2021 y el 26/03/2021. Nombre de la tarea Duraci´on Duraci´on real T-01 Toma de contacto inicial con el problema. 5 horas 5 horas T-02 An´alisis de riesgos. 2,5 horas 3 horas T-03 An´alisis de costes. 2,5 horas 2 horas T-04 B´usqueda de aplicaciones similares. 2 horas 2 horas T-05 Formaci´on en Unity y C#. 20 horas 20 horas T-06 Preparaci´on del entorno de trabajo. 3 horas 2 horas T-07 Plan de trabajo. 3 horas 3 horas T-08 Redacci´on de la memoria. 20 horas 28 horas T-09 Tutor´ıas online y mails. 5 horas 5 horas Total fase de Inicio. 63 horas 70 horas Tabla 2.42: Plan de trabajo real de la fase de Inicio. Fase de Elaboraci´on o An´alisis Se estim´o como fecha de comienzo el 15/03/2021 y de fin el 15/04/2021. Finalmente esta fase estuvo comprendida entre el 27/03/2021 y el 23/04/2021. Nombre de la tarea Duraci´on Duraci´on real T-10 Establecimiento de requisitos. 2 horas 2 horas T-11 Modelo de casos de uso. 5 horas 5 horas T-12 Especificaci´on de casos de uso. 8 horas 7 horas T-13 Modelo de dominio. 2 horas 2 horas T-14 Diagramas de proceso/ flujo. 5 horas 6 horas T-15 Dise˜no de la Interfaz de Usuario. 12 horas 12 horas T-16 Investigaci´on de arquitecturas en Unity. 3 horas 3 horas T-17 Arquitectura de la aplicaci´on. 7 horas 8 horas T-08 Redacci´on de la memoria. 20 horas 18 horas T-09 Tutor´ıas online y mails. 6 horas 4 horas Total fase de Elaboraci´on o An´alisis. 70 horas 67 horas Tabla 2.43: Plan de trabajo real de la fase de Elaboraci´on o An´alisis. Fase de Construcci´on Se estim´o como fecha de comienzo el 16/04/2021 y de fin el 01/06/2021. Finalmente esta fase estuvo comprendida entre el 24/04/2021 y el 08/06/2021. 27 2.6. SEGUIMIENTO Nombre de la tarea Duraci´on Duraci´on real T-18 Implementaci´on del men´u principal. 5 horas 5 horas T-19 Implementaci´on de la escena jugadas. 25 horas 41 horas T-20 Implementaci´on de la escena listar jugadas. 10 horas 10 horas T-21 Implementaci´on de la escena pizarra. 20 horas 14 horas T-22 Implementaci´on de la escena plantilla. 15 horas 20 horas T-23 Implementaci´on de la escena ajustes. 10 horas 16 horas T-24 Implementaci´on del cambio de idiomas. 10 horas 13 horas T-08 Redacci´on de la memoria. 10 horas 8 horas T-09 Tutor´ıas online y mails. 4 horas 4 horas Total fase de Construcci´on. 109 horas 131 horas Tabla 2.44: Plan de trabajo real de la fase de Construcci´on. Fase de Transici´on y Pruebas Se finaliza el TFG 2 semanas m´as tarde de lo planificado, el 20/06/2021. Nombre de la tarea Duraci´on Duraci´on real T-25 Pruebas personales de funcionalidad. 20 horas 23 horas T-26 Pruebas finales de funcionalidad con usuarios. 5 horas 6 horas T-27 Elaboraci´on del manual de instalaci´on. 5 horas 5 horas T-28 Elaboraci´on del manual de usuario. 3 horas 3 horas T-29 Presentaci´on y preparaci´on de la defensa. 5 horas 7 horas T-30 Revisi´on de la memoria. 15 horas 17 horas T-09 Tutor´ıas online y mails. 5 horas 7 horas Total fase de Transici´on y Pruebas. 58 horas 68 horas Tabla 2.45: Plan de trabajo real de la fase de Transici´on y Pruebas. 2.6.3. Desviaciones en la planificaci´on En la tabla 2.46 se aprecia con respecto a la tabla 2.39, c´omo el n´umero de horas empleadas ha sido superior a lo planificado. Fase Horas Horas reales Fase de Inicio 63 70 Fase de Elaboraci´on o An´alisis 70 67 Fase de Construcci´on 109 131 Fase de Transici´on y Pruebas 58 68 Total 300 336 Tabla 2.46: Distribuci´on temporal real por fases. Pero, ¿a qu´e se ha debido en cada fase? A continuaci´on expongo las conclusiones que he podido extraer, ya que reflexionando ser´a menos probable que vuelva a ocurrir en proyectos futuros. 28 CAP´ ITULO 2. PLANIFICACI ´ ON Fase de Inicio En esta fase destaca el tiempo de elaboraci´on de la plantilla, ya que no ten´ıa mucha experiencia con LaTeX y tuve que aprender casi de cero. Por contra, se consigui´o una plantilla que hubo que modificar m´ınimamente, por lo que los tiempos de redacci´on se redujeron en las siguientes fases. Tomando esto en consideraci´on, no deber´ıa repetirse, al haber ganado experiencia en el manejo de esta tecnolog´ıa. Fase de Elaboraci´on o An´alisis La fase de an´alisis no tuvo desviaciones, debido a que es la parte m´as trabajada a lo largo de la carrera. Fase de Construcci´on El desconocimiento de Unity, pese a la realizaci´on de diversos tutoriales [12] [7] al inicio juega un papel determinante en el tiempo de implementaci´on. La escena jugadas, al ser la primera en realizarse, es la que m´as tiempo lleva, no tanto por complejidad, si no por ser la primera toma de contacto. La gesti´on de la plantilla tambi´en resulta un tanto m´as compleja debido a tener que comprobar y sobreescribir los jugadores tanto en creaci´on como edici´on. Por otra parte, cabe destacar c´omo la pizarra llev´o menos tiempo debido al asset comentado en el apartado 5.5.2. Esta soluci´on casi completa al paradigma, permiti´o reducir tiempos en esta fase, al tener ´unicamente que adaptar el c´odigo. Se puede concluir que la cantidad de horas necesarias debi´o ser mayor, por el hecho de tratarse de una nueva tecnolog´ıa, algo a tener en consideraci´on en el aspecto laboral. Fase de Transici´on y Pruebas Finalmente el tiempo de pruebas es mayor debido a la incorporaci´on de nuevas funcionalidades en pro de completar la app. Tambi´en se cuenta con m´as usuarios de prueba, lo que lleva impl´ıcito m´as tiempo de explicaci´on, resoluci´on de dudas y apunte de sugerencias. De igual manera se emplea m´as tiempo del establecido en las revisiones de la memoria (completando alguna secci´on, como esta) y la presentaci´on, de cara a la defensa. 29 2.6. SEGUIMIENTO 30 CAP´ ITULO 3. AN ´ ALISIS Cap´ıtulo 3 An´alisis En este cap´ıtulo se detalla la aplicaci´on a desarrollar con las tareas de an´alisis, la parte troncal de cualquier desarrollo software, que ello conlleva: actores, requisitos, el tratamiento de los datos, los casos de uso a cubrir, el modelo de dominio y el flujo de la aplicaci´on. 3.1. Actores y roles de la aplicaci´on Esta aplicaci´on no implementa diferencias entre administrador, desarrollador y usuario, puesto que se enfoca como una app de usuario final, la cual pueda ser usada por completo de manera sencilla y auto contenida, sin conexi´on a internet tras su descarga. Debido a esto, puede apreciarse que ´unicamente existe un rol en la aplicaci´on, el usuario, el cual tiene acceso a la funcionalidad completa. Este rol puede ser desempe˜nado por dos actores, el entrenador y su asistente (aunque realmente no se necesitan conocimientos avanzados de balonmano para usarla, por lo que cualquier persona puede desempe˜nar el rol de usuario). De ahora en adelante me referir´e con entrenador (englobando a su asistente), al rol de usuario. 3.2. Requisitos A continuaci´on se detallan los requisitos del proyecto en funci´on de los objetivos establecidos, y siguiendo como gu´ıa el libro de Sommerville utilizado previamente en la carrera [41]. Se han a˜nadido nuevos requisitos no contemplados al inicio del proyecto, por disponer de m´as tiempo para desarrollar. 3.2.1. Requisitos Funcionales Parafraseando la definici´on de [37] los requisitos funcionales son la “Definici´on de los servicios que el sistema debe proporcionar, c´omo debe reaccionar a una entrada particular, y c´omo debe comportarse ante situaciones particulares”. Es decir, las funcionalidades que debe ser capaz de realizar la aplicaci´on, las cuales aparecen en la tabla 3.1. 31 3.2. REQUISITOS ID Descripci´on RF01 Jugadas. El sistema debe permitir a˜nadir nuevas jugadas al sistema. RF02 Jugadas II. El sistema permitir´a mostrar todas las jugadas presentes en el sistema y reproducirlas. RF03 Jugadas III. El sistema debe permitir eliminar jugadas. Para poder eliminar una jugada el sistema solicitar´a confirmaci´on al usuario. RF04 Dibujo en pizarra digital. El sistema debe permitir al usuario dibujar libremente en una pizarra digital que tenga por fondo un campo de balonmano reglamentario. Tendr´a a su disposici´on m´as de un color, un borrador, la posibilidad de cambiar el grosor de estos y la opci´on de reiniciar la pizarra. RF05 Capturas de pantalla. El sistema permitir´a al usuario guardar capturas de pantalla de sus dibujos en la pizarra libre. RF06 Plantilla. El sistema permitir´a al usuario a˜nadir jugadores a la plantilla del equipo. RF07 Plantilla II. El sistema permitir´a mostrar al usuario los jugadores que conforman su plantilla. RF08 Plantilla III. El sistema deber´a permitir al usuario modificar a los jugadores desde el listado de plantilla. RF09 Plantilla IV. El sistema debe permitir eliminar jugadores. Para poder eliminar un jugador el sistema solicitar´a confirmaci´on al usuario. RF10 Ajustes. El sistema deber´a permitir al usuario seleccionar los colores de los jugadores de su equipo y del equipo rival. RF11 Idiomas. El sistema debe permitir elegir el idioma en que se muestra la app, que seleccione el usuario de entre los posibles. Tabla 3.1: Requisitos funcionales. 3.2.2. Requisitos No Funcionales Los Requisitos No Funcionales o RNF, tabla 3.2 definen propiedades del sistema, cu´an fiable debe ser, su velocidad, sus necesidades de almacenamiento, etc. 32 CAP´ ITULO 3. AN ´ ALISIS ID Descripci´on RNF01 Adaptabilidad. El sistema debe asegurar que toda la aplicaci´on se visualiza correctamente en cualquier pantalla con relaci´on de aspecto 16:9. RNF02 Codificaci´on de caracteres. El sistema deber´a utilizar el formato UTF-8, y no mostrar problemas tipogr´aficos. RNF03 Usabilidad. El sistema debe ser muy usable, y tener una curva de aprendizaje casi plana. Se debe enfocar al perfil de un entrenador de entre 20 y 65 a˜nos, que tiene conocimientos generales de inform´atica. RNF04 Responsividad. El sistema debe ser altamente responsivo, no mostrando pantallas de carga superiores a los 2 segundos. RNF05 Compatibilidad. El sistema debe poder ejecutarse en cualquier dispositivo Android compatible, siendo la versi´on 4.4 la m´ınima para su funcionamiento. De igual manera deber´a garantizar su funcionamiento en Windows 10 y MacOS 10.15, o superiores. RNF06 Conectividad. Una vez descargada, la aplicaci´on no har´a uso de internet. RNF07 Fiabilidad. El sistema deber´a estar disponible las 24 horas del d´ıa, todos los d´ıas del a˜no. RNF08 Ajustes de color. El sistema deber´a ser capaz de mostrar una previsualizaci´on en la elecci´on de color, desde los ajustes. RNF09 Multilenguaje. El sistema deber´a funcionar completamente en los idiomas: espa˜nol, ingl´es, franc´es y alem´an. Los comentarios a˜nadidos por el usuario no ser´an traducidos. RNF10 Multilenguaje II. El sistema deber´a mostrar por defecto el lenguaje espa˜nol, y posteriormente, aquel lenguaje que fuera seleccionado. RNF11 Compatibilidad de ficheros. El sistema deber´a permitir exportar e importar f´acilmente los ficheros generados, que deben ser 100 % compatibles entre los sistemas operativos. Tabla 3.2: Requisitos no funcionales. 3.2.3. Requisitos Funcionales de Informaci´on Los Requisitos Funcionales de Informaci´on o RFI, en la tabla 3.3, describen requisitos funcionales, que declaran la informaci´on que es almacenada en el sistema, para posibilitar el funcionamiento. ID Descripci´on RFI01 Jugadas. El sistema guardar´a informaci´on sobre la posici´on de los jugadores de ambos equipos, as´ı como el avance por el campo de los mismos, y la ubicaci´on del bal´on reglamentario, para cada jugada existente. RFI02 Jugadores. El sistema almacena el nombre, dorsal y posici´on de los jugadores de la plantilla. RFI03 Capturas de pantalla. El sistema almacena las capturas de pantalla de la pizarra de dibujo libre. RFI04 Privacidad. El sistema no almacenar´a datos personales, potencialmente sensibles de ning´un usuario, no vulnerando as´ı ni su privacidad ni la LO PDPGDD, Ley Org´anica 3/2018 de Protecci´on de Datos Personales y Garant´ıa de los Derechos Digitales. Tabla 3.3: Requisitos funcionales de informaci´on. 33 3.3. PROTECCI ´ ON DE DATOS 3.3. Protecci´on de datos La sociedad actual, cada vez m´as informatizada y conectada, hace ya unos a˜nos que se encuentra sumida en un gran problema: la exposici´on de sus datos personales al resto del mundo, quedando a merced de posibles atacantes. Por ello, y como se estudia en la asignatura Profesi´on y Sociedad [19], es muy importante asegurar la integridad de los datos de los usuarios, a la par que debemos informarles sobre qu´e datos son recogidos. Actualmente, en nuestro pa´ıs, ´esto se rige por la LO PDPGDD, Ley Org´anica 3/2018 de Protecci´on de Datos Personales y Garant´ıa de los Derechos Digitales, as´ı como por el RGPD, Reglamento General de Protecci´on de Datos. Se debe informar al usuario de aquellos datos que ser´an almacenados (proporcionados por ellos mismos) y de aquellos procesados o generados en base al registro de uso u otras acciones. El usuario, debe dar consentimiento inequ´ıvoco y expl´ıcito para el tratamiento de sus datos, as´ı como del conocimiento de ello. Se debe plasmar la privacidad y uso que se dar´an a los datos personales. No olvidemos que no todos los datos son iguales, hay datos especialmente sensibles, aquellos que pueden identificar a una persona como son: su nombre completo, su direcci´on, el DNI, datos econ´omicos o laborales, valores biom´etricos, su localizaci´on... todos ´estos y muchos otros, requieren especial cuidado en su trato. El verdadero peligro reside en que pueden ser cruzados, haciendo as´ı identificable a una persona, creando un perfil digital que vulnere su privacidad. Por ello, los datos han de ser anonimizados por las empresas, en caso de querer realizar estad´ısticas o an´alisis para su negocio. Y en ning´un caso deber´ıan venderse en bruto, es decir, no se pueden ceder datos a otras empresas sin el consentimiento expl´ıcito del usuario, puesto que redundar´ıa en la p´erdida del control, y ser´ıa m´as f´acil realizar un perfil de la persona, atentando as´ı contra la normativa vigente. La mejor soluci´on para garantizar la privacidad, es pedir la menor cantidad de datos necesaria. Razonando sobre esto, varias decisiones fueron tomadas en el desarrollo de esta aplicaci´on: Registro. No se solicitar´a al usuario un registro, puesto que no supone ventaja alguna en el uso. Esto evita registrar cualquier dato personal, por nimio que sea. Datos de jugadores. El ´unico dato personal que se solicita en toda la aplicaci´on es el nombre de los jugadores del equipo. Cabe recalcar que el nombre, por s´ı solo, no permite identificar a una persona, ni siquiera pese a ir acompa˜nado de una posici´on de juego y un dorsal. Adem´as de ser insuficientes para trazar un perfil, son f´acilmente reconocibles por cualquiera que asista a un partido. Y por si fuera poco, podr´ıan usarse apodos en lugar del nombre real. Almacenamiento interno. Los datos generados por la aplicaci´on se almacenan ´unicamente en el dispositivo; prescindir de una copia de seguridad en la nube tiene sus desventajas, pero por otra parte lo hace independiente de las brechas de seguridad que tengan dichos sistemas, y permite cumplir el RNF-06 (funcionamiento sin conexi´on a internet). En definitiva, esta aplicaci´on no solicita datos personales cr´ıticos, y no se utilizan de ninguna manera. Pese a que se pueden compartir f´acilmente, al no estar encriptados, su p´erdida no supondr´ıa delito alguno, por lo expuesto anteriormente. El entrenador, as´ı como sus jugadores, pueden estar plenamente tranquilos acerca de su privacidad en la app EntrenaBal. 34 CAP´ ITULO 3. AN ´ ALISIS 3.4. Casos de uso 3.4.1. Diagrama de casos de uso Tras los requisitos, y consultando [26], se realiza el diagrama de casos de uso, que como se menciona en el apartado 5.2.2, expone de manera gr´afica y simple la interacci´on entre el usuario (el entrenador en este caso) y el sistema/ aplicaci´on. Este diagrama, figura 3.1, presenta por tanto al actor y las acciones que puede realizar (contenidas en elipses), siendo los “extend” casos de uso adicionales, a los que se pueden acceder desde el caso de uso que las engloba. Esto es as´ı ya que ampl´ıan la funcionalidad del caso general y pueden llevarse a cabo o no. Figura 3.1: Diagrama de casos de uso. 35 3.4. CASOS DE USO Caso de Uso CU-10: Gestionar plantilla jugadores Precondici´on Haber iniciado la aplicaci´on y encontrarse en el men´u principal. Paso Control Descripci´on 1 Usuario Indica que quiere gestionar la plantilla de jugadores. 2 SISTEMA Solicita al actor que elija entre los casos de uso “A˜nadir jugador”, “Editar jugador” y “Eliminar todos los jugadores”. 3 Usuario El actor indica el caso de uso que quiere realizar. 4 SISTEMA Seg´un la elecci´on, navega al caso de uso correspondiente. El caso de uso termina con ´exito. Extensiones Paso Control Descripci´on de la extensi´on 3.a Si el usuario solicita regresar al men´u. SISTEMA Informa al actor de la cancelaci´on (regresando al men´u). salir Se abandona el caso de uso, quedando sin efecto. 3.b Si el usuario solicita realizar el caso de uso “A˜nadir jugador”. SISTEMA Navega al caso de uso “A˜nadir jugador”. El caso de uso termina con ´exito.. 3.c Si el usuario solicita realizar el caso de uso “Editar jugador”. SISTEMA Navega al caso de uso “Editar jugador”. El caso de uso termina con ´exito.. 3.d Si el usuario solicita realizar el caso de uso “Eliminar todos los jugadores”. SISTEMA Navega al caso de uso “Eliminar todos los jugadores”. El caso de uso termina con ´exito.. Postcondici´on Se muestran las acciones a˜nadir, editar y eliminar todos los jugadores al usuario, permitiendo la correcta navegaci´on a cada uno de ellos. Tabla 3.13: Escenario del Caso de Uso CU-10: Gestionar plantilla jugadores. 42 CAP´ ITULO 3. AN ´ ALISIS Caso de Uso CU-11: A˜nadir jugador Precondici´on Haber iniciado la aplicaci´on y encontrarse en la escena Plantilla. Paso Control Descripci´on 1 Usuario Indica que quiere a˜nadir un jugador a la plantilla. 2 SISTEMA Solicita al actor que pulse el bot´on “A˜nadir jugador”. 3 Usuario Pulsa el bot´on “A˜nadir jugador”. 4 SISTEMA Solicita al actor que especifique el dorsal del jugador. 5 Usuario Indica el dorsal del jugador. 6 SISTEMA Solicita al actor que seleccione la posici´on del jugador. 7 Usuario Selecciona la posici´on del jugador. 8 SISTEMA Solicita al actor que especifique el nombre del jugador. 9 Usuario Indica el nombre del jugador. 10 SISTEMA Solicita al actor que proporcione una descripci´on del jugador. 11 Usuario Proporciona una descripci´on del jugador. 12 SISTEMA Solicita al actor que pulse el bot´on “Guardar” cuando est´e conforme. 13 Usuario Pulsa el bot´on “guardar”. 14 SISTEMA Registra el nuevo jugador con el dorsal asociado como nombre de fichero. 15 SISTEMA El caso de uso termina con ´exito. Extensiones Paso Control Descripci´on de la extensi´on 3.a, 5.a 7.a, 9.a 11.a, 13.a Si el usuario solicita cancelar la operaci´on. SISTEMA Solicita al actor confirmaci´on para cancelar el proceso. Usuario Confirma que quiere cancelar el proceso. SISTEMA Informa al actor de la cancelaci´on (volviendo al men´u previo). salir Se abandona el caso de uso, quedando sin efecto. 11.b Si el usuario no quiere proporcionar una descripci´on. Control Se retorna el control al paso 12. 14.a Si no se ha proporcionado un dorsal v´alido, un nombre y una posici´on. SISTEMA Informa al actor del suceso, inst´andole a que complete todos los campos obligatorios. Control Se retorna el control al paso 4. 14.b Si el dorsal del jugador ya est´a registrado. SISTEMA Informa al actor del suceso, inst´andole a que introduzca otro diferente. Control Se retorna el control al paso 4. Postcondici´on El sistema cuenta con un nuevo jugador, cuyos datos corresponden con los introducidos. Tabla 3.14: Escenario del Caso de Uso CU-11: A˜nadir jugador. 43 3.4. CASOS DE USO Caso de Uso CU-12: Editar jugador Precondici´on Disponer de al menos un jugador en el sistema. Encontrarse en la escena plantilla. Paso Control Descripci´on 1 Usuario Indica que quiere editar un jugador de la plantilla. 2 SISTEMA Solicita al actor que pulse el bot´on “Editar jugador” en la fila correspondiente. 3 Usuario Pulsa el bot´on “Editar jugador” de la fila correspondiente. 4 SISTEMA Solicita al actor que especifique el nuevo dorsal del jugador. 5 Usuario Indica el nuevo dorsal del jugador. 6 SISTEMA Solicita al actor que seleccione la nueva posici´on del jugador. 7 Usuario Selecciona la nueva posici´on del jugador. 8 SISTEMA Solicita al actor que especifique el nuevo nombre del jugador. 9 Usuario Indica el nuevo nombre del jugador. 10 SISTEMA Solicita al actor que proporcione una nueva descripci´on del jugador. 11 Usuario Proporciona una nueva descripci´on del jugador. 12 SISTEMA Solicita al actor que pulse el bot´on “Guardar” cuando est´e conforme. 13 Usuario Pulsa el bot´on “guardar”. 14 SISTEMA Registra el nuevo jugador con el dorsal asociado como nombre de fichero. 15 SISTEMA El caso de uso termina con ´exito. Extensiones Paso Control Descripci´on de la extensi´on 3.a, 5.a 7.a, 9.a 11.a, 13.a Si el usuario solicita cancelar la operaci´on. SISTEMA Solicita al actor confirmaci´on para cancelar el proceso. Usuario Confirma que quiere cancelar el proceso. SISTEMA Informa al actor de la cancelaci´on (volviendo al men´u previo). salir Se abandona el caso de uso, quedando sin efecto. 3.b, 5.b 7.b, 9.b 11.b, 13.b Si el usuario solicita borrar al jugador. SISTEMA Solicita al actor confirmaci´on para borrar al jugador. Usuario Confirma que quiere cancelar el proceso. SISTEMA Navega al caso de uso “Eliminar jugador”. 5.c Si el usuario no quiere proporcionar un nuevo dorsal. Control Se retorna el control al paso 6. 7.c Si el usuario no quiere proporcionar una nueva posici´on. Control Se retorna el control al paso 8. 9.c Si el usuario no quiere proporcionar un nuevo nombre. Control Se retorna el control al paso 10. 11.c Si el usuario no quiere proporcionar una descripci´on. Control Se retorna el control al paso 12. 14.a Si no se ha proporcionado un dorsal v´alido, un nombre y una posici´on. SISTEMA Informa al actor del suceso, inst´andole a que complete todos los campos obligatorios. Control Se retorna el control al paso 4. 14.b Si el dorsal del jugador ya est´a registrado. SISTEMA Informa al actor del suceso, inst´andole a que introduzca otro diferente. Control Se retorna el control al paso 4. Postcondici´on El jugador seleccionado del sistema modifica sus datos con los nuevos introducidos, no duplic´andose ni eliminando otro jugador con mismo dorsal. Tabla 3.15: Escenario del Caso de Uso CU-12: Editar jugador. 44 CAP´ ITULO 3. AN ´ ALISIS Caso de Uso CU-13: Eliminar jugador Precondici´on Disponer de al menos un jugador en el sistema, el cual se est´a editando. Paso Control Descripci´on 1 Usuario Indica que quiere eliminar al jugador que est´a siendo editado. 2 SISTEMA Solicita al actor que pulse el bot´on “Borrar jugador”. 3 Usuario Pulsa el bot´on “Borrar jugador”. 4 SISTEMA Solicita al actor una confirmaci´on para eliminar las jugadas. 5 Usuario Indica que est´a conforme con el borrado del jugador. 6 SISTEMA Elimina al jugador del almacenamiento. 7 SISTEMA Recarga el listado de jugadores, actualizado. El caso de uso finaliza con ´exito. Extensiones Paso Control Descripci´on de la extensi´on 1.a 3.a Si el usuario solicita cancelar la operaci´on. SISTEMA Informa al actor de la cancelaci´on. salir Se abandona el caso de uso, quedando sin efecto. 5.a El usuario no muestra su conformidad. salir Se abandona el caso de uso, quedando sin efecto. Postcondici´on El jugador seleccionado es eliminado del sistema y ya no aparece en la tabla de plantilla. Tabla 3.16: Escenario del Caso de Uso CU-13: Eliminar jugador. Caso de Uso CU-14: Eliminar a todos los jugadores Precondici´on Disponer de al menos un jugador en el sistema, realizando el CU-11. Paso Control Descripci´on 1 Usuario Indica que quiere eliminar todos los jugadores de la plantilla. 2 SISTEMA Solicita al actor que pulse el bot´on “Borrar TODO”. 3 Usuario Pulsa el bot´on “Borrar TODO”. 4 SISTEMA Solicita al actor una confirmaci´on para eliminar a todos los jugadores. 5 Usuario Indica que est´a conforme con el borrado de todos los jugadores. 6 SISTEMA Solicita al actor una confirmaci´on extra para eliminar finalmente a todos los jugadores. 7 Usuario Indica que est´a seguro del borrado de todos los jugadores. 8 SISTEMA Elimina todos los jugadores del almacenamiento. 9 SISTEMA Recarga el listado de jugadores, actualizado. El caso de uso finaliza con ´exito. Extensiones Paso Control Descripci´on de la extensi´on 1.a 3.a Si el usuario solicita cancelar la operaci´on. SISTEMA Informa al actor de la cancelaci´on (regresando al men´u). salir Se abandona el caso de uso, quedando sin efecto. 5.a 7.a El usuario no muestra su conformidad. salir Se abandona el caso de uso, quedando sin efecto. Postcondici´on Todos los jugadores son eliminados del sistema y ya no aparece ninguno en la tabla de plantilla.. Tabla 3.17: Escenario del Caso de Uso CU-14: Eliminar a todos los jugadores. 45 3.5. MODELO DE DOMINIO Caso de Uso CU-15: Gestionar el color de los jugadores Precondici´on Haber iniciado la aplicaci´on y encontrarse en la escena Ajustes. Paso Control Descripci´on 1 Usuario Indica que quiere gestionar el color de las equipaciones. 2 SISTEMA Solicita al actor que modifique los colores a su gusto. 3 Usuario Modifica los colores de ambos equipos hasta que est´a conforme. 4 SISTEMA Solicita al actor que pulse el bot´on “Guardar cambios”. 5 Usuario Pulsa el bot´on “Guardar cambios”. 6 SISTEMA Guarda los nuevos colores en el sistema. El caso de uso finaliza con ´exito. Extensiones Paso Control Descripci´on de la extensi´on 3.a Si el usuario solicita canelar el proceso. SISTEMA Informa al actor de la cancelaci´on, regresando al men´u principal. salir Se abandona el caso de uso, quedando sin efecto. Postcondici´on El color de las equipaciones de los jugadores es modificado, pudiendo ver los cambios en la visualizaci´on previa de ajustes, y en la escena jugadas. Los colores se mantienen hasta el siguiente cambio. Tabla 3.18: Escenario del Caso de Uso CU-15: Gestionar el color de los jugadores. Caso de Uso CU-16: Cambiar idioma de la aplicaci´on Precondici´on Haber iniciado la aplicaci´on y encontrarse en el men´u principal. Paso Control Descripci´on 1 Usuario Indica que quiere cambiar el idioma de la aplicaci´on. 2 SISTEMA Solicita al actor que seleccione el nuevo lenguaje en el que mostrar la aplicaci´on. 3 Usuario Selecciona el lenguaje que quiere desde el desplegable. 4 SISTEMA Actualiza el idioma de la aplicaci´on. 6 SISTEMA Guarda la nueva elecci´on de idioma en el sistema. El caso de uso finaliza con ´exito. Extensiones Paso Control Descripci´on de la extensi´on 3.a Si el usuario solicita canelar el proceso. SISTEMA Informa al actor de la cancelaci´on, ocultando el desplegable sin cambiar el idioma. salir Se abandona el caso de uso, quedando sin efecto. 3.b Si el usuario selecciona el lenguaje actual. SISTEMA Informa al actor de la cancelaci´on, ocultando el desplegable sin cambiar el idioma. salir Se abandona el caso de uso, quedando sin efecto. Postcondici´on El lenguaje mostrado de todos y cada uno de los textos de la app es modificado al lenguaje elegido. El idioma se mantiene hasta el siguiente cambio. Tabla 3.19: Escenario del Caso de Uso CU-16: Cambiar idioma de la aplicaci´on. 3.5. Modelo de dominio En la figura 3.2, se muestra el modelo de dominio. En ´este, se encuentran las clases identificadas a nivel de an´alisis y las relaciones entre ellas. 46 CAP´ ITULO 3. AN ´ ALISIS El modelo de dominio es una representaci´on conceptual de las clases que conforman un software en espec´ıfico. Se describen las entidades que las conforman, as´ı como sus atributos y las relaciones con otras entidades. Figura 3.2: Modelo de Dominio. 3.6. Flujo de la App Con la finalidad de tener una visi´on clara del flujo de acciones que se pueden realizar en la App, se presenta la figura 3.4, el diagrama de proceso (desde el men´u principal). Como ya coment´e en el subcap´ıtulo 5.2.2, ´estos permiten visualizar mediante un diagrama de actividades los procesos elementales de negocio, es decir, plasmar los requisitos como acciones que realizan los usuarios. Para ayuda del lector, se incluye una peque˜na leyenda, figura 3.3, que se tomar´a como base para explicar los conceptos. En la figura 3.3 se pueden observar 5 elementos que conforman el diagrama de proceso, y cada uno presenta una nota rosa correspondiente a su nombre, tom´andolo as´ı como gu´ıa. 1. Nodo inicial. Desde el cu´al parte el flujo, es la acci´on que inicia el sistema. 2. Nodo final. Independientemente de las tareas desarrolladas, todo flujo debe terminar, y debe hacerlo en este s´ımbolo. 3. Acci´on. Las acciones son un conjunto de operaciones que una vez se inician, terminan. Son aquellas que brindan funcionalidad al sistema, y en la figura 3.4 se diferencian por colores para facilitar el seguimiento: rojo para salir de la aplicaci´on, naranja para indicar que nos encontramos en el men´u, morado para navegar hacia este, azul para los casos de uso principales, verde para los casos de uso que los extienden y amarillo (el ´unico por defecto) para el resto de las acciones. 4. Nodo de uni´on o decisi´on. Estos nodos cumplen dos funcionalidades. O bien se usan para decidir qu´e opci´on de entre las posibles (la pregunta es planteada en la flecha que llega al nodo) y as´ı continuar, o bien 47 3.6. FLUJO DE LA APP para recoger flechas que llegados a ese punto (nodo) continuar´ıan de una misma manera, simplificando as´ı el diagrama disminuyendo el n´umero de l´ıneas presentes. 5. Flecha de flujo Unen actividades y nodos, permitiendo y aclarando, la navegaci´on por el sistema. Figura 3.3: Leyenda del diagrama de proceso. Finalmente, se muestra el diagrama del men´u, figura 3.4, seguido de los diagramas de los dem´as casos de uso de la aplicaci´on, accesibles desde ´este. Figura 3.4: Diagrama de proceso desde el men´u principal. 48 CAP´ ITULO 3. AN ´ ALISIS Figura 3.5: Diagrama de proceso del caso de uso: Gestionar jugadas din´amicas 49 3.6. FLUJO DE LA APP Figura 3.6: Diagrama de proceso del caso de uso: Listar jugadas guardadas Figura 3.7: Diagrama de proceso del caso de uso: Dibujo libre en pizarra 50 CAP´ ITULO 3. AN ´ ALISIS Figura 3.8: Diagrama de proceso del caso de uso: Gestionar plantilla jugadores 51 4.3. DISE ˜ NO DETALLADO DE PAQUETES Figura 4.5: Dise˜no detallado del paquete Sprites. Figura 4.6: Dise˜no detallado del paquete Scripts. 58 CAP´ ITULO 4. DISE ˜ NO Figura 4.7: Dise˜no detallado del paquete PreFabs. 4.4. Dise˜no de la Base de Datos Tras analizar los objetivos a cumplir, y formarme en Unity, r´apidamente me percato de que no es necesario crear una base de datos para este proyecto, y que de hecho, ser´ıa contraproducente. Las bases de datos en Unity suelen implementarse con SQLite (aunque la mayor´ıa de juegos simples no las usan, como pude apreciar en mi b´usqueda [34]), lo cual no supon´ıa un problema puesto que es abordado en la carrera. Pero se toma esta decisi´on, de prescindir de base de datos debido a las siguientes razones: Complejidad innecesaria. Las acciones que requerir´ıan almacenamiento persistente, teniendo en cuenta que no hay registro, son el guardado de jugadas, capturas de pantalla y jugadores. Debido a que no se trata informaci´on privada de los usuarios, no se requiere de una seguridad extra que aporta una base de datos. Los elementos que son almacenados son f´acilmente exportables como GameObjects que son, y por tanto, su guardado es pr´acticamente inmediato. Las ediciones de jugadores se pueden realizar sobre el propio archivo, por lo que se simplifica el tratamiento de los ficheros. A fin de cuentas, encontrar una soluci´on completamente v´alida para un problema, que lleva menos tiempo y simplifica todos los procesos, es admirada en cualquier empresa software. Mantenibilidad. Mantener una base de datos con el tiempo es una tarea que conlleva cierta dedicaci´on. Teniendo en cuenta que para las acciones actuales la presencia de una base de datos no aporta grandes ventajas, es mejor mantener el software simple, prescindiendo de la gesti´on de una base de datos. Compartir archivos. Al no disponer de una base de datos, y s´ı de ficheros binarios corrientes, la compartici´on de jugadas y jugadores entre dispositivos es sumamente simple para el usuario final, no implicando m´as operaciones por su parte que copiar y pegar archivos. 59 4.5. DISE ˜ NO DE LA INTERFAZ DE USUARIO 4.5. Dise˜no de la Interfaz de Usuario Este proyecto Unity tiene por finalidad su ejecuci´on en Android, pero tambi´en contempla su uso en otros sistemas operativos, como son Windows y macOS. En cualquier caso, el rasgo principal que debe caracterizar a la app es la simplicidad de uso, una interfaz sencilla que permita a todos los usuarios, independientemente de sus aptitudes inform´aticas (usabilidad), manejar sin problemas todos los casos de uso a implementar. Esta secci´on se basa en gran medida en la asignatura Interacci´on Persona Computadora [18], que aporta muchos de los conceptos clave necesarios, ya que de la interacci´on entre la persona y la m´aquina puede depender el ´exito o fracaso de cualquier aplicaci´on. Por tanto, la interfaz se puede definir como aquella parte de la app que permite al usuario interactuar con la computadora, y a ´esta informar de los cambios que se producen en el modelo 4.1. En la interfaz tambi´en se tiene en consideraci´on al hardware, que en este caso ser´ıa o bien la pantalla t´actil de una tablet (con su control t´actil para todos los elementos, inlcu´ıdo el teclado) o rat´on y teclado convencional si se dispone de la posibilidad inal´ambrica, o bien, se ejecuta desde un ordenador. El inter´es en el dise˜no de interfaces de usuario es muy alto, debido a que juega un papel fundamental en el ciclo de vida de una aplicaci´on (el 50 %, seg´un un estudio de Myers & Rosson en 1992). No es una cuesti´on trivial, puesto que las personas somos impredecibles, y acertar con un dise˜no agradable y acorde a la mayor´ıa, no es ni mucho menos sencillo. Para ello se han de seguir unas gu´ıas de dise˜no que ayuden a enfocar correctamente el dise˜no de la interfaz, y siendo necesarias las pruebas con usuarios reales (no t´ecnicos) para detectar cuanto antes dificultades de uso. En los siguientes subcap´ıtulos tratar´e de ampliar estos conceptos, exponiendo adem´as el dise˜no de la interfaz de usuario del proyecto. 4.5.1. Usabilidad Comentada anteriormente, la aplicaci´on debe ser usable, que es la capacidad de un producto para alcanzar los objetivos marcados, en un contexto espec´ıfico, con criterios de: Eficacia. Cumplir con los requisitos, de manera precisa. Eficiencia. Lograr los objetivos con una calidad notable, con respecto a los recursos empleados. Satisfacci´on. El usuario debe encontrarse c´omodo ante el uso de la aplicaci´on. Para ello, no debe suponer un gran esfuerzo de aprendizaje para el usuario, manteniendo lo m´as simple posible cada aspecto. Esto se puede medir en funci´on de si el usuario es capaz de deducir todas las funcionalidades de un sistema, simplemente explorando. Y de la misma manera, mantener al m´ınimo la necesidad de recuerdo, es decir, que el usuario pueda permanecer grandes periodos de tiempo sin utilizar la aplicaci´on y que esto no repercuta en ser capaz de recuperar su nivel. La eficiencia, en ´este ´ambito, trata sobre lograr el m´ınimo esfuerzo a dedicar por parte del usuario. 60 CAP´ ITULO 4. DISE ˜ NO Cabe recordar que todos podemos errar como usuarios, el tratamiento de errores humanos juega un papel fundamental en cualquier sistema inform´atico. Por ejemplo, si el usuario quiere regresar al men´u sin haber guardado una jugada, debe mostrarse un aviso por pantalla que le informe de ello, quedando en su mano salir sin guardar, pero habiendo evitado el despiste. Se trata de evitar riesgos, pese a que pueda entorpecer el uso normal de la aplicaci´on. La tolerancia al error estar´a en mano del usuario, ya que ser´a quien tenga siempre la ´ultima palabra. Finalmente, la satisfacci´on por parte del usuario es clave, si no se siente a gusto, no seguir´a usando la aplicaci´on, por buena que sea. Es problem´atico, ya que no es algo tan objetivo como poder realizar todas las tareas o hacerlas eficientemente y sin posibilidad de errores; lo que es agradecido por algunos, puede ser aborrecido por otros, por lo que deben evitarse extremos, y medir la satisfacci´on mediante cuestionarios. Toda retroalimentaci´on es bien recibida, y debe ser analizada para avanzar en el camino correcto. Con todo ello, podemos se˜nalar a la interfaz como la encargada de mostrar el modelo del sistema (un modelo completo y correcto del funcionamiento) de una forma adecuada al usuario, para que lo entienda correctamente. Para lograrlo, se emplean los principios de dise˜no, recomendaciones generales de dise˜no basados en la experiencia, y en la forma de pensar, valorando especialmente: Comprensi´on intuitiva. La percepci´on de la interfaz gu´ıa al usuario, en base a su experiencia previa. Un ejemplo inform´atico ser´ıa el uso de logos bien conocidos, como el de una papelera para eliminar ficheros, una barra para visualizar elementos de una lista, o los iconos de un reproductor de v´ıdeo, todos comparten el mismo patr´on; ser sumamente conocidos y extendidos, de manera que sean f´acilmente reconocibles. Visibilidad. Todo aquello que se pueda controlar debe quedar al alcance del usuario. Aquello no presente, como puede ser el manejo mediante gestos, no resulta intuitivo al usuario, y por tanto, requiere de un esfuerzo adicional para su aprendizaje. El usuario debe tener claro qu´e puede hacer, y cu´al es el cambio que produce en cada momento, por lo que se ha de mantener informado al usuario para que sea consciente de la actividad que est´a realizando y a cuales podr´ıa avanzar. Retroalimentaci´on. Las acciones realizadas por el usuario deben mostrar un efecto visible, e inmediato (o al menos, un indicador de carga si la espera es mayor a 1 segundo). Generalmente ser´a informaci´on visual, pero tambi´en puede ser sonora o t´actil. En este TFG las respuestas ser´an visuales, ya que la informaci´on sonora (pese a ser una ayuda para personas con discapacidades visuales), generalmente es un inconveniente: entornos ruidosos que impiden su apreciaci´on, situaciones en las que el ruido ambiente no es permitido, personas con dificultades auditivas... Consistencia. Aquellos aspectos similares deben actuar de manera similar, y aquello que sea diferente, no debe parecerse. Esto es un claro ejemplo de las acciones destructivas (borrado de ficheros, p´erdida del progreso) o de navegaci´on en la aplicaci´on, en las primeras, el color rojo nos indica alerta y el verde seguridad; mientras que en la navegaci´on por la interfaz, es aconsejable emplear un mismo indicador, posicionado siempre en la misma zona (superior izquierda, preferiblemente). El usuario se comunica con la m´aquina mediante dispositivos apuntadores (en este caso el control t´actil o mediante teclado y rat´on). Conociendo cuales son los m´etodos de los que dispone el usuario, se puede dise˜nar de una manera m´as acorde. En este caso, el dispositivo objetivo es una tablet com´un de 10.1”, un dispositivo relativamente peque˜no, por lo que hay que prestar suficiente espacio entre acciones, para evitar pulsaciones err´oneas, de la misma manera que se deben agrupar las funcionalidades similares (minimizando el movimiento), y alejando aquellas acciones que pueden ser peligrosas como el borrado de elementos. 61 4.5. DISE ˜ NO DE LA INTERFAZ DE USUARIO Dada la naturaleza del proyecto, los men´us desplegables no parecen ser necesarios, y atendiendo a la ley de Fitts se descartan finalmente debido a la complejidad que representan, siendo m´as lentos (en comparaci´on a otros m´etodos), y no olvidando la alta probabilidad de equivocarse eligiendo otro submen´u. Volviendo a los errores, se trata de poner especial atenci´on a los lapsus y deslices, es decir, evitar que el usuario se equivoque limitando las acciones peligrosas, ya que los errores de concepto que pueda tener el usuario son m´as dif´ıciles de corregir. Deshabilitando funcionalidades (o m´as bien, los botones que las permiten) cuando no est´en disponibles, disuade errores y gu´ıa en cierta parte al usuario, esto se ve claramente con las jugadas din´amicas, al no poder reproducirlas mientras no haya pasos. Otra medida tomada en cuenta fue respetar el trabajo del usuario, procurando no borrar la informaci´on introducida mientras no lo solicite, como es el caso del guardado temporal de campos de texto, en la creaci´on de un jugador en plantilla, mientras permanezca en dicha escena. 4.5.2. Gu´ıas de dise˜no Son una serie de ideas que se pueden aplicar a un producto para facilitar su dise˜no, marcando los pasos que se pueden y no se pueden dar. No hay que olvidar que son plantillas generalistas, y que no resuelven todos los problemas. Algunas de las consideraciones tenidas en cuenta son: Importancia de los colores. No es recomendable mostrar demasiados colores en una sola pantalla, y si por alg´un casual deben aparecer, no han de aparecer muy juntos. Por otra parte deben mantenerse tonos similares en toda la aplicaci´on. Colores “conocidos”. Es recomendable el uso del color rojo para tareas de alerta, cancelar o salir, y el verde para confirmaciones y acciones no destructivas. Estos colores son reconocidos por cualquier persona en la sociedad ya que son reconocibles desde otros ´ambitos, como pueden ser los sem´aforos. Texto. La importancia del texto es crucial. Debe mostrarse informaci´on escrita con un tama˜no adecuado de letra, y no debe ser muy extenso, disponer de m´as de 60 caracteres de ancho, es considerada una mala pr´actica. Uso de men´us. Los men´us no debe ser muy extensos siguiendo la ley Hick-Hyman. Si se presentan demasiadas opciones u ocupan un espacio excesivo, es muy probable que abrumen al usuario. Manejo de acciones. Aquellas acciones peligrosas, tales como los borrados, deben permanecer alejadas de otras para evitar as´ı llevarlas a cabo por un lapsus. Misma disposici´on. Recientemente, con la llegada de los smartphones, los cuales incorporan aceler´ometros que le permiten estar al tanto de su orientaci´on, adecuando la visualizaci´on para que el usuario nunca vea algo del rev´es. Sin embargo, esto genera problemas en el dise˜no de interfaces. En este caso, puesto que la rotaci´on autom´atica no tiene mucho sentido (y menos cuando se puede usar la aplicaci´on en dispositivos sin estas caracter´ısticas), se prescinde de ella mostr´andose siempre en la misma posici´on (horizontal) y en una disposici´on en particular para respetar las fundas comunes de tablet que tengan un atril. 62 CAP´ ITULO 4. DISE ˜ NO 4.5.3. Dise˜no de la Interfaz de Usuario En este subcap´ıtulo se expondr´an, por escenas/ funcionalidades, los prototipos dise˜nados como base para la implementaci´on de la interfaz, destacando algunas de las decisiones consideradas. Como prototipos, no se corresponden totalmente con la versi´on final implementada. Se debe tener en cuenta que el dispositivo objetivo es una tablet Android de 10.1”, las m´as comunes. Los prototipos son dise˜nados de manera digital porque permite rectificar m´as f´acilmente, y las im´agenes usadas pod´ıan llegar a usarse en la implementaci´on, como ocurri´o. Men´u principal El men´u inicial trataba ser simple y mostrar los elementos de manera clara y ordenada. Es sustituido debido a que el dise˜no no se asemeja a los est´andares actuales, m´as modernos con logos simples. Figura 4.8: Prototipo inicial del men´u principal. Por otra parte quisiera rese˜nar el dise˜no del icono de la app, que ser´a una aspecto visual s´olo apreciable en el dispositivo, antes de lanzar la app. Figura 4.9: Prototipo de icono de la aplicaci´on. 63 4.5. DISE ˜ NO DE LA INTERFAZ DE USUARIO Jugadas din´amicas El punto central de las jugadas din´amicas, figura 4.10, es lograr una correcta visualizaci´on de los m´ultiples botones, que se disponen por los bordes, y poder movilizar correctamente los jugadores. La disposici´on inicial de los jugadores en el campo es por tanto un aspecto clave, ya que no tiene mucho sentido que todos partan desde la zona de banquillo. El uso habitual involucrar´a a la totalidad de los jugadores, si estos est´an dispuestos en el campo en una formaci´on general, involucra menos movimientos, o m´as cortos, por parte del usuario. Figura 4.10: Prototipo de jugadas din´amicas. El dise˜no de la imagen que representa el bal´on (figura 4.11), tiene por finalidad su correcta visualizaci´on en el terreno de juego, no confundi´endose con los jugadores. Para ello, se elige una imagen de bal´on gen´erico con dos colores, en forma de espiral, ya que el color contrasta notablemente con el del terreno de juego. Como es un elemento clave del juego, se representa con un tama˜no ligeramente mayor que el de los jugadores, para que pueda apreciarse en todo momento. Figura 4.11: Prototipo del bal´on de juego. Pizarra El prototipo de la pizarra libre, figura 4.12, ha sido el ´unico que no ha sufrido modificaciones en su implementaci´on final. Se predisponen los elementos de dibujo al lateral derecho dejando as´ı m´as area de dibujo. El bot´on de Borrar TODO estar´a protegido, por lo que no ocurrir´an lapsus pese a encontrarse cerca de los ´utiles de dibujo. 64 CAP´ ITULO 4. DISE ˜ NO Figura 4.12: Prototipo de la pizarra de dibujo libre. En la figura 4.13, se puede apreciar una de las pantallas de aviso al usuario, en este caso pregunta por borrar todo aquello que se dibujase. El resto de pantallas de aviso son muy similares, por lo que no expondr´e todas ellas debido al gran n´umero de estas. Figura 4.13: Prototipo de aviso de borrado en pizarra. Lista de jugadas Para poder eliminar las jugadas que se hayan dise˜nado, ya sea por error u otras consideraciones, se presentan en forma de listado como puede apreciarse en la figura 4.14. Con una cantidad m´ınima de botones se logra seleccionar s´olo aquellas que se quieren borrar, todas, o desmarcarlas. Borrando as´ı la cantidad deseada por el usuario. 65 4.5. DISE ˜ NO DE LA INTERFAZ DE USUARIO Figura 4.14: Prototipo de un listado de jugadas. Plantilla de jugadores De manera an´aloga, en forma de tabla se presentan los jugadores de la plantilla del club, figura 4.15, con los campos m´ınimos que ayuden a identificarlo, primando el campo de Apuntes, pues es lo realmente ´util para el entrenador, en conjunto con la posici´on que desempe˜na. Figura 4.15: Prototipo de un listado de jugadores. 66 CAP´ ITULO 4. DISE ˜ NO En la figura 4.16, se aprecia el dise˜no del men´u de creaci´on y edici´on de los jugadores. Al crearse no se puede borrar, l´ogicamente, por lo que el bot´on estar´a deshabilitado. El espacio entre los botones se establece para los mensajes de error que puedan surgir, como por ejemplo, no poder guardar un jugador debido a que ya existe otro con dicho n´umero. Figura 4.16: Prototipo de creaci´on/ edici´on de un jugador. Ajustes El prototipo de ajustes inicial, figura 4.17, muestra 8 equipaciones posibles tanto para el equipo propio como para el rival, con una visualizaci´on previa de c´omo se ver´ıan en el terreno de juego, y junto al bal´on. Con esta opci´on, si por ejemplo el azul era elegido para el equipo propio, quedar´ıa imposibilitado para el rival, no pudiendo coincidir nunca. Im´agenes implementadas Algunas de las im´agenes empleadas en el prototipado, fueron descargadas desde repositorios de im´agenes gratuitas, las cuales fueron aplicadas tambi´en a la interfaz. A continuaci´on listo los enlaces a las mismas, para dar el cr´edito que merecen sus autores: Bal´on para el logo Icono de men´u: Ajustes Icono de men´u: Plantilla Icono de men´u: Salir Banderas de pa´ıses para idiomas 67 4.6. REALIZACI ´ ON EN DISE ˜ NO DE CASOS DE USO Figura 4.23: Realizaci´on en dise˜no del CU06: Listar jugadas guardadas. 74 CAP´ ITULO 4. DISE ˜ NO Figura 4.24: Realizaci´on en dise˜no del CU07: Eliminar jugadas guardadas. 75 4.6. REALIZACI ´ ON EN DISE ˜ NO DE CASOS DE USO Figura 4.25: Realizaci´on en dise˜no del CU08: Dibujo libre en pizarra. 76 CAP´ ITULO 4. DISE ˜ NO Figura 4.26: Realizaci´on en dise˜no del CU09: Guardar captura pantalla. 77 4.6. REALIZACI ´ ON EN DISE ˜ NO DE CASOS DE USO Figura 4.27: Realizaci´on en dise˜no del CU10: Gestionar plantilla jugadores. 78 CAP´ ITULO 4. DISE ˜ NO Figura 4.28: Realizaci´on en dise˜no del CU11: A˜nadir jugador. 79 4.6. REALIZACI ´ ON EN DISE ˜ NO DE CASOS DE USO Figura 4.29: Realizaci´on en dise˜no del CU12: Editar jugador. 80 CAP´ ITULO 4. DISE ˜ NO Figura 4.30: Realizaci´on en dise˜no del CU13: Eliminar jugador. 81 4.6. REALIZACI ´ ON EN DISE ˜ NO DE CASOS DE USO Figura 4.31: Realizaci´on en dise˜no del CU14: Eliminar a todos los jugadores. 82 CAP´ ITULO 4. DISE ˜ NO Figura 4.32: Realizaci´on en dise˜no del CU16: Cambiar idioma de la aplicaci´on. 83 5.4. CVS CONTROL DE VERSIONES PC Windows b´asico Dispositivo de pruebas antiguo, de 32 bits. Sistema operativo Windows 10, 32 bits. Procesador Intel Core Duo. Dos n´ucleos, 1.4 GHz. Memoria RAM 2GB. Pantalla 19”, 1366x768 p´ıxeles. Formato 16:9. Tabla 5.3: Entorno de desarrollo: PC Windows b´asico. PC Windows medio Ordenador de prestaciones comunes, de 64 bits. Sistema operativo Windows 10, 64 bits. Procesador Intel i5-4570. Cuatro n´ucleos, 3.2 GHz. Memoria RAM 8GB. Pantalla 21”, 1920x1080 p´ıxeles. Formato 16:9. Tabla 5.4: Entorno de desarrollo: PC Windows medio. 5.4. CVS Control de Versiones 5.4.1. GitLab GitLab [17] es una aplicaci´on completa destinada a desarrolladores software, en concreto para los ciclos de desarrollo (creaci´on de los componentes software a partir de los dise˜nos ideados previamente) y despliegue (hacer disponible el software para su uso, tras las pruebas). Adem´as, la escuela nos permite hacer uso de esta plataforma con cuentas de funcionalidad “Premium”, siendo ´esto una gran ventaja sobre la versi´on normal (mejor trabajo entre equipos, mayor capacidad de control y minutos de pruebas, entre otras). Cuenta con numerosas herramientas para facilitar el desarrollo y gesti´on de software: Planificaci´on. Mediante issues (tareas o asuntos que resolver) se pueden organizar las funcionalidades a alcanzar, dividiendo as´ı en peque˜nas tareas el trabajo completo que debe ser alcanzado. Se establece un nombre identificativo para la tarea, as´ı como una descripci´on y la posibilidad de agregar a un miembro del equipo como encargado de la misma. Tambi´en se incluye un tablero Kanban [24] (figura 5.1), con el que se pueden vislumbrar f´acilmente las tareas que faltan por hacer, aquellas que est´an en progreso, que fueron finalizadas, en fase de revisi´on, o aprobadas (y cualquiera que se quiera a˜nadir por parte del usuario, para su mejor gesti´on personal). Las issues pueden tener una fecha estimada de fin, facilitando el visionado de las que est´an prontas a vencer, y recibiendo avisos por aquellas que deber´ıan estar completadas pero que no se lograron a tiempo. Control de versiones. La creaci´on de repositorios3es uno de los aspectos m´as conocidos, ya que permite recuperar versiones del software espec´ıficas. Esto es ´util en caso de tener que regresar a un punto anterior por cualquier motivo, generalmente el dejar de lado una funcionalidad por ser inalcanzable. Este control se lleva a cabo mediante: •Ramas. Cada rama, permite a los miembros del equipo trabajar en sus tareas sin interferir en el trabajo de otros. Es muy com´un tener una jerarqu´ıa donde existe una rama master donde se vierten las versiones del software, se usa por tanto, exclusivamente para los entregables. Tambi´en la rama develop 3Espacio digital centralizado donde se almacena, mantiene y distribuyen archivos inform´aticos. 90 CAP´ ITULO 5. IMPLEMENTACI ´ ON Figura 5.1: Ejemplo de tablero de Issues. Fuente: [16]. la considerada rama com´un, donde es volcado el trabajo del resto de ramas para su puesta en com´un. Desde develop, surgen las ramas de feature’s (del ingl´es caracter´ıstica o funcionalidad), peque˜nas tareas que aportan al global de la aplicaci´on. •Resoluci´on de conflictos. Pese a la naturaleza de las ramas, en ocasiones se debe desarrollar en paralelo alguna parte del sistema, y por tanto, puede haber conflictos entre las diferentes aportaciones de c´odigo. Esto es revisado f´acilmente desde GitLab, donde nos avisa de ´estos a la hora de hacer un merge request, marcando en rojo las partes de c´odigo involucradas. •Commits. Mediante esta operaci´on, se sincronizan los cambios implementados en local por el desarrollador, incorpor´andolos al repositorio. Es un est´andar acompa˜nar al commit con un mensaje declarativo de aquello que se ha logrado implementar, y no realizarlo en caso de tener errores de compilaci´on del c´odigo. Estos cambios son almacenados en la rama de desarrollo que se est´e utilizando. •Merge requests. Tras al menos un commit, se puede realizar la operaci´on de fusi´on a otra rama, generalmente a develop. Resultando as´ı en la combinaci´on de los ficheros modificados por el programador, con nueva funcionalidad, con lo ya presente en la rama destino. En definitiva, GitLab es una excelente herramienta para la gesti´on del c´odigo. 5.4.2. Copias locales Como m´etodo alternativo de seguridad, aparte de la copia local, emplear´e dos discos duros, donde guardar´e todas las versiones del proyecto como zip; y la versi´on actual de cada momento, como directorio completo. Atendiendo as´ı al riesgo R13 de la tabla 2.1. 91 5.5. ASPECTOS RELEVANTES SOBRE LA IMPLEMENTACI ´ ON 5.5. Aspectos relevantes sobre la implementaci´on 5.5.1. Unity, conceptos clave/b´asicos aprendidos Quisiera exponer debido a las diferencias que supone el desarrollo en Unity en comparaci´on a otros lenguajes de programaci´on m´as t´ıpicos del grado, y de la mano del manual de Unity [44], algunos de los conceptos claves empleados con esta tecnolog´ıa. Assets Son la representaci´on de cualquier item que puede ser usado en el proyecto, y que son archivos importados en Unity como im´agenes, v´ıdeos, m´usica, texturas (propias o generales), controladores de animaciones, modelos 3D, etc [45]. En cualquier caso, el archivo original permanece intacto, puesto que se crea una copia como una representaci´on en el juego. Si posteriormente se realizan modificaciones en los Assets, ´estas pueden aplicarse actualiz´andolos f´acilmente. A su vez puede encontrarse en la Asset Store una gran cantidad de ´estos ya sean de manera gratuita o de pago, para ayudar al programador a desarrollar a partir del trabajo previo de otros. Esta idea es la misma que vimos en la asignatura Dise˜no Basado en Componentes y Servicios [25] donde una extensa tienda de componentes permite reutilizar c´odigo al programador, para tardar menos tiempo, usar menos recursos, y lograr un mejor resultado final. Escenas Son Assets que contienen la aplicaci´on o parte de ella, ya que es donde se sit´ua el contenido. Las escenas permiten crear niveles de un juego o separar partes de una aplicaci´on. Para crear una escena debe hacerse desde una plantilla, las cuales proporcionan una preconfiguraci´on, ayudando de esta manera al programador simplificando su tarea al presentar todos los elementos que necesita para empezar. De hecho, se pueden crear plantillas propias (que son almacenadas como Assets), teniendo as´ı el programador un resultado personalizado para lo que necesite. Toda escena en Unity debe tener una c´amara para poder visualizar correctamente los elementos presentes en el Canvas, por convenci´on, la primera c´amara habilitada es conocida como Main Camera. Las escenas son, por tanto, la manera de separar las diferentes vistas que tiene una aplicaci´on. Una ser´a el men´u principal, desde el cual se puede regresar al sistema, y las dem´as, diferentes escenas que aportan la funcionalidad por medio de los diferentes objetos presentes en ellas y los scripts que los modifican. As´ı que para navegar entre escenas solo hace falta introducir una transici´on, y tener en cuenta la situaci´on de la escena actual. Canvas En el canvas [46] se sit´uan todos los elementos de interfaz de usuario, es un GameObject con un Component de tipo Canvas, del cual parten todos los elementos de interfaz de usuario, que son sus hijos. Por medio del sistema de eventos se comunica con el sistema de mensajes. 92 CAP´ ITULO 5. IMPLEMENTACI ´ ON Los objetos presentes en el canvas siguen una jerarqu´ıa, donde el primer hijo es posicionado primero, y se sigue el orden natural, pudiendo sobreponerse unos a otros, por lo que para reordenarlos basta con cambiar el orden de la jerarqu´ıa (pudiendo realizarse de manera manual o v´ıa script, mediante los m´etodos de Transform Component). Un canvas se puede renderizar para ser empleado en una pantalla, c´amara, o en un mundo (lo que podr´ıa ser el escenario de un videojuego 3D). Los cambios en una pantalla, como puede ser el tama˜no, o entre pantallas (resoluci´on) son tenidos en cuenta aqu´ı y debe asegurarse que funcionar´a de manera autom´atica. Emplear un Canvas como c´amara es similar a una pantalla, con la salvedad de la distancia que incorpora la c´amara. ´ Esta es la encargada de dar la perspectiva, el campo de visi´on, el ´angulo con el que se interpreta..., por lo que los ajustes modificar´an la manera de contemplar el escenario. Y en caso de emplear el espacio de mundo, el canvas se comporta como cualquier otro objeto, enfoc´andose en aquello que puede apreciarse. Component Un componente incluye de manera autocontenida instrucciones de c´odigo y que implementan cierta funcionalidad. Los componentes pueden ser usados por los objetos (GameObjects) para reunir funcionalidades y crear las aplicaciones por medio de peque˜nos bloques de c´odigo. Por ejemplo, para poder hacer clic en un objeto, se a˜nade el componente Selectable, y se registra un capturador de eventos, el cual avisar´a a la l´ogica del programa para actuar conforme a ello, ya sea una pulsaci´on de bot´on, arrastrar un jugador, o pintar una l´ınea sobre el tablero. La idea se basa en crear un sistema conectado por partes m´as peque˜nas de software, reduciendo el tiempo a emplear. A su vez, permite ajustarse a las buenas pr´acticas de programaci´on, como es la reutilizaci´on, modularidad y una mayor calidad en el producto final. GameObject [47] Son los objetos fundamentales de Unity y representan los escenarios y aquello que se incluya en ´estos, actuando como contenedores de los Componentes que se encargan de la funcionalidad. Figura 5.2: GameObject que representa a un cubo. Fuente: [47] 93 5.5. ASPECTOS RELEVANTES SOBRE LA IMPLEMENTACI ´ ON [49] Los sprites son objetos 2D, y un tipo de Asset que puedes importar al proyecto. Por ejemplo las im´agenes al trabajar en 2D como es el caso, son Sprites de manera autom´atica. Prefabs El sistema de Prefabs [48] permite crear, configurar y almacenar un GameObject por completo (componentes, propiedades y GameObjects hijos) en un Asset reusable. Es una plantilla desde la cual se pueden crear instancias para los objetos de una escena. En caso de querer disponer en una escena de varios GameObjects “iguales”, se deber´ıa realizar con un Prefab, en nuestro caso para los jugadores, por ejemplo. La diferencia reside en que, de esta manera, todas las copias quedan sincronizadas, y permiten realizar cambios de manera conjunta, al aplicarlos al prefab. Los Prefabs permiten crear una jerarqu´ıa, de tal manera que se puedan conseguir objetos m´as complejos, pero que sean modificables de manera sencilla desde los diferentes niveles. Y, evidentemente, no todas las instancias son id´enticas pudiendo modificar sus propiedades (o siguiendo el ejemplo, posiciones), pudiendo llegar a crear variantes de los prefabs. Ejemplos de Prefabs ser´ıan los jugadores, los botones de movimiento r´apido, los rotuladores de la pizarra, los botones atr´as y todas las filas que son mostradas en cualquier parte de la app. Scripts Los scripts (peque˜nos fragmentos de c´odigo interpretado por otros programas, y no por el procesador como es el caso de los programas compilados) permiten crear componentes propios para controlar la aplicaci´on, manejar eventos que se produzcan (como la interacci´on del usuario) o modificar las propiedades de Componentes. ´ Estos pueden ser aplicados a los GameObjects para modificar su comportamiento. Programados en C# (ver secci´on 5.1.2) se ejecutan en la aplicaci´on todo el tiempo que est´e activa, la primera vez con la funci´on Start() y una vez por frame con Update(). Son, por tanto, la parte central de cualquier aplicaci´on Unity, pues es lo que la hace responsiva. En los Scripts encontraremos por ejemplo: los cambios de escena, el manejo de eventos que realice el usuario, como son los movimientos de jugadores en la creaci´on de jugadas din´amicas y tambi´en los cambios necesarios para guardar y eliminar jugadas, entre otros. 5.5.2. Desarrollo de la pizarra Para la funcionalidad de la pizarra (o escena en Unity) se ha empleado un Asset descargado [35] desde el Asset Store, gratuito, que presentaba pr´acticamente la totalidad de funcionalidad requerida. Puede ser consultada desde la p´agina web del Asset Store, todos los derechos a su creador. Realmente fue enriquecedor poder encajar la funcionalidad provista en la aplicaci´on. El hecho de que resolviese el problema no evit´o que tuviera que adaptar el c´odigo a la estructura del proyecto. Adem´as de cambios visuales, se corrigieron m´ınimas imperfecciones, y se agregaron otras funcionalidades, como son las capturas de pantalla y las comprobaciones de seguridad para evitar despistes. 94 CAP´ ITULO 5. IMPLEMENTACI ´ ON En la Universidad, hab´ıamos tratado previamente con componentes, pero siempre los hab´ıamos creado nosotros, o los profesores proporcionaban algo similar a una API, la cual pod´ıamos usar de manera sencilla. Personalmente, me alegro de haberlo encontrado y haber podido aplicar los conceptos estudiados para integrar una soluci´on real, presente en el mercado al software que estaba desarrollando, ya que es una pr´actica habitual en el mundo laboral, donde constantemente debes trabajar con APIs y componentes prefabricados. Ha sido, en definitiva una gran y enriquecedora experiencia. 5.6. ¿C´omo se asegura la protecci´on de datos de los usuarios? La importancia de la protecci´on de datos fue tratada en el subcap´ıtulo 3.3 en el que adem´as se expone c´omo EntrenaBal no solicita pr´acticamente ning´un dato a los usuarios. Los datos solicitados son meramente de los jugadores, y son: su nombre (o apodo), su dorsal, y la posici´on en la que juegan. Ninguno de estos datos es cr´ıtico y no se comparten con terceros ni se analizan. Pese a todo, podr´ıa decirse que los datos est´an seguros, ya que: No se utilizan servicios de terceros, por lo que no hay que aceptar la pol´ıtica de privacidad de otras aplicaciones o empresas. Todo el almacenamiento es local, por lo que la seguridad e integridad de ´este, depende ´unicamente del usuario. Si el m´etodo de seguridad o contrase˜na de su dispositivo es vulnerable, o directamente no tiene, es responsabilidad ´unicamente del usuario. Y finalmente, no supone ning´un riesgo, ya que los datos involucrados son p´ublicos, considerando que su disposici´on en el campo determina su posici´on, y el n´umero y el dorsal aparecen en la camiseta de juego. 95 5.6. ¿C ´ OMO SE ASEGURA LA PROTECCI ´ ON DE DATOS DE LOS USUARIOS? 96 CAP´ ITULO 6. PRUEBAS Cap´ıtulo 6 Pruebas En este cap´ıtulo se exponen las pruebas realizadas para asegurar la calidad de la aplicaci´on as´ı como la comprobaci´on de todas las funcionalidades presentes en la app. De igual manera, se exponen las observaciones tras la exposici´on de la aplicaci´on a los usuarios. 6.1. Pruebas de caja negra Las pruebas de c´odigo son una parte fundamental en cualquier desarrollo software. Permiten asegurar la calidad del producto final as´ı como comprobar que se est´an cumpliendo todos los requisitos y objetivos. Las pruebas se clasifican habitualmente en dos grandes grupos: Pruebas de caja blanca. Eval´uan el c´odigo “internamente”, es decir comprueban la correcci´on de la l´ogica implementada. El mayor exponente de ´estas son los test unitarios, los cuales consisten en evaluar los diferentes m´etodos o partes de c´odigo de manera aislada, asegurando que todos funcionan de manera correcta. Se asegura que nada rompe el sistema, es decir, que ninguna acci´on modifica el correcto funcionamiento. Pruebas de caja negra por caso de uso. Por otra parte, este tipo de pruebas se basan en comprobar la funcionalidad sin ver el c´odigo. Se eval´ua de manera externa el correcto funcionamiento del software, para cada uno de los casos de uso; la salida obtenida debe ser igual a la esperada, para todos los casos. Tambi´en resulta interesante evaluar la interfaz gr´afica, al ser una aplicaci´on que se basa en este aspecto, pero es casi imposible realizarlas de manera autom´atica. Por ende, suelen realizarse con usuarios de prueba, que eval´uan la aplicaci´on como se expone en el siguiente subcap´ıtulo. Si bien se han realizado pruebas de caja blanca a cada m´etodo, a continuaci´on se exponen ´unicamente las pruebas de caja negra manuales, a petici´on expresa de mi tutora. Cabe destacar en este punto, el alto componente gr´afico de Unity. La bater´ıa de pruebas detalladas de caja negra, es la siguiente 1: 1CP-01, por ejemplo, equivale a Caso de Prueba 1. 97 6.1. PRUEBAS DE CAJA NEGRA 6.1.1. Jugadas CP-01 Crear una jugada din´amica. Descripci´on Desde la ventana de Jugadas se a˜naden pasos formando una jugada. Entrada Se disponen los jugadores en el terreno de juego, y por cada posici´on se a˜nade un paso mediante el bot´on “+”. Resultado esperado Una jugada que se puede reproducir y guardar correctamente. Tambi´en se pueden a˜nadir m´as pasos tras reproducir. Resultado Correcto. Tabla 6.1: Descripci´on del CP-01: Crear una jugada din´amica. CP-02 Guardar una jugada din´amica. Descripci´on A˜nadir una jugada din´amica al sistema. Entrada La jugada creada en el CP-01. Desde la escena Jugadas se selecciona “Guardar” y en el formulario se introduce un nombre de jugada no existente en el sistema: Nombre: Ataque posicional. Finalmente se selecciona “Confirmar”. Resultado esperado La jugada es a˜nadida y es visible desde la escena Jugadas al seleccionar “Cargar jugada” y desde la escena Listar jugadas. Resultado Correcto. Tabla 6.2: Descripci´on del CP-02: Guardar una jugada din´amica. CP-03 Cargar una jugada din´amica. Descripci´on Se carga una jugada din´amica que fue guardad previamente. Entrada Jugada guardada en el CP-03. Desde la escena Jugadas, se selecciona “Cargar jugada” y se selecciona “Cargar” desde la fila correspondiente a la jugada que tiene por nombre “Ataque posicional”. Resultado esperado La jugada es cargada, el n´umero de pasos as´ı lo indica. Se puede reproducir sin problemas y se visualiza la animaci´on de pasos. Resultado Correcto. Tabla 6.3: Descripci´on del CP-03: Cargar una jugada din´amica. CP-04 Reproducir una jugada cargada. Descripci´on Se reproducen los pasos de una jugada cargada. Entrada Se parte de la jugada cargada del CP-03. Desde la escena Jugadas, y con una jugada cargada, se pulsa el bot´on play. Resultado esperado La animaci´on comienza, mostrando los pasos almacenados de la jugada correctamente. Resultado Correcto. Tabla 6.4: Descripci´on del CP-04: Reproducir una jugada cargada. 98 CAP´ ITULO 6. PRUEBAS CP-05 Reproducir una jugada en creaci´on. Descripci´on Se reproducen los pasos de una jugada que est´a siendo creada. Entrada Se parte de la jugada que est´a siendo creada en el CP-01. Desde la escena Jugadas, y con una jugada que est´a en proceso de creaci´on, se pulsa el bot´on play. Resultado esperado La animaci´on comienza, mostrando los pasos almacenados de la jugada correctamente. Resultado Correcto. Tabla 6.5: Descripci´on del CP-05: Reproducir una jugada en creaci´on. CP-06 Movimiento r´apido de jugadores. Descripci´on Movimiento de los jugadores de ambos equipos. Entrada Desde la escena Jugadas, al crear una jugada se pulsan los botones de movimiento r´apido de ambos equipos. Resultado esperado Se observa que los jugadores de ambos equipos (seg´un el bot´on) van del campo, a la zona de banquillo, y de ´esta a la posici´on inicial. Resultado Correcto. Tabla 6.6: Descripci´on del CP-06: Movimiento r´apido de jugadores. CP-07 Borrar pasos al crear una jugada Descripci´on Se borran los pasos que fueron a˜nadidos a una jugada. Entrada Jugada con pasos a˜nadidos como en el caso del CP-01. Se selecciona “Borrar”. En la pantalla de aviso se selecciona “Si”. Resultado esperado El contador de pasos vuelve a 1. Ahora no se puede reproducir, y no se puede borrar hasta que se a˜nadan m´as pasos. Resultado Correcto. Tabla 6.7: Descripci´on del CP-07: Borrar pasos al crear una jugada. CP-08 Volver a men´u desde Jugadas Descripci´on Desde la escena Jugadas, sin guardar, se vuelve al men´u. Entrada Jugada con pasos a˜nadidos como en el caso del CP-01. Se selecciona “Borrar”. En la pantalla de aviso se selecciona “Salir”. Resultado esperado Se regresa al men´u principal de la aplicaci´on. Resultado Correcto. Tabla 6.8: Descripci´on del CP-08: Volver a men´u desde Jugadas. 99 6.2. PRUEBAS CON USUARIOS 106 CAP´ ITULO 7. CONCLUSIONES Y L´ INEAS DE TRABAJO FUTURAS Cap´ıtulo 7 Conclusiones y l´ıneas de trabajo futuras Una vez finalizado el proyecto, se pueden extraer valiosas conclusiones acerca del mismo as´ı como posibles mejoras implementar en un futuro. 7.1. Conclusiones Todos los objetivos establecidos en el subcap´ıtulo 1.3 han sido cumplidos de manera satisfactoria. A nivel de implementaci´on de hecho, se lograron m´as objetivos que los inicialmente propuestos. A grandes rasgos estos han sido: Gesti´on de proyectos. Familiarizarme con todo el proceso de desarrollo software, si bien no en una profundidad extrema, he podido ampliar mi punto de vista, y conocimientos, as´ı como en el uso de GitLab, y en la gesti´on de riesgos y tiempos. Planificaci´on. La planificaci´on es un elemento clave, y este TFG me ha dado pautas para mi futuro laboral. El tiempo excedido en la planificaci´on inicial ha sido fruto de la inexperiencia en la gesti´on, y en la novedad que supuso C# y el manejo de Unity. En todo caso, considero valiosa la experiencia y tendr´e en cuenta mis fallos para evitarlos en el futuro. Despliegue en Android. Se ha logrado crear una aplicaci´on de gesti´on de balonmano para Android (y tambi´en en Windows y Mac), que facilita al entrenador crear t´acticas y ense˜narlas a sus jugadores. Unity. He aprendido algunas de las funcionalidades que brinda este motor de videojuegos, aunque no hayan sido empleadas, comola cantidad de soporte para juegos 3D de las que dispone. Conocimiento del balonmano. Este trabajo tambi´en me ha hecho darme cuenta de los muchos aspectos a considerar en cualquier deporte, y en particular, en el balonmano. Destacar c´omo el saber m´as acerca de un tema, puede llevar a un equipo de desarrollo a incrementar su planificaci´on inicial. 7.2. L´ıneas de trabajo futuras A continuaci´on, expongo algunas funcionalidades que podr´ıan implementarse en la aplicaci´on con la finalidad de hacerla m´as completa y ´util. Debido a la atenci´on que requieren algunas de ellas, podr´ıa resultar m´as interesante la creaci´on de otra aplicaci´on, que permita a un segundo entrenador o ayudante, estar al tanto. 107 7.2. L´ INEAS DE TRABAJO FUTURAS Control del partido. Mediante un bot´on flotante que puede estar presente en cada secci´on de la aplicaci´on, se permite registrar la actividad de un partido, y las acciones que ocurren en el mismo por medio de diferentes acciones. Adem´as de mostrar un cron´ometro con el tiempo jugado, las acciones se a˜nadir´ıan teniendo esto en cuenta, por medio de botones simples, que lanzasen preguntas al entrenador, como por ejemplo: •Goles. Tras pulsar el bot´on se pregunta qu´e equipo realiza el gol, en caso de que sea el propio, aparecer´a un desplegable con los jugadores, y finalmente permitir´a diferenciar si fue normal, por falta o por penalti. •Faltas o amonestaciones. De manera an´aloga preguntar´ıa si el equipo la ha recibido o la ha provocado, preguntando en todo caso por el jugador involucrado, y el tipo de amonestaci´on: ninguna, verbal, amarilla o roja. •Tiros, fintas, paradas, cambios... Todo aquello que pudiera implementarse sin ocupar un espacio excesivo en pantalla. Formaciones para jugadas. Una de las opciones que quedaron en el tintero en cuanto a las jugadas, fue permitir al entrenador elegir la formaci´on inicial de los jugadores, e incluso crear las suyas propias. Se podr´ıa elegir desde un men´u desplegable en la propia escena, o desde ajustes, para no saturar. Recolecci´on de estad´ısticas. En estrecha relaci´on con el punto anterior, la recolecci´on de los datos de un partido se pueden recolectar y mostrar en diversos gr´aficos para ayudar al entrenador a obtener conclusiones. El an´alisis estad´ıstico de los deportes es desde hace d´ecadas, sin´onimo de ´exito. Sugerencias t´acticas. En una propuesta m´as ex´otica, cabr´ıa la posibilidad de, mediante machine learning, proponer al entrenador cambios en la plantilla inicial, o asociaciones de jugadores con los que el equipo gana m´as, por ejemplo. 108 BIBLIOGRAF´ IA Bibliograf´ıa [1] J. Alrow e I. Neustadt, UML 2 and the Unified Process, 2.aed. Addison-Wesley Professional, 2005. [18] M. Gonzalo, Y. Crespo, C. Hern´andez y A. Mart´ınez, Apuntes de Interacci´on Persona Computadora. Universidad de Valladolid, 2018, Curso 2018-2019. [19] C. Hern´andez, M. Barrio y H. Ortega, Apuntes de Profesi´on y Sociedad. Universidad de Valladolid, 2020, Curso 2020-2021. [20] B. Hughes y M. Cotterell, Software Project Management, 5.aed. McGraw Hill, 2009. [25] M. ´ A. Laguna, Apuntes de Desarrollo Basado en Componentes y Servicios. Universidad de Valladolid, 2020, Curso 2020-2021. [26] C. Larman, UML y Patrones. Introducci´on al An´alisis y Dise˜no Orientado a Objetos y al Proceso Unificado, 2.aed. Prentice Hall, 2004. [37] F. Prieto, Apuntes de Fundamentos de Ingenier´ıa de Software. Universidad de Valladolid, 2018, Curso 2018- 2019. Tema: 2. [41] I. Sommerville, Ingenier´ıa del software, 9.aed. Pearson, 2011, Cap´ıtulo 2. [55] J. M. Vegas, Apuntes de Planificaci´on y Gesti´on de Proyectos. Universidad de Valladolid, 2020, Curso 2020- 2021. 109 BIBLIOGRAF´ IA 110 WEBGRAF´ IA Webgraf´ıa [2] Astah. (2021). ((Astah Professional Software.)) Accedido: 2021-03-07, direcci´on: https : / / astah . net / products/astah-professional/. [3] BLUELINDEN. (2016). ((V´ıdeo demostrativo de creaci´on de jugadas de la App: Pizarra T´actica.)) Accedido: 2021-02-27, direcci´on: https:/ /www.youtube .com/ watch?v= cL9qELNLS6o&t = 4s&ab _channel= BluelindenApps. [4] BLUELINDEN. (2019). (((Aplicaci´on Android) Pizarra T´actica: Balonmano.)) Accedido: 2021-02-27, direcci´on: https://play.google.com/store/apps/details?id=com.bluelinden.coachboardhandball. [5] BOE. (2018). ((XVII Convenio colectivo estatal de empresas de consultor´ıa y estudios de mercado y de la opini´on p´ublica.)) Accedido: 2021-03-06, direcci´on: https://www.boe.es/boe/dias/2018/03/06/pdfs/BOE- A-2018-3156.pdf. [6] BOE. (2020). ((Real Decreto-ley 28/2020, de 22 de septiembre, de trabajo a distancia.)) Accedido: 2021-03-06, direcci´on: https://www.boe.es/diario_boe/txt.php?id=BOE-A-2020-11043. [7] Brackeys. (2017). ((Tutoriales: Unity Begginer Tutorials.)) Accedido: 2021-03-16, direcci´on: https://www. youtube.com/playlist?list=PLPV2KyIb3jR5QFsefuO2RlAgWEz6EvVi6. [8] I. Buckley. (2019). ((Lenguajes de desarrollo para Unity.)) Accedido: 2021-03-10, direcci´on: https://www. makeuseof.com/tag/unity-game-development-languages/. [9] C. B. Bueno y F. O. G. Rubio. (2015). ((Gesti´on de Proyectos Software.)) Accedido: 2021-03-04, direcci´on: https://ocw.unican.es/pluginfile.php/274/course/section/194/GP-t5.pdf. [10] CoachYouths. (2021). ((Basketball Playbook Designer.)) Accedido: 2021-02-27, direcci´on: https : / / www . basketballplaybookdesigner.com/. [11] CodeProject. (2014). ((What is CodeLens?)) Accedido: 2021-03-11, direcci´on: https://www.codeproject. com/Articles/794766/What-is-CodeLens. [12] H. Costa. (2017). ((Tutoriales: Juego Plataformas 2D en Unity 5.)) Accedido: 2021-03-11, direcci´on: https: //www.youtube.com/playlist?list=PLiplYDjUMtti5bWJ1Ugystr-vUg8B5EuP. [13] ElAndroideFeliz. (2020). ((C´omo instalar aplicaciones en APK en un m´ovil Android.)) Accedido: 2021-06-12, direcci´on: https://www.xatakandroid.com/tutoriales/como-instalar-aplicaciones-en-apk-en-un- movil-android. [14] ElAndroideFeliz. (2020). ((C´omo instalar archivos o aplicaciones APK en Android.)) Accedido: 2021-06-12, direcci´on: https://elandroidefeliz.com/instalar-aplicaciones-archivos-apk-android/#:~:text= Abre%20el%20el%20men%C3%BA%20de,%2D%3E%20Instalar%20aplicaciones%20desconocidas%C2%AB.. [15] Fotocasa. (2021). ((An´alisis del coste del alquiler.)) Accedido: 2021-03-06, direcci´on: https://www.fotocasa. es/es/alquiler/pisos/valladolid-provincia/todas-las-zonas/l. [16] GitLab. (2021). ((Issue Boards.)) Accedido: 2021-03-09, direcci´on: https://docs.gitlab.com/ee/user/ project/issue_board.html. 111 WEBGRAF´ IA [17] GitLab. (2021). ((What is GitLab?)) Accedido: 2021-03-09, direcci´on: https://about.gitlab.com/whatis-gitlab/. [21] E. de Ingenier´ıa Inform´atica de Valladolid. (2017). ((Gu´ıa del alumno del TFG (Estructura, Formato, Documentaci´on).)) Accedido: 2021-02-18, direcci´on: https://www.inf.uva.es/wp-content/uploads/2013/01/ 00-GuiaAlumnoTFG_2017.pdf. [22] E. de Ingenier´ıa Inform´atica de Valladolid. (2021). ((Calendario de dep´osito y defensa de TFG 2020- 2021.)) Accedido: 2021-02-26, direcci´on: https : / / www . inf . uva . es / wp - content / uploads / 2014 / 09 / CalendarioPresentacionTFG.pdf. [23] InnerSloth. (2021). ((Among Us.)) Accedido: 2021-03-10, direcci´on: https://innersloth.com/gameAmongUs. php. [24] Kanbanize. (2020). ((¿Qu´e es un tablero Kanban?)) Accedido: 2021-03-07, direcci´on: https://kanbanize. com/es/recursos-de-kanban/primeros-pasos/que-es-tablero-kanban. [27] masterD. (2020). ((Unity ¿Qu´e es y para qu´e sirve?)) Accedido: 2021-03-08, direcci´on: https://www.masterd. es/blog/que-es-unity-3d-tutorial/. [28] Mediatonic. (2021). ((Fall Guys: Ultimate Knockout.)) Accedido: 2021-03-10, direcci´on: https://fallguys. com/. [29] Microsoft. (2021). ((Documentaci´on de C#.)) Accedido: 2021-03-10, direcci´on: https://docs.microsoft. com/es-es/dotnet/csharp/. [30] Microsoft. (2021). ((Gesti´on de proyectos con MS Project.)) Accedido: 2021-03-07, direcci´on: https://www. microsoft.com/es-es/microsoft-365/project/project-management-software. [31] Microsoft. (2021). ((Visual Studio Code and Unity.)) Accedido: 2021-03-11, direcci´on: https : / / code . visualstudio.com/docs/other/unity. [32] mola. (2017). (((Aplicaci´on Android) Field Hockey Dood.)) Accedido: 2021-02-27, direcci´on: https://play. google.com/store/apps/details?id=air.FieldHockeyDoodFree. [33] MonoProject. (2021). ((Cross Platform Mono for .NET.)) Accedido: 2021-03-08, direcci´on: https://www.monoproject.com/. [34] F. Mortals. (2015). ((Is Database Really Necessary in Unity.)) Accedido: 2021-04-24, direcci´on: https:// gamedev.stackexchange.com/questions/109080/is-database-necessary. [35] F. Mortals. (2019). ((Free Draw Unity Asset.)) Accedido: 2021-05-16, direcci´on: https://assetstore.unity. com/packages/tools/painting/free-draw-simple-drawing-on-sprites-2d-textures-113131. [36] E. Pais. (2021). ((Calculadora de salario neto.)) Accedido: 2021-03-06, direcci´on: https://cincodias.elpais. com/herramientas/calculadora-sueldo-neto/#tabla_resultados. [38] RFEBM. (2020). ((Reglamento de partidos y competiciones.)) Accedido: 2021-02-16, direcci´on: https://www. rfebm.com/sites/default/files/documentos/rpc_modificacion_asamblea_-_web.pdf. [39] S. Rodr´ıguez. (2020). ((Los videojuegos facturar´an 159 mil millones de d´olares en 2020.)) Accedido: 2021- 02-29, direcci´on: https://comunicacionmarketing.es/comunicacion/10/07/2020/los-videojuegos- facturaran-159-mil-millones-de-dolares-en-2020/15290.html. [40] G. Software. (2021). (((Aplicaci´on Android) TacticalPad Futsal Handball.)) Accedido: 2021-02-27, direcci´on: https://play.google.com/store/apps/details?id=com.clansoft.tacticalpadfutsallite. [42] Techopedia. (2015). ((What is Intellisense?)) Accedido: 2021-03-11, direcci´on: https://www.techopedia. com/definition/24580/intellisense. [43] TechTarget. (2019). ((What is WebGL?)) Accedido: 2021-02-28, direcci´on: https://whatis.techtarget. com/definition/WebGL. 112 WEBGRAF´ IA [44] Unity. (2020). ((Unity MANUAL.)) Accedido: 2021-03-11, direcci´on: https://docs.unity3d.com/Manual/ index.html. [45] Unity. (2020). ((Unity Manual: Asets Workflow.)) Accedido: 2021-03-11, direcci´on: https://docs.unity3d. com/Manual/AssetWorkflow.html. [46] Unity. (2020). ((Unity Manual: Canvas.)) Accedido: 2021-03-11, direcci´on: https://docs.unity3d.com/ 2020.1/Documentation/Manual/UICanvas.html. [47] Unity. (2020). ((Unity Manual: GameObject.)) Accedido: 2021-03-11, direcci´on: https://docs.unity3d.com/ 560/Documentation/Manual/class-GameObject.html. [48] Unity. (2020). ((Unity Manual: Prefabs.)) Accedido: 2021-03-11, direcci´on: https://docs.unity3d.com/ Manual/Prefabs.html. [49] Unity. (2020). ((Unity Manual: Sprites.)) Accedido: 2021-03-11, direcci´on: https://docs.unity3d.com/ Manual/Sprites.html. [50] Unity. (2021). ((Motor de videojuegos Unity.)) Accedido: 2021-03-08, direcci´on: https://unity.com/es. [51] Unity. (2021). ((Plataformas objetivo de Unity.)) Accedido: 2021-03-10, direcci´on: https://unity.com/es/ features/multiplatform. [52] Unity. (2021). ((Unity Hub.)) Accedido: 2021-03-10, direcci´on: https : / / docs . unity3d . com / Manual / GettingStartedInstallingHub.html. [53] Ustwogames. (2021). ((Monument Valley.)) Accedido: 2021-03-10, direcci´on: https : / / www . monumentvalleygame.com/mv2. [54] U. de Valladolid. (2021). ((Gu´ıa docente Trabajo de Fin de Grado (menci´on en Ingenier´ıa de Software).)) Accedido: 2021-02-23, direcci´on: https://albergueweb1.uva.es/guia_docente/uploads/2020/545/ 46976/1/Documento.pdf. [56] C. Villanueva. (2018). ((¿Qu´e es y para qu´e sirve un diagrama de Gantt?)) Accedido: 2021-02-24, direcci´on: https://blog.teamleader.es/diagrama-de-gantt. [57] I. Villaumbrales. (2019). ((Testing, la importancia sobre la fase de test de software.)) Accedido: 2021-02-24, direcci´on: https://www.hiberus.com/crecemos-contigo/testing-fase-de-testeo-de-software/. 113 WEBGRAF´ IA 114 AP´ ENDICE A. AP´ ENDICE A: MANUAL DE INSTALACI ´ ON Ap´endice A: Manual de instalaci´on En este manual, se describe una breve gu´ıa de instalaci´on seg´un el sistema operativo. Teniendo en cuenta los requisitos (por sistema operativo) que se deben cumplir, as´ı como explicaciones detalladas del proceso, se busca que el usuario final no tenga problemas en la instalaci´on de la aplicaci´on. Puede encontrar los archivos de instalaci´on para cada sistema desde el siguiente enlace. Si quiere desplegar el proyecto en el IDE de Unity, puede descargar la carpeta UnityProject desde el siguiente enlace. Si no sabe c´omo, en dicho enlace encontrar´a el fichero README.md, donde se especifican los pasos. A.1. Instalaci´on en sistemas Android A.1.1. Requisitos Versi´on m´ınima: Android 4.4. Almacenamiento interno, al menos 50 MB. A.1.2. Proceso de instalaci´on en Android Conocer la versi´on de Android [13] [14] le permitir´a seguir esta gu´ıa, de manera m´as acorde a su dispositivo. La versi´on m´ınima soportada es la 4.4, si es menor, no podr´a ejecutarla. Si desconoce cu´al es su versi´on, puede consultarla con los siguientes pasos (reflejados en la figura 1): Abrir la aplicaci´on Ajustes. Pulsar en Acerca del tel´efono/dispositivo (normalmente, al final). Podr´a visualizarlo en “Versi´on de Android”. Si bien se ha realizado un esfuerzo por elaborar una gu´ıa general, ha de saber que puede haber variaciones en funci´on de la capa de personalizaci´on del fabricante, por lo que los pasos indicados pueden variar. Tambi´en ha de descargar el fichero, desde la carpeta ejecutables del repositorio, EntrenaBal.apk. Los ficheros .apk son los paquetes de instalaci´on de cualquier aplicaci´on Android, y contienen todos los datos que la forman. Puede tenerlo en su sistema de ficheros, o descargarlo desde internet y proceder con su instalaci´on. Al tratarse de ficheros ejecutables, el sistema nos avisa para protegernos, una apk no ha sido revisada en busca de malware, y 115 B.2. JUGADAS Tambi´en puede salir de la aplicaci´on pulsando en el bot´on rojo “Salir” (esquina inferior derecha). B.2. Jugadas Desde el men´u principal, figura 6, se puede acceder, haciendo clic en “Jugadas”, a la pantalla de creaci´on y visualizaci´on de jugadas din´amicas. ´ Estas pueden visualizarse en cualquier momento pulsando el bot´on play que aparece abajo, ya sea mientras se crea una jugada o tras cargar una que previamente hayamos guardado. Una vez dentro, figura 7, puede observar un campo de balonmano y 7 jugadores por equipo, adem´as de un bal´on. Puede disponer estos elementos donde quiera arrastrando con clic izquierdo o con el dedo, en el caso de los dispositivos de pantalla t´actil. Una vez los jugadores se encuentren en la siguiente etapa de la jugada, pulse el bot´on “+” situado arriba en el centro, esto a˜nadir´a un paso a la jugada, pudiendo a˜nadir tantos como quiera. Figura 7: EntrenaBal: Jugadas din´amicas Como podr´a observar, a los laterales se encuentran unos botones (azul y rojo), figura 8, que permiten mover r´apidamente a todos los jugadores de cada equipo fuera del campo. Esto puede ser de utilidad en caso de querer realizar una jugada sin rivales, o si involucra a pocos jugadores, no teniendo por tanto, que mover manualmente a muchos jugadores. Figura 8: EntrenaBal: Botones de movimiento de equipo En caso de que se equivoque al a˜nadir pasos o quiera comenzar de cero, puede borrarlos pulsando el bot´on rojo “Borrar”, se le mostrar´a una pantalla como la figura 9, para evitar borrados por accidente. Una vez considere finalizada su jugada, puede guardarla pulsando el bot´on blanco “Guardar”, desde el cual, 122 AP´ ENDICE B. AP´ ENDICE B: MANUAL DE USO Figura 9: EntrenaBal: Borrado de pasos figura 10, se solicitar´a un nombre identificativo para guardar su jugada. Como m´ınimo tendr´a 1 car´acter y como m´aximo, 25. Si ya existe una jugada con el nombre especificado NO podr´a guardar, apareciendo un mensaje informativo en la figura 10. Figura 10: EntrenaBal: Guardar jugada De manera similar, podr´a cargar una jugada previamente guardada pulsando el bot´on verde “Cargar jugada”, lo que mostrar´a el listado de jugadas guardadas (en la figura 11 puede ver un ejemplo) en el dispositivo, permiti´endole seleccionar la que quiera pulsando en el bot´on verde “Cargar” de la correspondiente fila. Una vez cargada, puede reproducirla pulsando el bot´on verde play; cada vez que lo pulse, la animaci´on volver´a a comenzar. Recalcar que tras cargar una jugada, pueden a˜nadirse pasos y guardarla como una nueva. 123 B.3. LISTAR JUGADAS Figura 11: EntrenaBal: Cargar una jugada Si tiene pasos a˜nadidos y pulsa el bot´on gris con una flecha (esquina superior izquierda) o la funci´on de escape comentada previamente, aparecer´a una pantalla de aviso, figura 12, para prevenir que pierda el trabajo realizado, por un despiste. Figura 12: EntrenaBal: Salir sin guardar B.3. Listar jugadas Desde el men´u principal, figura 6, se puede acceder a “Listar jugadas”, donde se muestra una tabla que contiene las jugadas almacenadas en el dispositivo como se puede apreciar en la figura 13. En la columna derecha aparecen 124 AP´ ENDICE B. AP´ ENDICE B: MANUAL DE USO casillas seleccionables con la finalidad de borrar aquellas marcadas desde el bot´on rojo “Borrar selecci´on”, estas quedar´an marcadas con un tick, como es el caso de “Defensa r´apida”. Tambi´en se cuenta con los botones verdes “Seleccionar todas” y “Vaciar selecci´on”, para realizar las acciones que su propio nombre indica, facilitando as´ı el trabajo. Figura 13: EntrenaBal: Listar jugadas Con la/s jugada/s a borrar seleccionada/s, se puede pulsar el bot´on rojo “Borrar selecci´on” el cual mostrar´a un mensaje de aviso, como el de la figura 14, para evitar borrar jugadas por error. En caso de que se hayan seleccionado todas las jugadas, se mostrar´an dos mensajes de error debido al alto impacto que puede suponer. Figura 14: EntrenaBal: Borrar jugada/s En cualquier momento puede pulsar el bot´on gris con una flecha (esquina superior izquierda) o la funci´on de escape comentada previamente para regresar al men´u principal. 125 B.4. PIZARRA B.4. Pizarra Desde el men´u principal, figura 6, se puede acceder, haciendo clic en “Pizarra”, a una pizarra de dibujo completa. En el margen derecho de la figura 15, se pueden observar 4 rotuladores de colores: azul (por defecto), negro, rojo y verde que permiten al usuario distinguir colores para acciones, jugadores o equipos. Por encima de ´estos se encuentra una goma que permite borrar las l´ıneas trazadas. Para modificar el grosor de ´estos elementos, se encuentra en la esquina inferior derecha un selector, donde cuanto m´as a la izquierda m´as fino ser´a el trazo y m´as grueso cuanto m´as a la derecha. Figura 15: EntrenaBal: Pizarra interactiva Debido a que el borrado mediante goma puede resultar tedioso, o insuficiente por la rapidez de un partido, se presenta en la esquina superior derecha el bot´on rojo “Borrar TODO”, el cual s´olo se puede pulsar si se ha dibujado algo, y que mostrar´a una pantalla de confirmaci´on. Si en dicha pantalla, figura 16 se selecciona “BORRAR” se regresa a la pizarra y no aparecer´a ning´un dibujo. Por otra parte, se puede pulsar el bot´on verde “Guardar captura” el cual salvar´a en el espacio interno del dispositivo una captura de pantalla de la pizarra, y muestra un mensaje informativo entre los dos botones superiores. En caso de tener algo dibujado (sin haber guardado captura) y pulsar el bot´on gris con una flecha (esquina superior izquierda) o la funci´on de escape comentada previamente, se mostrar´a una ventana informativa para evitar perder el dibujo por error, como se puede apreciar en la figura 17. 126 AP´ ENDICE B. AP´ ENDICE B: MANUAL DE USO Figura 16: EntrenaBal: Borrar dibujos Figura 17: EntrenaBal: Salir sin guardar captura 127 B.5. PLANTILLA B.5. Plantilla Desde el men´u principal, figura 6, se puede acceder, haciendo clic en “Plantilla”, a una pantalla donde se muestran en forma de tabla, figura 18, los jugadores que hayan sido a˜nadidos y est´en almacenados en el dispositivo. Tiene por finalidad permitir al entrenador una m´ınima gesti´on de sus jugadores mostrando la informaci´on m´as b´asica y permitiendo a˜nadir un comentario a cada uno, que puede ser usado, por ejemplo, para tiempos de recuperaci´on de una lesi´on o para establecer cambios. Figura 18: EntrenaBal: Plantilla de jugadores Desde esta pantalla podemos, mediante el bot´on verde “A˜nadir jugador” incorporar un nuevo jugador a las filas del equipo. De manera similar, podremos editar los existentes pulsando en el bot´on verde de la fila correspondiente. En ambos casos se mostrar´a una pantalla como la figura 19 donde no podr´a guardar hasta que cumplimente los 3 campos obligatorios. En caso de que elija un dorsal ya asignado, se mostrar´a un mensaje informativo entre los botones “Borrar jugador” y “Guardar” y tampoco se guardar´a. Al a˜nadir un jugador el bot´on de “Borrar jugador” no estar´a disponible ya que carece de sentido. Al editar un jugador esta funci´on s´ı estar´a disponible, y, como se puede observar en la figura 20, lanzar´a una pantalla de aviso para no borrar accidentalmente un jugador. En caso de estar editando un jugador y querer regresar al listado, mediante la flecha gris de arriba a la izquierda, se mostrar´a una pantalla de aviso (figura 21) para no perder los cambios de manera accidental. Si desde la pantalla que se aprecia en la figura 18 pulsa el bot´on rojo “Borrar TODO” se proceder´a a mostrar dos pantallas de aviso como la figura 22, debido al impacto que puede suponer esta acci´on de cara al entrenador. 128 AP´ ENDICE B. AP´ ENDICE B: MANUAL DE USO Figura 19: EntrenaBal: A˜nadir o editar un jugador Figura 20: EntrenaBal: Borrar un jugador 129 B.5. PLANTILLA Figura 21: EntrenaBal: Mensaje de aviso al editar Figura 22: EntrenaBal: Borrado de todos los jugadores 130 AP´ ENDICE B. AP´ ENDICE B: MANUAL DE USO B.6. Ajustes Finalmente, si clicamos en “Ajustes” desde el men´u principal, figura 6, accederemos a los ajustes de la aplicaci´on (figura 23), donde se puede cambiar el color de la equipaci´on del equipo propio y del adversario. Este cambio se lleva a cabo seleccionando un color en la ruleta RGB y desplazando el cursor de luminosidad, haciendo asi m´as oscuro (llegando al negro) o m´as claro (llegando al blanco) el color final. En la “Visualizaci´on previa” se van actualizando los cambios, de tal manera que el usuario sea consciente del resultado. Figura 23: EntrenaBal: Ajustes Una vez est´e conforme con los colores, pulse el bot´on verde “Guardar cambios”. ´ Estos ser´an aplicados y podr´a verlos en los jugadores de cada equipo, y los botones de movimiento r´apido, como se aprecia en la figura 24 en contraposici´on a los colores iniciales de la figura 7. Estos cambios aplican tambi´en a las jugadas previamente guardadas. 131