Prototipo de Aplicación Web para la Gestión de una ...

Escu

ela

Po

lité

cn

ica S

up

erio

r de

Ja

én

UNIVERSIDAD DE JAÉN Escuela Politécnica Superior de Jaén

Trabajo Fin de Grado

Alumno: Juan Francisco Abán Fontecha Tutor: D. Ángel Luis García Fernández Dpto.: Departamento de Informática

Junio, 2019

Prototipo de AplicaciónWeb para la Gestión de una Competición de Judo

Universidad de Jaén

Escuela Politécnica Superior de Jaén

Departamento de Informática

Don Ángel Luis García Fernández , tutor del Trabajo Fin de Grado titulado:

PROTOTIPO DE APLICACIÓN WEB PARA LA GESTIÓN DE UNA COMPETICIÓN

DE JUDO, que presenta Juan Francisco Abán Fontecha, autoriza su presentación

para defensa y evaluación en la Escuela Politécnica Superior de Jaén.

Jaén, Junio de 2019

El alumno: El tutor:

Juan Francisco Abán Fontecha Ángel Luis García Fernández

JUAN FRANCISCO ABÁN FONTECHA

2 Escuela Politécnica Superior de Jaén

AGRADECIMIENTOS

Mi visión del trabajo realizado es bastante optimista de cara al fin de una etapa

como son los cuatro años en la Universidad de Jaén formándome de cara a un

futuro-actual trabajo, donde se me ha permitido combinar mis esfuerzos personales

junto con los de grandes profesionales para alcanzar una meta fijada, que era

conseguir sacar este grado de ingeniería.

Respecto al esfuerzo último en este trabajo realizado salgo con más fuerza,

debido a que a pesar de tener tardes de no avanzar nada con el proyecto por un

bloqueo mental o a no entender de manera clara qué necesitaba nuestro cliente,

conseguí crear esta aplicación, que, a pesar de no ser una aplicación estrella que

me vaya a hacer ganar dinero, yo, al verla creada, la recibo como premio a todo un

tiempo de sudor y lágrimas empleados en un camino junto a muchas personas con

las que he podido convivir y de las cuales he podido y aún espero aprender mucho

más, ya sea en Jaén, Andalucía, España o cualquier parte del mundo.

Para terminar este trabajo, no podría hacerlo sin valorar el esfuerzo de las

personas que me han ayudado a guiar y a llevar por buen camino este trabajo.

Empezando por mi tutor de este trabajo, Ángel Luis García Fernández, considerado

por muchos uno de los mejores profesores del Grado de Ingeniería Informática.

Siguiendo con mi familia (Madre, Hermanas, Paco) por su apoyo y sus ayudas en

cuanto al diseño inicial nada claro y muy confuso. Mi cuñado Ángel como Judoka de

gran nivel y guía en términos como wazari, y kata-guruma, del cual es un gran

realizador. Y, cómo no, finalizando con mi compañera, novia, amante y amiga que

tantas tardes cuando estaba agobiado me animaba a continuar para terminar con la

aplicación.

A todas y cada una de las personas que han seguido mi camino, me han

acompañado y han visto crecer a esta criatura llamada TFG, y como valedora de un

esfuerzo de años para conseguir terminar parte de mi etapa como universitario y

entrar al mercado laboral, sabiendo que puedo dar día a día el 200% de mí para

conseguir todo aquello que me proponga.

Simplemente quiero decir: ¡Gracias!.



Índice 1. Introducción. ....................................................................................................................5

1.1. Competiciones de Judo. ...........................................................................................5

1.2. Aplicaciones existentes. ...........................................................................................7

1.3. Objetivo del TFG ......................................................................................................9

1.4. Lógica de Negocio. ...................................................................................................9

2. Análisis. .........................................................................................................................12

2.1. Escenarios .............................................................................................................12

2.2. Requisitos ..............................................................................................................15

2.2.1. Requisitos Funcionales ..........................................................................................15

2.2.2. Requisitos No Funcionales .....................................................................................17

2.3. Casos de uso .........................................................................................................18

2.3.1. Diagramas de Secuencia .......................................................................................19

2.4. Planificación ...........................................................................................................33

2.4.1. Planificación y estructuración del equipo ................................................................33

2.4.2. Estimación de tareas. .............................................................................................34

2.4.3. Planificación y estructuración del material ..............................................................36

2.4.4. Reparto de tareas y recursos en el tiempo .............................................................37

2.4.5. Estimación de costos (Presupuesto) ......................................................................39

3. Diseño ...........................................................................................................................41

3.1. Arquitectura ............................................................................................................41

3.2. Diagrama de clases ................................................................................................42

3.3. Modelo Entidad Relación........................................................................................45

3.4. Interfaz ...................................................................................................................47

4. Implementación .............................................................................................................54

4.1. Framework de desarrollo web ................................................................................54

4.2. Tecnología de Base de datos .................................................................................55

4.3. Otras Tecnologías ..................................................................................................56

4.4. Cambios en el diseño durante la implementación...................................................57

5. Pruebas .........................................................................................................................58

5.1. Experiencia con cliente...........................................................................................59

6. Resultados ....................................................................................................................59

7. Conclusiones .................................................................................................................62

8. Bibliografía ....................................................................................................................63

8.1. Bibliografía Complementaria ..................................................................................63

ANEXO I. Manual de usuario. ...............................................................................................64



1. Introducción.

El Judo (Fig. 1) es un arte marcial y deporte de combate de origen japonés,

este término en japonés puede traducirse como «Camino hacia la flexibilidad», o

«Camino de la gentileza, cortesía», influyendo el desarrollo mental y emocional a

través de la práctica. Los practicantes de este arte marcial son denominados

judokas.

Fig. 1: Palabra Judo en japonés.

El Judo es uno de los cuatro estilos principales de lucha deportiva más

practicados hoy en día en todo el mundo. A partir del Judo kodokan se han derivado

las actuales formas de jiujitsu europeo, jiujitsu americano, jiujitsu brasileño, sambo

ruso, nihon tai jutsu y krav magá. Esto se debe principalmente a que judokas

formados en Japón y sus discípulos a lo largo del mundo se han encargado del

desarrollo de estas otras formas. Dado esto y su popularidad lo ha llevado a la

celebración de combates y cómo no campeonatos alrededor de todo el mundo, y con

diferentes categorías, divididos por sexo y pesos.

1.1. Competiciones de Judo.

Las competiciones del IJF World Judo Tour (WJT) normalmente consisten en

dos sesiones, las preliminares y el bloque final. Las fases de competencia que tienen

lugar en las sesiones dependen del tipo de evento. Cualquier cambio a esto será

acordado y aprobado por el IJF Head Sport Director. Dependiendo del número de

participantes, algunas rondas pueden no ser requeridas para cada categoría.

Solo hay un sistema de competición y uniforme para todos los eventos IJF

WJT, un sistema de eliminación con repesca que comienza en cuartos de final (los

últimos ocho participantes). Para otros eventos, se pueden usar diferentes tipos de

sistemas, como doble repesca, repesca completa o eliminación directa.



Para cada categoría, los atletas se dividirán en dos tablas por medio de un

"sorteo", y se utilizará un sistema de eliminación para producir dos finalistas que

competirán por la medalla de oro.

Los atletas derrotados en los cuartos de final competirán en dos formas

diferentes de repesca:

• Los ganadores de cada uno de estos dos concursos de repesca competirán

por la medalla de bronce contra el perdedor del combate de semifinales de la mesa

opuesta respectiva.

• Los ganadores (2) de esos combates se colocan en tercer lugar.

• Los perdedores (2) se colocan en quinto lugar.

• Los perdedores (2) de los concursos de repesca se colocan en séptimo lugar.

En la hoja de sorteo (Fig. 2), el atleta en la parte superior usa un judogi blanco

y el que está abajo usa un judogi azul. Se otorgarán medallas de oro, plata y dos (2)

medallas de bronce.

Fig. 2: Ejemplo de hoja de sorteo de competición de Judo.

Como podemos observar la mecánica de las competiciones es bastante

problemática, ya que hay diferentes tipos de competición y unos sistemas de

repesca bastante complicados.



No solo nos fijamos en eso, sino en la capacidad del público de seguir los

combates, dado que se realizan en un recinto como es el polideportivo de la

Salobreja, y suele haber unos 6 Tatamis o incluso 9, dependiendo del número de

participantes y del tipo de competición. Por lo que los asistentes a dicha competición

sólo pueden observar las técnicas que los competidores hacen pero no entender

quién va ganando en que momento determinado.

Con este proyecto se pretende construir una aplicación web que facilite la labor

de la persona encargada de la organización de este tipo de eventos, ya que esta

tarea es laboriosa debido a los problemas que hemos comentado en los párrafos

anteriores.

1.2. Aplicaciones existentes.

Hoy día, gracias al aporte de nuestro cliente y competidores de esta disciplina,

hemos podido descubrir diferentes aplicaciones que se usan a día de hoy para

realizar la labor de organización y reparto de los combates de dichas competiciones,

son las siguientes:

Aplicación propia implementada en una hoja de Excel: Hasta

ahora la organización de las competiciones y eventos se está

realizando con una aplicación implementada en una hoja de cálculo

especialmente para esta labor, ésta es muy exhaustiva y alberga la

infinidad de posibilidades de reparto que incluye la lógica de este tipo

de competiciones, pero dada la cantidad de datos que llegan a

manejar esto hace muy complicado su uso.

Todo esto ocasiona una labor casi perturbadora para nuestro cliente,

ya que no tiene memoria, el reparto de combates no siempre es

equitativo y de acuerdo a las normas. Por ejemplo, en cada

competición a pesar de que los participantes sean los mismos, los

datos deben ser insertados de nuevo, e incluso debe realizarse un par

de veces el sorteo para que no coincidan cabezas de serie, al no

haber introducido los datos de manera correcta.



Para las competiciones infantiles, existe una problemática mayor al

existir habitualmente alrededor de 600 participantes, por ello, en la

hoja de cálculo es muy tedioso insertar dicha cantidad de datos, no

solo ello sino que además suelen tener problemas al tocar miembros

del mismo club en los diferentes tatamis.

Por otra parte, nos encontramos que este sistema no soluciona la

problemática del seguimiento del torneo, ya que no disponemos de un

mecanismo que permita visualizar la puntuación de cada tatami, es

decir, para la organización interna sí que vale, pero los árbitros o

jueces de cada tatami no tienen la oportunidad de poder incluir los

resultados que se van dando en este programa de inmediato, sino

que deben esperar a finalizar todos los combates para ello.

Ippon.org draw Judo Tournament Software (IJF ScoreBoard):

[IJFHB]Utilizada por la IJF (International Judo Federation, Fig. 3), para

mostrar resultados y organizar las competiciones. Aplicación muy

completa que nos ayuda a la organización de dichos eventos. Su

principal problemática reside en que no dispone de otros idiomas que

no sean el inglés.

Otras problemáticas que hemos detectado con el uso y con la

información dada por parte del cliente es que toda la interacción se

realiza con el teclado; por medio de teclas vamos introduciendo la

puntuación de cada participante. Y una vez configurado el combate es

muy difícil salir de la puntuación a pesar de haber finalizado el

combate.

Esta dificultad en la utilización puede causar un trastorno para la

organización de la competición. Además de no tener compatibilidad

con Windows 10, lo que puede suponer una alteración si se utilizan

sistemas actuales.



Esta aplicación destaca por tener un manual de instrucciones en el

cual viene todo detallado, y que no se hace tedioso mientras nos

enseña las claves para su uso.

1.3. Objetivo del TFG

El TFG denominado “Prototipo de aplicación web para la

organización de una competición de Judo” tiene como objetivo

principal crear un prototipo que ayude a la organización de campeonatos

de judo de cualquier nivel. Esto implica:

o Automatizar competiciones, reparto automático de combates

basado en la lógica de negocio descrita en el apartado 1.4.

o Facilitar el seguimiento de los resultados al público asistente

a las competiciones.

o Crear estadísticas para cada competición, incluyendo

diferencias entre las competiciones realizadas.

Tras hablar con el cliente y tomar este proyecto desde un ámbito

provincial se piensa, si ésta da buen resultado a este nivel, su aplicación

a competiciones en ámbito regional, permitiéndonos así cruzar datos

entre federaciones, haciendo más sencillo el manejo de éstos para evitar

duplicidades.

1.4. Lógica de Negocio.

Ya hemos explicado cómo funcionan las competiciones de Judo a nivel

internacional de una manera genérica, así como algunas soluciones como la usada

actualmente en un documento excel, e incluso los objetivos que nos planteamos en

