aplicación web para la gestión de un club de balonmano

TRABAJO FIN DE ESTUDIOS

Aplicación web para la gestión de un club debalonmano

Unai Rudiez Asua

PROYECTO FIN DE CARRERA

Tutor: Juan José Olarte Larrea

Curso 2011-2012

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2012

publicaciones.unirioja.esE-mail: [email protected]

Aplicación web para la gestión de un club de balonmano, trabajo fin de estudiosde Unai Rudiez Asua, dirigido por Juan José Olarte Larrea (publicado por la Universidad

de La Rioja), se difunde bajo una LicenciaCreative 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.

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

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

2

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.

3

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

4

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

5

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.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

6

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.

7

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.

8

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.

9

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

10

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.

11

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.

12

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.

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.

13

Ciclo 3: Estudio previo. 3.

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.

14

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.2. Crear casos de uso. Generar los casos de uso.

6.1.1.3. Diagramas de actividad: Generar los diagramas de actividad.


tarea.


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.


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

15

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.

16

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.

17

Figura 2.9.1 DIAGRAMA DE DESCOPOSICIÓN DE TAREAS GENERAL

Figura 2.9.2 DIAGRAMA DE DESCOPOSICIÓN DE TAREAS SEGUNDA ITERACIÓN

18

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

19

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

20

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



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

21

Identificar propiedades y métodos principales 3

Ampliar diagrama de clases 4

Construcción 50

Crear Script BD 3

Implementar 40

Crear ayuda 6


Pruebas 6

Probar script BD 1


Aplicación Web gestión de entrenamientos (Ciclo 3) 88

Análisis 10,5

Casos de uso 6



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

22

Implementar 40

Crear ayuda 6


Pruebas 8


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

23

2.11.3. Diagrama de Gantt.

Figura 2.9.2 DIAGRAMA DE DESCOPOSICIÓN GENERAL

Figura 2.9.2 DIAGRAMA DE DESCOPOSICIÓN DE TAREAS SEGUNDA ITERACIÓN

24

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.


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.

25

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.

26

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.

27

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.

28

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.

Figura 4.3.1. Diagrama Caso de uso general

29

_ 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.

30

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.

31

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:



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.



32

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.



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.



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.

33

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.


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.


RFG10. El sistema debe permitir que un usuario registrado como Administrador pueda notificar

noticias referentes a jugadores y equipos.


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.


administrador.


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.

34

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.


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.


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.

35

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.

36

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

37

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.

38

5 Ciclo 1 WEB PÚBLICA DEL CLUB

5.1. Análisis de requisitos.


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.


_ Postcondición:

39

1.3. Consultar horarios de partidos: Representa las acciones con las que el usuario puede los

horarios de los equipos del club.


_ 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.


_ Postcondición:

40

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.

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.

Imagen 5.2.1.2

Imagen 5.2.1.1 Imagen 5.2.1.2

41

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.

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.

Imagen 5.2.1.3


42

Esta versión es definitiva (Imagen 5.2.1.6), se trabaja a partir de esta para el resto de la web.

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.

Imagen 5.2.1.6


43

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.

Donde indicamos “” 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.

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.

Imagen 5.2.1.9

<?include("superior.php"); ?>

<div id="contenido">



</div>

