TRABAJO FIN DE ESTUDIOS

TRABAJO FIN DE ESTUDIOS PROYECTO FIN DECARRERA Aplicación web para la gestión de un club de balonmano Unai Rudiez Asua Tutor: Juan José Olarte Larrea Curso 2011-2012

Aplicación web para la gestión de un club de balonmano, trabajo fin de estudios de Unai Rudiez Asua, dirigido por Juan José Olarte Larrea (publicado por la Universidad de La Rioja), se difunde bajo una Licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los titulares del copyright. El autor Universidad de La Rioja, Servicio de Publicaciones, 2012 publicaciones.unirioja.es E-mail: publicaciones@unirioja.es

UNIVERSIDAD DE LA RIOJA Facultad de Ciencias, Estudios Agroalimentarios e Informática PROYECTO FIN DE CARRERA Ingeniería Técnica en Informática de Gestión Aplicación Web para la Gestión de un Club de Balonmano. Alumno: Unai Rudiez Asua Director: Juan José Olarte Larrea Logroño, 5 de junio 2012

RESUMEN El presente proyecto pretende crear una aplicación Web para gestionar un club deportivo, en concreto C.P. Calasancio de Logroño, sección de balonmano. El objetivo principal es permitir un mayor seguimiento de jugadores y entrenadores de la base. Para ello se realizarán 4 partes diferenciadas por el tipo de usuario: Una página Web pública, con información general del club y de la sección. Parte Jugador, donde verá las notificaciones del club y entrenadores de su equipo, se podrá comunicar con ellos y valorar a sus entrenadores. Parte Entrenador, tendrá acceso a todo lo relacionado con su equipo, se podrá comunicar con sus jugadores y evaluará su evolución en diferentes aspectos. Podrá preparar e imprimir entrenamientos. Administrador, se encargará del buen manejo de la aplicación, controlando las diferentes partes, ya que tendrá acceso a todo lo que se añada/modifique y dará el visto bueno. Gestionará la base de datos de entrenamientos y los comunicados entre jugadores/padres y entrenadores. La aplicación tendrá dos bases de datos: La primera almacenará todo lo relacionado con jugadores y entrenadores, así como su usuario y contraseña. En la segunda serán recopilados ejercicios tipo de entrenamientos. El proyecto se desarrollará en colaboración con el Club Polideportivo Calasancio de Logroño, así como con Roberto Del Val que se encargará del diseño gráfico. Se pretende que el resultado final sea lo suficientemente completo y sencillo de manejar, como para que dicha aplicación mejore los servicios que el club da a sus jugadores y facilite y mejore la preparación de entrenamientos. 2

Contenido RESUMEN... 2 Contenido... 3 1 Introducción... 6 1.1. Tema abordado... 6 1.2. Motivo de la elección... 6 1.3. Límites... 6 2 Documento de objetivos del proyecto... 7 2.1. Objetivo... 7 2.2. Participantes... 7 2.3. Comunicaciones... 7 2.4. Alcance del proyecto.... 8 2.4.1. Requisitos mínimos alcanzables.... 8 2.4.2. Posibles ampliaciones... 8 2.5. Estudio de viabilidad... 9 2.6. Metodología... 9 2.7. Tecnologías a utilizar... 9 2.8. Identificación de riesgos y planes de acción.... 9 2.8.1. Riesgos posibles:... 10 2.8.2. Planes de acción.... 10 2.9. Entregables.... 11 2.10. Descomposición de tareas... 11 Ciclo 1: Seguimiento Proyecto.... 12 Ciclo 2: Gestión Proyecto.... 12 Ciclo 3: Estudio previo.... 13 Ciclo 4: Especificación de requisitos de la plataforma.... 13 Ciclo 5: Creación de una página Web con la información general del club.... 13 Ciclo 6: Creación de la Aplicación para la gestión de jugadores.... 14 Ciclo 7: Creación de la Aplicación para la gestión de Entrenamientos.... 15 Ciclo 8: Pruebas.... 15 Ciclo 9: Documentación.... 16 2.11 ESTIMACION TEMPORAL... 18 2.11.1.Calendario de trabajo... 18 3

2.11.2. Estimación de tiempos por tareas.... 19 2.11.3. Diagrama de Gantt.... 23 3 Gestión del proyecto... 24 3. 1. Primera replanificación.... 24 3.1.1. Introducción.... 24 3.1.2. Factores de retraso.... 24 3. 2. Segunda replanificación.... 24 3.2.1. Introducción.... 24 3.2.2. Factores de retraso.... 25 4. Análisis de requisitos: Visión general.... 26 4.1. Introducción.... 26 4.1.1. Ámbito... 26 4.1.2. Definiciones, siglas y abreviaturas... 26 4.2 Descripción global... 26 4.2.1. Perspectiva del producto... 26 4.2.2. Funciones del producto.... 27 4.2.3. Características de los usuarios.... 27 4.3 Casos de uso.... 27 4.3.1. Visión general de la plataforma.... 27 4.4 Documento de especificación de requisitos.... 29 4.4.1. Referencias.... 29 4.4.2. Apreciación global de este documento.... 29 4.4.3. Tecnologías y recursos.... 30 4.4.4. Especificación de Requisitos.... 30 4.5. Descripción del plan de pruebas.... 36 4.6 Pruebas de sistema y aceptación.... 37 5 Ciclo 1 WEB PÚBLICA DEL CLUB... 38 5.1. Análisis de requisitos.... 38 5.1.1. Introducción.... 38 5.1.2. Usuarios del sistema.... 38 5.1.3. Casos de uso de definición.... 38 5.2. Diseño... 40 5.2.1. Diseño de interfaces.... 40 5.2.2. Código... 43 4

6 Ciclo 2 APLICACIÓN GESTIÓN DE JUGADORES... 45 6.1 Análisis:... 45 6.1.1. Casos de uso... 45 6.1.2 Clases de análisis.... 57 6.2.1. Diseño de la BD:... 61 6.2.1.2. Documentación de tablas:... 63 6.2.2. Diseño de interfaces... 70 6.2.3. Diseño de clases de negocio... 74 6.4 Pruebas:... 79 6.4.1. Clases de equivalencia... 79 7 Ciclo 3 APLICACIÓN GESTIÓN DE ENTRENAMIENTOS... 84 7.1 Análisis:... 84 7.1.1 Casos de uso... 84 7.1.2. Clases de análisis.... 88 7.2.1 Diseño de la BD:... 90 7.2.1.1. Diagrama:... 90 7.2.1.2. Documentación de tablas:... 91 7.2.2. Diseño de interfaces... 93 7.2.2. Diseño de interfaces... 93 7.2.3. Diseño de clases de negocio... 95 7.4 Pruebas:... 95 7.4.1 Clases de equivalencia... 95 8. Conclusiones... 98 8.1. Evaluación de objetivos... 98 8.2. Opinión personal... 98 8.2.1. Desarrollo del proyecto... 98 8.2.2. Plazos... 99 8.2.3. Tecnología... 99 8.2.4. Estudio de mejoras, rendimiento, etc.... 99 ACTAS DE REUNIÓN... 100 5

1 Introducción 1.1. Tema abordado El presente proyecto pretende desarrollar una aplicación Web compuesta por varias partes, que en su conjunto permita una mejor gestión de jugadores y entrenadores, evaluar su rendimiento y sus respectivos trabajos. 1.2. Motivo de la elección Actualmente soy miembro del club como jugador y como entrenador. Hace un tiempo vimos la necesidad de tener una página Web informativa. Cuando nos reunimos consideramos interesante dar mejores servicios a jugadores (y padres de estos) dándoles más información sobre: su progresión, asistencia, comportamiento ya que el club considera que también participa en la educación de dichos jugadores. En todos mis años de entrenador, siempre he comentado y oído comentarios acerca de las dificultades de encontrar ejercicios para trabajar diferentes aspectos del juego y así la dificultad de preparar buenos entrenamientos. Al final siempre tienes que buscar en libros, entrenamientos que tenemos almacenados o comentar con otros compañeros. Con todas estas ideas, compañeros del club y yo hemos considerado importante crear la aplicación que nos de estos servicios. 1.3. Límites Este proyecto está ligado a una empresa real y tengo permanente contacto con los usuarios finales (yo mismo soy uno de ellos). Esto me otorga una ventaja importante: puedo crear la plataforma a mi gusto y al de mis compañeros. Pero al mismo tiempo también entraña un riesgo: la propia ambición a la hora de crear nos puede llevar a crear una aplicación excesivamente grande y complicada de llevar a cabo. Para evitar este problema se establecen unos requisitos mínimos y varias mejoras que se podrán ir incluyendo. La aplicación estará formada por partes independientes que se irán uniendo según se vayan realizando. 6

2 Documento de objetivos del proyecto 2.1. Objetivo El objetivo del proyecto es la construcción de una plataforma para la informatización y gestión de un club deportivo. La aplicación surge de la unión de varias necesidades del club, información de propio club, información a jugadores y entrenadores, mayor control sobre los jugadores y entrenadores y aportar una ayuda más a los entrenadores a la hora de preparar entrenamientos. Se considera mejor solución la aplicación Web, frente a la de escritorio, para que haya una comunicación real jugador-entrenador y los propios entrenadores puedan acceder desde su casas. El objetivo final será la comunicación jugadores/padres con el club y entrenadores. Las tecnologías a emplear están aún por determinar y serán barajadas durante el mismo, estudiándose la opción más adecuada. 2.2. Participantes En representación del cliente, C.P. Calasancio, interviene: José Luis Goñi Sáez Roberto Del Val García (también como diseñador grafico) Como responsables de la ejecución del proyecto intervenimos: El alumno, Unai Rudiez Asua. El director del proyecto, Juan José Olarte Larrea. 2.3. Comunicaciones De común acuerdo entre el director del proyecto y el alumno, la comunicación entre ambos se ha establecido de la siguiente forma: Mediante correo electrónico. Será el medio de comunicación más habitual y se utilizará para notificar por parte del alumno el estado del proyecto y para la resolución de dudas puntuales, así como para concertar reuniones entre ambos. 7

Reuniones. Se realizarán de forma esporádica, cuando se alcance un hito importante en el ciclo del proyecto o cuando se produzca un problema importante. Se levantará acta de cada reunión realizada. La comunicación con el club será de manera personal cuando se considere oportuno y mediante correo electrónico. 2.4. Alcance del proyecto. Se han establecido una serie de requisitos mínimos que deben alcanzarse, para poder entregar el proyecto. También se establecerán una serie de posibles ampliaciones, que se llevarán a cabo en orden de importancia y en función del tiempo disponible. Al finalizar el proyecto se documentará que ampliaciones han podido ser realizadas y cuáles no. Como he explicado antes la aplicación estará dividida en bloques independientes 2.4.1. Requisitos mínimos alcanzables. Creación de una página Web con la información general del club. Creación de una base de datos con los datos de jugadores y entrenadores. Creación de una base de datos con ejercicios para entrenamientos Creación Aplicación Web 2.4.2. Posibles ampliaciones Incluir sección de fotos, video y/o zona de ocio. Creación de un foro. Creación de tienda virtual. 8