este proyecto para albergarlos dentro de nuestro prototipo, con la ayuda del cliente.

En este apartado pretendemos explicar cómo vamos a tomar el funcionamiento

de aspectos clave en la competición, para que a la hora de usar nuestro prototipo se

conozca en qué torneos se puede utilizar y en cuáles no.



Toda esta información está basada en cómo se realizan las competiciones a

nivel provincial en Jaén. Esto nos ayudará un poco más a entender nuestro

prototipo.

El desarrollo de las competiciones depende del número de participantes en

cada categoría, e incluso puede ser necesario crear una categoría intermedia que

nos ayude en el reparto de combates si no disponemos de suficientes participantes

en una categoría o si hubiese demasiados.

Las categorías oficiales según la Federación Española de Judo son las que

podemos ver a continuación en la figura 3.

MASCULINO FEMENINO

Superligero: - 60 Kgrs. - 48 Kgrs.

Semiligero: - 66 Kgrs. - 52 Kgrs.

Ligero: - 73 Kgrs. - 57 Kgrs.

Semimedio: - 81 Kgrs. - 63 Kgrs.

Medio: - 90 Kgrs. - 70 Kgrs.

Semipesado: - 100 Kgrs. - 78 Kgrs.

Pesado: + 100 Kgrs. + 78 Kgrs.

Fig.3: Tabla de pesaje oficial de la Federación Española de Judo.

Una vez tenemos los datos de las personas participantes en la competición

podremos hacer el reparto. En éste debemos tener en cuenta:

Los cabezas de serie deben estar en diferentes grupos si usamos el

formato de liga, pero incluso si son eliminatorias debemos favorecer

que haya mejores combates en las últimas fases.

No cruzar, salvo excepciones, a participantes del mismo club o la

misma región, dependiendo del tipo de competición.

Respetar el orden en el que pasan a las siguientes fases.

Hay distintos tipos de competición, liguillas, de 3 a 8 participantes, y

clasificatorias, de 9 en adelante, respetando siempre los cabezas de serie. Es



decir, los marcados como cabezas de serie deben ser repartidos en grupos o en

clasificatorias diferentes para favorecer su pase a fases posteriores.

En ambos tipos existen repescas, para dar oportunidades a todos los

participantes a optar a medallas o a una mejor clasificación en la competición. Hay

dos tipos de repescas:

a. Repesca doble: Las personas que han perdido contra los semifinalistas

se enfrentarán al resto de rivales para optar a llevarse un bronce.

b. Repesca de cuartos de final: Las personas que han perdido contra los

semifinalistas, con el matiz de haber llegado al menos hasta cuartos de

final, se enfrentarán al resto de rivales para optar a llevarse un bronce.

Hemos seleccionado para este tipo de proyecto un modelo de desarrollo

clásico en cascada (Figura 4), éste se basa en diferentes fases o niveles que nos

permiten ir desarrollando poco a poco el producto software. El primer nivel o fase es

el análisis del proyecto, que nos permitirá conocer las necesidades básicas de

nuestro cliente.

Fig.4: Esquema de un modelo de desarrollo basado en cascada.



2. Análisis.

En este apartado vamos a realizar el análisis del proyecto, que nos ayude a

entender de una manera mucho mejor cómo es el prototipo y las necesidades de

este prototipo apoyándonos en nuestro cliente.

2.1. Escenarios

Vamos a utilizar el método de los escenarios, ya que tenemos un cliente que

nos puede corroborar si realmente esta forma de actuar es acertada de acuerdo a su

pensamiento y a su facilidad de uso. Tras reunirnos varias veces con el cliente

hemos llegado a redactar los siguientes escenarios (1 principal y 2 alternativos).

ESCENARIO PRINCIPAL:

A Diego le envían los participantes en el próximo campeonato de Judo, en un

fichero con el formato siguiente: nombre, apellidos, peso, cinturón, centro o

gimnasio. Tras tener dicho fichero, él abre la aplicación web e ingresa su usuario y

contraseña como gestor de competiciones, se va a su perfil y aparecen dos

opciones:

1. Consultar las competiciones creadas.

2. Crear nueva competición: esta opción después nos ofrece las siguientes

operaciones:

a) Para mayores de edad: Nos pedirá introducir nombre de la competición y

categorías o pesos presentes, los datos de los participantes a través de un fichero,

lo seleccionamos donde se encuentra almacenado y nos dará a elegir el tipo de

competición que queremos celebrar, y de manera automática obtenemos el reparto

de los combates.

Una vez tengamos los combates la aplicación ofrecerá la opción de

modificarlos con el botón de editar.



b) Para menores de edad: Este tipo de competiciones siempre se debe de

crear antes del campeonato y con tiempo suficiente, para permitir a los profesores

registrar a los participantes.

Introducimos el nombre de la competición y las categorías o pesos presentes,

modificable posteriormente.

** ESCENARIO ALTERNATIVO PROFESOR OTRO CENTRO.

Un profesor del centro deportivo Vandelvira ya conoce los alumnos de su

centro que van a participar en el campeonato que se celebrará la próxima semana.

Entra en nuestra aplicación web e introduce su usuario y contraseña, y aparecen dos

opciones:

1. Consultar las competiciones pasadas: donde podrá ver los resultados

obtenidos por sus alumnos y por otros en competiciones ya celebradas.

2. Añadir alumnos a una competición: Esta opción es la que nos permitirá

introducir los datos de los alumnos que vayan a participar en la próxima competición.

Los datos necesarios por alumno son: nombre, apellidos, DNI, fecha de nacimiento,

domicilio, localidad, provincia, código postal, teléfonos y correo electrónico. Si es la

primera vez que introduce a un alumno concreto, incluso podrá incluir fotografía,

fotocopia del DNI y del libro de familia, además del número de licencia del año

anterior. También dispondrá en esta opción de un listado de alumnos que

participaron en competiciones anteriores, facilitando así la introducción de datos, en

la parte superior deberá seleccionar la competición, que fue creada por el gestor de

competiciones.

Tras seleccionar datos de los alumnos o introducir datos nuevos, pulsará

aceptar y estos alumnos quedarán registrados de manera automática en la

competición.

** FIN ESCENARIO ALTERNATIVO PROFESOR OTRO CENTRO.

Una vez que se han registrado los participantes en cuestión, volvemos a abrir

la aplicación web con nuestro usuario y contraseña como gestor de competiciones e



irnos a “Ver competiciones”, seleccionamos la competición en concreto de menores.

Se nos abrirá una pequeña ficha con sus datos, desde los participantes hasta el

nombre, pesos, etc.

Ahora tendremos que dar a seleccionar tipo de competición, nos dará a elegir

peso a peso, diciéndonos el número de participantes de cada una y sus categorías

(Cinturones), nos dará la opción de:

i. Liguillas: que podrán ser desde 3 a 8 participantes.

ii. Clasificatorias.

Elegimos el tipo de competición más adecuado para nuestro campeonato y

nos ofrecerá el reparto de los combates.

c) Introducir Resultados: Una vez esté creada la competición accederá a los

resultados ya sea el gestor de la competición o cualquier usuario con derechos de

árbitro lo que permitirá entrar en la competición existente y cambiar la puntuación de

cada combate.

d) Seguir Resultados: Cualquier usuario desde la página principal podrá entrar

en cada competición y ver a tiempo real cómo van los diferentes combates.

ESCENARIO ALTERNATIVO PROFESOR OTRO CENTRO:

José, profesor del centro deportivo Vandelvira, ya conoce los alumnos de su

centro que van a participar en el campeonato que se celebrará la próxima semana,

él entra en la aplicación web, introduce su usuario y contraseña, y le mostrará dos

opciones:

1. Observar competiciones pasadas: donde él podrá ver los resultados

obtenidos por sus alumnos y por otros en otras competiciones ya celebradas.

2. Añadir alumnos a competición: Esta opción es la que nos permitirá

introducir los datos de los alumnos que vayan a participar en la próxima competición,

él dispondrá en esta opción de un listado de alumnos que participaron en



competiciones anteriores, facilitando la introducción de datos, en la parte superior

deberá seleccionar la competición, que fue creada por el gestor de competiciones.

Tras seleccionar datos de los alumnos o introducir datos nuevos, pulsará

aceptar y estos alumnos quedarán registrados de manera automática en la

competición.

ESCENARIO ALTERNATIVO USUARIO Y CONTRASEÑA INCORRECTA:

Marta, profesora del centro deportivo San José de Calasanz, introduce de

manera incorrecta el usuario y/o la contraseña. El sistema permite hasta 3 intentos

erróneos, al cuarto intento con el mismo usuario, de manera automática nos envía a

una página para recuperar la contraseña donde tendrá que poner su usuario o su

correo electrónico y se le enviará un código y un enlace para poder renovar su

contraseña.

2.2. Requisitos

En nuestra aplicación lo primero que nos damos cuenta es que se distinguen

varios roles claros; la persona encargada de la Organización de la Competición, los

Profesores o Entrenadores de las personas participantes en el evento, que son

también encargadas de apuntarlos, y los espectadores de dicha competición,

además del sistema.

Para cada rol disponemos de requisitos funcionales y no funcionales, gracias a

la técnica de los escenarios podemos extraerlos y los describimos en los siguientes

apartados.

2.2.1. Requisitos Funcionales

El público:

RF1: Necesita poder entrar a la aplicación para ver los resultados de los

combates y seguir la competición.



RF2: Necesita entrar a la aplicación y ver el historial de competiciones

además de una clasificación de resultados por equipos.

RF3: Durante la competición podrá dejar sus comentarios sobre los

combates.

Entrenador/a:

RF4: Necesita registrarse en la aplicación para utilizarla con este rol.

RF5: Necesita iniciar sesión para modificar datos personales.

RF6: Necesita subir información sobre participantes de los que se

encarga para agregarlos a una competición, creada en la aplicación

previamente.

Persona Organizadora de competiciones:

RF7: Necesita crear eventos en la aplicación para que el resto de

usuarios puedan acceder a ellos.

RF8: Necesita configurar los eventos para poder adaptarlos a las

necesidades.

RF9: Podrá subir un fichero CSV con información de participantes para

añadirlo a una competición.

RF10: Podrá exportar datos a ficheros PDF con las estadísticas y

resultados de las competiciones para enviárselo posteriormente a quien

corresponda, almacenarlos, etcétera.

Como podemos ver entre público, entrenadores y organizadores hay una

relación directa, que hace que el organizador pueda ser entrenador y a su vez pueda

ser público, es decir los requisitos son incrementales.

Sistema:



RF11: Dispondrá de un módulo de inicio de sesión para que los

diferentes usuarios puedan acceder a funciones especiales.

RF12: Mostrará resultados de una competición al hacer clic sobre ella en

la pantalla principal.

RF13: Será capaz, con los datos de las personas participantes y el tipo

de competición, de ofrecer el reparto de combates de manera

automática para la celebración de la misma.

RF14: Generará estadísticas de cada competidor/a para permitir evaluar

su rendimiento.

2.2.2. Requisitos No Funcionales

Dado que se trata de requisitos relacionados con el rendimiento, no es

necesario dividirlos por roles, hablaremos directamente del sistema:

a. RNF1: El sistema debe ser accesible para personas con problemas de

visión, desde simple daltonismo a pérdida total, incluyendo atributos para

ser leídos por lectores de pantalla y configuración de alto contraste.

b. RNF2: El sistema debe permitir iniciar sesión con respuesta inferior a 30

segundos.

c. RNF3: El sistema bloqueará temporalmente una cuenta si equivoca el inicio

de sesión 3 veces durante un minuto, y lo hará de manera definitiva tras 12

intentos fallidos, es decir 3 bloqueos temporales.

d. RNF4: El sistema debe ser accesible desde cualquier tipo de dispositivo,

desde un smartphone a un PC de sobremesa.

e. RNF5: El sistema debe ser capaz de operar adecuadamente con unas 300

personas conectadas de manera concurrente.

f. RNF6: Todas las comunicaciones externas entre servidores de datos,

aplicación y cliente del sistema deben estar cifradas.

g. RNF7: El tiempo de aprendizaje del sistema por un usuario deberá ser

inferior a 2 horas.

h. RNF8: El sistema debe contar con manuales de usuario estructurados

adecuadamente.



i. RNF9: El sistema debe proporcionar mensajes de error que sean

informativos y orientados a usuario final.

j. RNF10: El sistema debe poseer interfaces gráficas bien formadas.

2.3. Casos de uso

Los casos de uso son una forma de representar los pasos o actividades que se

realizan para llevar a cabo un proceso. En nuestro caso particular los pasos

necesarios para la organización de la competición de Judo.