<?include("inferior.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" />

44

Carrusel.css indica como es carrusel de imágenes del Index.

JavaScript

Todo estos JavaScript son necesarios para el carrusel de la pantalla de inicio (index.php).

Y estos otros son los que se utilizan para las galerías de imágenes de fotografías.

<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>

<script type="text/javascript" src="js/photoslider.js"></script>

<script type="text/javascript" src="js/galeria.js"></script>

45

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


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.

46

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.

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.

Figura 6.1.1.2.1

47

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

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.

Figura 6.1.1.2.2

48

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.

49

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


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


50

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

51

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


52

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


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


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.

53

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.

54

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.

55

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

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.

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.

Figura 6.1.1.3.1

Figura 6.1.1.3.2

56

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.

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.

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.

Figura 6.1.1.3.3

Figura 6.1.1.3.4

57

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.

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.

Figura 6.1.2.2.1 Vista general de paquetes de la aplicación.

58

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.

-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

Figura 6.1.2.2.2 Clases de análisis. Paquete Negocio.

59

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.

60

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.

Figura 6.1.2.2.4 Clases de análisis. Paquete Model.

61

-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”.

62

6.2.1.1 Diagrama:

63

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

64

Asistencias

Representa las faltas de asistencia de los jugadores del club. Son introducidas por los

entrenadores.


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

PRIMARY BTREE Sí

nif 4

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:


PRIMARY BTREE Sí id 13

65

Entrenador

Representa a los usuarios con permiso de jugador en la aplicación.



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.



equipo1 varchar(20) No equipo -> nombre

equipo2 varchar(20) Sí equipo -> nombre

fechaacceso datetime Sí

Índices:



equipo1 BTREE No equipo1 4

equipo2 BTREE No equipo2 4 YES

66

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.



equipo varchar(20) No equipo -> nombre

fecha date No

cuerpo longtext No

Índices:


PRIMARY BTREE Sí

nif 2

equipo 2

fecha 2

equipo BTREE No equipo 2

67

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:



68

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:


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.


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

69

Índices:



jugador BTREE No

puntuacion 10 YES

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.


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:



jugador BTREE No

jugador 9 YES

puntuacion 18 YES

idencuesta 18

70


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.

71

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.

72

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.

73

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.

74


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

Autenticar.php: Comprobamos el login y password del usuario y el tipo de permisos que tiene.

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 ',àpellido1` =

'$apellido1',àpellido2` = '$apellido2',`direccion` = '$direccion',`cp` = '$cp',`provincia` =

'$provincia',`poblacion` = '$poblacion',`telefono` = '$telefono',èmail` =

'$email',`fechanacimiento` = '$nacimiento',`nick` = '$nick' WHERE `persona`.`nif` =

'$nif'",$_SESSION['link']);

}

75

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;

}

}

76

cerrarSesion.php: Con esta cerramos sesión y liberamos todas las variables.

Por separado tenemos:

Actualizar.php: Tiene todas las funciones necesarias para actualizar la base de datos.

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");

}

function actualizarPersona( $nif, $nombre, $apellido1, $apellido2, $direccion, $poblacion,

$cp, $provincia, $telefono, $email, $nacimiento, $nick)

{


session_start();



}

mysql_query("UPDATE `jugadores`.`persona` SET `nombre` = '$nombre ',àpellido1` =

'$apellido1',àpellido2` = '$apellido2',`direccion` = '$direccion',`cp` = '$cp',`provincia` =

'$provincia',`poblacion` = '$poblacion',`telefono` = '$telefono',èmail` =

'$email',`fechanacimiento` = '$nacimiento',`nick` = '$nick' WHERE `persona`.`nif` =

'$nif'",$_SESSION['link']);

}

77

Borrar.php: Tiene todas las funciones necesarias para borrar la base de datos.

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)

{


session_start();



}

mysql_query("INSERT INTO `jugadores`.`persona` (`nif`, `nombre`, àpellido1`, àpellido2`,

`direccion`, `poblacion`, `cp`, `provincia`, `telefono`, èmail`, `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");

}

function borrarPersona($nif)

{


session_start();



}

return (mysql_query("DELETE FROM persona WHERE nif='$nif'",$_SESSION['link'] ));

}

78

Seleccionar.php: Tiene todas las funciones necesarias para seleccionar lo base de datos

function seleccionarPersonaNif($nif)

{


session_start();



}

return (mysql_query("SELECT * FROM persona WHERE nif='$nif'",$_SESSION['link'] ));

}

79

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 El Usuario existe en la

BD

(IU1) El Usuario no existe en la BD

(IU2)

Exigencia El usuario es jugador,

entrenador y/o

administrador

(IU3) El usuario no es jugador, entrenador ni administrador

(IU4)

Password

Exigencia El password existe en la BD

(IU5) El password no existe en la BD

(IU6)

Incluir persona (IP)


Nif

Nº caracteres 9 caracteres (IP1) <9 caracteres >10 caracteres