2.5. Estudio de viabilidad Se ha buscado una aplicación que cumpla los requisitos que se piden, se ha contactado con la Federación Riojana de balonmano para informarnos de la aplicación que utilizan, pero no cumple las características buscadas y tampoco están contentos con ella. Después de revisar las peticiones se considera un proyecto alcanzable con nuestros recursos y se adapta como PFC. 2.6. Metodología El proyecto se desarrollará siguiendo la metodología del Proceso Unificado del Desarrollo de Software, propuesto por Jacobson, Rumbaugh y Booch ([JAC00]). Esta metodología se basa en los casos de uso, la arquitectura y sigue un ciclo de vida iterativo e incremental. Se ha elegido esta metodología porque se adapta muy bien, ya que se van realizando bloques, los cuales se van añadiendo a la aplicación en cada iteración, aumentando cada uno de los ciclos los productos obtenidos en los anteriores. De esta forma tendremos la oportunidad de recoger la opinión del cliente en etapas tempranas, con lo que disminuiremos el riesgo de insatisfacción respecto del producto. También no facilitará la introducción de posteriores amplificaciones. 2.7. Tecnologías a utilizar PHP: Después de una reunión con el tutor mi idea era utilizar otro lenguaje como JSP, pero al verme limitado en tiempo utilizaré el lenguaje PHP al estar más familiarizado con el. MySQL: Me he decantado por MySQL, fundamentalmente debido a la gratuidad del mismo, a su amplia difusión y a que es una herramienta que conozco pero quiero conocer mejor. Ajax: esta técnica la conozco muy poco, es relativamente nueva y me permite que la aplicación sea más interactiva, con lo que considero interesante incluirla. 2.8. Identificación de riesgos y planes de acción. Durante el ciclo de vida del proyecto es posible que surjan imprevistos que afecten al desarrollo y a la duración del mismo. En este apartado trataremos de identificarlos y establecer un plan de 9

acción que ayude a minimizar en lo posible los efectos negativos en caso de que ocurra alguna de estas incidencias. 2.8.1. Riesgos posibles: 1. Problemas de índole personal del alumno: enfermedades, accidentes, cambios en el entorno laboral que afecten al número de horas disponibles para dedicar al proyecto, etc. 2. Errores en la estimación de fechas, derivados de la falta de un horario estricto y fijo para el proyecto o de la inexperiencia del alumno en alguno de los campos que abarca el proyecto. 3. Detección de la falta de viabilidad del proyecto. Puede ocurrir que durante el transcurso del proyecto se llegue a un punto que impida continuar adelante con él, ya sea por falta de medios materiales, conocimientos técnicos o por cualquier otro motivo. 4. El producto final no satisface al alumno y/o al director. Una vez terminado el proyecto podría ocurrir que el producto final no sea del agrado del alumno o que no se ajuste a lo esperado por el director del proyecto. 5. Desconocimiento de alguna herramienta necesaria. Se parte de la base de que hay algunas herramientas a priori necesarias y desconocidas para el alumno (por ejemplo Ajax), pero durante la ejecución del proyecto puede surgir alguna otra no prevista. 6. Problemas hardware o software en el equipo de desarrollo. 2.8.2. Planes de acción. 1. Problemas personales: Como el equipo de desarrollo está compuesto únicamente por el alumno, la planificación de fechas y horas dedicadas al proyecto se verá afectada. 2. Errores en la estimación de fechas: Se documentará adecuadamente el error de la estimación y se replanificarán las tareas si es conveniente. 3. Falta de viabilidad en el proyecto: Esta situación debe evitarse a toda costa. Se soluciona con la metodología del desarrollo incremental. 4. Producto final no satisfecho: Para combatir esta situación, se utiliza la metodología del desarrollo incremental. 5. Problemas hardware o software: El proyecto se desarrollará principalmente en el ordenador personal del alumno. Para evitar pérdidas se realizarán las siguientes copias de seguridad: Una memoria USB, al final de cada sesión de trabajo. Otra USB cuando se termine cada bloque de trabajo. 10

Disco Internet y disco duro externo aproximadamente cada mes. Dadas las características del proyecto, si se produce algunas de las incidencias aquí señaladas o alguna otra no causará impacto económico sobre el coste, pero sí sobre la duración. Como la idea es ir trabajando en el proyecto siempre que sea posible durante el tiempo que este en prácticas de empresa, estos posibles problemas supondrán un esfuerzo mayor a partir de esa fecha, abril 2011. 2.9. Entregables. Durante el desarrollo del proyecto se generarán y entregarán los siguientes productos: Memoria del proyecto. o Documento de Planificación y Gestión del Proyecto. o Documento de Análisis de requisitos. o Documento de diseño de la plataforma. Producto final: plataforma completa. o Aplicación sección administración. o Aplicación sección Entrenador. o Aplicación sección Jugador o Página Web. Presentación del proyecto. 2.10. Descomposición de tareas Para poder organizar mejor el proyecto y para una mejor estimación de tiempo del mismo, este se ha dividido en tares y estas a su vez en subtareas. Las tareas son numeradas consecutivamente y las subtareas dentro de la tarea a la que pertenecen también (figura 2.9.1). En las tareas principales hay subtareas que se repiten en otras tareas, para evitar redundancia no se explicarán las tareas ya explicadas a no ser que resulten relevantes para el entendimiento de la aplicación. Dentro de cada una de las iteraciones se repetirán prácticamente las mismas tareas, en la figura 2.9.2.se ha puesto a modo de ejemplo el diagrama de descomposición de tareas correspondiente a la segunda iteración (Aplicación para la gestión de jugadores). Por el mismo motivo tampoco se explicarán las tareas que sean idénticas en cada una de las iteraciones salvo para destacar algún aspecto relevante. 11

2. A continuación describimos de forma breve cada una de las tareas del proyecto: Ciclo 1: Seguimiento Proyecto. Esta tarea engloba temporalmente toda la vida del proyecto porque el seguimiento del proyecto se realizará en diversos momentos de su ciclo de vida. Se compone de: 1.1. Reuniones director: Tiempo dedicado a las reuniones con el director de proyecto. 1.2. Reuniones empresa: Tiempo dedicado a las reuniones con representante de empresa. 1.3. Reuniones diseñador: Tiempo dedicado a las reuniones con diseñador gráfico. 1.4. Revisiones: Periódicamente se realizará una revisión global del estado del proyecto para detectar posibles desviaciones en el cumplimiento de objetivos y tomar las medidas correctivas correspondientes. Ciclo 2: Gestión Proyecto. Esta tarea abarca las labores de documentación 2.1. Generación DOP: Creación del presente documento de objetivos del proyecto. 2.1.1. Estudio previo. Obtener información sobre dirección de proyectos. 2.1.2. Descomposición de tareas. Descomponer el proyecto en tareas. Generar el diagrama de descomposición de tareas. 2.1.3. Asignar tiempo a tareas. Estimar el tiempo que se dedicará a cada una de las tareas. 2.1.4. Diagrama Gantt. Crear el diagrama Gantt utilizando MS-Project. 2.1.5. Documentación. Documentar textualmente las tareas identificadas. 2.1.6. Revisión. Revisar la documentación generada en esta tarea. 2.2. Generación Memoria: La duración de esta tarea se extiende durante la vida proyecto. 2.2.1. Estudio previo. Estudiar documentación de proyectos de años anteriores y otra información proporcionada por el departamento sobre proyectos fin de carrera. 2.2.2. Creación memoria. Creación del documento de Memoria del proyecto 2.2.3. Revisión documento. Revisar la documentación generada en esta tarea 2.3. Defensa Proyecto 2.4. Preparación. Preparación de la presentación del proyecto ante el tribunal. 2.5. Defensa. Defensa del proyecto ante el tribunal. 12

3. Ciclo 3: Estudio previo. 3.1. Establecer los límites del sistema a desarrollar junto con representantes del club. 3.2. Estudiar viabilidad del sistema. Ciclo 4: Especificación de requisitos de la plataforma. En este proyecto, como ya hemos indicado, se apoya en el Proceso Unificado del Desarrollo y estamos utilizando un ciclo de vida iterativo e incremental. Hemos dividido el proyecto en 3 ciclos. Cada una de las iteraciones se ha dividido básicamente en 4 subtareas: Análisis, Diseño, Construcción y Pruebas. Ciclo 5: Creación de una página Web con la información general del club. Esta tarea corresponde a la realización de la parte pública de aplicación, en la que cualquier persona interesada podrá informarse sobre el club y navegar por ella. 5.1. Análisis: Analizaremos el sistema a desarrollar en la iteración. 5.1.1. Casos de uso: 5.1.1.1. Identificar actores. 5.1.1.2. Crear casos de uso. Generar los casos de uso. 5.1.1.3. Diagramas de actividad: Generar los diagramas de actividad. 5.1.1.4. Revisión: Revisar la documentación generada a lo largo de esta tarea. 5.1.2. Clases de análisis. 5.1.2.1. Identificar clases. Identificar las clases más importantes para el diseño de la aplicación, sin entrar en detalle de métodos y propiedades. 5.1.2.2 Diagrama de clases. Generar el diagrama de clases UML. 5.2. Diseño: Diseñar la web. 5.2.1. Revisar diseño con el club. 5.3. Construcción: 5.3.1. Implementación: Escribir el código necesario para la creación de la web. 5.3.3. Crear ayuda: Generar la ayuda de la presentación. 5.3.4. Documentación código. 5.4. Pruebas: 5.4.2. Pruebas unitarias aplicación. 13

Ciclo 6: Creación de la Aplicación para la gestión de jugadores. Esta tarea corresponde con la segunda iteración de nuestro proyecto. Al final de este ciclo dispondremos de la aplicación web que nos permitirá gestionar los jugadores del club por parte de un usuario Administrado (incluir, eliminar, modificar jugadores, incluir /eliminar de equipo), gestionar los jugadores de su equipo mediante un usuario Entrenador (valorar, asistencia, notificaciones ) y comprobar las notificaciones propias y del su equipo, así como valorar a su entrenador por parte del usuario jugador. 6.1. Análisis: Analizaremos el sistema a desarrollar en la iteración. 6.1.1. Casos de uso: 6.1.1.1. Identificar actores. 6.1.1.2. Crear casos de uso. Generar los casos de uso. 6.1.1.3. Diagramas de actividad: Generar los diagramas de actividad. 6.1.1.4. Revisión: Revisar la documentación generada a lo largo de esta tarea. 6.1.2. Clases de análisis. 6.1.2.1. Identificar clases. Identificar las clases más importantes para el diseño de la aplicación, sin entrar en detalle de métodos y propiedades. 6.1.2.2. Diagrama de clases. Generar el diagrama de clases UML 6.2. Diseño: Diseñar el sistema a construir. 6.2.1. Diseño de la BD: En esta tarea se diseñará la Base de Datos para almacenar todo los datos relacionados con jugadores y entrenadores. 6.2.1.1 Diagrama UML: Generar diagrama UML de la BD. 6.2.1.2. Documentación de tablas: Breve explicación de las tablas y sus campos de la BD. 6.2.1.3. Revisión: Revisar la documentación generada a lo largo de esta tarea. 6.2.2. Diseño de interfaces 6.2.2.1. Generar prototipos: Crear prototipos de interfaces gráficas. 6.2.2.2. Documentar prototipos: Breve explicación de los prototipos generados anteriormente. 6.2.3. Diseño de clases de negocio 14

6.2.3.1. Identificar clases y métodos principales: Partiendo de los casos de uso y las clases de análisis. 6.2.3.2. Ampliar diagrama de clases: Ampliar diagrama de clases de análisis para así poder entrar en más detalle. 6.3. Construcción: 6.3.1 Crear script BD: Generar el script de la BD a partir del diagrama E-R generado anteriormente. 6.3.2. Implementación: Escribir el código necesario para las clases de negocio y la capa de presentación. 6.3.3. Crear ayuda: Generar la ayuda de la presentación. 6.3.4. Documentación código: Crear la documentación de las clases y el código escrito. 6.4. Pruebas: 6.4.1. Probar script BD: Probar el script y solucionar los posibles fallos que se produzcan. 6.4.2. Pruebas unitarias aplicación. Ciclo 7: Creación de la Aplicación para la gestión de Entrenamientos. Esta tarea corresponde con la tercera iteración de nuestro proyecto. Al final de este ciclo dispondremos de la aplicación web que permitirá incluir ejercicios a los usuarios Entrenador y Administrador, crear entrenamientos con grupos de ejercicios seleccionados. (Sigue la misma estructura que el anterior). Ciclo 8: Pruebas. En esta tarea se revisará el plan de pruebas de integración, que se ha ido creando al final de cada una de las iteraciones del ciclo de vida del proyecto. Aquí sólo nos ocuparemos de las pruebas de integración que nos aseguren que todos los módulos de la plataforma interactúan correctamente. 8.1. Revisión del plan de pruebas: Revisar globalmente el plan de pruebas de integración creado en tareas anteriores y modificar si es preciso los aspectos que se consideren oportunos. 15