Al extraer los requisitos hemos podido ver que tenemos 3 actores que actúan

sobre el sistema:

Personas Organizadoras: Gestionar Competición (Crear, Borrar, Actualizar e

Insertar Participantes).

Personas Entrenadoras: Insertar datos de participantes en competición.

Público: Ver competición, Comentar competición.

Insertar Participantes es una extensión de la gestión de la competición, y tanto

Organizadores como Entrenadores deben autentificarse para realizar dichas

acciones. Como podemos ver en la Figura 4 representamos el esquema a seguir.

Fig.4: Esquema de Caso de Uso de nuestra aplicación.



Existen dos actores o figuras principales que van a usar nuestro sistema,

Usuarios/as y Público. El usuario puede ser Organizador, Entrenador y Árbitro a su

vez, esta figura posee su propio usuario y contraseña que le permitirá presentarse

ante el sistema con su propio rol. En el caso del Organizador, le permitirá gestionar

las competiciones, en el caso del Entrenador tan solo Insertar los participantes a una

competición y si desempeña el rol de Árbitro podrá actualizar la puntuación de los

combates para dar a tiempo real la visión de ésta.

Como Público definimos a cualquier persona que ingrese en nuestro sistema ya

sea para ver las competiciones o para comentarlas, siendo dichas competiciones a

tiempo real o una vez que ya hayan pasado.

2.3.1. Diagramas de Secuencia

Necesitamos conocer la funcionalidad de nuestros casos de uso. Para ello

vamos a desarrollar los diagramas de secuencia de cada uno de ellos para entender

mejor esto, lo haremos de una manera ordenada por su importancia dentro de la

aplicación. Dado que el proceso de Autentificación, es clave en nuestra aplicación

será el primero en desarrollarse (Fig. 5).

Fig.5: Diagrama de Secuencia del caso de uso Autentificación.



Autentificación

Objetivo Diferenciar tipo de usuario que accede a la aplicación

Requisitos

Asociados

RF11, RNF2 y RNF3

Descripción En este diagrama podemos observar cómo existe una

comunicación directa entre el sistema, el usuario real y el resto de

clases como usuario, organizador y entrenador. En estas clases

verifica mediante comprobación de usuario y contraseña, por el

método Autentificación, que realmente es quien dice ser y ver

qué rol (Organizador, Entrenador o Árbitro) desempeña dentro de

nuestra aplicación, ya que depende de ello para ver qué tareas

poder realizar y cuáles no.

Precondición Acceso a nuestra aplicación normalmente a través de internet

Secuencia

normal

Paso Acción

1 Para comenzar tenemos entramos en un bucle donde

insertamos un usuario y una contraseña en el modulo

de autenticación.

2 Usuario y contraseña son comprobados por el sistema

3 Si la autentificación es correcta nos devuelve el rol que

desempeña dentro de nuestro sistema para permitir

unas u otras acciones y obtiene los permisos.

Postcondición Se anota en una tabla de auditoria el acceso de este usuario

Excepciones Paso Acción

2 Si no esta registrado en el sistema o se ha equivocado

al introducir las claves nos devuelve “Autentificación

incorrecta”.

Si hay 3 o más intentos incorrectos el usuario queda

bloqueado a espera de unos 20 minutos.

Fig.6: Tabla descriptiva de la acción Autentificación.



Tras poder acceder al sistema y determinar que su rol es Organizador vemos

que debe gestionar las competiciones, es decir, su funcionalidad la podemos dividir

en Crear, Borrar y Actualizar las competiciones, por ello vamos a crear un

diagrama por cada una de ellas evitando así que tengamos un diagrama demasiado

extenso.

Fig.7: Diagrama de Secuencia de una parte del caso de uso Gestionar competiciones (Crear Competición).



Crear competición

Objetivo Poder registrar un nuevo campeonato en la aplicación

Requisitos

Asociados

RF1 y RF7.

Descripción Esta acción solo es posible realizarla si somos administradores

del sistema, una vez que hemos accedido y que el tipo de usuario

es correcto nos permite introducir toda la información de la

competición a traves de un formulario.

Precondición Autentificarse en el sistema con rol Organizador

Secuencia

normal

Paso Acción

1 Autentificación del usuario y comprobación del tipo de

usuario.

2 Introducir todos los datos de la competición en el

formulario y pulsar el botón.

3 El sistema nos muestra un mensaje de creación

correcta de la competición

Postcondición Se anota en una tabla de auditoria el acceso de este usuario


1 Usuario no desempeña el rol de “Administrador” el

sistema nos mostrará un mensaje diciendo que no

tenemos permisos para esa acción.

2 Si algún dato no es correcto o no admitido por los

parametros fijados nos mostrara errores por cada

elemento del formulario no correcto.

Fig.8: Tabla descriptiva de la acción Crear participantes

Podemos ver en la figura 7, hay dos referencias, la primera a la

Autentificación del usuario y una vez que se comprueba el rol de éste y verificar

que es Organizador entonces pasamos a crear la competición. De otra manera nos

daría error por falta de permisos. La segunda referencia que nos encontramos es la

Introducción de participantes, es una opción que se le da debido a las

especificaciones requeridas por nuestro cliente, ya que existen competiciones donde



solo ellos, a través de la federación, conocen los nombres de los participantes y

facilita la tarea antes de la organización de cualquier evento.

El segundo diagrama que vemos es el de Borrar competición (Fig. 7) que es

otra funcionalidad del rol de Organizador.

Fig.9: Diagrama de Secuencia de una parte del caso de uso Gestionar competiciones (Borrar Competición).

Borrar competición

Objetivo Poder eliminar del registro un campeonato de la aplicación

Requisitos

Asociados

Descripción Esta acción solo es posible realizarla si somos Organizadores,

una vez que hemos accedido y que el tipo de usuario es correcto

nos permite ver todas las competiciones que existen y borrar

alguna de ellas a traves de un botón del menú.

Precondición Autentificarse en el sistema con rol Organizador.



Que la competición a borrar exista en el registro.

Secuencia

normal

Paso Acción


usuario.

2 El sistema nos muestra una lista con todas las

competiciones existentes y un botón lateral que

permita su borrado.

3 El usuario selecciona la competición a borrar y

confirma el borrado.

Postcondición Se eliminarán del sistema aquellos registros anotados que

correspondan al id de esta competición





3 De haber algún problema interno del sistema nos

mostrará un mensaje diciendo que es imposible borrar

los datos.

Fig.10: Tabla descriptiva de la acción Borrar competición.

En éste podemos observar como solo tenemos una referencia al caso de uso

de Autentificación, desarrollado anteriormente, en él podemos apreciar cómo se

necesitan ciertos permisos para borrar una competición, de poder hacerlo se le

ofrece al usuario el listado completo de las competiciones para que seleccione la

que desea eliminar.

Otra funcionalidad o caso de uso del rol de Organizador y Árbitro es

Actualizar competición, que podemos verlo en la figura 8.



Fig.11: Diagrama de Secuencia de una parte del caso de uso Actualizar Competición.

Actualizar competición

Objetivo Poder configurar un campeonato de la aplicación ya creado

Requisitos

Asociados

RF6 y RF8

Descripción Esta acción solo es posible realizarla si somos Organizadores,

una vez que hemos accedido y que el tipo de usuario es correcto

nos permite ver todas las competiciones que existen y actualizar

alguna de ellas a traves de un botón del menú.

Precondición Autentificarse en el sistema con rol Organizador.

Que la competición exista en el registro.

Secuencia

normal

Paso Acción


usuario.




competiciones existentes y un botón lateral que

permita su borrado.

3 El usuario selecciona la competición a editar.

4 El usuario mediante un formulario edita aquellos

campos, no clave, de la competición.

Postcondición Se editan del sistema aquellos registros anotados que

correspondan al id de esta competición





4 Puede existir un problema de fechas inconsistentes o

acentos que el sistema notificará al usuario justo

debajo del campo del formulario.

Fig.12: Tabla de descripción del caso de uso Gestionar competiciones (Actualizar Competición).

En la creación de competiciones vimos una referencia a la extensión Insertar

Participantes del rol Organizador. La cual tiene mucha importancia para el control

de personas que competirán, debido a que sin participantes no tenemos

competición.

En la figura 13, nos encontramos con la extensión Insertar participantes, que

es parte fundamental en el desarrollo de nuestra aplicación, este modulo aparece en

muchos de los diagramas de secuencia vistos anteriormente, esto se debe a que

tiene un gran peso y una entidad propia.

Esto le permite aparecer de manera individual ya que no solo es utilizada por

otros casos sino que tiene existencia propia y utilidad debido a que es la unica

acción que pueden realizar los usuarios de nuestra aplicación con el rol de

profesorado y entrenador.



Fig.13: Diagrama de Secuencia de la extensión de Gestionar competiciones (Insertar Participantes).

Insertar participantes

Objetivo Añadir la información de nuevas personas a las competiciones y

a nuestra aplicación para ser reutilizada.

Requisitos

Asociados

RF6 y RF9

Descripción Esta acción solo es posible realizarla si somos Organizadores o

Entrenadores (Profesores), una vez que hemos accedido y que el

tipo de usuario es correcto nos permite ver todas las

competiciones que existen y un listado con la información

existente en la aplicación sobre los participantes y nos permite

añadir estos o incluso subir información de algún participante.

Precondición Autentificarse en el sistema con rol Organizador o

Entrenador(Profesor).



Que existan competiciones en el registro.

Secuencia

normal

Paso Acción


usuario.


competiciones existentes.

3 El usuario selecciona la competición a la que añadir los

usuarios.

4 El sistema nos muestra una lista con los participantes

que ya existen en la aplicación.

5a. El usuario selecciona participantes que quiere añadir.

5b. El usuario añade nueva información de participantes.

5c. El usuario sube un archivo csv con información de

varios participantes para añadirlos.

6 El usuario confirma los participantes que va añadir a la

aplicación.

Postcondición Se añadiran los participantes a la competición actualizando y

añadiendo los registros necesarios en la Base de datos.





5a. Puede que la aplicación aún no tenga participantes

añadidos a la Base de datos. El sistema nos muestra

un mensaje de que no existen registros.

5b. El usuario puede introducir datos incorrectos en los

campos del formulario y el sistema informará sobre

estos errores.

5c. Si el usuario sube un fichero con una extensión o un

formato diferente al requerido el sistema dará un

mensaje de error al usuario informandole.

Fig.14: Tabla descriptiva de la extensión de Gestionar competiciones (Insertar Participantes).



En los casos de uso desarrollados hasta ahora, hemos visto aquellas

funcionalidades que se relacionan con usuarios que disponen de contraseña, pero

hay otras que las puede realizar cualquier usuario que visite nuestra aplicación web,

que son Ver y Comentar la competición, esta segunda como extensión de

funcionalidad de la primera.

Fig.15: Diagrama de Secuencia del caso de uso Ver Competición.

Ver competición

Objetivo Permitir a cualquier usuario de la web ver información acerca de

una competición.

Requisitos

Asociados

RF1, RF2 y RF12



Descripción Al entrar el usuario en la web debe ir al apartado competiciones,

que estará disponible en un pequeño menú superior, tras hacer

clic en éste nos aparecerá la lista de competiciones de las que

disponemos.

El usuario seleccionara una y mostrará los diferentes tatamis que

estén dispuestos en el recinto y poder así seguir la puntuación de

cualquiera de ellos.

Precondición Tener acceso a internet y a nuestra web.

Secuencia

normal

Paso Acción

1 Acceder a la web a traves de internet.

2 El sistema mostrará el menú inicial.

3 El usuario selecciona el menú Ver competición.

4 El sistema nos muestra una lista con las competiciones

existentes en la aplicación.

5. El usuario selecciona la competición.

6. El sistema le devuelve un cuadro de mando de la

competición donde puede ver la información sobre

esta.

Postcondición


4 No existan competiciones creadas aún por lo que el

sistema mostrará un mensaje para informar al usuario

sobre esta situación.

Fig.16: Tabla descriptiva del caso de uso Ver Competición.

Si queremos Comentar la competición (Fig. 17) los pasos son muy similares,

solo que esto solo podemos realizarlo durante la visualización de la misma, por ello

vemos una referencia al diagrama desarrollado en la figura 15 (Ver competición).



Fig.17: Diagrama de Secuencia de la funcionalidad del caso de uso Ver Competición (Comentar Competición).

Comentar competición

Objetivo Permitir a cualquier usuario de la web comentar competiciones.

Requisitos

Asociados

RF3

Descripción El usuario mientras ve cualquier competición podrá dejar en un

modulo que aparece en la información general de la competición

sus propios comentarios.