(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

(IP7)

(IP8)

Provincia


(IP10)

(IP11)

80

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

(IP24)

(IP25)

Formato Dirección de correo electrónico

(IP26) Otro formato (IP27)

Fecha nacimiento

Formato Fecha año-mes-dia (IP28) Fecha año-mes-dia (IP29)

Incluir jugador (IJ)


Nif

Exigencia El Nif existe en la BD (IJ1) El Nif no existe en la BD (IJ2)

Exigencia El Nif es no es jugador

de dos equipos

(IJ3) El Nif es jugador de dos equipos

(IJ4)

Exigencia El Nif no es jugador de

un equipo de la misma

categoría

(IJ5) El Nif es jugador de un equipo de la misma categoría

(IJ6)

Equipo

Exigencia El equipo existe en la BD

(IJ7) El equipo no existe en la BD

(IJ8)

81

Incluir Entrenador (IE)


Nif

Exigencia El Nif existe en la BD (IE1) El Nif no existe en la BD (IE2)

Exigencia El Nif es no es

entrenador de dos

equipos

(IE3) El Nif es entrenador de dos equipos

(IE4)

Equipo


(IE5) El equipo no existe en la BD

(IE6)

Crear Encuesta (CE)


Número de preguntas

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

Entrenador

(CE8)

Pregunta

Nº caracteres <= 50 caracteres (CE9) 0 caracteres >500 caracteres

(CE10)

Modificar persona (MP)


Nif

Nº caracteres 9 caracteres (MP1) <9 caracteres >10 caracteres

(MP2)

(MP3)

Exigencia El nif no existe en la BD (MP4) El nif existe en la BD (MP5)

Dirección

82

Nº caracteres <= 100 caracteres (MP6) 0 caracteres >100 caracteres

(MP7)

(MP8)

Provincia

Nº caracteres <= 40 caracteres (MP9) 0 caracteres >40 caracteres

(MP10)

(MP11)

Código Postal

- Nº caracteres 5 caracteres (MP12) <5 caracteres >5 caracteres

(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

(MP23)

(MP24)

Formato Dirección de correo electrónico

(MP25) Otro formato (MP26)

Fecha nacimiento

Formato Fecha año-mes-dia (MP27) Fecha año-mes-dia (MP28)

Incluir Noticias de Equipo (INC)


Cuerpo

Nº caracteres <= 200 caracteres (INC1) 0 caracteres > 200 caracteres

(INC2)

(INC3)

Fecha

Formato Fecha año-mes-dia (INC4) Fecha año-mes-dia (INC5)

Equipo


(INC6) El equipo no existe en la BD

(INC7)

Nº caracteres <= 500 caracteres (CE9) 0 caracteres >500 caracteres

(CE10)

83

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 Identificación correcta de usuario

Entradas Usuario: “unrudiez”

Contraseña: “cala”

Clases de equivalencia cubiertas (IU1), (IU3), (IU5)

Resultado esperado Identificación satisfactoria

Resultado obtenido Correcto

Prueba correcta Si-

Prueba unitaria 2

Descripción nombre de usuario errónea o sin

permisos

Entradas Usuario: “ urudiez”

Contraseña: “cala”

Clases de equivalencia cubiertas (IU2) ,(IU4)

Resultado esperado El usuario no tiene permisos

Resultado obtenido Correcto

Prueba correcta Si-

84

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.

85

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.

Figura 7.1.1.2.1

86

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


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


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.

87

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.

88

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


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.

89

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.

-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.

Figura 7.1.2.2.2 Clases de análisis. Paquete Negocio.

90

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.

91

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.


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.


id int(11) No

idtabla int(11) No

tabla varchar(20) No

entrenador varchar(9) No

92

Estructura de tabla para la tabla nuevo

Representa los ejercicios introducidos por los entrenadores, luego deberán ser validados por el

administrador.


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.


id int(11) No

idtabla int(11) No

tabla varchar(20) No

valor int(11) No

93


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.

94

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.

95


7.2.3.1. Identificar clases y métodos principales:

Conector datos:

Utilizara los mismos mecanismos que el ciclo 6

Por separado tenemos

Borrar.php: Tiene todas las funciones necesarias para borrar la base de datos.

Insertar.php: Tiene todas las funciones necesarias para Insertar campos en la base de datos.

Seleccionar.php: Tiene todas las funciones necesarias para seleccionar lo base de datos.

7.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.

7.4.1 Clases de equivalencia.

Incluir entrenamiento. (IU)


Entrenamiento para

Exigencia El modelo existe en la

BD

(IE1) El modelo no existe en la

BD

(IE2)

Tipo

Exigencia El tipo existe en la BD (IE1) El tipo no existe en la BD (IE2)

Título


(IP10)

(IP11)

Explicación

- Nº caracteres <=640 caracteres (IP12) 0 caracteres > 640 caracteres

(IP13)

(IP14)

Imagen

- Nº caracteres Es jpg/png/jpeg (IP18) No es jpg/png/jpeg (IP19)

96

Incluir ejemplo (IEJ)


Título

Nº caracteres <= 50 caracteres (IEJ 1) 0 caracteres >50 caracteres

(IEJ 2)

(IEJ 3)

Explicación

- Nº caracteres <=640 caracteres (IEJ 4) 0 caracteres > 640 caracteres

(IEJ 5)

(IEJ 6)

Imagen

- Nº caracteres Es jpg/png/jpeg (IEJ 7) No es jpg/png/jpeg (IEJ 8)

Validar ejemplo (VE):


Entrenamiento para


BD

(VE1) El modelo no existe en la

BD

(VE2)

Tipo

Exigencia El tipo existe en la BD (VE3) El tipo no existe en la BD (VE4)

Título

Nº caracteres <= 50 caracteres (VE5) 0 caracteres >50 caracteres

(VE6)

(VE7)

Explicación

- Nº caracteres <=640 caracteres (VE8) 0 caracteres > 640 caracteres

(VE9)

(VE10)

Imagen

- Nº caracteres Es jpg/png/jpeg (VE11) No es jpg/png/jpeg (VE12)

97

Buscar entrenamiento (BE):


Entrenamiento para


BD

(BE1) El modelo no existe en la

BD

(BE2)

Tipo

Exigencia El tipo existe en la BD (BE3) El tipo no existe en la BD (BE4)

Título

Nº caracteres <= 50 caracteres (BE5) 0 caracteres >50 caracteres

(BE6)

(BE7)

Explicación

- Nº caracteres <=640 caracteres (BE8) 0 caracteres > 640 caracteres

(BE9)

(BE10)

Imagen

- Nº caracteres Es jpg/png/jpeg (BE11) No es jpg/png/jpeg (BE12)

Resultado de las pruebas unitarias.

Respecto a las pruebas, como en la anterior aplicación, serán realizadas todas las necesarias.

También la aplicación controla que los datos sean correctos y las longitudes y formatos

especiales, solo el administrador incluye datos finales.

98

8. Conclusiones

Tras finalizar este proyecto, las conclusiones y opiniones obtenidas son varias, así como la

consecución de los objetivos tanto del proyecto como propios.

A continuación se procede a detallar y evaluar el grado de cumplimiento de dichos objetivos y a

dar una opinión sobre la experiencia general que ha supuesto realizar el proyecto de fin de

carrera.

8.1. Evaluación de objetivos

Al comenzar el PFC, uno de mis objetivos básicos era el de realizarlo mientras estaba en

prácticas, lo que por motivos personales no pude. Cuando terminé las prácticas, en abril de 2011,

mi intención era ponerme íntegramente con el proyecto, pero tuve la suerte de tener un trabajo

para dos meses. Hubo varias prorrogas de contrato hasta cumplir un año. Después de la reunión

para el Grado en Ingeniería Informática, decidí retomar el proyecto y abandonar el trabajo.

Los objetivos para Club Calasancio eran los de crear una nueva zona Web donde gestionar los

miembros del club y ayudar con la tareas de preparar entrenamientos. También ayudar a estar

más cercanos a los padres de los jugadores

Con la aplicación ya en la mano y tras haber pasado numerosas pruebas, se puede afirmar que

cumple los requisitos. Y la intención es seguir trabajando con la aplicación para seguir mejorando

la estética y sobre todo los servicios que se les ofrece a las persona del club

8.2. Opinión personal

En el punto actual, daremos una opinión personal sobre el proceso de desarrollo del proyecto de

fin de carrera.

8.2.1. Desarrollo del proyecto

Del proceso de desarrollo del proyecto, la labor más dura ha sido la creación de la memoria. La

mayor dificultad ha sido el saber cuál es el siguiente paso. No obstante, hay muchas partes de

este documento, que pueden ayudar a realizar más rápido, más ordenado y mejor, pero sobre

todo a grupos de personas más numerosos.

99

8.2.2. Plazos

En lo referente al tema de plazos de ejecución y entrega, podemos afirmar que inicialmente

fuimos demasiado optimistas. Según la planificación inicial hecha, debería de haber acabado a

finales de mayo del curso pasado.

Este retraso fue debido básicamente a un trabajo no esperado que me ocupó la totalidad de las

horas que se iban a dedicar al proyecto.

Me ha ayudado el haber tenido muy bien pensado lo que se quería conseguir, ya que aunque no

estaba trabajando en el PFC, siempre estaba en mente de la gente del club y seguíamos

comentándolo.

En el momento que decidí intentar matricularme en el grado, terminé el trabajo y me puse de

lleno con el proyecto.

8.2.3. Tecnología

Respecto a la tecnología con la que hemos desarrollado el proyecto, me decidí por utilizar PHP,

con el que ya estaba familiarizado, aunque hacía ya bastante tiempo que no utilizaba.

He incluido AJAX y JavaScript y parte de futuras mejoras serán utilizar más estas tecnologías,

porque ayudan a que, la misma aplicación, sea más cómoda para el usuario.

En esta parte estoy satisfecho, porque viendo que tenía tiempo suficiente cuando he terminado

el 3 ciclo, he añadido algunas mejoras de este tipo.

8.2.4. Estudio de mejoras, rendimiento, etc.

Es cierto que muchas cosas serán mejorables, quizás, en un proyecto igual pero comercial, al

dedicar más tiempo al diseño y a la codificación, podrían haberse mejorado ciertos aspectos.

Además el grado de experiencia también me parece determinante, y estoy convencido de que

todavía me queda mucho por aprender y un largo camino por recorrer hasta el dominio. Otros

temas que han quedado pendientes como el estudio de los Patrones de diseño, el uso de otras

soluciones y tecnologías, seguramente me hubieran ayudado mucho a la hora de desarrollar el

proyecto.

100

ACTAS DE REUNIÓN

Actas de reunión

Lugar: Polideportivo Escolapios.

Fecha 03/09/10

Hora: 20:00-20:30

Desarrollo

El alumno presento las propuestas y diferentes ideas surgidas con comentarios con compañeros.

Resumen de conclusiones

Se establece proponer el proyecto en la Universidad y comunicarlo cuando se tengan noticias.

Asistentes

Unai Rudiez Asua

José Luis Goñi Sáez

Asunto

Mostrar la idea de crear una aplicación Web para el club

Orden del día

101

Actas de reunión


Fecha 16/08/11

Hora: 20:00-20:30

Desarrollo


Se establece seguir trabajando y mostrarle los progresos por Email. Roberto también mandará el resto de

bocetos o cambios por Email.

Asistentes

Unai Rudiez Asua

Roberto Del Val

Asunto

Mostrar Primeras versiones de web pública

Orden del día

Mostrarle mi idea según lo que nos hemos comunicado por correo

Entregarme los bocetos

102

Actas de reunión


Fecha 16/04/12

Hora: 20:00-20:30

Desarrollo


Se establecen algunas modificaciones (encuestas) y algún método más de búsquedas de

jugadores, se sugiere categoría.

Asistentes

Unai Rudiez Asua

Jose Luis Goñi

Roberto Del Val

Asunto

Mostrar base de datos y parte del programa

Orden del día

103

Actas de reunión


Fecha 15/05/12

Hora: 20:00-20:30

Desarrollo


Se establecen algunas modificaciones y añadir valoraciones y búsquedas de los entrenamientos.

También se necesita que los entrenadores puedan incluir entrenamientos

Asistentes

Unai Rudiez Asua

Jose Luis Goñi

Roberto Del Val

Asunto

Mostrar Ciclo 3

Orden del día

104

Actas de reunión

Lugar: Despacho 224. Edificio Vives.

Fecha 02/11/10

Hora: 18:00-19:00

Desarrollo

El alumno envió el documento de petición de proyecto para su aprobación. Se acuerdan preparar

un titulo y revisar proyectos y comenzar con la documentación


Se establece enviar lo antes posible un titulo, y comenzar con resumen y DOP.

Asistentes

Unai Rudiez Asua

Juan José Olarte Larrea

Asunto

Reunión con motivo del proyecto fin de carrera.

Explicación del funcionamiento general de un proyecto fin de carrera

Orden del día

105

Actas de reunión

Lugar: Despacho 224. Edificio Vives.

Fecha 16/04/12

Hora: 18:00-19:00

Desarrollo

El alumno envió la memoria realizada hasta el punto 4.


Se establece enviar todos los cambios según se vayan realizando para no agrupar demasiadas

tareas.

Asistentes

Unai Rudiez Asua

Juan José Olarte Larrea

Asunto

Reunión con motivo de la continuación del proyecto fin de carrera.

Explicación razones por la que retoma en estos momentos.

Solución de dudas y corrección de posibles fallos de la memoria.

Orden del día

aplicación web para la gestión de un club de balonmano

Documents