8.2. Ejecución plan de pruebas: Ejecutar el plan de pruebas revisado en el paso anterior y anotar los resultados obtenidos. 8.3. Revisión de errores detectados: Revisar y solucionar los posibles errores detectados en los puntos anteriores. Ciclo 9: Documentación. Esta tarea corresponde con la creación de documentación para administradores y diferentes usuarios de la plataforma, basándonos en las ayudas creadas en cada iteración del desarrollo de la plataforma. 16

Figura 2.9.1 DIAGRAMA DE DESCOPOSICIÓN DE TAREAS GENERAL Figura 2.9.2 DIAGRAMA DE DESCOPOSICIÓN DE TAREAS SEGUNDA ITERACIÓN 17

2.11 ESTIMACION TEMPORAL 2.11.1.Calendario de trabajo Debido a mi situación actual (realizo prácticas en Arsys hasta el 28/03/2011, entreno en el propio club, entreno a la selección cadete femenina de La Rioja y soy árbitro de la federación de balonmano), mi idea es ir trabajando en el proyecto las horas libres que tenga hasta que finalice las prácticas en Arsys, momento en el que podré dedicar de cuatro a cinco horas diarias más. Los martes y jueves serán los días en los que podré adelantar más trabajo. Abajo muestro mi horario semanal. Lunes Martes Miércoles Jueves Viernes Sábado Domingo 9:00 10:00 11:00 12:00 13:00 14:00 15:00 17:00 17:00 18:00 19:00 20:00 21:00 22:00 Prácticas Arsys Entrenamiento Club Entrenamiento Selección Arbitrajes Partidos 18

2.11.2. Estimación de tiempos por tareas. En la siguiente tabla se desglosan todas las tareas del proyecto y se estima el tiempo en horas necesario para realizar cada una de ellas. Nombre tarea Duración estimada en horas Seguimiento proyecto 14 Revisiones 7 Reuniones 7 Gestión del proyecto 80 Generación DOP 16 Estudio previo 5 Descomposición de tareas 5 Asignar tiempo a tareas 2 Diagrama Gantt 2 Documentación 1 Revisión 1 Generación Memoria 53 Estudio previo 15 Creación memoria 34 Revisión documento 4 Defensa proyecto 11 Preparación 10 Defensa 1 Estudio previo 9 Establecer los límites del sistema a desarrollar 6 Estudiar la viabilidad del sistema 3 Especificación de requisitos 5 Documento de especificación de requisitos 5 Web Publica del club (Ciclo 1) 49 Análisis 2 Casos de uso 2 Identificar actores 1 19

Crear casos de uso 1 Revisión 1 Diseño 7 Diseño 7 Crear versiones gráficas 4 Documentar versiones 3 Construcción 34 Implementar 30 Crear ayuda 3 Documentación código 1 Pruebas 5 Pruebas unitarias aplicación 4 Diseño pruebas integración 1 Aplicación Web gestión de jugadores (Ciclo 2) 89 Análisis 9 Casos de uso 5 Identificar actores 1 Crear casos de uso 2 Diagramas de actividad 2 Revisión 1 Clases de análisis 4 Identificar clases 1 Diagramas de clases 3 Diseño 24 Diseño BD 8 Crear diagrama E-R 4 Documentar tablas 3 Revisión 1 Diseño de interfaces 9 Crear prototipos interfaces gráficas 7 Documentar prototipos 2 Diseño clases de negocio 7 20

Identificar propiedades y métodos principales 3 Ampliar diagrama de clases 4 Construcción 50 Crear Script BD 3 Implementar 40 Crear ayuda 6 Documentación código 1 Pruebas 6 Probar script BD 1 Pruebas unitarias aplicación 5 Aplicación Web gestión de entrenamientos (Ciclo 3) 88 Análisis 10,5 Casos de uso 6 Identificar actores 1 Crear casos de uso 2 Diagramas de actividad 2 Revisión 1 Clases de análisis 5 Identificar clases 2 Diagramas de clases 3 Diseño 22 Diseño BD 8 Crear diagrama E-R 4 Documentar tablas 3 Revisión 1 Diseño de interfaces 7 Crear prototipos interfaces gráficas 4 Documentar prototipos 3 Diseño clases de negocio 7 Identificar propiedades y métodos principales 3 Ampliar diagrama clases 4 Construcción 47 21

Implementar 40 Crear ayuda 6 Documentación código 1 Pruebas 8 Pruebas unitarias aplicación 5 Diseño pruebas integración 3 Pruebas 21 Revisión plan de pruebas 5 Ejecución plan de pruebas 4 Revisión errores detectados 12 Documentación 14 Manual usuario jugador 7 Manual usuario administrativo 7 TOTAL HORAS PROYECTO 379 Tabla 2.10.1 Estimación de horas 22

2.11.3. Diagrama de Gantt. Figura 2.9.2 DIAGRAMA DE DESCOPOSICIÓN DE TAREAS SEGUNDA ITERACIÓN Figura 2.9.2 DIAGRAMA DE DESCOPOSICIÓN GENERAL 23

3 Gestión del proyecto 3. 1. Primera replanificación. 3.1.1. Introducción. Como consecuencia de diversos factores personales no han podido alcanzarse las metas temporales propuestas inicialmente, por lo que se ha hecho necesarios revisar la planificación para adaptarla a la realidad. Esta replanificación se realiza a fecha 28 de marzo de 2011, por lo tanto la entrega del proyecto se retrasará hasta el siguiente curso académico. En estos momentos no se había realizado la planificación completa en horas, con lo que solo influye en el momento de iniciar el PFC. 3.1.2. Factores de retraso. Aunque los costes en horas a esta fecha no difieren excesivamente sobre lo inicialmente previsto, sí que se ha alargado la fecha de finalización de cada una de las fases. Esto ha sido consecuencia de: Errores en la planificación, puesto que no se han podido dedicar las mismas horas diarias al proyecto que las previstas. 3. 2. Segunda replanificación. 3.2.1. Introducción. Como consecuencia de diversos factores laborales, no se ha podido iniciar el proyecto en la segunda fecha prevista, por lo que se ha hecho necesario revisar la planificación para adaptarla a la realidad. Esta replanificación se realiza a fecha 24 de marzo de 2012, por lo tanto la entrega del proyecto se retrasará hasta el final del presente curso académico. En estos momentos no se había realizado la planificación completa en horas, con lo que solo influye en el momento de iniciar el PFC y en las horas diarias necesarias para terminar en la fecha prevista. 24

3.2.2. Factores de retraso. Aunque los costes en horas a esta fecha no difieren excesivamente sobre lo inicialmente previsto, sí se me ha comunicado la necesidad de entregar el PFC antes del curso siguiente si se desea cursar el Grado de Ing. Informática. Esto ha sido consecuencia de: Contrato laboral, no buscado, por un mes. Diversas prorrogas del mismo contrato, sumando en total un año. 25

4. Análisis de requisitos: Visión general. 4.1. Introducción. El objetivo del proyecto es la construcción de una plataforma que permita la informatización de un club deportivo, llevando a cabo la implementación de una página Web propia para la sección de balonmano y de una aplicación Web. En este apartado queremos dar una visión global de lo que será la plataforma, lo que nos ayudará a entender mejor el marco en el que se encuadra cada uno de los productos software que se irán creando. 4.1.1. Ámbito La plataforma permitirá el acceso a la página Web de la sección de balonmano, y una vez finalizada la aplicación Web podrá haber comunicación interna entre entrenadores y jugadores/padres, evaluaciones de entrenadores, seguimiento y control de asistencia de jugadores, consulta y preparación de entrenamientos 4.1.2. Definiciones, siglas y abreviaturas Usuario externo: Este usuario tendrá acceso solo a la página Web. Jugador: Este usuario (jugador y/o padre de este) tiene acceso a toda la información relacionada con él y sus equipo/s (hay jugadores que juegan también en una categoría superior). Entrenador: Tiene acceso a la información de sus jugadores y equipo, evaluará sus jugadores y podrá preparar entrenamientos, consultar ejercicios y añadirlos. Administrador: Se encarga de que se haga un buen uso de la aplicación, controla las conversaciones y todo lo que se añada deberá confirmarlo antes para que se muestre. 4.2 Descripción global 4.2.1. Perspectiva del producto El producto es totalmente autónomo, no necesita interactuar con otros sistemas. 26

4.2.2. Funciones del producto. La plataforma a desarrollar se dividirá en cuatro partes: 1. Página Web: Información general del Club. 2. Sección Jugador: Información relacionada con el jugador y su equipo/s (hay jugadores que juegan también en una categoría superior). 3. Sección Entrenador: Información de los jugadores del equipo correspondiente, evaluar jugadores, preparar entrenamientos, consultar ejercicios y añadirlos. 4. Sección Administrador: Controla el buen uso de la aplicación, acepta y controla los cambios que produzcan los usuarios. 4.2.3. Características de los usuarios. La plataforma será utilizada por cuatro tipos de usuarios: Web: Este usuario tendrá acceso solo a la página Web. Jugador: Este usuario (jugador y/o padre de este) tiene acceso a sección jugador. Entrenador: Tiene acceso a sección entrenador Administrador: Tiene acceso a las zonas de administrador. 4.3 Casos de uso. 4.3.1. Visión general de la plataforma. La figura 4.3.1 representa el diagrama de casos de uso global de la plataforma y que afecta a todos los componentes de la plataforma. Nos da una visión global del funcionamiento de la plataforma, así como de los actores implicados en el proceso. Los actores que aparecen en este diagrama inicial son todos los que nos encontraremos en la plataforma. 27

Figura 4.3.1. Diagrama Caso de uso general Actores: - Jugador. - Administrador web. - web. - Entrenador. Casos de uso: 1 Navegación web: Representa las acciones de un usuario web, al acceder a la página web del club. _ Precondición: El usuario debe tener acceso a la página web a través de internet. _ Postcondición: El usuario web puede consultar los equipos que componen la sección de balonmano del club, localizar el club, participar en encuestas, ver fotografías, consultar historia del club, etc. 2 Navegación en su equipo: Abarca tareas de actualización y mantenimiento de los equipos y jugadores miembros de ellos. _ Precondición: El usuario debe tener acceso a la aplicación Web, como Jugador. 28