Precondición Tener acceso a internet y a nuestra web.

Secuencia

normal

Paso Acción

1 Acceder a la web a traves de internet.

2 El sistema mostrará el menú inicial.

3 El usuario selecciona el menú Ver competición.

4 El sistema nos muestra una lista con las competiciones

existentes en la aplicación.



5. El usuario selecciona la competición.

6. El sistema le devuelve un cuadro de mando de la

competición donde puede ver la información sobre

esta.

7. El usuario podrá poner sus propios comentarios junto

con un alias para ser facilmente reconocido.

Postcondición


4 No existan competiciones creadas aún por lo que el

sistema mostrará un mensaje para informar al usuario

sobre esta situación.

7 Si el comentario se considerá ofensivo se procederá

de manera automatica a borrarse para evitar herir

sensibilidades.

Fig.18: Tabla de descripción de la funcionalidad del caso de uso Ver Competición (Comentar Competición).

Una vez obtenemos estos diagramas podríamos crear un diagrama UML de

clases inicial (Fig. 19) con las relaciones que se dan en éste y las principales clases.

Más adelante veremos cómo se irá modificando pero este diagrama nos sirve para

hacernos una idea de cómo se estructurará nuestra aplicación.



Fig.19: Diagrama de clases inicial que podemos extraer de los diagramas de secuencia.

2.4. Planificación

Una vez tenemos los diagramas de casos de uso para comenzar a dar más

pasos se necesita una planificación de todo aquello que necesitamos, no solo en

materia de hardware, software y material humano, sino que necesitamos repartir el

uso de dichos recursos en el tiempo y las tareas que se deben realizar por parte del

equipo formado en este proyecto.

Lo vamos hacer de forma ordenada para acabar relacionando las tareas y los

recursos con el tiempo de forma que nos ayude en el reparto del trabajo. Haremos

un diagrama PERT, donde indicaremos la preferencia de unas tareas sobre otras,

para hallar un camino crítico que nos permita estimar exactamente la duración del

proyecto.

2.4.1. Planificación y estructuración del equipo

Un equipo en la gestión clásica tiene diferentes perfiles, gerente, líder, analista

de sistemas, diseñador, ingeniero software, responsable de calidad, responsable de

pruebas y administrador de la configuración del proyecto, entre otros.



Dado que en nuestro proyecto no podemos tener todos los perfiles habrá

personas que realizarán diferentes perfiles, dada la complejidad del sistema vamos a

necesitar aproximadamente 4 personas:

Gerente y líder del proyecto: Esta persona se ocupará de la gestión principal

del proyecto desde su planificación, estimación de costos hasta liderar y motivar al

equipo para que se trabaje de una manera fluida y se consigan los objetivos

planteados.

Ingeniero del software y diseñador: Primero hará el trabajo de diseñador,

haciendo los bocetos que expliquen lo que el sistema debe cumplir, y dando al resto

del equipo, de manera clara, cómo y qué se quiere diseñar. Posteriormente hará

labores de ingeniero del software revisando los códigos para que estos sean legibles

y faciles de entender. También realizará pruebas unitarias y de ensamblaje, que

permitan verificar que el trabajo del resto del equipo es acorde a lo que se espera de

la aplicación, como podemos ver éste, además, realizará funciones de responsable

de calidad.

Desarrollador: Este perfil será adoptado por la mayoría del equipo ya que

cada persona tendrá una especialidad como desarrollo de interfaces, esto nos

permitirá dar una mayor versatilidad al proyecto y poder complementar al equipo.

Responsable de Pruebas: A esta altura del proyecto también necesitaríamos

alguien encargado de unir y hacer las pruebas de integridad. Este perfil no puede ser

adoptado por la misma persona que desarrolle, puesto que necesitamos cierto grado

de imparcialidad.

A lo largo del proyecto estos perfiles van cambiando, ya que como hemos

explicado anteriormente en el perfil del desarrollador todo el equipo se va

encargando de una parte, todo esto se hará en el reparto de tareas.

2.4.2. Estimación de tareas.

Las tareas a realizar son las comunes en un proyecto software:

Investigación de soluciones existentes.

o Aplicación propia mediante hoja de cálculo excel.



o IJF ScoreBoard.

Análisis de requisitos.

Planificación del proyecto.

Selección de personal.

Selección de tecnologías inicial.

Diseño de aplicación web.

o Desarrollo de la arquitectura a implementar.

o Diagrama de clases.

o Modelo entidad relación.

o Interfaz.

Implementación del prototipo, basado en sus funcionalidades.

o Gestión de usuarios.

Registro.

Inicio de sesión de usuarios.

Permisos.

o Gestor de competiciones.

Creación.

Configuración.

Borrado.

o Inserción y borrado de participantes.

o Diseño y evolución del algoritmo de reparto de combates: dada la

particularidad de estas competiciones de Judo necesitaremos un

algoritmo propio que nos ayude en el reparto de los participantes

en tatamis y los combates que van a realizar.

o Desarrollo e implementación de la interfaz.

Pruebas de integridad.

Elaboración de manual de usuario y desarrollo de documentación.

Entrega al cliente y posterior evaluación.

Las tareas, como podemos imaginar, son adaptadas a la dificultad de la

implementación propia del sistema a desarrollar. La mayoría de estas tareas se

realizan de manera paralela permitiendo así una evolución de nuestro proyecto.



2.4.3. Planificación y estructuración del material

Dado que este proyecto no es de gran envergadura, se utilizará un ordenador

portátil como servidor principal desde donde se lanzará la aplicación web para

realizar las pruebas pertinentes. Cada persona del equipo descrito anteriormente

necesitaría su material propio para trabajar en este caso, cada cual pondría su

propio dispositivo para realizar sus tareas, calculándose su amortización

posteriormente e incluyendola en el presupuesto del proyecto.

Si pensamos en licencias necesarias del software que vamos a usar, el primero

es Netbeans, para el desarrollo del sistema, dada la comunidad activa que tiene y la

cantidad de lenguajes que nos permite desarrollar, además vamos a utilizar

EasyPert, que es libre y tiene gran funcionalidad para planificación. Usaremos

software privativo como es Visual Paradigm y Microsoft Office, por lo que el pago de

sus licencias también tiene un coste que entra dentro del proyecto.

Por último, necesitaremos usar material de oficina, desde folios para la

impresión de algunos esquemas y prototipos para enseñárselos al cliente tanto la

gestión y papeleo propio del proyecto como su documentación. Ahora vamos a

pasar a detallar el coste del material:

Licencias:

o Visual Paradigm: Dado que el proyecto no tiene mucha

dimensión podriamos hacer uso de una licencia única, y que las

personas del equipo que quieran usarlo no lo hagan a la vez, su

precio según la página oficial es de 349$ (285.36€), con un año

de mantenimiento en su versión Standard.

o Microsoft Office: Este software es muy importante para

documentar y planificar, ya que el uso de Excel y Word es muy

extenso y nos permite gran complicidad en diferentes

plataformas. Además, necesitamos comunicarnos de manera

oficial entre los miembros del equipo, todo esto lo conseguimos

con la versión 365 Empresa Premium, su precio es de 10,50€ por

usuario y mes con un compromiso anual. Dado que serían 4



usuarios haciendo uso de éste, saldría alrededor de 42 €

mensuales por todos los usuarios necesarios.

o Axure RP8 Pro: Este software nos ayuda en el diseño y

prototipado de nuestra aplicación, y al menos necesitamos este el

primer mes para poder realizar una primera muestra que nos

permita enseñarla y validarla con nuestro cliente. Su precio es de

29€ al mes, dado que sería el primer mes de uso.

Material de oficina: Dado que su uso no será excesivo, y que queremos

un proyecto consecuente y comprometido con el medio ambiente,

hacemos un cálculo de una caja de folios, de papel reciclado, y una caja

de bolígrafos, que estén fabricados con material biodegradable.

2.4.4. Reparto de tareas y recursos en el tiempo

Una vez que ya tenemos las tareas y el resto de material aproximado que

tenemos nos queda verlo en el plano del tiempo, lo que nos va a permitir:

Determinar la duración total del proyecto

Ver el camino crítico, es decir, las actividades que no pueden retrasarse

ya que afectaría a la duración del proyecto y esto sería un gran

problema.

Estimamos el inicio desde el 5 de marzo de 2018, cuando empecé a desarrollar

el proyecto, a pesar de que este documento debe hacerse a posteriori, en nuestro

caso se desarrolla en paralelo por falta de tiempo. Éste puede estar sujeto a

cambios, pero no deben ser cambios muy grandes e incluso si es una buena

planificación, como mucho se deberia variar en las holguras, pero sin modificar la

fecha de finalización de éste. La tabla (Figura 13) muestra las tareas a desarrollar,

su duración y si depende de cualquier otra actividad que se deba realizar

previamente:

ID Tarea Duración Dependencia Responsable

A Análisis inicial del problema 80 horas - Gerente

B Investigación soluciones existentes 40 horas A Diseñador



C Análisis de requisitos 56 horas B Gerente y

Diseñador

D Planificación del proyecto 48 horas B Gerente

E Selección de personal 24 horas D Gerente

F Selección de tecnologías 16 horas C Diseñador y

Desarrollador

G Diseño de aplicación web 40 horas C,D Diseñador

H Implementación del prototipo 120 horas E,F,G Desarrollador

I Pruebas de integración 16 horas H Responsable de

Pruebas

J Elaboración del manual de usuario 16 horas I Desarrollador y

Diseñador

K Entrega al cliente 8 horas J Equipo completo

Fig.20: Tabla de tareas, precedencia y duración del proyecto.

Haciendo uso del software EasyPert vamos a poder realizar nuestro diagrama

Pert (Figura 21) que nos permite calcular la duración total del proyecto, además de

seleccionar el camino crítico.

Fig.21: Diagrama PERT del proyecto.

Como ya hemos visto en la figura 20 la duración esta en horas, lo que nos va a

permitir hacer un cálculo más real a las horas de trabajo, teniendo en cuenta que

cada trabajador tiene una jornada laboral de unas 7 horas y que se trabajan 5 días a

la semana, unas 35 horas semanales aproximadamente.



En el diagrama PERT (Figura 21) podemos ver que existen 2 caminos críticos,

pero en uno de ellos hay una actividad ficticia de duración 0, por lo que los caminos

criticos son: A-B-C-F-H-I-J-K y A-B-C-G-H-I-J-K. Ambos muy similares, solo cambia

una de las actividades, lo que quiere decir que la única tarea que tiene algo de

holgura es la planificación del proyecto, es decir, esta es la que podría sufrir un

pequeño retraso, de unas 19 horas aproximadamente.

La duración total del proyecto son 376 horas, que hablando de manera laboral

son alrededor de 11 semanas de trabajo, si dejamos una semana para imprevistos,

dada la fecha inicial la entrega del proyecto sería el 28 de mayo de 2018.

2.4.5. Estimación de costos (Presupuesto)

Debemos de contar que el presupuesto para este proyecto, dado que tenemos

un cliente real contando con él y con la federación jiennense de Judo, nos permitirá

ser mas realistas. Ya conocemos la duración del proyecto que son 12 semanas,

viendo que necesitamos 4 personas para realizarlo, contando que éstas tengan su

propio portátil y lo usen en el proyecto, nos evitamos el coste de ordenadores

nuevos, pero no su amortización, que entraría dentro del proyecto.

Coste del equipo: Dado que las 4 personas que necesitamos trabajando en

nuestra empresa son empleadas para un proyecto de desarrollo software, nos

permite fijar sus horarios a través del XVII Convenio colectivo estatal de empresas

de consultoría, y estudios de mercados y de la opinión pública, establecido en el

BOE del martes 6 de marzo de 2018, entrarían en el Area 3 con el lider del grupo

profesional A, mientras que el resto serían del grupo E.

El empleado del grupo A, cobraría 25000€ anuales repartidos en 14 pagas,

según convenio, dado que el proyecto dura 3 meses, tendría como salario base

mensual 1786€ más 892,85€ correspondientes a la paga extraordinaria.

Los empleados del grupo E, cobrarían 14800,66€ anuales repartidos en 14

pagas, según convenio, dado que el proyecto dura 3 meses, tendría como salario

base mensual 1057,19€ más 528,60€ correspondientes a la paga extraordinaria.



La inversión total por el equipo es de 19902,04€.

Amortización equipo informático: Dado que disponemos de 4 ordenadores

que necesitamos trabajando en nuestra empresa, éstos debido a que los usamos en

el desarrollo del software, deben ser de una calidad media-alta, todos son portátiles

HP con procesador i7-6500U a 2.50GHz y con 8Gb de RAM, su precio en mercado

es de 680€. Un ordenador con éstas características tiene una vida media de 2 años

y nuestro proyecto dura 3 meses, su amortización mensual es de 28,35€ por lo que

la amortización de los 3 equipos durante el tiempo del proyecto es de 255,15€.

Coste de Licencias: Dado que vamos a usar software privativo necesitamos el

pago de una licencia, en el caso de Visual Paradigm la licencia es por un año

285.36€, por lo que añadimos al proyecto el gasto de amortización por el uso

durante éste, dado que haciendo el cálculo de 4 semanas por mes nos da un gasto

de 6€ aproximadamente por semana, al multiplicarlo por 12 semanas de uso, nos

daría alrededor de 72€ totales en el proyecto.

Otro de los software que vamos a usar es Microsoft Office, que se usará

durante todo el proyecto. En total son 42€/mes dado que son alrededor de 3 meses

el coste de su uso sería de 126€.

Coste de material de oficina: El gasto de este material se considera de diario,

por lo que una caja de folios junto con una caja de bolígrafos, material indispensable,

es alrededor de unos 30€.

Coste total del proyecto: Dados todos los costos vistos anteriormente, el

precio total de dicho proyecto es de 20385,19€ por el desarrollo de la aplicación con

manual de usuario, instalación y cursos para aprender a utilizar la aplicación y

posteriores revisiones que permitan mejorar y adaptar algoritmos del reparto de

combates.

Podemos ver a continuación una tabla resumen [Fig. 22] con todos el

presupuesto detallado:

Tipo de coste Descripción Precio base

(mensual)

Cantidad Coste total

Personal Trabajador grupo 1786€ (892,85€ 2 por 3 meses 12501,7€



A extra)

Trabajador grupo

E

1057,19€

(528,60€ extra) 2 por 3 meses 7400,34€

Amortización Equipo

informatico 28,35€

3 equipos por 3

meses 255,15€

Licencias Visual paradigm 24€ 1 licencia por 3

meses 72€

Microsoft Office 42€ 1 licencia por 3

meses 126€

Axure RP 8 29€ 1 licencia por 1

mes 29€

Material de

oficina Folios y bolis 30€ 30€

Total 20414,19€

Fig.22: Tabla resumen del presupuesto de la aplicación.

3. Diseño

3.1. Arquitectura

Nuestra aplicación dada su naturaleza, tendrá una arquitectura cliente-servidor,

que utiliza servidores web que ofrecen como interfaz distintas web, en nuestro caso

el servidor será un equipo portátil HP con un i7-6500U a 2.50GHz, con 8Gb de RAM.

Servidor: Alberga tanto la base de datos como los servicios que va a ofrecer a

través de una red local en un principio para las pruebas, pero una vez llevado a

producción estos se ofrecerán por medio de internet. Éste espera las conexiones de

los clientes para ofrecerles el servicio.

Cliente: Cada equipo externo que se conecte a la aplicación web, toda su

funcionalidad la realizará en los datos que alberga nuestro servidor, tan solo tendrá

que entrar a la URL de destino donde se publique la web para hacer uso de ésta. Su

conversación se representa en la figura 23.



Fig.23: Funcionamiento entre servidor y cliente.

Es una arquitectura clásica cliente-servidor, en la cual existe un servidor que

ofrece servicios y varios clientes que se conectan a ella, en un principio pensando en

la cantidad de equipos que suele haber en una competición de Judo vemos que

puede ser alrededor de 200 personas, por lo que no necesitará un servidor que

realice balanceo de carga ni ningun servicio especial que evite la caída de éste. Pero

como extensión es bueno tenerlo en mente para evitar problemas con esto.

La haremos en dos niveles dado que el mismo servidor que utilizaremos para

albergar la aplicación web además albergará la base de datos que localizará en una

determinada ubicación. Está basada en tres capas, la capa cliente, capa de base de

datos y una capa intermedia que albergará la aplicación del servidor, es decir, el

servidor. Su funcionamiento es más complejo de lo que vemos en la figura 16, ya

que el cliente solicita la web a través del navegador a nuestro servidor, éste va a la

base de datos para recoger los datos necesarios para la web, los incrusta en nuestra

aplicación y ésta se envia al cliente para que pueda reproducirla en su navegador en

formato HTML.

El uso de este formato nos da las siguientes ventajas:

Evitamos una sobrecarga en el servidor de Base de datos, ya que es

nuestro servidor el que debe realizar las conexiones.

Dividimos la funcionalidad especializando con capa de presentación, capa

de lógica de negocio y capa de almacenamiento.

3.2. Diagrama de clases

Para la realización del diagrama de clases debemos fijarnos en la figura 19,

ésta representa un primer diagrama de clases sin refinar, es decir, extraído

directamente de nuestros diagramas de casos de uso.



Algunos cambios respecto al diagrama anterior son por ejemplo, el número de

intentos que lo albergábamos en el sistema, cuando este atributo depende del

usuario y del sistema. Otra cosa que vemos es que se accede de manera directa al

sistema, cuando tenemos aplicaciones que están protegidas y tenemos diferentes

interfaces según los usuarios autentificados.



Fig

.24: D

iag

ram

a d

e c

lase

s d

el p

roto

tipo

de la

ap

licac

ión

web

.



Como vemos en la figura 24 tenemos el diagrama de clases final para nuestro

prototipo, vemos ligeros cambios aunque otro importantes como la adición de las

interfaces que nos permiten separar las 3 vistas que vamos a utilizar en la

aplicación. Tenemos una por el tipo genérico de usuarios, y otra por cada usuario

con rol definido como es el Organizador y el Entrenador, pero estas últimas

interfaces heredan de la general todas las funciones que pueden realizar, pudiendo

así una vez estemos registrados, realizar las operaciones propias del rol más las

genéricas. El resto es muy intuitivo ya que el sistema es la figura principal, pero el

usuario solo se comunica con éste a través de las interfaces, lo que permite liberar

un poco a la clase principal de carga de trabajo, el resto de clases son inaccesibles

de manera directa por el usuario, dando un toque de seguridad.

3.3. Modelo Entidad Relación

Nuestro modelo lo vamos a extraer de las entidades de nuestro diagrama de

clases que necesitan persistencia, es decir, que su información necesita ser

almacenada en nuestra base de datos. Si nos fijamos en la figura 24, dada la

simpleza de nuestro diagrama, es fácil entender cuáles necesitan esta función, pero

como ya sabemos no solo basta con ello sino que necesitamos indicar cuál será

nuestra primary key, e indicar qué atributos se pasan en las relaciones o si es

necesario crear una nueva tabla para la relación.

Fig.25: Modelo entidad-relación extraído del diagrama de clases, realizado con Smartdraw.



Dado el modelo que vemos en la figura 25, podemos extraer las tablas que

necesitamos crear en nuestra base de datos, para ello seguiremos las reglas que

nos ayudarán en el proceso de identificación. Un cambio principal es el de los

permisos, vemos que existen dos relaciones entre Usuario y Competición. Una

indica quién creó esta competición (Organizador) y otra indica quién puede

modificarla (Entrenadores).

Las tablas que extraemos son:

COMPETICIÓN (Nombre, FechaCelebración, Disponibilidad, Usuario)

USUARIO (Usuario, Contraseña, Rol, Email)

COMPETICION_USUARIO_MOD(Nombre, Usuario)

PARTICIPANTE (DNI o COD. Licencia, Nombre, Equipo, Nacionalidad,

FechaNacimiento, peso)

COMPETICION_PARTICIPANTE(Nombre_Competición, DNI o COD.

Licencia)

COMENTARIO (Nombre_Competición, ID, Nombre, Comentario)

La tabla de COMPETICION_USUARIO_MOD podríamos denominarla

Permisos_Usuario, ya que esta tabla indica qué usuarios pueden modificar qué

competiciones, a pesar de que tan solo pueden gestionar participantes. Utilizamos

este modelo ya que la cantidad de datos que vamos a manejar es bastante grande,

tenemos alrededor de unos 1000 competidores a nivel autonómico, hablando en

términos de participantes, si hablamos de cantidad de competiciones se realizan

unas 14 a lo largo de todo el año, de las cuales en paralelo suele haber unas 6 ó 7.

Dado este modelo que es realmente la base para nuestro desarrollo, podemos

ver que abarcamos casi todos los aspectos necesarios, pero de cara a la

funcionalidad completa de nuestra aplicación me di cuenta de que nos faltaba una

figura realmente importante, que eran los combates, esta entidad nos permite

almacenar quién se enfrenta a quién y cómo va avanzando nuestra competición.



En el momento del análisis no la tuvimos en cuenta, por lo que podemos

imaginar que esto puede llegar a ser un grave problema para nuestro desarrollo,

pero realmente podemos hacer una adición al final, permitiéndonos una

funcionalidad casi completa, exceptuando nuestro reparto de los participantes en

combates.

Nuestra nueva tabla tendría los siguientes atributos:

COMBATES (Nombre Participante, Nombre Competición, Nivel)

En el nivel pondríamos si se trata de un combate de grupos o un combate más

adelantado, como pueden ser octavos o cuartos de final, semifinales o final.

3.4. Interfaz

Para realizar el diseño de nuestra interfaz, lo primero que debemos es

responder a una serie de preguntas, que a lo largo de este documento ya podemos

hallar la mayoría de las respuestas:

1. ¿Qué desea el usuario que la aplicación haga?

2. ¿Cómo entra en la tarea diaria de los distintos actores?

3. ¿Qué nivel, computacionalmente hablando, tienen los usuarios?

4. ¿Qué estilos de aspecto y comportamiento son los deseados por los

usuarios?

Son solo 4 preguntas de las muchas que podemos realizarnos, pero con ellas

extraeremos una interfaz para nuestra aplicación, para ello contaremos, cómo no,

con la inestimable ayuda de nuestro cliente y algunos de los/as profesores/as

encargados de introducir datos en ella. Vamos a responder una a una a todas las

preguntas, consiguiendo con sus respuestas sacar diferentes partes o patrones de

nuestra aplicación.

a. ¿Qué desea el usuario que la aplicación haga? Esto nos dará la

funcionalidad, como ya hemos descrito en apartados anteriores, además de

representarlo con los casos de uso, vemos que puede realizar un usuario en

nuestra aplicación:



i. Inicio de sesión: Un usuario con usuario y contraseña podrá

iniciar sesión, para acceder a un menú personal según su rol:

Menú Organizador: Éste podrá gestionar las

competiciones, es el encargado de crearlas,

modificarlas, eliminarlas e incluso programarlas para

que se muestren como visibles en la web.

Menú Profesor: Este tan solo podrá acceder a las

competiciones para añadir o quitar participantes.

ii. Ver competiciones: Todos los usuarios, con y sin login,

podrán ver las competiciones pasadas y aquellas que están en

ese momento.

iii. Comentar competiciones: Al igual que la anterior, esta tarea

es para todo tipo de usuarios, existirá un filtro que evitará las

palabras mal sonantes, así como los insultos en cualquier

idioma.

iv. Ver estadísticas: Esto estará disponible con fichas similares a

las de competición, permitiendo el acceso a participantes y a

equipos, ya sea por nacionales o por centros deportivos,

permitiendo extraer de los datos que mantiene nuestra web de

combates ganados, puntos conseguidos, media de puntos por

combate, derrotas consecutivas, etc.

b. ¿Cómo entra en la tarea diaria de los distintos actores? Conociendo la

actual labor de nuestro cliente y su realidad, al igual que la del conjunto de

entrenadores que dedicarían su tiempo a añadir participantes en las

competiciones, conocemos que es una labor tediosa, actualmente, para

ellos el hecho de tener cada cierto tiempo insertar todos los datos de los

participantes.

Desde nuestra aplicación debemos evitar convertir esta tarea en el mismo

tedio, consiguiendo que sea algo más bien casi automático, actualizando

datos cada poco tiempo. Para ello contamos con la memoria de

participantes que agrega cada usuario, al insertar nombre o ID de ficha de



participante de manera automática nos aparecerán los datos del

participante, teniendo que pulsar tan solo una tecla para añadirlo.

c. ¿Qué nivel, computacionalmente hablando, tienen los/as usuarios/as?

Entre quienes conocemos, sabemos que el nivel informatico dentro de los

futuros usuarios de nuestra aplicación es muy variado, por lo que es

recomendable que sea una aplicación fácil e intuitiva, permitiéndonos así

que todos aquellos usuarios/as que vayan a acceder a nuestra aplicación

puedan hacerlo sin ningun tipo de problema, debemos, cómo no, realizar un

pequeño manual que ayude a aquellas personas con mayor problema.