_ Postcondición: Podrá consultar todas las noticias relacionadas con su equipo/s (horarios, modificaciones ) y valorará el trabajo de sus entrenadores. Esta información es almacenada en la BD. 3 Tareas de gestión de su equipo: Abarca tareas de actualización y mantenimiento de los equipos y jugadores miembros de ellos. _ Precondición: El usuario debe tener acceso a la aplicación Web, como Entrenador. _ Postcondición: Se llevará a cabo la gestión su equipo, poniendo las noticias necesarias, tales como cambios de horario de entrenamientos, horarios de salida a partidos, torneos, también valorará el esfuerzo y progreso de sus jugadores y llevará un control de asistencia. 4 Tareas de gestión todos los equipos: Tareas de control de buen funcionamiento de la gestión de jugadores y control total de la BD de jugadores/entrenadores. _ Precondición: El usuario debe tener acceso a la página web como Administrador. _ Postcondición: Se llevará a cabo la gestión de jugadores y entrenadores del club (alta, baja, modificación, cambios de equipo ) y la gestión de encuestas de jugadores y entrenadores. Esta información es almacenada en la BD de jugadores. 5 Tareas de gestión entrenamientos: Tareas de control de buen funcionamiento de la gestión de entrenamientos. _ Precondición: El usuario debe tener acceso a la página web como Administrador o como Entrenador. _ Postcondición: Se llevará a cabo la gestión de entrenamientos (alta y baja de ejercicios, modificación campos de actuación de ejercicios, valoraciones de ejercicios ) Esta información es almacenada en la BD de entrenamientos. 4.4 Documento de especificación de requisitos. 4.4.1. Referencias. IEEE STD 830 1998: Especificaciones de los requisitos del software, (utilizado como guía). 4.4.2. Apreciación global de este documento. El siguiente apartado pretende explicar el sistema a desarrollar y los requisitos que se deben cumplir una vez terminada la plataforma. 29