d. ¿Qué estilos de aspecto y comportamiento son los deseados por

los/as usuarios/as? Hasta ahora, como bien vimos en el apartado 1.2, el

aspecto del que disponemos es una tabla de excel, debemos crear un

formato atractivo y con colores no muy llamativos, ya que las competiciones

pueden durar horas en las cuales los propios usuarios, ya sea organizador o

público, deben estar atentos a sus pantallas por lo que debe evitar el

cansancio provocado por este tipo de colores.

A continuación elaboro un prototipo de la interfaz con la aplicación RP Axure

Team Edition, que nos ayudará no solo con el aspecto y la visualización sino con la

funcionalidad que tendrá nuestra aplicación web, éste será validado por el cliente

antes de finalizarlo y exponerlo en este documento, donde explicaremos los bocetos

realizados y su funcionalidad con esta aplicación.



Fig.27: Pantallas principales de los prototipos de diseño de la interfaz validados por el cliente.

Como podemos ver, en la figura 27, aparece la interfaz principal de nuestra

aplicación, tanto en formato móvil como en formato ordenador. Éstas constan de

partes similares que son, Logo principal, Menú y, además, en la segunda forma

podemos ver un apartado de novedades donde podremos ver noticias importantes

sobre el Judo, y un apartado de contenido donde se irá modificando según vayamos

navegando por nuestra web.

El menú principal irá cambiando dependiendo de si hemos iniciado sesión con

el rol de entrenador u organizador [Fig. 28].

En el caso del árbitro, verá el mismo menú disponible para el entrenador, solo

que al entrar en la opción modificar competición tan solo le permitirá acceder al

tatami asignado para modificar dicha puntuación.

Fig.28: Menús con las funcionalidades diferenciadas según el rol con el que iniciemos sesión.

Menú principal

Novedades

Contenido



Fig.29: Interfaz de la función de ver o listar competiciones.

La funcionalidad de ver o listar competiciones [Fig. 29] consta de las mismas

partes que ya hemos explicado en la interfaz principal de nuestra aplicación, solo

que si estamos registrados con rol de organizador, accederemos para ver dos iconos

diferentes al lado de cada competición, que nos permitirá editar y eliminar las

competiciones. Si estamos registrados como profesores tan solo veremos el icono

de edición, que nos permitirá añadir y quitar participantes de nuestro propio equipo.

Fig.30: Interfaz de inicio de sesion de la aplicación.



El inicio de sesión [Fig. 30] se realiza a través de un formulario dónde debemos

introducir el usuario y la contraseña, con el cual no descartamos usar la verificación

captcha para aumentar la seguridad de nuestro sistema, pero en un principio sería

un inicio simple. También nos permite registrarnos, pero dicho registro debe ser

autorizado por un usuario con el rol organizador.

Fig.31: Formulario de creación de una nueva competición.

En el formulario de creación de una competición [Fig. 31], estará limitado al uso

con un ordenador por motivos de seguridad, disponemos de la introducción de los

parametros acordados, como nombre, será ID de la competición, su fecha de la

celebración que nos permite la elección a través de un calendario, la opción de estar

disponible o no en la web, la localización del evento y, por último, añadir los

participantes, éste consta de dos métodos diferentes:

1. Agregar participantes documento: Mediante un documento CSV

podremos insertar la información de estos participantes que estarán en

cada competición.



2. Agregar participantes formulario: Éste nos permitirá introducir uno a uno

los datos de las personas que participarán en la competición que estamos

creando.

Ambos métodos estarán disponibles tanto para el organizador como para el

entrenador.

Las funcionalidades disponibles para todos los usuarios son Comentar

competiciones y Ver competiciones. Éstas están en el menú principal siempre

para permitir a cualquier tipo de usuario hacer uso de ésta.

Fig.32: Contenido de la vista de una competición.

En la figura 32, vemos el contenido de la ficha que nos aparecerá una vez

hagamos clic en una de las competiciones, como vemos. Cada competición se

divide en tatamis y en la fase final, en éstas podremos seguir el progreso de la

competición, mediante tablas donde encontramos los resultados de los combates,

las vistas del tatami y de la fase final se diferencian en el tipo de tabla que usan,

debido a que en los tatamis suele salir en formato liga, en cambio la fase final solo

en aquellas competiciones que comiencen a combatir a partir de octavos de final, es

decir 16 participantes.



En este apartado de las competiciones podremos ver en la parte inferior, si

hablamos de la versión de ordenador, o un pequeño enlace a una página nueva en

el formato móvil, donde accederemos a los comentarios de la competición y aquí

podremos junto con un nick y con las normas básicas de respeto y cordialidad

establecidas, leer y escribir críticas sobre la competición que estamos observando.

Ádemas de poder acceder a las fichas personales de cada participante con sus

estadísticas que se generan de manera automática a partir de las competiciones en

las que participe que se encuentren en nuestra aplicación [Fig. 33].

Fig. 33: Contenido de las fichas de Tatami y participante Versión Móvil.

De las fichas tatami y participante tan solo enseñamos la versión movil dado

que el contenido es exactamente el mismo en ambas, para acceder a la versión

completa de nuestro prototipo de interfaz puede acceder a traves del enlace

siguiente: https://goo.gl/2UAvMk.

4. Implementación

4.1. Framework de desarrollo web

El framework seleccionado será symfony, con la versión 1.4.20 , la elección de

éste no es casual, sino que despues de investigar diferentes tipos de lenguajes y

diferentes framework para el desarrollo de nuestra aplicación, se decide utilizarlo por

las siguientes razones:

Proyecto con mucha lógica de negocio



Código necesario ligero, legible y efectivo

Interacción con usuario mediante Ajax

Desarrollo rápido pero robusto

Conocimiento de lenguaje PHP avanzado

Gran comunidad de apoyo

Como podemos ver, todas estas razones son las que nos animan a desarrollar

la aplicación web con symfony, el hecho de tener un código ligero, legible y efectivo,

es dado que tenemos una lógica de negocio cambiante, es decir, que son normas

federativas las que hacen cambiar la forma de reparto de combates lo que nos

puede llevar a tener que cambiar éste en un par de años pudiendo gracias a nuestro

framework cambiar sólo lo necesario.

Como apoyo utilizaremos también las herramientas de bootstrap, lo que nos

permite un diseño más elegante y con mayor potencial a la hora del desarrollo de

nuestra aplicación web, es considerada el mayor conjunto de herramientas para la

edición y el desarrollo de sitios web.

Como servidor web dado que usamos NetBeans, como ya comentamos en

apartados anteriores, usaremos el servidor por defecto que éste trae, que es Apache

Tomcat en su versión 8, éste no es necesario cambiarlo cuando pasemos a

producción, pero sí recomendable utilizar otro Web Server como Glassfish.

4.2. Tecnología de Base de datos

La tecnología a utilizar en este aspecto será MySQL, con el driver que nos

permite NetBeans, para conectarlo con nuestro proyecto de symfony, lo que nos

permitirá hacerlo más accesible, además de permitir dar una mayor portabilidad

cuando decidamos hacer pruebas y pasarlo a producción. Al igual que el framework

usamos éste debido a que necesitamos una herramienta bastante potente y que

admita un número alto de conexiones y transacciones, en nuestro caso la mayor

parte consultas, con el sistema. Por ello debemos usar una tecnologia fiable y

robusta que nos lo permita.



[DMJDBC] Para ello utilizaremos el driver de JDBC que tendremos que

descargar del siguiente enlace:

http://dev.mysql.com/downloads/connector/j/5.1.html

Una vez descargado tan solo tendremos que añadirlo a las bases de datos de

nuestro software, NetBeans, y configurarlo como lo pone en la referencia de nuestra

bibliografía.

4.3. Otras Tecnologías

Además de la tecnología del framework y de la tecnología utilizada en nuestra

base de datos, tenemos otras que acompañan y nos hacen más fácil el camino al

exito de nuestro proyecto, y a continuación detallamos algunas de ellas:

Twig: Es un motor de plantillas que es mucho más potente que las plantillas

base que podemos usar en PHP. Nos permite elaborar las partes comunes que se

irán replicando a lo largo de la aplicación, es decir, pie y cabecera de nuestra

aplicación que son comunes en todas las páginas y adición de todos los ficheros css

y js que necesitamos para el buen funcionamiento de ésta.

En symfony se usa como una extensión más y nos evita tener que crear un

controlador de excepciones en PHP. Twig también puede hacer cosas que PHP no

puede, como controlar el espacio en blanco, cuenta con un recinto de seguridad,

escape de salida automático y contextual e incluye funciones personalizadas y filtros

que sólo afectan a las plantillas.

Composer: Es un gestor de paquetes a nivel aplicación para PHP, es el que

nos ha ayudado en todo el proceso de creación de nuestro proyecto con symfony,

junto con Cygwin hemos podido instalar todo lo necesario dentro de nuestro

proyecto con línea de comandos simples [Figura 34].

Fig. 34: Línea de comandos de cygwin, junto con algunos comandos simples de composer.



Bootstrap: Es un framework web que contiene plantillas de diseño con

tipografía, formularios, botones, cuadros, menús de navegación y otros elementos

de diseño basado en HTML, CSS e incluso algunas partes de JavaScript. Su

principal misión es facilitar el desarrollo del front-end a diferencia de muchos otros

framework web.

4.4. Cambios en el diseño durante la implementación

Como es habitual en todo proyecto de desarrollo de una aplicación web,

ocurren cambios, ya sean debidos a las sugerencias o necesidades del cliente o a la

naturaleza de la aplicación, así como a falta de planificación en lo que respecta a las

tareas que llevamos a cabo durante éste.

En mi caso, por la naturaleza sencilla de la aplicación, vimos necesarios

algunos datos más en cuanto a información almacenada se refiere, ya que en un

principio solo queríamos tener datos básicos de los/as usuarios/as, que van hacer

uso de nuestra aplicación. Pero tras pensar un momento en la seguridad, se me vino

a la cabeza el momento en que olvidamos la clave y/o usuario y necesitamos entrar

a la web. Gracias a esto, vi la necesidad de almacenar en la tabla usuarios junto a

nombre de usuario y contraseña, un correo electrónico.

Además, repasando la estructura para elaborar nuestro algoritmo, vimos que

no tomamos en cuenta si en ese campeonato concreto el participante es cabeza de

serie o no, para ello sería bueno contar con un atributo booleano (Verdadero o falso)

que nos indicará si realmente lo es para facilitar el trabajo a la hora de desarrollar

nuestro algoritmo.

Por último pero no menos importante dado uno de los requisitos que deseaba

el cliente desde un inicio y su falta de tiempo para poder actualizar la puntuación en

todos los combates que se realizan en un tatami, nos dimos cuenta que había una

figura como es el árbitro de mesa, que habitualmente cuenta con 2 personas por

tatami, que se podía tener en cuenta para realizar este trabajo y poder hacerlo en

tiempo real, por lo que nos surge un nuevo rol.

Como es habitual en el desarrollo tradicional de software, todos estos cambios

ya se ven en la documentación anterior, quedando actualizada ésta y dando la visión



final o actual de nuestra aplicación. No solo tenemos cambios como éstos, sino que

en el propio análisis se pueden cometer errores dejando fuera de esta cosas

importantes, como puede ser alguna entidad de base de datos, como en nuestro

caso, que al implementar o querer hacerlo de una funcionalidad concreta nos damos

cuenta de que falta dicha figura.

5. Pruebas

Realizar pruebas reales ha sido imposible por falta de tiempo, debido al tiempo

necesario de desarrollo de la aplicación y a las fechas en las que se ha desarrollado

fue imposible terminar las funcionalidades previstas para hacer pruebas en un

entorno real.

Pese a todo se realizaron pruebas unitarias que nos ayudan a verificar la mayor

parte de casos posibles de uso en cuanto a las distintas funcionalidades se refieren

en él, y pruebas de integración que nos ha permitido ver todo esto en conjunto. Se

han realizado las pruebas a través tanto del ordenador utilizado como servidor como

desde un terminal móvil para ver la capacidad responsive del diseño. Esta capacidad

no es más que la rapidez de respuesta y la calidad de adaptarse a diferentes

pantallas de nuestra aplicación web.

Futuras pruebas a realizar posterior al desarrollo, y/o elaboración de la

documentación, que se desean realizar tanto por parte del desarrollador como por

parte del cliente son en un entorno real tanto pruebas de estrés, es decir someter a

la aplicación a un número ilimitado de conexiones de terminales para ver la

respuesta y el almacenamiento de datos de varias competiciones de ámbito real.

Estas pruebas nos ayudarán a verificar tanto el diseño de la propia aplicación