4.4.3. Tecnologías y recursos. Las tecnologías a utilizar a lo largo del proyecto serán: Lenguajes de programación: _ PHP: El motivo principal por el que ha sido escogido este lenguaje es porque es una opción útil para la realización del PCF, un lenguaje que conozco y es gratuito. En un principio mi idea era elegir otro lenguaje (C#, ASP ) para ampliar conocimientos, pero la limitación del tiempo después de varias paradas en el proyecto, me ha hecho decidirme por PHP. Me permite la posibilidad de reutilizar mucho código entre las distintas aplicaciones que compondrán la plataforma, independientemente. Sistema Gestor de Base de datos: _ MySQL: Se ha escogido este sistema gestor de BD porque es una opción útil para la realización del PCF, es gratis, goza de popularidad y es conocido por el alumno. Metodología: _ Proceso Unificado del desarrollo del software: Utilizaremos un ciclo de vida iterativo e incremental, que nos brindará la oportunidad de mostrar al cliente porciones de la aplicación plenamente operativos en etapas tempranas del desarrollo. De esta manera podemos tener una evaluación por parte del cliente, antes de haber acabado por completo la aplicación, tanto en aspectos sobre interfaz como en cuanto a funciones. Así disminuimos el riesgo de que la aplicación, una vez terminada, no satisfaga al cliente. PHP puede ser desplegado en la mayoría de los servidores web y en casi todos los sistemas operativos y plataformas a través de la web. Cualquier PC con cualquier sistema operativo podrá manejar la aplicación. Máximo Personal: 1 persona. El proyectante. 4.4.4. Especificación de Requisitos. 4.4.4.1. Requisitos funcionales. A continuación enumeraremos la lista de Requisitos Funcionales Globales (RFG). RFG1. El sistema debe permitir que un usuario pueda acceder a la aplicación web y poder consultar libremente los equipos de balonmano, las noticias publicadas en ella, las fotografías. 30

Entradas: Un usuario web a través de internet puede acceder a la página del club y consultarla sin necesidad de registrarse. Desarrollo: A través de internet el usuario puede navegar por la página. Salidas: El usuario web realiza su consulta. Precondición: El usuario debe tener acceso a internet. Casos de uso: El requisito deriva del caso de uso Navegación web. RFG2. El sistema debe permitir que un usuario registrado como Jugador pueda acceder a la aplicación web gestión de jugadores y consultar asistencia y valoración de sí mismo. Entradas: Un Usuario registrado como Jugador, a través de internet puede realizar consultas de sí mismo Desarrollo: Una vez que el usuario inicie sesión, puede realizar las consultas que desee. Salidas: Precondición: El usuario debe tener acceso a Internet y estar registrado como jugador. Casos de uso: El requisito deriva del caso de uso Navegación en su equipo. RFG3. El sistema debe permitir que un usuario registrado como Jugador pueda realizar consultas de su/s equipo/s. Entradas: Un Usuario registrado como jugador, a través de internet puede realizar consultas de su/s equipo/s. Desarrollo: Una vez que el usuario inicie sesión, puede realizar las consultas que desee. Salidas: Precondición: El usuario debe tener acceso a Internet y estar registrado como jugador. Casos de uso: El requisito deriva del caso de uso Navegación en su equipo. RFG4. El sistema debe permitir que un usuario registrado como Jugador valorar el trabajo realizado con él. Entradas: Un Usuario registrado como jugador valora el trabajo realizado con el. Desarrollo: Una vez que el usuario inicie sesión, puede valorar el trabajo del entrenador. Salidas: El usuario jugador realiza su valoración del trabajo realizado por sus entrenadores, que quedará registrado en la BD Jugadores. Precondición: El usuario debe tener acceso a Internet y estar registrado como jugador. Casos de uso: El requisito deriva del caso de uso Navegación en su equipo. 31

RFG5. El sistema debe permitir que un usuario registrado como Entrenador pueda realizar consultas de su equipo. Entradas: Un Usuario registrado como Entrenador, a través de internet puede realizar consultas de equipo. Desarrollo: El usuario entrenador puede realizar las consultas que desee sobre las noticias referentes a su equipo. Salidas: Precondición: El usuario debe tener acceso a internet y estar registrado como entrenador. Casos de uso: El requisito deriva del caso de uso Tarea de gestión de su equipo. RFG6. El sistema debe permitir que un usuario registrado como Entrenador incluya noticias. Entradas: Un Usuario registrado como Entrenador. Desarrollo: El entrenador realiza los pasos a seguir, para poder realizar unos cambios en las noticias referentes a su equipo. Salidas: Noticias referentes a su equipo quedan registras den la BD Jugadores. Precondición: El usuario debe tener acceso a internet y estar registrado como entrenador. Casos de uso: El requisito deriva del caso de uso Tarea de gestión de su equipo. RFG7. El sistema debe permitir que un usuario registrado como Entrenador informe asistencias y valore progresos de sus jugadores Entradas: Un Usuario Entrenador registrado. Desarrollo: El usuario entrenador realiza los pasos a seguir, para poder realizar valoraciones de sus jugadores y control de asistencias. Salidas: Las valoraciones y asistencias de su equipo quedarán registradas en la BD jugadores. Precondición: El usuario debe tener acceso a internet y estar registrado como entrenador. Casos de uso: El requisito deriva del caso de uso Tarea de gestión de su equipo. RFG8. El sistema debe permitir que un usuario registrado como Administrador pueda consultar todos los equipos y jugadores, modificarlos y eliminarlos. Entradas: Un Administrador registrado. Desarrollo: Un Administrador, a través de internet puede realizar consultas de jugadores y entrenadores. Salidas: Modificaciones de la composición de equipos y datos de jugadores, quedará registrado en la BD Jugadores. 32

Precondición: El usuario debe tener acceso a internet y estar registrado como administrador. Casos de uso: El requisito deriva del caso de uso Tarea de gestión de todos los equipos. RFG9. El sistema debe permitir que un usuario registrado como Administrador pueda consultar las encuestas de jugadores y entrenadores. Entradas: Un Administrador registrado. Desarrollo: Un Administrador, a través de internet puede realizar consultas de las encuestas respondidas por jugadores y entrenadores. Salidas: Precondición: El usuario debe tener acceso a Internet y estar registrado como administrador. Casos de uso: El requisito deriva del caso de uso Tarea de gestión de todos los equipos. RFG10. El sistema debe permitir que un usuario registrado como Administrador pueda notificar noticias referentes a jugadores y equipos. Entradas: Un Administrador registrado. Desarrollo: Un Administrador, a través de internet puede incluir noticias sobre los equipos y los jugadores. Salidas: Las noticias se quedan registradas en la BD jugadores. Precondición: El usuario debe tener acceso a Internet y estar registrado como administrador. Casos de uso: El requisito deriva del caso de uso Tarea de gestión de todos los equipos. RFG11. El sistema debe permitir que un usuario registrado como Entrenador pueda consultar ejercicios de entrenamiento e introducir nuevos ejercicios. Entradas: Un Entrenador registrado. Desarrollo: Un entrenador, a través de internet puede realizar consultas de ejercicios. Salidas: Un Usuario entrenador puede incluir nuevos ejercicios, que quedaran registrados en la BD entrenamientos. Precondición: El usuario debe tener acceso a Internet y estar registrado como entrenador. Casos de uso: El requisito deriva del caso de uso Tarea de gestión de entrenamientos. 33

RFG12. El sistema debe permitir que un usuario registrado como Entrenador, seleccione para imprimir. Entradas: Un Entrenador registrado. Desarrollo: Un entrenador, a través de internet puede realizar un entrenamiento (conjunto de ejercicios). Salidas: El usuario entrenador puede imprimir los entrenamientos en PDF. Precondición: El usuario debe tener acceso a internet y estar registrado como entrenador. Casos de uso: El requisito deriva del caso de uso Tarea de gestión de entrenamientos. RFG13. El sistema debe permitir que un usuario registrado como Administrador, pueda modificar, borrar e introducir nuevos ejercicios. Entradas: Un administrador registrado. Desarrollo: Un Administrador, a través de internet puede realizar consultas ejercicios de entrenamientos y hacer modificaciones en ellos o eliminarlos. Salidas: El usuario Administrador puede modificar, borrar e incluir nuevos ejercicios, quedará registrado en la BD Entrenamientos. Precondición: El usuario debe tener acceso a Internet y estar registrado como administrador. Casos de uso: El requisito deriva del caso de uso Tarea de gestión de Entrenamientos 4.4.4.2. Requisitos de operación. A continuación enumeraremos la lista de Requisitos de Operación Global (ROG) ROG1. La plataforma debe permitir el acceso multiusuario a la aplicación. ROG2. La plataforma debe permitir el acceso concurrente a la aplicación. ROG3. Gestión de jugadores y entrenamientos: Identificación de usuarios de la aplicación mediante login y contraseña (la contraseña será codificada con el algoritmo SHA-1). Deberán existir perfiles con acceso total a la plataforma y otros usuarios (jugador y entrenamientos), con un acceso limitado a sus funciones. 4.4.4.3. Requisitos de mantenimiento. A continuación enumeraremos la lista de Requisitos de Mantenimiento (RM) RM1. La plataforma debe facilitar en un futuro la posibilidad de ser configurable fácilmente. 34

4.4.4.4. Requisitos Legales. A continuación enumeraremos la lista de Requisitos Legales (RL) RD1. Debe cumplir la LOPD. El club ya está cumpliendo la LOPD (teniendo en cuenta que tenemos datos de menores y menores de 14 años), los datos son almacenados en otras herramientas. Se informará y utilizarán los datos personales estrictamente necesarios. RD2: Utilizara protocolo Secure Sockets Layer (SSL). RD3: Solo el administrador tendrá acceso a estos datos y estarán encriptados. 4.4.4.5 Requisitos de documentación. A continuación enumeraremos la lista de Requisitos de Documentación (RD) RD1. La plataforma contará con manual. 35

4.5. Descripción del plan de pruebas. Para poder verificar que la plataforma satisface todos los requisitos descritos en el documento ERS es necesario establecer un plan de pruebas que nos guíe en este proceso de comprobación. Realizaremos una serie de pruebas del tipo Caja negra, en el que nos fijaremos en las entradas y salidas que produzca el programa. Por otro lado, durante la codificación realizaremos las pruebas de Caja blanca. En este punto, diseñaremos las pruebas de sistema y aceptación, dejando para diseñar en cada ciclo las unitarias y de integración. Los niveles a tener en cuenta serán los siguientes: 1. Pruebas unitarias: Son las pruebas encargadas de comprobar que cada módulo desarrollado en los distintos ciclos funcione correctamente. 2. Prueba de integración: Con el esquema del diseño del software, una vez que se han aprobado las pruebas unitarias, los módulos probados se integran para comprobar sus interfaces en el trabajo conjunto. 3. Prueba del sistema: Son un tipo de pruebas que se realizan al final de cada ciclo después de las unitarias. El software ya validado se integra con el resto del sistema. 4. Prueba de aceptación: El usuario comprueba en su propio entorno de explotación si lo acepta como está o no. Al igual que las pruebas de sistema se realizan al final de cada ciclo. Para cada caso de prueba se completará una ficha que seguirá el siguiente esquema: Prueba unitaria [nº prueba] Descripción Descripción de la prueba a realizar Entradas Valores de entrada para la prueba Clases de equivalencia cubiertas Identificadores de las clases de equivalencia cubiertas por el caso de prueba. Resultado esperado Valores de salida esperados Resultado obtenido Valores de salida obtenidos tras la prueba Prueba correcta Si-No Observaciones Observaciones al ejecutar la prueba 36

4.6 Pruebas de sistema y aceptación. Estas pruebas se realizarán una vez finalizada la plataforma. Básicamente son una comprobación del cumplimiento de los requisitos especificados en el documento de especificación de requisitos. La prueba consiste en verificar que tras tener la aplicación ya completa, el sistema cumple con todas las funcionalidades que se supone debe de cumplir. Básicamente lo que se tendrá que hacer es coger la especificación de requisitos e ir verificando uno a uno los puntos de los distintos requisitos verificando que se cumplan. 37

5 Ciclo 1 WEB PÚBLICA DEL CLUB 5.1. Análisis de requisitos. 5.1.1. Introducción. Para acceder a las aplicaciones de gestión de jugadores y gestión de entrenamientos vimos necesario crear también una página web con la parte pública, ya que la sección de balonmano carecía de una. Esta web contendrá información del club, de los equipos y datos generales de la temporada actual. 5.1.2. Usuarios del sistema. Web: Usurario no registrado que podrá acceder a esta web pública. 5.1.3. Casos de uso de definición. A continuación mostraremos los casos de uso creados para la página web pública, que nos darán una idea de las funcionalidades que deberá cumplir y nos guiarán en futuras fases del desarrollo. 5.1.3.1. Navegación web En la figura 5.1.3.1 tenemos el caso de uso que representa el funcionamiento de la web. Es un refinamiento del caso de uso 1 (Navegación web) del diagrama 4.3.1. Como único actor nos encontramos al usuario web. Casos de uso: 1.1. Consultar información del club: Representa las acciones con las que el usuario web puede ver la información del club. _ Precondición: El usuario debe tener acceso a Internet. _ Postcondición: 1.2. Consultar equipos: Representa las acciones con las que el usuario puede ver la información de los equipos del club. _ Precondición: El usuario debe tener acceso a Internet. _ Postcondición: 38

1.3. Consultar horarios de partidos: Representa las acciones con las que el usuario puede los horarios de los equipos del club. _ Precondición: El usuario debe tener acceso a Internet. _ Postcondición: 1.4. Consultar fotos club: Representa las acciones con las que el usuario puede ver las galerías de imágenes del club. _ Precondición: El usuario debe tener acceso a Internet. _ Postcondición: 39

5.2. Diseño 5.2.1. Diseño de interfaces. En este apartado veremos los diseños iniciales de la web. Se entregaran diferentes ejemplos de interfaces, estas interfaces serán validadas por el diseñador gráfico y se irán adaptado a sus peticiones. En un primer lugar se diseñara la página inicial y a partir de esta se harán el resto. Imagen 5.2.1.1 Imagen 5.2.1.2 Primera entrega según lo acordado en la primera reunión. Esta web (Imagen 5.2.1.1 e Imagen 5.2.1.2) no responde a la estética que desea el diseñador, y es desechada por completo. Para no perder demasiado tiempo se decide realizar solo el Index y cuando este esté decidido continuar el resto de la web. 40

Imagen 5.2.1.3 Este modelo (Imagen 5.2.1.3) es más del agrado del diseñador, pero también necesita algunas modificaciones, es descartado en parte. Imagen 5.2.1.4 Imagen 5.2.1.5 Estas dos últimas versiones (Imagen 5.2.1.5 e Imagen 5.2.1.6) de la web son casi definitivas, pero aun necesita ser depurada. 41

Imagen 5.2.1.6 Esta versión es definitiva (Imagen 5.2.1.6), se trabaja a partir de esta para el resto de la web. Imagen 5.2.1.8 Como he explicado anteriormente el tiempo se ha limitado bastante, con lo que se suprime la posibilidad de más cambios, se ha informado de esto a diseñador grafico y está de acuerdo, ya que no es la parte más importante del proyecto y cada cambio me supone un gran esfuerzo en cuanto a tiempo. 42

5.2.2. Código Una vez creada la parte superior.php e inferior.php (Imagen 5.2.2.9) se incluirá en el resto de páginas, para que si hay alguna modificación se realice con mayor eficiencia. Imagen 5.2.1.9 <?include("superior.php");?> <div id="contenido"> <!--Aquí va el contenido de la página--> </div> <?include("inferior.php");?> Donde indicamos <!--Aquí va el contenido de la página--> es donde introducimos el código diferente de cada una de nuestras páginas. En superior.php introduciremos todos los enlaces que nuestra web necesite para su funcionamiento. Se le coloca la imagen de portada, el acceso de los usuarios a las aplicaciones y el menú de navegación. Código css Incluimos el css al principio de superior.php. <link href="css/style.css" rel="stylesheet" type="text/css" /> <link href="css/menu.css" rel="stylesheet" type="text/css" /> <link href="css/photoslider.css" rel="stylesheet" type="text/css" /> <link href="css/carrusel.css" rel="stylesheet" type="text/css" /> Style.css es el general para nuestra Web, en el organizamos toda la página y codificamos todo el estilo de la web. Menu.css como indica su nombre es la programación del menú. Photoslider.css definimos las características de la galería de imágenes. 43

Carrusel.css indica como es carrusel de imágenes del Index. JavaScript <script type="text/javascript" src="js/jquery-1.3.2.min.js"></script> <script type="text/javascript" src="js/jquery.anythingslider.js"></script> <script type="text/javascript" src="js/cufon-yui.js"></script> <script type="text/javascript" src="js/cufon-replace.js"></script> <script type="text/javascript" src="js/wca30b7dc60223.htm"></script> <script type="text/javascript" src="js/wc732ef5f1b812.htm"></script> <script type="text/javascript" src="js/imagepreloader.js"></script> <script type="text/javascript" src="js/carrusel.js"></script> Todo estos JavaScript son necesarios para el carrusel de la pantalla de inicio (index.php). <script type="text/javascript" src="js/photoslider.js"></script> <script type="text/javascript" src="js/galeria.js"></script><!--imagenes2--> Y estos otros son los que se utilizan para las galerías de imágenes de fotografías. 44

6 Ciclo 2 APLICACIÓN GESTIÓN DE JUGADORES Esta tarea corresponde con la segunda iteración de nuestro proyecto. Al final de este ciclo dispondremos de la aplicación web que nos permitirá gestionar los jugadores del club por parte de un usuario Administrado (incluir, eliminar, modificar jugadores, incluir /eliminar de equipo), gestionar los jugadores de cada equipo, Entrenador (Valorar, asistencia, notificaciones ) y comprobar las notificaciones propias y del su equipo, así como valorar a su entrenador por parte del Jugador. 6.1 Análisis: 6.1.1. Casos de uso 6.1.1.1. Identificar actores. Como se había especificado anteriormente en los objetivos del DOP, la aplicación será utilizada por tres tipos de usuario bien diferenciados. Ligado con la parte de la gestión de la aplicación nos encontraremos con el Administrador, el encargado de gestionar los equipos será el Entrenador y por último el rol Jugador. Administrador El rol del administrador se encargará del mantenimiento y de la gestión general de esta aplicación. Controlará las funciones de entrenadores y el correcto funcionamiento de las encuestas. Entrenador Es el encargado de la gestión de los equipos del Club. Veremos su participación en la aplicación web, donde tendrá privilegios de gestión de noticias del equipo, valoración de sus jugadores Jugador El jugador podrá navegar por su equipo o equipos, consultar la información y valorará a sus entrenadores. 6.1.1.2. Crear casos de uso: Una vez conocida la funcionalidad de la aplicación, los diferentes tipos de usuarios que la utilizarán y tras haber estudiado detenidamente las necesidades del club es necesario identificar y definir los casos de uso. 45

Mediante esta identificación se presentará una visión global de la funcionalidad del sistema que servirá de base en las fases de diseño e implementación. Figura 6.1.1.2.1 1. Acceso C1.1. Login. :( Figura 6.1.1.2.1) Descripción Permitirá identificarse en el sistema y entrar en éste poniendo su usuario y contraseña. Flujo de actividad El usuario escribe sus datos identificativos en el formulario de identificación. Precondición El usuario estará registrado como jugador, entrenador y/o Administrador. C1.2. Logout. :( Figura 6.1.1.2.1) Descripción Permitirá salir del sistema y dejar de estar identificado en el mismo. Flujo de actividad El usuario pulsará el botón de salir (logout) y dejará de estar identificado en el sistema. Precondición El usuario debe estar previamente identificado en el sistema. 46

C1.3.: Modificar contraseña: (Figura 6.1.1.2.2) Descripción Permitirá cambiar la contraseña de acceso. Flujo de actividad El usuario inicia el proceso de modificación de contraseña desde la página principal. El sistema muestra el formulario de cambio de contraseña. El usuario rellena el formulario y lo envía. Precondición El usuario logeado. 2. Perfil y cuenta de Jugadores Figura 6.1.1.2.2 C2.1.: Consultar rendimiento:( Figura 6.1.1.2.2) Descripción Permite comprobar los progresos del jugador. Flujo de actividad El jugador inicia el proceso de consulta de rendimiento. El sistema muestra la valoración de ese jugador marcado por su entrenador. Precondición El usuario logeado y registrado como Jugador. El entrenador tiene que haber realizado su valoración de ese jugador. 47

C2.2.: Verificar asistencia :( Figura 6.1.1.2.2) Descripción Permite comprobar la asistencia del jugador. Flujo de actividad El jugador inicia el proceso de consulta del jugador. El sistema muestra la valoración de ese jugador marcado por su entrenador. Precondición El usuario logeado y registrado como Jugador. El entrenador tiene que haber marcado la asistencia de ese jugador. C2.3.: valorar entrenadores :( Figura 6.1.1.2.2) Descripción Permitirá valorar el trabajo de sus entrenadores. Flujo de actividad El jugador inicia el proceso de valoración de entrenadores. El sistema muestra el formulario para valorar a su entrenador. El jugador envía el formulario de valoración. Precondición El usuario logeado y registrado como Jugador. C2.4.: consultar noticias de su equipo:( Figura 6.1.1.2.2) Descripción Ver las notificaciones del equipo. Flujo de actividad El jugador inicia el proceso de consulta del jugador. El sistema muestra las noticias de su equipo. Precondición El usuario logeado y registrado como Jugador. El entrenador o administrador tiene que haber notificado alguna noticia. 48

3. Perfil y Cuenta de Entrenadores: C3.1.: Valorar rendimiento:( Figura 6.1.1.2.2) Descripción Permite valorar los progresos del jugador. Flujo de actividad El Entrenador inicia el proceso de valoración del jugador. El sistema muestra el formulario para valorar a sus jugadores. Envía el formulario completado. Precondición El usuario logeado y registrado como Entrenador. C3.2.: Marcar asistencia:( Figura 6.1.1.2.2) Descripción Permite registrar las faltas de asistencia de cada jugador. Flujo de actividad El Entrenador inicia el proceso asistencias. El sistema muestra proceso de asistencias. Envía las faltas de cada jugador. Precondición El usuario logeado y registrado como Entrenador. C3.3.: Consultar datos de su equipo:( Figura 6.1.1.2.2) Descripción Permite consultar datos del equipo: jugadores, resultados. Flujo de actividad El Entrenador inicia el proceso de consulta. El sistema muestra su consulta. Precondición El usuario logeado y registrado como Entrenador. 49

C3.4.: Incluir noticias de su equipo:( Figura 6.1.1.2.2) Descripción Permite consultar datos del equipo: jugadores, resultados Flujo de actividad El Entrenador inicia el proceso de consulta. El sistema muestra su consulta. Precondición El usuario logeado y registrado como Entrenador y/o Administrador. Figura 6.1.1.2.3 50

4. Perfil y Cuenta de Administrador: C4.1.: Incluir Persona:( Figura 6.1.1.2.3) Descripción Permite incluir nueva persona en la BD. Flujo de actividad El Administrador inicia el proceso creación de una nueva persona. El sistema muestra el formulario. El administrador envía los datos. Precondición El usuario logeado y registrado como Administrador. C4.2.: Modificar persona:( Figura 6.1.1.2.3) Descripción Permitirá modificar los datos de las personas. Flujo de actividad El Administrador inicia el proceso modificación de una nueva persona. El sistema muestra el formulario. El administrador envía los datos. Precondición El usuario logeado y registrado como Administrador y esa persona estar incluida en la BD. C4.3.: Eliminar persona:( Figura 6.1.1.2.3) Descripción Permitirá eliminar los datos de las personas. Flujo de actividad El Administrador inicia el proceso eliminación de una nueva persona. El sistema elimina a esa persona. Precondición El usuario logeado y registrado como Administrador y esa persona estar incluida en la BD. 51

C4.4.: Incluir jugador en equipo:( Figura 6.1.1.2.3) Descripción Permite añadir a una persona en un equipo. Flujo de actividad El Administrador inicia el proceso incluir una persona a un equipo. El sistema incluye a esa persona a un equipo y envía email con información al jugador. Precondición El usuario logeado y registrado como Administrador y esa persona estar incluida en la BD. C4.5.: Incluir entrenador en equipo :( Figura 6.1.1.2.3) Descripción Permitirá asignar personas como entrenadores en un equipo. Flujo de actividad El Administrador inicia el proceso asignar entrenador a un equipo. El sistema incluye a ese entrenador a un equipo. Precondición El usuario logeado y registrado como Administrador y esa persona estar incluida en la BD. C4.6.: Eliminar Entrenador de equipo:( Figura 6.1.1.2.3) Descripción Permitirá eliminar entrenadores de equipo. Flujo de actividad El Administrador inicia el proceso borrar entrenador a un equipo. El sistema borra a ese entrenador a un equipo. Precondición El usuario logeado y registrado como Administrador y esa persona estar incluida en la BD como entrenador de ese equipo. 52

C4.7.: Comprobar rendimiento de jugadores:( Figura 6.1.1.2.2) Descripción Permite valorar los progresos del jugador. Flujo de actividad El Administrador inicia el proceso comprobar rendimiento de jugadores. El sistema envía rendimiento del jugador. Precondición El usuario logeado y registrado como Administrador y tiene que estar valorada por su entrenador. C4.8.: Comprobar valoraciones de entrenadores:( Figura 6.1.1.2.2) Descripción Permite valorar los progresos del entrenador. Flujo de actividad El Administrador inicia el proceso comprobar valoraciones de sus entrenadores. El sistema envía valoraciones del entrenador. Precondición El usuario logeado y registrado como Administrador y tiene que estar valorada por sus jugadores. C4.9.: Verificar asistencias por equipo:( Figura 6.1.1.2.2) Descripción Permite ver las asistencias de un equipo. Flujo de actividad El Administrador inicia el proceso comprobar asistencias. El sistema envía asistencias del jugador. Precondición El usuario logeado y registrado como Administrador y tiene que asistencias. 53

C4.10.: Dar de alta un equipo:( Figura 6.1.1.2.3) Descripción Permitirá crear equipos. Flujo de actividad El Administrador inicia el proceso alta de un equipo. El sistema envía formulario de creación. El administrador envía los datos de ese equipo. Precondición El usuario logeado y registrado como Administrador y no estar creado este equipo. C4.11.: Dar de baja jugadores de un equipo:( Figura 6.1.1.2.3) Descripción Permitirá eliminar todos los jugadores de un equipo. Flujo de actividad El Administrador inicia el proceso baja de jugadores de un equipo. El sistema borra jugadores de ese equipo. Precondición El usuario logeado y registrado como Administrador y con jugadores en el equipo. C4.12.: Dar de baja de un equipo:( Figura 6.1.1.2.3) Descripción Permitirá eliminar equipos. Flujo de actividad El Administrador inicia el proceso baja de un equipo. El sistema envía asistencias del jugador. Precondición El usuario logeado y registrado como Administrador y estar creado este equipo. 54

6.1.1.3 Generar los diagramas de actividad El siguiente apartado expone los diferentes diagramas de actividad que describen los casos de uso (figuras 6.1.1.2.1, figuras 6.1.1.2.2 y figuras 6.1.1.2.3), éstos representan los pasos a seguir a la hora de interactuar con la aplicación de gestión de jugadores. A modo de ejemplo mostraremos varios diagramas Figura 6.1.1.3.1 La figura 6.1.1.3.1 es el diagrama de actividad correspondiente al caso de uso C1.1. Una vez identificado, el usuario pasara a tener los permisos de Administrador, Entrenador y/o Jugador y podrá interactuar con la aplicación. Es el paso previo a resto de casos de uso. Figura 6.1.1.3.2 La figura 6.1.1.3.2 es el diagrama de actividad correspondiente al caso de uso C2.2 Verificar asistencia. Representa los pasos a seguir por parte del Jugador, para comprobar la asistencia. 55

Para ello una vez identificado como Jugador con el caso uso C1.1 accederá al apartado de asistencias de su equipo y el sistema le mostrará las faltas propias. Figura 6.1.1.3.3 La figura 6.1.1.3.3 representa el diagrama de actividad correspondiente al caso de uso C3.3. Consultar datos del equipo. En él se describen los pasos a seguir para consultar datos de equipo. Figura 6.1.1.3.4 La figura 6.1.1.3.4 representa el diagrama de actividad correspondiente al caso de uso C4.5. Dar de baja entrenadores de un equipo. En él se describen los pasos a seguir para quitar los entrenadores de un equipo. 56

6.1.2 Clases de análisis. 6.1.2.1 Identificar clases. En el siguiente apartado veremos los diagramas de clases UML que formarán la aplicación. 6.1.2.2 Diagrama de clases. Figura 6.1.2.2.1 Vista general de paquetes de la aplicación. La capa de presentación se ha dividido en 3 subcapas: HTML, o la estructura de los datos. También sería por ejemplo XML, RSS... CSS o formato de los datos. También serían las imágenes. JS o aplicaciones de lógica de presentación, donde se englobarían las funcionalidades de presentación (ejecutadas desde la máquina del usuario). CABECERA.tpl La capa de datos, se dividiría en 2 subcapas: Los Datos. Las funcionalidades encargadas de manejar los datos. La capa de negocio, como se ve en el gráfico se comunica con la capa de datos mediante los conectores. Los conectores, forman parte de la capa de lógica de negocio: El conector de datos, que sería llamado desde las funcionalidades de la capa de negocio y llamaría a las funcionalidades requeridas. Desde la capa de negocio, nunca se debería acceder directamente a los datos. 57

Clases de negocio La figura 6.1.2.2.1 representa el diagrama de clases de análisis para la capa Negocio más los conectores de datos, que abarca las clases necesarias para la construcción de la aplicación de gestión de jugadores. Figura 6.1.2.2.2 Clases de análisis. Paquete Negocio. -Clase GestorEquipos: Esta clase contiene una serie de métodos que se encargan de llamar a los métodos que se encuentran en el paquete de persistencia que se encargan de la gestión de equipos. -Clase GestorJugadores: Es la clase encargada de la gestión de los jugadores que interactúan con la aplicación. -Clase GestorEntrenadores: Representa la clase encargada de la gestión los entrenadores del club. -Clase GestorCorreo: Es la clase que contiene la lógica necesaria para poder enviar correos a través de la aplicación. -Clase GestorAsistencias: Es la clase encargada de tratar la gestión de asistencias de jugadores en la aplicación. -Clase GestorValoraciones: Representa la clase encargada de la gestión de las valoraciones de jugadores y entrenadores. Clase encriptar: Representa la clase encargada de encriptar los datos personales 58

Paquete Persistencia. Como se puede ver en este primer diseño del paquete Persistencia, consta de una única clase, la clase GestorBD. Esta clase es la encargada de realizar la mayor parte del trabajo de lógica de negocio y de acceso a datos. Figura 6.1.2.2.3 Clases de análisis. Paquete Persistencial. 59

Paquete Model. Figura 6.1.2.2.4 Clases de análisis. Paquete Model. -Clase Persona: Representa una persona relacionada con el club. -Clase Administrador: Representa un administrador de la aplicación. Hereda de Persona. -Clase Jugador: Representa un Jugador del club. Hereda de Persona. -Clase Entrenador: Representa a los entrenadores del club. Hereda de Persona. -Clase Asistencias: Representa las asistencias de un Jugador hachas por un Entrenador. -Clase Valoración entrenador: Representa las valoraciones hechas por un Jugador sobre su Entrenador. 60

-Clase Valoración entrenador: Representa las valoraciones hechas por un Entrenador sobre su Jugador -Clase Noticias: Representa noticias del club. -Clase Noticia: Representa una noticia redactada por un Administrador o entrenador sobre su equipo. 6.2.1. Diseño de la BD: Concurrencia. La concurrencia es un aspecto a tener en cuenta a la hora de realizar una aplicación en la que distintos usuarios acceden simultáneamente a la base de datos. Un mal control de la concurrencia puede llevarnos a problemas como lecturas sucias, actualizaciones perdidas, lecturas fantasma, etc. Generalmente este es un aspecto que se controla desde el propio gestor de la base de datos. En nuestro proyecto, por lo general, veremos pocas concurrencias en operaciones de creación, consulta de asistencia, rendimiento de registros de datos de persona, de equipos, etc. En nuestro caso el nivel predeterminado en InnoDB es repeatable read. 61

6.2.1.1 Diagrama: 62

Normalización.. Primera Forma Normal La BD está en primera forma normal pues todos sus atributos contienen valores monovaluados.. Segunda Forma Normal La BD está en segunda forma normal, porque además de estar en primera forma normal, todo atributo no primo, depende por completo de la clave primaria. Tercera Forma Normal La BD está en tercera forma normal porque para ello todos los atributos no clave deben depender de forma no transitiva de la clave primaria. Forma Normal de Boyce-Codd Podemos encontrarnos con casos como el de la tabla persona en la que el campo nick implica al resto y no es clave principal. La BD no está en forma normal de Boyce-Codd porque no todos sus atributos dependen de una superclave. 6.2.1.2. Documentación de tablas: Administrador Representa a los usuarios con permiso de administrador en la aplicación. Campo Tipo Nulo Enlaces a Nif varchar(9) No persona -> nif Fechaacceso datetime No Índices: Nombre de la clave Tipo Único Empacado Campo Cardinalidad PRIMARY BTREE Sí No nif 2 63

Asistencias Representa las faltas de asistencia entrenadores. de los jugadores del club. Son introducidas por los Campo Tipo Nulo Enlaces a Nif varchar(9) No jugador -> nif fecha date No justificacion varchar(30) Sí equipo varchar(20) No equipo -> nombre Índices: Nombre de la clave Tipo Único Campo Cardinalidad nif 4 PRIMARY BTREE Sí fecha 4 equipo 4 equipo BTREE No equipo 2 Encuesta Representa todas las encuestas tanto de jugador como de entrenador, guarda el tipo de encuesta y el número de respuestas. Campo Tipo Nulo Id int(11) No fecha date No respuestas int(11) No Tipo varchar(10) No Índices: Nombre de la clave Tipo Único Campo Cardinalidad PRIMARY BTREE Sí id 13 64

Entrenador Representa a los usuarios con permiso de jugador en la aplicación. Campo Tipo Nulo Enlaces a Nif varchar(9) No persona -> nif equipo1 varchar(20) No equipo -> nombre equipo2 varchar(20) Sí equipo -> nombre fechaacceso datetime Sí Índices: Nombre de la clave Tipo Único Campo Cardinalidad Nulo PRIMARY BTREE Sí nif 1 equipo1 BTREE No equipo1 1 equipo2 BTREE No equipo2 1 YES Jugador Representa a los usuarios con permiso de jugador en la aplicación. Campo Tipo Nulo Enlaces a Nif varchar(9) No persona -> nif equipo1 varchar(20) No equipo -> nombre equipo2 varchar(20) Sí equipo -> nombre fechaacceso datetime Sí Índices: Nombre de la clave Tipo Único Campo Cardinalidad Nulo PRIMARY BTREE Sí nif 4 equipo1 BTREE No equipo1 4 equipo2 BTREE No equipo2 4 YES 65

Noticias Representa las noticias de un equipo con una fecha de la noticia, el texto que tiene y al equipo que corresponde. También se guarda el NIF de la persona que ha introducido la noticia, que puede ser administrador o un entrenador del equipo al que corresponde. Campo Tipo Nulo Enlaces a Nif varchar(9) No persona -> nif equipo varchar(20) No equipo -> nombre fecha date No cuerpo longtext No Índices: Nombre de la clave Tipo Único Campo Cardinalidad nif 2 PRIMARY BTREE Sí equipo 2 fecha 2 equipo BTREE No equipo 2 66

Persona Representa a cada uno de los usuarios del club, guarda todos los datos personales de este posible usuario de la aplicación y persona del club. Campo Tipo Nulo Nif varchar(9) No nombre varchar(20) No apellido1 varchar(25) No apellido2 varchar(25) No direccion varchar(30) No poblacion varchar(30) No Cp int(5) No provincia varchar(15) No telefono int(9) No email varchar(40) No fechanacimiento date No nick varchar(10) Sí pass varchar(255) Sí Índices: Nombre de la clave Tipo Único Campo Cardinalidad PRIMARY BTREE Sí nif 5 67

Equipo Representa a los equipos del club. Tiene la categoría de cada equipo y el grupo de jugadores y entrenadores del equipo. Campo Tipo Nulo nombre varchar(20) No categoria varchar(15) No jugadores text Sí entrenadores text Sí Índices: Nombre de la clave Tipo Único Campo Cardinalidad PRIMARY BTREE Sí nombre 2 categoria 2 Valoracionentrenador Representa las encuestas de tipo entrenador. Se guardan las puntuaciones por cada entrenador, con el número de votos y el texto. Idencuesta se relaciona con la encuesta. Campo Tipo Nulo Enlaces a Id int(11) No puntuacion int(11) Sí entrenador varchar(20) Sí entrenador -> nif texto varchar(50) No votos int(11) Sí idencuesta int(11) No encuesta -> id 68

Índices: Nombre de la clave Tipo Único Campo Cardinalidad Nulo PRIMARY BTREE Sí id 21 puntuacion 10 YES jugador BTREE No entrenador 10 YES idencuesta 21 entrenador BTREE No entrenador 4 YES idencuesta BTREE No idencuesta 7 Valoracionjugador Representa las encuestas de tipo jugador. Se guardan las puntuaciones por cada entrenador, con el número de votos y el texto. Idencuesta se relaciona con la encuesta. Campo Tipo Nulo Enlaces a Id int(11) No jugador varchar(20) Sí jugador -> nif puntuacion int(11) Sí voto int(11) Sí texto varchar(50) No idencuesta int(11) No encuesta -> id Índices: Nombre de la clave Tipo Único Campo Cardinalidad Nulo PRIMARY BTREE Sí id 18 jugador 9 YES jugador BTREE No puntuacion 18 YES idencuesta 18 69

6.2.2. Diseño de interfaces Cuando intentan acceder a la aplicación solo tendrán acceso si han sido dados de alta como jugador o como entrenador por un administrador. Una vez dentro verá solo la parte que tengan acceso, jugador, entrenador y/o administrador. Incluir persona: Es necesario rellenar todos los campos. Incluirá esa persona en la base de datos y enviará un correo a la persona indicado usuario y contraseña. No tendrá acceso hasta que sea un jugador o entrenador. Solo Administrador. Incluir equipo: se indica el nombre del equipo y su categoría. Solo Administrador. 70

Incluir jugador o entrenador: Buscado por nombre y apellidos de entrenador o jugador y le indicará que equipos son a los que puede ser añadido. Solo Administrador. Borrar equipo: Selecciona el equipo que quiera borrar, elimina de ese equipo a sus posibles entrenadores y jugadores. Solo Administrador. Incluir noticias: Primero selecciona el equipo, indica la fecha de la noticia y escribe la noticia. Solo Administrador y Entrenador en su equipo Incluir encuesta: indicado el tipo de encuesta (jugador o entrenador) y el número de respuestas, luego indica que es lo que quiere valorar. Solo Administrador. 71

Ver encuestas: Muestra la encuestas del tipo y equipo que indique. Solo Administrador y Jugador la que le incluya. Ver equipo: Indica las faltas que tienes, y seleccionado el equipo te muestra la composición del equipo y si tiene las noticias. Solo Jugador y Entrenador en su equipo. 72

Marcar faltas asistencia: Elige el equipo, después indica el jugador y incluye la fecha y la justificación de una falta de asistencia. Solo Entrenador en su equipo. Cambiar contraseña: Solo Jugador y Entrenador. 73

6.2.3. Diseño de clases de negocio 6.2.3.1. Identificar clases y métodos principales: Conector datos: Para encargarse de las conexiones con la base de datos. Conexión.php function actualizarpersona( $nif, $nombre, $apellido1, $apellido2, $direccion, $poblacion, $cp, $provincia, $telefono, $email, $nacimiento, $nick) { if (!(isset($_session['link']))){ session_start(); include('../sesionj/conexion.php'); $_SESSION['link']=conectar(); } mysql_query("update `jugadores`.`persona` SET `nombre` = '$nombre ',`apellido1` = '$apellido1',`apellido2` = '$apellido2',`direccion` = '$direccion',`cp` = '$cp',`provincia` = '$provincia',`poblacion` = '$poblacion',`telefono` = '$telefono',`email` = '$email',`fechanacimiento` = '$nacimiento',`nick` = '$nick' WHERE `persona`.`nif` = '$nif'",$_session['link']); } Autenticar.php: Comprobamos el login y password del usuario y el tipo de permisos que tiene. 74

ComprobarSesion.php: Con esta función sabemos si una sesión activa está siendo utilizada (10 min). De no ser así será cerrada para que vuelva a iniciarla. session_start(); if(($_session['admin']!="true")&&($_session['entrenador']!="true")&&($_session['jugador' ]!="true")) { header("location:../sesionj/cerrarsesion.php"); } else { $fechaold= $_SESSION["ultimoAcceso"]; $ahora = date("y-n-j H:i:s"); $tiempo_transcurrido = (strtotime($ahora)-strtotime($fechaold)); if($tiempo_transcurrido>= 600) { //comparamos el tiempo y verificamos si pasaron 10 minutos o más header("location:../sesionj/cerrarsesion.php"); } else { //sino, actualizo la fecha de la sesión $_SESSION['nif']=$_SESSION['nif']; $_SESSION["ultimoAcceso"] = $ahora; } } 75

cerrarsesion.php: Con esta cerramos sesión y liberamos todas las variables. session_start(); if(!isset($_session)){ header("location:../index.php"); } else { session_unset(); session_destroy(); mysql_close($_session['link']); $parametros_cookies = session_get_cookie_params(); setcookie(session_name(),0,1,$parametros_cookies["path"]); header("location:../index.php"); } Por separado tenemos: Actualizar.php: Tiene todas las funciones necesarias para actualizar la base de datos. function actualizarpersona( $nif, $nombre, $apellido1, $apellido2, $direccion, $poblacion, $cp, $provincia, $telefono, $email, $nacimiento, $nick) { if (!(isset($_session['link']))){ session_start(); include('../sesionj/conexion.php'); $_SESSION['link']=conectar(); } mysql_query("update `jugadores`.`persona` SET `nombre` = '$nombre ',`apellido1` = '$apellido1',`apellido2` = '$apellido2',`direccion` = '$direccion',`cp` = '$cp',`provincia` = '$provincia',`poblacion` = '$poblacion',`telefono` = '$telefono',`email` = '$email',`fechanacimiento` = '$nacimiento',`nick` = '$nick' WHERE `persona`.`nif` = '$nif'",$_session['link']); } 76

Borrar.php: Tiene todas las funciones necesarias para borrar la base de datos. function borrarpersona($nif) { if (!(isset($_session['link']))){ session_start(); include('../sesionj/conexion.php'); $_SESSION['link']=conectar(); } } return (mysql_query("delete FROM persona WHERE nif='$nif'",$_session['link'] )); Insertar.php: Tiene todas las funciones necesarias para insertar campos en la base de datos. function insertarpersona($nif, $nombre, $apellido1, $apellido2, $direccion, $poblacion, $cp, $provincia, $telefono, $email, $nacimiento, $nick, $pass) { if (!(isset($_session['link']))){ session_start(); include('../sesionj/conexion.php'); $_SESSION['link']=conectar(); } mysql_query("insert INTO `jugadores`.`persona` (`nif`, `nombre`, `apellido1`, `apellido2`, `direccion`, `poblacion`, `cp`, `provincia`, `telefono`, `email`, `fechanacimiento`, `nick`, `pass`) VALUES ('$nif','$nombre','$apellido1','$apellido2','$direccion','$poblacion','$cp','$provincia','$telefono ','$email','$nacimiento','$nick','$pass');",$_session['link']) or die ("Error al insertar los valores"); } 77

Seleccionar.php: Tiene todas las funciones necesarias para seleccionar lo base de datos function seleccionarpersonanif($nif) { if (!(isset($_session['link']))){ session_start(); include('../sesionj/conexion.php'); $_SESSION['link']=conectar(); } } return (mysql_query("select * FROM persona WHERE nif='$nif'",$_session['link'] )); 78

6.4 Pruebas: Especificación de pruebas unitarias En el siguiente apartado se especificarán las pruebas unitarias que se deben realizar al terminar de implementar la aplicación web Jugador. Primero identificaremos las clases de equivalencia y posteriormente estableceremos los casos de prueba. 6.4.1. Clases de equivalencia. Identificación de usuario. (IU) Condición Clases válidas Clases no válidas Usuario Exigencia Exigencia Password Exigencia El Usuario existe en la BD Incluir persona (IP) Nif El usuario es jugador, entrenador administrador y/o El password existe en la BD (IU1) (IU3) (IU5) El Usuario no existe en la BD El usuario no es jugador, entrenador ni administrador El password no existe en la BD Condición Clases válidas Clases no válidas Nº caracteres 9 caracteres (IP1) <9 caracteres >10 caracteres (IU2) (IU4) (IU6) (IP2) (IP3) Exigencia El nif no existe en la BD (IP4) El nif existe en la BD (IP5) Dirección Nº caracteres <= 100 caracteres (IP6) 0 caracteres >100 caracteres Provincia Nº caracteres <= 40 caracteres (IP9) 0 caracteres >40 caracteres (IP7) (IP8) (IP10) (IP11) 79

Código Postal - Nº caracteres 5 caracteres (IP12) <5 caracteres >5 caracteres (IP13) (IP14) - Formato 5 dígitos (IP16) Alguno no dígito (IP17) Teléfono - Nº caracteres 8 <= longitud <= 9 (IP18) <8 caracteres >9 caracteres (IP19) (IP20) Formato dígitos (IP21) Alguno no dígito (IP22) Email - Nº caracteres <= 45 caracteres (IP23) 0 caracteres > 45 caracteres Formato Fecha nacimiento Dirección de correo electrónico (IP26) Otro formato (IP24) (IP25) (IP27) Formato Fecha año-mes-dia (IP28) Fecha año-mes-dia (IP29) Incluir jugador (IJ) Nif Condición Clases válidas Clases no válidas Exigencia El Nif existe en la BD (IJ1) El Nif no existe en la BD (IJ2) Exigencia Exigencia Equipo Exigencia El Nif es no es jugador de dos equipos El Nif no es jugador de un equipo de la misma categoría El equipo existe en la BD (IJ3) El Nif es jugador de dos equipos (IJ5) (IJ7) El Nif es jugador de un equipo de la misma categoría El equipo no existe en la BD (IJ4) (IJ6) (IJ8) 80

Incluir Entrenador (IE) Nif Condición Clases válidas Clases no válidas Exigencia El Nif existe en la BD (IE1) El Nif no existe en la BD (IE2) Exigencia El Nif es no es Equipo Exigencia Crear Encuesta (CE) entrenador de dos equipos El equipo existe en la BD (IE3) El Nif es entrenador de dos equipos (IE5) El equipo no existe en la BD Condición Clases válidas Clases no válidas Número de preguntas (IE4) (IE6) Formato dígitos (CE1) Alguno no dígito (CE2) Exigencia 2<= valor <=10 (CE3) No se introduce ningún valor Valor <2 Valor >10 (CE4) (CE5) (CE6) Tipo Exigencia Jugador o Entrenador (CE7) No es Jugador ni Pregunta Entrenador Nº caracteres <= 50 caracteres (CE9) 0 caracteres >500 caracteres Modificar persona (MP) Nif Condición Clases válidas Clases no válidas Nº caracteres 9 caracteres (MP1) <9 caracteres >10 caracteres (CE8) (CE10) (MP2) (MP3) Exigencia El nif no existe en la BD (MP4) El nif existe en la BD (MP5) Dirección 81

Nº caracteres <= 100 caracteres (MP6) 0 caracteres >100 caracteres Provincia Nº caracteres <= 40 caracteres (MP9) 0 caracteres >40 caracteres Código Postal - Nº caracteres 5 caracteres (MP12) <5 caracteres >5 caracteres (MP7) (MP8) (MP10) (MP11) (MP13) (MP14) - Formato 5 dígitos (MP15) Alguno no dígito (MP16) Teléfono - Nº caracteres 8 <= longitud <= 9 (MP17) <8 caracteres >9 caracteres (MP18) (MP19) Formato dígitos (MP20) Alguno no dígito (MP21) Email - Nº caracteres <= 45 caracteres (MP22) 0 caracteres > 45 caracteres Formato Fecha nacimiento Dirección de correo electrónico (MP25) Otro formato (MP23) (MP24) (MP26) Formato Fecha año-mes-dia (MP27) Fecha año-mes-dia (MP28) Incluir Noticias de Equipo (INC) Condición Clases válidas Clases no válidas Cuerpo Nº caracteres <= 200 caracteres (INC1) 0 caracteres > 200 caracteres Fecha (INC2) (INC3) Formato Fecha año-mes-dia (INC4) Fecha año-mes-dia (INC5) Equipo Exigencia El equipo existe en la BD (INC6) El equipo no existe en la BD Nº caracteres <= 500 caracteres (CE9) 0 caracteres >500 caracteres (INC7) (CE10) 82

Resultado de las pruebas unitarias. Respecto a las pruebas pondremos algunos ejemplos por motivos de claridad y espacio, siendo realizadas todas las necesarias. También somos conscientes de que la aplicación controla que los datos sean correctos, solo el administrador incluye datos y son controlados por JavaScript, los vacíos y también las longitudes y formatos especiales (Email y fecha) y el resto se seleccionan dentro de los que la aplicación proporciona. Prueba unitaria 1 Descripción Entradas Clases de equivalencia cubiertas Resultado esperado Resultado obtenido Prueba correcta Identificación correcta de usuario Usuario: unrudiez Contraseña: cala (IU1), (IU3), (IU5) Identificación satisfactoria Correcto Si- Prueba unitaria 2 Descripción nombre de usuario errónea o sin permisos Entradas Clases de equivalencia cubiertas Resultado esperado Resultado obtenido Prueba correcta Usuario: urudiez Contraseña: cala (IU2),(IU4) El usuario no tiene permisos Correcto Si- 83

7 Ciclo 3 APLICACIÓN GESTIÓN DE ENTRENAMIENTOS Esta tarea corresponde con la tercera iteración de nuestro proyecto. Al final de este ciclo dispondremos de la aplicación web que nos permitirá gestionar los entrenamientos, el Administrado (incluir, eliminar, modificar entrenamientos, validar los de los entrenadores), y el Entrenador (valorar, crear ejemplos, imprimir entrenamientos ). 7.1 Análisis: 7.1.1 Casos de uso 7.1.1.1 Identificar actores. Como se había especificado anteriormente en los objetivos del DOP, la aplicación será utilizada por dos. Ligado con la parte de la gestión de la aplicación nos encontraremos con el Administrador y el que utilizara la aplicación para hacer entrenamientos será el Entrenador. 7.1.1.2 Crear casos de uso: Una vez conocida la funcionalidad de la aplicación, los diferentes tipos de usuarios que la utilizarán y tras haber estudiado detenidamente las necesidades del club es necesario identificar y definir los casos de Uso. Mediante esta identificación se presentará una visión global de la funcionalidad del sistema que servirá de base en las fases de diseño e implementación. 84

Figura 7.1.1.2.1 Incluir ejemplo. :( Figura 7.1.1.2.1) Descripción Permitirá al entrenador incluir ejemplos en la BD. Flujo de actividad El entrenador incluye los datos del ejemplo de entrenamiento. Precondición El usuario estará registrado como entrenador. Validar ejemplo. :( Figura 7.1.1.2.1) Descripción Permitirá al administrador validar los ejemplos de la BD. Flujo de actividad El administrador valida los datos del ejemplo que ha introducido el entrenador asignándole una tabla y un tipo. Precondición El usuario estará registrado como administrador y hay ejemplos nuevos. 85

Incluir ejercicio. :( Figura 7.1.1.2.1) Descripción Permitirá al administrador borrar ejercicios de la BD. Flujo de actividad El administrador selecciona e incluye los datos del ejercicio. Precondición El usuario estará registrado como administrador. Modificar ejercicio. :( Figura 7.1.1.2.1) Descripción Permitirá al administrador modificar ejercicios de la BD. Flujo de actividad El administrador selecciona un ejercicio de la BD, para poder modificarlo. Precondición El usuario estará registrado como administrador. Borrar ejercicio. :( Figura 7.1.1.2.1) Descripción Permitirá al administrador borrar ejercicios de la BD. Flujo de actividad El administrador selecciona un ejercicio de la BD, para poder borrarlo. Precondición El usuario estará registrado como administrador. Consultar ejercicio. :( Figura 7.1.1.2.1) Descripción Permitirá al administrador o entrenador consultar los ejercicios de la BD. Flujo de actividad El usuario elige el tipo de ejercicio que quiere consultar. Precondición El usuario estará registrado como administrador o entrenador. 86

Consultar ejercicio. :( Figura 7.1.1.2.1) Descripción Permitirá al administrador o entrenador imprimir ejercicios de la BD. Flujo de actividad El usuario selecciona los ejercicios y selecciona imprimir en PDF. Precondición El usuario estará registrado como administrador o entrenador. 87

7.1.1.3 Diagramas de actividad El siguiente apartado expone los diferentes diagramas de actividad que engloban a los casos de uso (figuras 7.1.1.2.1), éstos representan los pasos a seguir a la hora de interactuar con la aplicación de gestión de entrenamientos. Un ejemplo: El entrenado incluye un ejercicio en la lista de su entrenamiento 7.1.2. Clases de análisis. En un principio se iba a separar por completa esta aplicación de la anterior (gestión de jugadores), pero después de un estudio, se considera que es mejor incluir esta aplicación dentro de la anterior ampliando la BD y utilizando el mismo sistema. 88

Clases de negocio La figura 7.1.2.2.1 representa el diagrama de clases de análisis para la capa Negocio mas los conectores de datos, que abarca las clases necesarias para la construcción de la aplicación de gestión de jugadores. Figura 7.1.2.2.2 Clases de análisis. Paquete Negocio. -Clase GestorEjercicio: Es la clase encargada de la gestión de los entrenamientos. -Clase Gestorvotación: Representa la clase encargada de la gestión de los votos de los ejercicios. -Clase GestorPáginación: Es la clase que controla como muestra los ejercicios. -Clase GestorImpresión: Es la clase encargada de tratar la gestión de asistencias de jugadores en la aplicación. 89

7.2.1 Diseño de la BD: 7.2.1.1. Diagrama: Se muestra la ampliación necesaria en la base de datos para la utilización de esta aplicación. Relación directa con entrenador, los entrenamientos y los ejercicios que incluye el entrenador. 90

7.2.1.2. Documentación de tablas: Estructura de tabla para la tabla ataque/defensa/contrataque/juegos/individual/calentamiento Representa los ejercicios de cada modelo. Campo Tipo Nulo Enlaces a id int(11) No tipo varchar(50) No titulo varchar(30) No cuerpo text No imagen text No Estructura de tabla para la tabla entrenamientos Representa los ejercicios seleccionados por cada entrenador para poder imprimirlos. Campo Tipo Nulo Enlaces a id int(11) No idtabla int(11) No tabla varchar(20) No entrenador varchar(9) No 91

Estructura de tabla para la tabla nuevo Representa los ejercicios introducidos por los entrenadores, luego deberán ser validados por el administrador. Campo Tipo Nulo Enlaces a id int(11) No entrenador varchar(9) No titulo varchar(30) No cuerpo text No fecha date No imagen int(11) No Estructura de tabla para la tabla votosentrenamientos Representa los votos que los entrenadores hacen a cada ejercicio de la BD. Campo Tipo Nulo Enlaces a id int(11) No idtabla int(11) No tabla varchar(20) No valor int(11) No 92

7.2.2. Diseño de interfaces Si el usuario está dado de alta como entrenador o como administrador, podrá acceder al penúltimo menú entrenamientos y en el podrá seleccionar sus partes. Incluir entrenamiento: Se selecciona tabla (defensa, ataque, contrataque ) y dentro de esos el tipo, se rellena el título y la explicación (obligatorios) y si se desea una imagen. Solo administrador. Incluir ejemplo: Rellena el título y la explicación (obligatorios) y si se desea una imagen. Solo entrenador. 93

Validar ejemplo: Si hay ejemplos nuevos, se le mostraran al administrador, los incluirá en la tabla del tipo que considere y podrá modificar. Se le indicara quien lo ha introducido por si necesita consultar. Si no le resulta útil también podrá borrarlo. Buscar entrenamiento: En la parte derecha se muestra los ejercicios que tiene seleccionados, y en la izquierda selecciona para que quiere el entrenamiento y el tipo. Ver entrenamiento: En esta parte el entrenador puede ver los ejercicios, votarlos y seleccionarlos para crear su entrenamiento. Si es administrador también podrá modificarlos o borrarlos. Imprimir entrenamiento: Se muestra en PDF los ejercicios elegidos por el entrenador o administrador. 94