como del servidor que las contiene, evitando así fugas de información debido a que

contendrían, de hacer un uso real de ésta en competiciones oficiales, información

confidencial como pueden ser datos sobre las personas que participan en ella, así

como alguna información sobre los usuarios de la web, pudiendo poner en peligro la

integridad de estos datos e incurriendo en un delito según la LOPD1.

1 Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (Enlace)



5.1. Experiencia con cliente

Tras acordar varias reuniones con el cliente, pude comprobar personalmente

un trato directo y cercano, la experiencia es enriquecedora a la vez que confusa, ya

que por parte del cliente podemos ver cómo tiene una idea preconcebida de todo

aquello que desea para la aplicación. Desde nuestra posición como desarrolladores

y basándome en mi propia experiencia y capacidades debemos asentar estas ideas

en una base real y posible de todo aquello que se nos pide desarrollar.

Finalmente, y sin muchas incidencias, pudimos comprobar como un primer

diseño fue aceptado tanto visual cómo funcionalmente y que cuadraba tanto en la

idea del cliente como del propio desarrollador, tras contarle que necesitaba que

hiciera la aplicación. Se decidió por seguir con un diseño tradicional, presentar una

vez acabada la fase de diseño el prototipo realizado con Axure RP al propio cliente,

donde, con gran satisfacción, fue recibida la idea.

6. Resultados

Tras la fase de implementación hemos conseguido algunos de los requisitos

planteados, para ver realmente el alcance vamos a contar con 2 tablas que divida en

requisitos funcionales y no funcionales, y evaluar en conjunto si realmente se han

llegado a cumplir las expectativas y dar una valoración final de manera personal del

trabajo.

Requisito Grado de cumplimiento

RF1: Necesita poder entrar a la

aplicación para ver los resultados de los

combates y seguir la competición.

Se ha llegado a cumplir la primera parte que nos

permite el acceso a la aplicación para ver la

información de la competición

RF2: Necesita entrar a la aplicación y

ver el historial de competiciones además de

una clasificación de resultados por equipos.

Ocurre como la anterior en la que nos permite

acceder a la aplicación y ver el historial de las

competiciones pero no la clasificación por

equipos.

RF3: Durante la competición podrá

dejar sus comentarios sobre los combates.

Tiene la arquitectura preparada para hacerlo,

pero no terminar de hacer bien la inserción de

comentarios.



RF4: Necesita registrarse en la

aplicación para utilizarla con este rol

(Entrenador).

Este lo cumple a la perfección permitiendonos el

registro y uso de la aplicación con este rol

RF5: Necesita iniciar sesión para

modificar datos personales.

Lo cumple permitiendo ver información personal

y modificarla si es necesario

RF6: Necesita subir información sobre

participantes de los que se encarga para

agregarlos a una competición, creada en la

aplicación previamente.

Puede acceder a dicha funcionalidad y permite

agregar información de participantes a las

competiciones.

RF7: Necesita crear eventos en la

aplicación para que el resto de usuarios

puedan acceder a ellos (como

Administrador).

Puede crear dichos eventos o competiciones con

información mediante un formulario y

previamente si ha accedido con usuario y

contraseña con rol Administrador.

RF8: Necesita configurar los eventos

para poder adaptarlos a las necesidades

(como Administrador).

Puede configurar estos eventos aunque

actualmente solo dispone de un método de

reparto de combates.

RF9: Podrá subir un fichero CSV con

información de participantes para añadirlo a

una competición (como Administrador).

Esta funcionalidad está implementada pero tan

solo probada con ficheros pequeños de

información.

RF10: Podrá exportar datos a ficheros

PDF con las estadísticas y resultados de las

competiciones para enviárselo

posteriormente a quien corresponda,

almacenarlos, etcétera.

No existen dichas estadísticas ni dicho método

de exportación, queda pendiente para

implementación futura.

RF11: Dispondrá de un módulo de

inicio de sesión para que los diferentes

usuarios puedan acceder a funciones

especiales.

Dispone de dicho módulo y el modo de elección

de rol es sencillo.

RF12: Mostrará resultados de una

competición al hacer clic sobre ella en la

pantalla principal.

Muestra la información sobre la competición en

la que hacemos clic y sus resultados.

RF13: Será capaz de, con los datos de

las personas participantes y el tipo de

competición, ofrecer el reparto de combates

de manera automática para la celebración de

la misma.

Actualmente cuenta con dicho reparto

automatico de combates, a pesar de que

necesita ser probado ante una cantidad de datos

mas elevada.

RF14: Generará estadísticas de cada

competidor para permitir evaluar su

rendimiento.

La aplicación no genera estadísticas.



Fig. 35: Tabla de cumplimiento de requisitos funcionales.

Como podemos observar y haciendo un balance del cumplimiento de requisitos

funcionales que establecemos en la tabla, podemos decir que se ha realizado un

buen trabajo pero hay falta de tiempo a la hora de desarrollar e implementar las

distintas funcionalidades descritas.

Pasamos a los requisitos no funcionales y vemos el grado de cumplimiento de

éstos, para poder definir finalmente una valoración global del trabajo realizado en

este desarrollo:

Requisito Grado de cumplimiento

RNF1: El sistema debe ser accesible para

personas con problemas de visión, desde

simple daltonismo a pérdida total, incluyendo

atributos para ser leídos por lectores de

pantalla y configuración de alto contraste.

Nuestra aplicación cuenta con los atributos

necesarios para ser leído por lectores, así como

permitir un alto contraste.

RNF2: El sistema debe permitir iniciar sesión

con respuesta inferior a 30 segundos.

Pese a necesitar más pruebas con este módulo y

con más conexiones entrantes la respuesta del

login es inferior a 30 segundos.

RNF3: El sistema bloqueará temporalmente

una cuenta si equivoca el inicio de sesión 3

veces durante un minuto, y lo hará de manera

definitiva tras 12 intentos fallidos, es decir 3

bloqueos temporales.

Nuestra aplicación realiza un bloqueo estandar

propio del modulo de login de symfony.

RNF4: El sistema debe ser accesible desde

cualquier tipo de dispositivo, desde un

smartphone a un PC de sobremesa.

Como comentamos anteriormente la aplicación

cuenta con un diseño responsive por lo que

cumple con este requisito.

RNF5: El sistema debe ser capaz de operar

adecuadamente con unas 300 personas

conectadas de manera concurrente.

No se han realizado pruebas de este tipo por

carencia de dispositivos o posibilidad de realizar

las pruebas en entorno real.

RNF6: Todas las comunicaciones externas

entre servidores de datos, aplicación y cliente

del sistema deben estar cifradas.

El intercambio de información en dichas

comunicaciones se realiza encriptado evitando

problemas de seguridad.

RNF7: El tiempo de aprendizaje del sistema

por un usuario deberá ser inferior a 2 horas.

Con las funcionalidades con las que cuenta

nuestra aplicación actualmente el tiempo inferior

de aprendizaje es de dos horas, pero seria

necesario realizar más pruebas de este tipo.

RNF8: El sistema debe contar con manuales

de usuario estructurados adecuadamente

Actualmente el sistema cuenta con dichos

manuales que nos enseñan a utilizar la



aplicación de manera adecuada, y con su diseño

totalmente actualizada.

RNF9: El sistema debe proporcionar

mensajes de error que sean informativos y

orientados a usuario final.

El sistema muestra mensajes de error

orientativos pero es necesario realizar pruebas

en un entorno de producción.

RNF10: El sistema debe poseer interfaces

gráficas bien formadas.

Las interfaces han sido diseñadas siguiendo

estandares del framework de desarrollo utilizado.

Fig. 36: Tabla de cumplimiento de requisitos no funcionales.

Viendo ambas tablas y contando con que la mayoría de requisitos no

funcionales cumple, nos damos cuenta de que hay grandes ausencias que permiten

agujeros de seguridad en nuestra aplicación y ralentizan el tiempo de aprendizaje de

la misma. En general podríamos decir que cumple con la mayor parte de los

requisitos fijados en un principio con nuestro cliente, pero que al contar con un

diseño rígido hay algunas funcionalidades necesarias que están inacabadas.

7. Conclusiones

En este trabajo se ha desarrollado una aplicación web con el framework symfony de

PHP, esta nos permite almacenar y organizar una competición de Judo de una

manera simple y con cierta rapidez.

Actualmente para esto se utilizaba un pequeño programa en una excel o una

aplicación bastante compleja, nuestra aplicación ofrece simpleza y bastante

potencial respecto a las anteriores, ya que nos da un sitio donde almacenar y

reutilizar información de una manera rapida, y la posibilidad de hacer un reparto de

combates rapido sin tener que preocuparnos de ciertos aspectos.

Ha quedado pendiente algunas funcionalidades como el streaming de los combates

a traves de la web y otras como poder editar tu propio metodo de reparto o incluir a

participantes que estan solos en su categoria poder incluirlos de manera temporal en

otra.

Este proyecto espero poder continuarlo de mano tanto de mi tutor de TFG como de

mi cliente para que este hijo nacido de un trabajo fin de grado siga creciendo y el día

de mañana pueda servir para un control de esas competiciones de Judo a las que

gracias a éste me he aficionado.



8. Bibliografía

[STSE] Shu Taira. La esencia del judo. Satori Ediciones, 2010. ISBN 978-84-936198-8-6

[IJFSOR] IJF Sport and Organitation Rules, March 2017.

[IJFHB] Ippon.org draw - IJF Handbook Versión 1.00

[RFENC] Normativa Campeonato de España de Judo de Veteranos 2018.

[PPSGR] Planificación del proyecto de software. Gerardo Ramírez Hernández. Enlace

[TECPSUA] Diapositivas Técnicas de estimación de costos de proyectos software.

Universidad de la Amazonia.

[PFPTINW] Perfiles y sus funciones en proyectos de TI. Articulo web northware. Enlace

[SLOFRLW] Symfony2 El libro oficial. Fabien Potencier y Ryan Weaver. Libros Web. Enlace

[BOECCEC] BOE 6 de marzo de 2018. Incluye Convenio Colectivo de empresas de

consultoría. Documento oficial. Enlace

[WIKIDINU] Wikipedia. Diseño de Interfaz de Usuario. Enlace

[ECURDIU] Ecured Diseño de Interfaces de Usuario. Enlace.

[MCMAWP] Mauriciocandamil. Axure RP Diseño wireframes y prototipos. Enlace.

[WNBPLS] WikiNetBeans. Plugin Symfony. Enlace.

[DMJDBC] DevMedia. Instalar y configurar driver JDBC para MySQL. Enlace.

[GGSYBO] Gitnacho github. Symfony books. Enlace.

8.1. Bibliografía Complementaria

[LPLVP] Lista de Precios Licencias de Visual Paradigm. Enlace

[LPLMO] Lista de Precios Licencias de Microsoft Office. Enlace

[CMACS] CCM Arquitectura cliente servidor 3 niveles. Enlace

[LWCES] Libros web. Crear esqueleto de symfony. Enlace.

[DONBMS] Documentación oficial NetBeans. Configurando My SQL Server. Enlace.

[DOBSEA]. Documentación oficial Bootstrap. Dar estilos a mi aplicación web. Enlace.



ANEXO I. Manual de usuario.

MANUAL DE USUARIO JudoKan Apps.

Fig. 1: Simulación de nuestra aplicación en dos dispositivos diversos.

Bienvenidos y bienvenidas al mundo de JudoKan Apps. Esta aplicación tiene un propósito

claro y es ser referente en el mundo del Judo como organizador de competiciones,

permitiendo así desde Organizadores y Organizadoras, como a Entrenadores y

Entrenadoras, pasando por todos y cada una de las personas que haga uso de esta

aplicación un uso fácil y sencillo haciéndolo extensible a otro tipo de competiciones

deportivas.

Como creador de la aplicación y desarrollador de esta te doy las gracias por hacer uso de

ella y acceder al manual de buen uso de esta misma. A continuación presentamos un

pequeño índice que permita guiarse a través de este manual de manera eficaz.

Autor: Juan Francisco Abán Fontecha.

Versión: 1.0

* Este manual esta sujeto a cambios para cualquier modificación ruego me escriban un email a

[email protected] para proceder a mejorar este manual. Muchas gracias.



ÍNDICE MANUAL DE USUARIO

1. Descripción de la aplicación ......................................................... 65

2. Instalación de entorno web privado .............................................. 66

3. Registro de usuarios ..................................................................... 67

a. Edición de información ............................................................ 68

4. Creación de competiciones .......................................................... 68

5. Añadir participantes ...................................................................... 70

a. Añadir un participante ............................................................. 70

b. Adición masiva de participantes .............................................. 70

c. Selección participantes existentes .......................................... 71

6. Reparto de combates ................................................................... 72

7. Introducción de resultados............................................................ 74



1. Descripción de la Aplicación.

Está aplicación web actualmente solo es accesible desde la red interna del mismo

dispositivo donde la despleguemos, es fácilmente exportable a un entorno web, pero a

continuación vamos a explicar cómo instalar el entorno web privado, es decir en una red

interna de nuestro dispositivo adecuada para el buen uso de esta.

¿Pará que usamos nuestra aplicación?

JudoKan Apps. Sirve como organizador de competiciones de Judo, nos permite realizar

un reparto de los combates automatizado una vez que tenemos toda la información de

participantes y de la propia competición.

¿Desde dónde es accesible?

Para su desarrollo se ha utilizado un lenguaje que nos permite que el peso de la

aplicación recaiga en el servidor, que es el dispositivo que alberga el servidor web, por lo

que se podrá acceder desde cualquier dispositivo con una calidad media sin problemas

de rendimiento.

En cuanto a la estructura visual se refiere usamos el sistema grid de Bootstrap, que es

un framework HTML, CSS y JS, que permite a nuestra aplicación una rápida adaptación

a diferentes dispositivos tanto ordenadores como móviles.

¿Es Accesible, en cuanto a diferentes capacidades se refiere?

En la creación de dicha aplicación web se ha intentado respetar todas las normas para

que permita a personas con diferentes capacidades hacer uso de nuestra aplicación sin

tener ningún tipo de problemática. Se seguirá trabajando en ello y evolucionando en las

siguientes versiones para permitir un uso correcto por parte de cualquier tipo de usuario.

¿Permite reutilizar información de participantes?

No solo podemos usarla como organizador y para hacer un reparto automático, sino que

dispone de una base de datos que nos permite tanto el almacenaje de la información

como su posterior uso en diferentes competiciones.

¿Podemos visualizar la competición en streaming?

Dada que es la primera versión de nuestra aplicación y sobre todo se va a utilizar cerca

del entorno del dispositivo que la despliegue en el servidor web privado, no admite esa

posibilidad, pero en un futuro pretende albergar esta y muchas otras funcionalidades que

permitan hacerla crecer y alcanzar un nivel alto en cuanto a funcionalidades de esta

envergadura.



2. Instalación de entorno web privado

A pesar de no ser este el lugar adecuado de explicar cómo utilizar una aplicación para

instalar en nuestro propio dispositivo un entorno web local vamos a explicarlo para hacer

uso de nuestra aplicación en esta versión, dado que aún no está desplegada en un

entorno web accesible desde cualquier red.

Podemos usar cualquier aplicación que conozcamos como WAMP, LAMP, BitNami,

MAMP, etc.

En nuestro caso nos hemos decantado por una aplicación sencilla de instalar y de

proceder a su uso, esta es XAMPP. Incorpora un servidor Apache, un sistema gestor de

bases de datos MySQL y lenguajes como PHP y Perl. Además, ofrece soporte para

gestionar cuentas FTP, acceso a bases de datos mediante PHPMyAdmin, bases de

datos SQLite y varias otras características.

De todas estas características nosotros tan solo haremos uso de su servidor Apache y

de su entorno de base de datos MySQL. Para proceder a su instalación tan solo

descargamos el ejecutable del siguiente enlace (apachefriends.org).

Fig. 2: Pantalla del proceso de instalación donde podemos elegir que deseamos instalar de XAMPP.

Las propiedades se dejan por defecto, durante el proceso de instalación, podremos no

instalar algunas de sus características como TomCat, Filezilla, Mercury e incluso

Webalizer, ya que no son necesarias para nuestra aplicación.

Una vez instalada necesitamos dar dos pasos:

1. Copiar la carpeta de nuestra Web: Nuestra carpeta se denomina TFG y debemos

copiarla en el entorno accesible por el servidor web local que acabamos de instalar

(XAMPP), si es Windows la ruta es: C:/xampp/htdocs.

2. Crear nuestra base de datos: Debemos crear la base de datos a partir de la

estructura junto con el fichero sql que disponemos junto a nuestro documento.

Debemos lanzarlo desde http://localhost/phpmyadmin/server_sql.php.

Una vez que tengamos esto accederemos a nuestra web desde http://localhost/TFG/web/.



3. Registro de usuarios.

Nuestra aplicación no necesita que dispongamos de un usuario registrado para poder

visitarla, pero sí para hacer uso de todas sus funcionalidades, disponemos de 3 roles

diferentes de usuarios registrados pero solo dos son seleccionables al crear nuestro usuario.

Para poder crear nuestro usuario debemos irnos al menú superior y seleccionar la opción

Iniciar sesión.

Fig. 3: Menú principal que nos permite ver las 3 opciones de nuestra aplicación para un usuario sin registrar.

En esta nueva página dispondremos de un pequeño enlace que debemos seleccionar para

poder registrarnos, al seleccionarlo nos llevará a un pequeño formulario donde debemos

rellenar sus campos y seleccionar nuestro rol.

Fig. 4: Pantalla de inicio de sesión y el formulario de registro para usuarios nuevos.

Los dos Roles son Profesor (Entrenador) que permite ver las competiciones y agregar a los

participantes. Y el rol de Arbitro que solo permite modificar los resultados de las

competiciones**.

Una vez que aceptamos los terminos de uso y que damos al botón de registro ya

disponemos de nuestro usuario, en versiones posteriores esto solo podrá ser aceptado por

un usuario con el rol de Administrador, como podemos observar estos usuarios no se

permite ser creados desde el formulario para evitar así problemas de seguridad.

**El rol de administrador nos da acceso a todas las secciones de la web, así como a toda la

información almacenada, esté o no activa.



a. Edición de usuarios.

Una vez creado nuestro usuario nos llevará al modulo de Inicio de Sesión, mediante el cual

podremos acceder a nuestra cuenta de usuario. Introduciendo el usuario y la contraseña.

Una vez hecho esto de manera correcta veremos en la esquina superior derecha de nuestra

aplicación un pequeño simbolo con un ojo que significa que hemos iniciado sesión y un

mensaje de bienvenida.

Fig. 5: Mensaje de bienvenida que nos muestra la aplicación.

Este mensaje no solo sirve como información para saber que hemos iniciado sesión en

nuestra aplicación sino para poder editar nuestros datos, una vez que hacemos clic sobre el.

Fig. 6: Formulario de edición de usuario.

Como podemos observar hay campos inactivos como son el nombre de usuario y el rol, ya

que estos se considerán inmutables en la edición del usuario. Para desconectarnos de

nuestra sesión podremos hacerlo mediante una nueva opción que aparece en el menú

superior tras iniciar sesión (Desconectar).

4. Creación de competiciones.

Esta acción solo es posible de hacer si hemos iniciado sesión con un usuario Administrador,

por defecto al crear nuestra base de datos disponemos de uno cuyo nombre de usuario y

contraseña son root. Esto nos permitirá hacer algunas pruebas con nuestra aplicación.

Una vez que iniciamos sesión con nuestro usuario Administrador, veremos un menú superior

ligeramente diferente.



Fig. 7: Menú superior del usuario con rol Administrador.

Como podemos observar nos aparece la opción de crear competiciones, hacemos clic

sobre ella y nos aparece un pequeño formulario que nos permite crear a nuestro gusto la

competición.

Fig. 8: Formulario de registro de competiciones.

Este formulario nos provee del usuario que está creando la competición, nos permite

insertar tanto el nombre, fecha como la ubicación de nuestra competición, además de si

permite que esté disponible. De no estarlo solo es visible por usuarios Administradores y

al irnos a la visión de listar Competiciones la vemos en un color diferente y con una

advertencia para que sepamos que no es visible.

Fig. 9: Listado de competiciones con advertencia en la competición deshabilitada.

Una vez creada la competición podremos verla en el listado, junto con edición, borrado y

adición de participantes, el borrado solo se permite a usuarios con el rol de

Administrador.



5. Añadir participantes.

Esta acción solo es posible realizarla con usuarios con el rol de Administrador o de

Profesor (Entrenador), cualquier otro tipo de usuario no vería dicha opción, Tenemos 3

tipos de opciones a la hora de añadir participantes a nuestra competición.

Fig. 10: Menú de adición de participantes.

a. Añadir un participante

Esta opción es la más común cuando queremos hacer pruebas o tenemos pocos

participantes, ya que con esta disponemos de un solo formulario donde podremos

insertar la información del participante a mano.

Fig. 11: Formulario de añadir un participante.

De manera automática el sistema nos clasifica en las diferentes categorías a los

participantes según el peso y el sexo.

b. Adición masiva de participantes

Para cuando necesitamos insertar mucha información de participantes y disponemos de

un fichero CSV o en su defecto una extensión de fichero que permita su conversión a

CSV, debemos tener en cuenta seguir un mismo esquema para la introducción correcta

de nuestro fichero.



Fig. 12: Apartado de adición masiva de participantes.

Una vez que insertemos el fichero y le demos a enviar nos llevara a la información de la

competición donde podremos ver si todo ha ido bien, de nos ser así nos dará un error y

nos indicará que ha sucedido.

c. Selección participantes existentes.

Esta opción es la que nos permite la reutilización de participantes entre competiciones,

tenemos que tener en cuenta en este apartado en especial que existe la ley de protección

de datos por lo que el sistema controla a que organización pertenece el Entrenador para

no mostrar participantes que no sean de esta. El administrador puede ver todos los

participantes que existan dentro de la base de datos.

Fig. 13: Tabla con participantes, que permiten ver los seleccionados y los disponibles.

Como vemos en la figura 13 disponemos de un buscador además de poder observar los

participantes que ya existen en nuestra competición y los que son susceptibles de ser

seleccionables.



6. Reparto de combates.

La última parte de este manual la vamos a dedicar al reparto de los combates adaptativo del

que disponemos, ¿Por qué decimos que es adaptativo? Nuestro sistema se encarga de

recorrer la información de los participantes que tenemos en nuestra competición y de crear

el organigrama para disputar los combates de una manera correcta y evitando repeticiones.

Para ello debemos acceder a nuestro menú Ver Competiciones, donde se nos mostrará la

lista de competiciones de las que disponemos, seleccionamos una de ellas para entrar a su

ficha, si disponemos de un usuario con un rol de Administrador podremos ver un botón

inferior de Reparto de Combates, como vemos en la figura 14.

Fig. 14: Ficha de una competición donde podemos ver los participantes y en la parte inferior el botón que nos

permite hacer el reparto de combates.

Tras hacer clic en este botón nos aparecerá un mensaje de advertencia para que sepamos

que se va a proceder a este reparto, tras aceptar vemos un pequeño formulario donde

veremos las categorías y los participantes, así como checkbox que nos permitirán

seleccionar a los cabezas de serie.

Fig. 15: Formulario de selección de cabezas de serie, junto con las categorías a las que pertenecen.



Una vez que seleccionamos nuestras cabezas de serie tan solo tendremos que pulsar en

proceder al reparto y nos aparecerá un listado con nombres y Tatamis donde se deben

realizar los combates. En esta pantalla que nos indica el reparto de los participantes y en los

tatamis que se realizarán dichos combates, es tan solo informativa y desde esta podremos

acceder a introducir los resultados.

Fig. 16: Pantalla informativa de los combates al realizar el reparto, con el botón que nos permitirá acceder a la

pantalla con el organigrama que permite la edición de resultados.

7. Introducción de resultados.

El acceso a los resultados se puede hacer de dos formas, de manera directa al repartir los

combates con el botón de la figura 16 (Ver resultados), o desde la visión de la competición

donde veremos que el botón realizar reparto que vemos en la figura 14 ha pasado a ser Ver

resultados como vemos en la figura 17.

Fig. 17: Ficha de competición con el botón Ver resultados.



Ambas posibilidades nos llevaran al organigrama de nuestra competición y nos permitirá ver

los combates que se van a realizar y en que tatami, de manera que será más simple para el

usuario reconocer a los combatientes.

Fig. 18: Organigrama de la competición que nos permitirá ver los resultados.

Si estamos registrados con un usuario con el rol árbitro o Administrador nos permitirá la

edición y el almacenamiento de los resultados con los dos botones que al modificar

cualquier input aparecerán de manera inmediata. No solo esto, sino que los pases al resto

de eliminatorias se irán refrescando conforme vayamos introduciendo los resultados, para

así facilitar la vida al administrador y gestor de la competición.

Prototipo de Aplicación Web para la Gestión de una ...

Documents

Transcript of Prototipo de Aplicación Web para la Gestión de una ...