universidad central del ecuador - repositorio digital ... · facultad de ingenierÍa, ciencias...

UNIVERSIDAD CENTRAL DEL ECUADOR

FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS Y MATEMÁTICA

CARRERA DE INGENIERÍA INFORMÁTICA

“SISTEMA DE ADMINISTRACIÓN DEPORTIVA PARA LA UNIVERSIDAD

CENTRAL DEL ECUADOR”

TRABAJO DE GRADUACIÓN

PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO INFORMÁTICO

AUTOR:

Salazar Asanki Roberto David

TUTOR:

Ing. Moncayo Unda Milton Giovanny, MSc.

QUITO – ECUADOR

2015

ii

DEDICATORIA

Dedico este trabajo principalmente a Dios que me ha dado la vida y la energía

necesaria para poder concluir con este reto personal y profesional, a mis padres

Linda y Alfonso que me han apoyado incondicionalmente durante todos estos

años, a mi hermano Luis que ha estado siempre con migo, a mi tutor, revisores

y profesores que me han enseñado y me han infundido el amor por esta

profesión, a mis queridos amigos y familiares que me han brindado su amistad

sincera, a mi esposa Sonia por ser mi soporte y fuente de inspiración para

superar cualquier reto que se presente, y finalmente a mi abuelita que desde el

cielo sé que me está cuidando y guiando en todo camino.

Roberto Salazar Asanki

iii

AGRADECIMIENTO

Agradezco a Dios por darme la fuerza, la energía y la sabiduría necesaria para

poder culminar esta meta profesional.

A mi tutor, Giovanny Moncayo y revisores, Jefferson Beltrán Y Franz Del Pozo

por la ayuda y guía que me han ofrecido para concluir con este proyecto de

tesis.

A las personas que conforman la Facultad de Cultura Física que me dieron la

apertura, colaboración y facilidades para desarrollar este proyecto.

A mi familia y amigos por su apoyo y colaboración incondicional sin ellos nada

de esto hubiera sido posible.

A la Universidad Central del Ecuador por formarme profesionalmente y darme la

oportunidad de crecer en torno a mi profesión.


iv

AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL

Yo, Roberto David Salazar Asanki en calidad de autor del trabajo de tesis

realizado sobre “SISTEMA DE ADMINISTRACIÓN DEPORTIVA PARA LA

UNIVERSIDAD CENTRAL DEL ECUADOR”, por la presente autorizo a la

Universidad Central del Ecuador, hacer uso de manera total o parcial del

contenido de esta obra, con fines estrictamente académicos o de investigación.

Los derechos que como autor me corresponda, con excepción de la presente

autorización seguirán vigentes a mi favor, de conformidad con lo establecido en

los artículos 5, 6, 8, 19 y demás pertinentes de la ley de propiedad intelectual y

su Reglamento.

Quito, a los 24 días del mes de julio de 2015.

________________________

Salazar Asanki Roberto David

C.C.: 1716925704

v

CERTIFICACIÓN DEL TUTOR

vi

INFORME FINAL DEL TUTOR

vii

DESIGNACIÓN DEL TRIBUNAL

viii

CALIFICACIÓN DEL TRABAJO DE GRADUACIÓN

ix

CONTENIDO

DEDICATORIA .................................................................................................... ii

AGRADECIMIENTO ........................................................................................... iii

AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL ........................................... iv

CERTIFICACIÓN DEL TUTOR ............................................................................ v

INFORME FINAL DEL TUTOR ........................................................................... vi

APROBACIÓN DEL TRIBUNAL ........................................................................ vii

CALIFICACIÓN DEL TRABAJO DE GRADUACIÓN ........................................ viii

RESUMEN ........................................................................................................ xvi

ABSTRACT ...................................................................................................... xvii

CERTIFICADO DE TRADUCCIÓN DEL RESUMEN ...................................... xviii

INTRODUCCIÓN ................................................................................................ 1

CAPÍTULO 1 ....................................................................................................... 2

1. PRESENTACIÓN DEL PROBLEMA ......................................................... 2

1.1. Planteamiento del Problema ..................................................................... 2

1.2. Formulación del Problema ........................................................................ 3

1.3. Objetivos de la Investigación .................................................................... 3

1.3.1. Objetivo General ............................................................................. 3

1.3.2. Objetivos Específicos ...................................................................... 4

1.4. Justificación .............................................................................................. 4

1.5. Limitaciones .............................................................................................. 4

CAPÍTULO 2. ...................................................................................................... 6

2. MARCO TEÓRICO ................................................................................... 6

2.1. Antecedentes ............................................................................................ 6

x

2.2. Alcance ..................................................................................................... 6

2.2. Análisis de herramientas ........................................................................... 7

2.1.1. Plataforma ....................................................................................... 7

CAPÍTULO 3. .................................................................................................... 13

3. METODOLOGÍA DE DESARROLLO ...................................................... 13

3.1. Metodologías ágiles ................................................................................ 13

3.2. Manifiesto ágil ......................................................................................... 13

3.3. Comparación de metodologías ............................................................... 15

3.4. Programación Extrema (XP) ................................................................... 17

3.4.1. Valores de XP ...................................................................................... 17

3.4.2. Principios de XP .................................................................................. 18

3.4.3. Ciclo de vida de XP ............................................................................. 19

3.5. Roles y Responsabilidades ..................................................................... 21

3.6. Aplicación de metodología ...................................................................... 22

3.7. Exploración ............................................................................................. 22

3.8. Planificación del proyecto ....................................................................... 24

3.8.1. Planificación Inicial ........................................................................ 25

3.8.2. Integrantes del equipo ................................................................... 25

3.8.3. Prototipos ...................................................................................... 25

3.8.4. Priorización de Historias de Usuario ............................................. 35

3.8.5. Plan de entrega ............................................................................. 37

3.8.6. Iteración 1 ..................................................................................... 38

3.8.7. Iteración 2 ..................................................................................... 44

3.8.8. Iteración 3 ..................................................................................... 51

3.8.9. Diario de Actividades ..................................................................... 59

xi

3.9. Implementación ....................................................................................... 63

3.9.1. Diagrama de Base de Datos ......................................................... 64

3.9.2. Diagramas por sección de negocio ............................................... 65

3.10. Manual Técnico ................................................................................... 78

3.11. Manual de Usuario ............................................................................... 94

3.12. Pruebas Funcionales ......................................................................... 106

CAPÍTULO 4 ................................................................................................... 115

4.1. CONCLUSIONES ................................................................................. 115

4.2. RECOMENDACIONES ......................................................................... 116

BIBLIOGRAFÍA ............................................................................................... 119

ANEXOS ......................................................................................................... 120

A. Historias de Usuario .............................................................................. 121

B. Tareas Historias de Usuario .................................................................. 139

xii

LISTADO DE FIGURAS

Figura 1. Arquitectura en Capas ......................................................................... 7

Figura 2. Capa de presentación .......................................................................... 8

Figura 3. Componentes de un sistema PostgreSQL ......................................... 10

Figura 4. Componentes de un sistema PostgreSQL ......................................... 12

Figura 5. Comparación de métodologías .......................................................... 17

Figura 6. Ciclo de vida de XP............................................................................ 19

Figura 7. Fase de Planificación ......................................................................... 24

Figura 8. Prototipo de autenticación ................................................................. 26

Figura 9. Prototipo de administración de equipos ............................................. 26

Figura 10. Prototipo de administración de catálogos ........................................ 27

Figura 11. Prototipo de administración de detalle de catálogos ........................ 27

Figura 12. Prototipo de administración de deportistas y árbitros ...................... 28

Figura 13. Prototipo de jugadores por equipo ................................................... 29

Figura 14. Prototipo de conformación de equipos ............................................. 29

Figura 15. Prototipo de campeonatos ............................................................... 30

Figura 16. Prototipo de visualización de fechas asignadas .............................. 31

Figura 17. Prototipo de asignación de fechas ................................................... 31

Figura 18. Prototipo de administración de canchas .......................................... 32

Figura 19. Prototipo de administración de usuarios .......................................... 34

Figura 20. Prototipo de administración de roles ................................................ 35

Figura 21. Distribución de Historias Iteración 1 ................................................ 39



Figura 24. Fase de Implementación .................................................................. 63

Figura 25. Diagrama de Base de Datos ............................................................ 64

Figura 26. Administración de usuarios .............................................................. 65

Figura 27. Administración de campeonatos ...................................................... 66

Figura 28. Administración de jugadores ............................................................ 67

Figura 29. Registro de partidos ......................................................................... 68

Figura 30. Administración de catálogos ............................................................ 69

xiii

Figura 31. Administración de canchas .............................................................. 69

Figura 32. Conformación de equipos ................................................................ 70

xiv

LISTADO DE TABLAS

Tabla 1. Diferencias entre metodologías ágiles y no ágiles .............................. 16

Tabla 2. Historias de Usuario ............................................................................ 22

Tabla 3. Integrantes y roles del equipo ............................................................. 25

Tabla 4. Priorización y distribución de Historias de Usuario ............................. 35

Tabla 5. Historias de Usuario a implementar en la Iteración 1 .......................... 38

Tabla 6. Historias de Usuario: Diseño de interfaz ............................................. 40

Tabla 7. Historias de Usuario: Administración de catálogos ............................. 40

Tabla 8. Historias de Usuario: Administración de canchas ............................... 41

Tabla 9. Historias de Usuario: Administración de equipos ................................ 41

Tabla 10. Historias de Usuario: Administración de jugadores ........................... 42

Tabla 11. Historias de Usuario: Administración de árbitros .............................. 42

Tabla 12. Historias de Usuario: Autenticación de Usuarios .............................. 43

Tabla 13. Pruebas de aceptación por historia de usuario ................................. 44

Tabla 14. Historias de Usuario a implementar en la Iteración 2 ....................... 45

Tabla 15. Historias de Usuario: Conformación de equipos ............................... 46

Tabla 16. Historias de Usuario: Generación de partidos ................................... 47

Tabla 17. Historias de Usuario: Programación de fechas y horarios ................ 47

Tabla 18. Historias de Usuario: Administración de campeonatos ..................... 47

Tabla 19. Historias de Usuario: Registro de resultados de los partidos ............ 48

Tabla 20. Historias de Usuario: Administración de usuarios ............................. 49


Tabla 22. Historias de Usuario a implementar en la Iteración 3 ........................ 51

Tabla 23. Historias de Usuario: Envió de e-mail con información de

Campeonatos.................................................................................................... 53

Tabla 24. Historias de Usuario: Administración y seguimiento de deportistas .. 54

Tabla 25. Historias de Usuario: Reportes de fechas de juego .......................... 54

Tabla 26. Historias de Usuario: Reporte de máximos anotadores .................... 55

Tabla 27. Historias de Usuario: Reporte de resultados de partidos .................. 55

Tabla 28. Historias de Usuario: Reporte de tabla de posiciones ...................... 56

Tabla 29. Historias de Usuario: Generación de carnets de jugadores .............. 56

xv

Tabla 30. Historias de Usuario: Reporte de lesionados .................................... 57

Tabla 31. Historias de Usuario: Reporte de amonestados ................................ 57


Tabla 33. Diario de actividades Iteración 1 ....................................................... 59



Tabla 36. Prueba 1 ......................................................................................... 106

Tabla 37. Prueba 2 ......................................................................................... 107

Tabla 38. Prueba 3 ......................................................................................... 107

Tabla 39. Prueba 4 ......................................................................................... 108

Tabla 40. Prueba 5 ......................................................................................... 109

Tabla 41. Prueba 6 ......................................................................................... 110

Tabla 42. Prueba 7 ......................................................................................... 110

Tabla 43. Prueba 8 ......................................................................................... 111

Tabla 44. Prueba 9 ......................................................................................... 111

Tabla 45. Prueba 10 ....................................................................................... 112

Tabla 46. Prueba 11 ....................................................................................... 112

Tabla 47. Prueba 12 ....................................................................................... 113

Tabla 48. Prueba 13 ....................................................................................... 113

Tabla 49. Prueba 14 ....................................................................................... 114

xvi

RESUMEN



El presente trabajo, trata sobre el desarrollo de una aplicación Web para

automatizar el proceso manual de administración de campeonatos y juegos de

Fútbol, Básquet y Vóley que organiza la Facultad de Cultura Física de la

Universidad Central del Ecuador.

El sistema permite registrar las facultades, los deportistas, los árbitros, los

equipos de fútbol, de básquet y de vóley, y administrar los campeonatos, los

horarios y los calendarios de los juegos organizados por la Facultad, además

permite dar seguimiento a los deportistas inscritos manera automática y

parametrizable y así mantener el control de la información que se genere en

cada uno de los campeonatos administrados por la aplicación.

DESCRIPTORES

GESTIÓN DE EQUIPOS / GESTIÓN DE PARTIDOS / GESTIÓN DE

RESULTADOS DEPORTIVOS / SEGUIMIENTO JUGADORES /

ADMINISTRACIÓN DE CAMPEONATOS / DESARROLLO DE APLICACIONES

xvii

ABSTRACT



Present document is about Web development application to manual process

automates for Facultad de Cultura Física of Universidad Central del Ecuador to

Soccer, Basketball and Volleyball championships or games manage.

System can record the college faculty , athletes , referees, football, basketball

and volleyball teams, and management schedules and calendars

championships organized by Facultad de Cultura Física, also it allows to track

registered athletes automatic and programmable way and keep control of the

information generated in each championships managed by application.

KEY WORDS

TEAMS MANAGEMENT / MATCHES MANAGEMENT / SPORTS RESULTS

MANAGEMENT/ PLAYERS MONITORING / CHAMPIONSHIPS

MANAGEMENT / APPLICATIONS DEVELOPMENT

xviii

CERTIFICADO DE TRADUCCIÓN DEL RESUMEN

Por medio del presente, yo, GUAMA MORALES SONIA CAROLINA con cédula

de identidad No. 1718304411, certifico que he realizado la traducción del idioma

español a inglés del resumen del trabajo de graduación denominado “SISTEMA

DE ADMINISTRACIÓN DEPORTIVA PARA LA UNIVERSIDAD CENTRAL

DEL ECUADOR” previo a la obtención del título de ingeniero realizado por el

egresado ROBERTO DAVID SALAZAR ASANKI.

Particular que informo para los fines pertinentes.

Atentamente,

______________________________

Ing. Guama Morales Sonia Carolina

Traductor

1

INTRODUCCIÓN

La Facultad de Cultura Física de la Universidad Central del Ecuador, requiere

una aplicación Web que permita la administración deportiva de horarios y

calendarios para los juegos y/o campeonatos que organiza la institución, al igual

que el seguimiento a los deportistas de cada facultad que se registren en el

sistema.

El documento describe el desarrollo del Sistema Web de Administración

Deportiva para la Universidad Central del Ecuador, que sirve para automatizar

los procesos manuales que tienen en la forma de administrar la creación de

campeonatos y/o juegos el control de estos y el seguimiento que se le da a los

deportistas de la facultades de la Universidad Central del Ecuador.

Se utiliza la metodología de desarrollo ágil XP (Xtreme Programming), para

aprovechar las ventajas que ofrece en la construcción de proyectos de corta

duración, y la practicidad de utilizarla en base a las pruebas y errores del

desarrollo de software.

2

CAPÍTULO 1

1. PRESENTACIÓN DEL PROBLEMA

1.1. Planteamiento del Problema

Actualmente la Facultad de Cultura Física realiza manualmente la creación de

calendarios deportivos para los juegos y campeonatos que realiza, tiene un

manejo manual y básico de toda la información que se registra en estos

acontecimientos.

La Facultad de Cultura Física, realiza la organización de los campeonatos y/o

juegos de la Universidad Central del Ecuador, con el paso del tiempo se ha

convertido en una necesidad el poder administrar de una mejor manera este

proceso, debido al tiempo que toma el obtener estadísticas o información que

se requiere en el día a día, bajo este precedente se presenta lo que se va a

automatizar en la institución.

Registro, actualización y eliminación de las Facultades de la Universidad

Central del Ecuador dentro del sistema de Administración Deportiva.

Registro y seguimiento a los deportistas de cada facultad de la

Universidad Central del Ecuador registrados en el sistema de

Administración Deportiva.

Registro de los equipos participantes en los diferentes juegos y/o

campeonatos que organiza la institución.

Asignación de los deportistas a los diferentes equipos creados dentro del

sistema.

Generación de calendarios para la realización de los juegos y/o

campeonatos.

Generación de información referente a tablas de posiciones, máximos

anotadores, amonestados, lesionados, etc.

3

Envío de calendarios y fechas de juego vía email a los deportistas

registrados en el Sistema de Administración Deportiva.

Para realizar una administración óptima de la información anteriormente

mencionada, se va a desarrollar el Sistema de Administración Deportiva para la

Universidad Central del Ecuador, el mismo que va a automatizar el manejo de

los procesos que actualmente se los lleva manualmente.

1.2. Formulación del Problema

En la Facultad de Cultura Física el proceso de administración deportiva es

realizado de forma manual.

Como este proceso es realizado físicamente la administración y generación de

calendarios para organizar los juegos y/o campeonatos de la Universidad

Central, toma bastante tiempo y no se lleva registro de lo que acontece en estos

eventos ni se registra un seguimiento a los deportistas que participan en estas

actividades.

Al mantener este sistema de administración deportiva manual dentro de la

institución, se tienen algunas dificultades que se mencionan a continuación:

Excesivo uso de tiempo y recursos en realizar la calendarización y

programación de los juegos y/o campeonatos que organiza la institución.

Falta de estadísticas y reportes que muestren el historial de los eventos

organizados por la institución.

1.3. Objetivos de la Investigación

1.3.1. Objetivo General

Realizar el análisis, diseño e implementación del Sistema Web para la

administración deportiva de la Universidad Central del Ecuador, para cubrir la

necesidad expuesta por la Facultad de Cultura Física.

4

1.3.2. Objetivos Específicos

1. Realizar la calendarización de los juegos y/o campeonatos de fútbol,

básquet y vóley organizados por la Universidad Central del Ecuador.

2. Realizar el seguimiento a los deportistas registrados en el Sistema de

Administración Deportiva para la Universidad Central del Ecuador.

3. Desarrollar el Sistema de Administración Deportiva para la Universidad

Central del Ecuador con herramientas de Software libre.

1.4. Justificación

La realización del proyecto busca satisfacer las necesidades que tienen los

usuarios de la Facultad de Cultura Física, dentro del proceso de administración

deportiva para organizar los campeonatos y/o juegos y dar seguimiento a los

deportistas inscritos dentro del sistema.

Mediante la implementación del sistema Web se va a brindar un mejor

seguimiento y administración al proceso deportivo de la Universidad Central del

Ecuador, que en la actualidad se los lleva de forma manual y es complicado el

administrar de esta manera el mencionado procedimiento.

La Facultad de Cultura Física al implementar el Sistema de Administración

Deportiva para la Universidad Central del Ecuador, va a incursionar en el campo

de la tecnología Web, lo que hace que la administración del proceso pueda ser

en línea y se lo pueda realizar desde cualquier lugar que tenga acceso a

Internet.

1.5. Limitaciones

Dentro de las limitaciones del sistema se enfatizan las siguientes, detalladas a

continuación:

a. El Sistema de Administración Deportiva para la Universidad Central del

Ecuador, realiza únicamente la administración de la organización en los

5

juegos y/o campeonatos de las siguientes disciplinas deportivas: fútbol,

básquet y vóley.

b. El Sistema de Administración Deportiva para la Universidad Central del

Ecuador, únicamente realiza el seguimiento de los deportistas

registrados en el mencionado sistema.

c. El Sistema de Administración Deportiva para la Universidad Central del

Ecuador, entrega los reportes en formato PDF.

d. La aplicación no está diseñada para respaldar de forma automática la

base de datos por lo que se lo debe hacer de manera manual respetando

las políticas que tenga la institución para este tipo de procesos.

6

CAPÍTULO 2.

2. MARCO TEÓRICO

2.1. Antecedentes

El deporte hoy en día va de la mano con la tecnología y con el acceso a la

información de manera eficiente, de forma que se pueda aprovechar los

avances tecnológicos para automatizar los procesos deportivos que son

fundamentales en el trabajo diario de la Facultad de Cultura Física.

La Facultad de Cultura Física se encuentra en un proceso de renovación para

facilitar y mejorar el trabajo de los docentes, personal administrativo y dar un

mejor servicio a los estudiantes, motivo por el cual requieren estar a la

vanguardia de la tecnología y brindar nuevas herramientas tecnológicas que le

permitan estar a la altura de una Universidad de primer nivel.

2.2. Alcance

La propuesta de desarrollo, es la implementación de un Sistema de

Administración Deportiva para la Universidad Central del Ecuador, este sistema

está enfocado en la administración de la organización de los juegos y/o

campeonatos deportivos que realice la institución, además del seguimiento a los

deportistas de las diferentes facultades de la Universidad Central del Ecuador

que se registren en el mencionado sistema.

La información generada por el Sistema de Administración Deportiva para la

Universidad Central del Ecuador, será entregada por medio de informes en

formato PDF, los cuales serán el resultado de determinadas búsquedas, que se

originen de acuerdo a la necesidad del usuario del sistema.

Esta aplicación está dirigida a la Facultad de Cultura Física que es la

responsable de la organización de juegos y/o campeonatos de la Universidad

Central del Ecuador.

7

2.2. Análisis de herramientas

2.1.1. Plataforma

Para el desarrollo de la aplicación se adoptará una arquitectura de tres capas

JEE y como gestor de base de datos PostgreSQL.

Arquitectura JEE6 (Java Enterprise Edition)

Java Platform Enterprise Edition o JEE, es una plataforma que permite al

desarrollador de aplicaciones Web dedicarse al diseño e implementación del

sistema, dejando de lado aspectos de bajo nivel que ya los soluciona de

manera eficiente la arquitectura, JEE maneja N capas para realizar desarrollos

de software empresarial, para la construcción del Sistema de Administración

Deportiva para la Universidad Central del Ecuador, se utilizará tres capas

definidas que se enumeran a continuación (wikipedia, 2015).

1. Capa de presentación

2. Capa de Negocio

3. Capa de Datos

Figura 1. Arquitectura en Capas

Tomado de Global Mentoring, http://globalmentoring.com.mx/cursos-java/java-empresarial/

arquitectura-multicapas/

http://globalmentoring.com.mx/cursos-java/java-empresarial/

8

Capa de presentación

Se encuentra en el servidor Web y tiene la finalidad de mostrar al usuario final

la aplicación de manera amigable para que la aplicación sea comprensible y

fácil de utilizar, a continuación se detallan los componentes que se utilizan en la

capa de presentación:

Java Server Faces (JSF).- Es un Framework, una tecnología que

simplifica el desarrollo de las aplicaciones Java, permite dar una mejor

visualización de componentes a los usuarios finales.

Páginas XHTML.- Son ficheros que dan la opción de disponer las

propiedades de los componentes JSF.

Figura 2. Capa de presentación Tomado de jboss.org – Community Documentation, RichFaces Overview,

http://docs.jboss.org/richfaces/4.0.X/4.0.0.CR1/Developer_Guide/en-US/html/chap-

Developer_Guide-RichFaces_overview.html

9

Managed Beans.- O controladores, son clases java que permiten

controlar las páginas JSF, para invocar métodos que hacen funcionar a

los diferentes eventos que contienen las mencionadas páginas, también

proveen la información que se puede visualizar en los componentes

descritos con anterioridad.

Rich Faces.- Son librerías de componentes visuales, tiene un Framework

avanzado de integración con funcionalidades de Ajax, que permite hacer

las aplicaciones más amigables y fáciles de desarrollar.

Capa de negocio

Se encuentra en el servidor de aplicaciones y maneja el negocio de las

aplicaciones, los componentes de esta capa se mencionan a continuación:

Enterprise Java Beans (EJB).- Permiten asegurar las transacciones y la

integridad de la información, teniendo en cuenta que a la aplicación

acceden varios usuarios a la vez, la ejecución de cada método de un EJB

es una transacción, por lo que se puede manejar de forma óptima las

transacciones y se mantiene la integridad de la información.

Existen tres tipos de EJB:

Entity Bean.- Representan entidades, son persistentes y proveen

acceso a los datos.

Session Beans.- Sirven para procesar modelos de negocio, y son

accedidos de manera síncrona.

Message-driven Beans.- Sirven para modelar modelos de

negocios y pueden ser accedidos de manera asíncrona.

10

Capa de Datos

La capa de datos contempla el motor de base de datos que va a soportar la

gestión de los datos de la aplicación. Para el desarrollo del proyecto se ha

considerado PostgreSQL debido a la gran cantidad de beneficios que ofrece

incluyendo las prestaciones de su licencia de código abierto.

PostgreSQL.- “Es un sistema de gestión de bases de datos objeto-

relacional, distribuido bajo licencia BSD y con su código fuente disponible

libremente. Utiliza un modelo cliente/servidor y usa multiprocesos en vez

de multihilos para garantizar la estabilidad del sistema. Un fallo en uno de

los procesos no afectará el resto y el sistema continuará funcionando.”

(rafaelma, 2010)

Figura 3. Componentes de un sistema PostgreSQL Tomado de rafaelma, http://www.postgresql.org.es/sobre_postgresql

11

Las principales características de PostgreSQL son las siguientes

(rafaelma, 2010):

“Es una base de datos 100% ACID

Integridad referencial

Tablespaces

Nested transactions (savepoints)

Replicación asincrónica/sincrónica / Streaming replication - Hot

Standby

Copias de seguridad en caliente (Online/hot backups)

Unicode

Juegos de caracteres internacionales

Multiples métodos de autentificación

Disponible para Linux y UNIX en todas sus variantes (AIX, BSD,

HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64) y Windows 32/64bit.

Funciones/procedimientos

Numerosos tipos de datos y posibilidad de definir nuevos tipos.

Además de los tipos estándares en cualquier base de datos,

tenemos disponibles, entre otros, tipos geométricos, de

direcciones de red, de cadenas binarias, UUID, XML, matrices, etc

Soporta el almacenamiento de objetos binarios grandes (gráficos,

videos, sonido)”

JPA (Java Persistense API).- “Proporciona una modelo de persistencia

para facilitar el trabajo de los desarrolladores al gestionar el mapeo de los

objetos y sus relaciones” (Oracle, 2010)

Servidor de Aplicaciones

JBoss Enterprise Application Plataform es una plataforma intermedia construida

en base a estandares de código abierto y cuenta con compatibilidad para

compilar aplicaciones Java EE. Esta plataforma se encuentra integrada con el

servidor de aplicaciones JBoss 7 el cual ofrece capacidades de clustering, envío

de mensajes y otras tecnologías para crear una estable, escalable y rápida

12

plataforma. Además incluye APIs y frameworks de desarrollo que se utilizan

para desarrollar de forma más rápida aplicaciones Java EE seguras, robustas y

escalables.

Figura 4. Componentes de un sistema PostgreSQL Tomado de wn.com, JBoss AS7 - The Next Generation, http://article.wn.com

/view/2015/06/02/Qumu_announces_new_Developer_Portal_Qumu_Corporation/

Requerimientos de Desarrollo

Los requerimientos para el desarrollo de esta aplicación son los siguientes:

PC de 4 GB de memoria RAM

Procesador CORE i3 como mínimo.

HD de 50 GB de capacidad libres como mínimo.

Sistema operativo Windows 7

13

CAPÍTULO 3.

3. METODOLOGÍA DE DESARROLLO

3.1. Metodologías ágiles

Existen varias metodologías aplicables para el desarrollo de software. Algunas

de estas metodologías controlan el avance del proyecto estableciendo

actividades, herramientas y notaciones rígidas y orientadas a la documentación

que se genera en cada etapa del desarrollo. Este enfoque no resulta

conveniente para proyectos donde existe un entorno cambiante, y se debe

mantener la calidad del desarrolla a pesar de cambios en los tiempos de forma

drástica.

Las metodologías ágiles ofrecen algunas bondades que permiten llenar esos

vacíos metodológicos. Los objetivos de las metodologías ágiles destacan la

preferencia de algunos valores por ejemplo: “Individuos e interacciones, sobre

procesos y herramientas, software operativo, sobre documentación extensiva y

colaboración con el cliente, sobre negociación de contratos” (Bustamante &

Rodríguez, 2014).

3.2. Manifiesto ágil

“Según el Manifiesto se valora:

Al individuo y las interacciones del equipo de desarrollo sobre el

proceso y las herramientas. La gente es el principal factor de éxito de

un proyecto software. Es más importante construir un buen equipo que

construir el entorno. Muchas veces se comete el error de construir

primero el entorno y esperar que el equipo se adapte automáticamente.

Es mejor crear el equipo y que éste configure su propio entorno de

desarrollo en base a sus necesidades.

14

Desarrollar software que funciona más que conseguir una buena

documentación. La regla a seguir es “no producir documentos a menos

que sean necesarios de forma inmediata para tomar un decisión

importante”. Estos documentos deben ser cortos y centrarse en lo

fundamental.

La colaboración con el cliente más que la negociación de un

contrato. Se propone que exista una interacción constante entre el

cliente y el equipo de desarrollo. Esta colaboración entre ambos será la

que marque la marcha del proyecto y asegure su éxito.

Responder a los cambios más que seguir estrictamente un plan. La

habilidad de responder a los cambios que puedan surgir a los largo del

proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc.)

determina también el éxito o fracaso del mismo. Por lo tanto, la

planificación no debe ser estricta sino flexible y abierta.

Los valores anteriores inspiran los doce principios del manifiesto. Son

características que diferencian un proceso ágil de uno tradicional. Los dos

primeros principios son generales y resumen gran parte del espíritu ágil. El

resto tienen que ver con el proceso a seguir y con el equipo de desarrollo, en

cuanto metas a seguir y organización del mismo. Los principios son:

I. La prioridad es satisfacer al cliente mediante tempranas y continuas

entregas de software que le aporte un valor.

II. Dar la bienvenida a los cambios. Se capturan los cambios para que el

cliente tenga una ventaja competitiva.

III. Entregar frecuentemente software que funcione desde un par de

semanas a un par de meses, con el menor intervalo de tiempo posible

entre entregas.

IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo

largo del proyecto.

15

V. Construir el proyecto en torno a individuos motivados. Darles el

entorno y el apoyo que necesitan y confiar en ellos para conseguir

finalizar el trabajo.

VI. El diálogo cara a cara es el método más eficiente y efectivo para

comunicar información dentro de un equipo de desarrollo.

VII. El software que funciona es la medida principal de progreso.

VIII. Los procesos ágiles promueven un desarrollo sostenible. Los

promotores, desarrolladores y usuarios deberían ser capaces de

mantener una paz constante.

IX. La atención continua a la calidad técnica y al buen diseño mejora la

agilidad.

X. La simplicidad es esencial.

XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos

organizados por sí mismos.

XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a

ser más efectivo, y según esto ajusta su comportamiento” (Canós,

Letelier, & Penad).

3.3. Comparación de metodologías

Para un adecuado seguimiento y control del desarrollo de aplicaciones web es

necesario considerar la aplicación de una metodología. Actualmente existen

metodologías tradicionales, entre las más conocidas RUP y las metodologías

orientadas a un marco de trabajo ágil como lo es XP o SCRUM entre otras.

Existen varias consideraciones que debe analizar antes de seleccionar una

metodología con la finalidad de obtener mayor beneficio de su aplicación y no

convertirlo en un riesgo o impedimento para el avance en el desarrollo del

proyecto.

16

La tabla 1 muestra un resumen de la comparación realizada entre las

metodologías basadas en un modelo rígido y dirigidos por la documentación

que se debe generar de forma obligatoria en cada una de las etapas del

proyecto, frente a las metodologías basadas en un entorno ágil.

Tabla 1. Diferencias entre metodologías ágiles y no ágiles

Tomado de Grupo ISSI, Metodologías Ágiles en el Desarrollo de Software, 2003, p.4

Metodologías Ágiles Metodologías Tradicionales

Basadas en heurísticas provenientes de

prácticas de producción de código

Basadas en normas provenientes de

estándares seguidos por el entorno de

desarrollo

Especialmente preparados para cambios

durante el proyecto

Cierta resistencia a los cambios

Impuestas internamente (por el equipo) Impuestas externamente

Proceso menos controlado, con pocos

principios

Proceso mucho más controlado, con

numerosas políticas/normas

No existe contrato tradicional o al menos

es bastante flexible

Existe un contrato prefijado

El cliente es parte del equipo de

desarrollo

El cliente interactúa con el equipo de

desarrollo mediante reuniones

Grupos pequeños (<10 integrantes) y

trabajando en el mismo sitio

Grupos grandes y posiblemente

distribuidos

Pocos artefactos Más artefactos

Pocos roles Más roles

Menos énfasis en la arquitectura del

software

La arquitectura del software es esencial y

se expresa mediante modelos

Dados los recursos con los que cuenta el proyecto y los plazos establecidos es

evidente que será de mayor beneficio para el desarrollo del software la

17

aplicación de una metodología ágil pues asegurará la participación del personal

de la Facultad de Cultura Física y facilitará el levantamiento de requerimiento al

igual que el desarrollo de las pruebas funcionales previo a la puesta en

producción del sistema.

Figura 5. Comparación de métodologías Tomado de Joskowicz José, Reglas y Prácticas en eXtreme Programming, 2008, p. 8.

3.4. Programación Extrema (XP)

“XP es una metodología ágil para pequeños y medianos equipos, desarrollando

software cuando los requerimientos son rápidamente cambiantes. A diferencia

de los procesos tradicionales para desarrollar software, XP asume el cambio

como algo natural, y que, puede suceder en alguna etapa del proyecto. En XP

se realiza el software que el cliente solicita y necesita, en el momento que lo

precisa, alentando a los programadores a responder a los requerimientos

cambiantes que plantea el cliente en cualquier momento. Esto es posible

porque está diseñado para adaptarse en forma inmediata a los cambios, con

bajos costos asociados, en cualquier etapa del ciclo de vida” (Calabria & Píriz,

2003).

3.4.1. Valores de XP

Los principios y valores en los que se fundamenta XP son los siguientes:

18

Comunicación.- Es uno de los valores más importantes para cumplir con cada

uno de los objetivos del proyecto. Cada una de las fases del proyecto requiere

que el equipo mantenga una buena comunicación, esto desde el

establecimiento de la planificación hasta la finalización y entrega del proyecto.

Mantener una buena comunicación con el cliente es crítico para el proyecto por

esa razón es necesario que el cliente este integrado al equipo. Una buena

comunicación ayuda a realizar solo la documentación necesaria.

Simplicidad.- XP propone apunta al desarrollo simplificado, es decir, enfoca los

esfuerzos en el desarrollo funcionalidades que aportan valor al negocio y

disminuye la prioridad sobre requerimiento complejos que aportan poco valor o

que por el momento no son necesarios. Como parte de la simplicidad XP

propone la aplicación de refactoring “que permite mantener el código en

funcionamiento pero mucho más simple y organizado” (Calabria & Píriz, 2003).

Retroalimentación.- Un adecuado feedback ayuda a mejorar la comunicación en

cada una de las fases del proyecto y a mantener informado al equipo sobre el

estado del proyecto.

Coraje.- “El coraje permite realizar cambios cuando algo no funciona del todo

bien, diseñar e implementar solo lo necesario para el presente, pedir ayuda o

reducir el alcance de una entrega si el tiempo no alcanza. Si no hay coraje en

un proyecto no se puede clasificar como extremo” (Calabria & Píriz, 2003).

3.4.2. Principios de XP

Los principios de XP permiten establecer buenas prácticas al momento de

aplicar la metodología sobre el desarrollo del proyecto. Los principios de XP

son:

Rápida retroalimentación.- asimilar los cambios de forma más rápida.

Asumir la simplicidad.- resolver las necesidades actuales y confiar en contar

con las habilidades para resolver problemas más complejos a futuro.

19

Cambios incrementales.- atacar los problemas dividiéndolos en pequeños

requerimientos con la finalidad de analizarlo a profundidad.

Aceptar el cambio.- asimilar el cambio en XP es algo habitual, se debe

mantener varias opciones para solucionar los problemas de forma más rápida.

Trabajo de calidad.- cada uno de los miembros del equipo debe cumplir sus

actividades de la mejor manera lo cual eleva la calidad del producto final.

3.4.3. Ciclo de vida de XP

XP cuenta con seis fases para el desarrollo de aplicaciones:

Figura 6. Ciclo de vida de XP Tomado de Calabria Luis, Píriz Pablo, Metodología XP, 2003, p.12

Exploración

“En esta fase se define el alcance general del proyecto. El cliente describe sus

necesidades mediante la redacción de sencillas “historias de usuario”. Los

programadores estiman los tiempos de desarrollo en base a esta información.

Debe quedar claro que las estimaciones realizadas en esta fase son primarias

(ya que estarán basadas en datos de muy alto nivel), y podrían variar cuando se

analicen más en detalle en cada iteración. Esta fase dura típicamente un par de

20

semanas, y el resultado es una visión general del sistema, y un plazo total

estimado” (Joskowicz , 2008).

Planificación

“Esta es una fase corta, el cliente, los gerentes y el grupo de desarrolladores

acuerdan el orden en que deberán implementarse las historias de usuario, y,

asociadas a éstas, las entregas. Típicamente esta fase consiste en una o varias

reuniones grupales de planificación. El resultado de esta fase es un Plan de

Entregas” (Joskowicz , 2008).

Iteraciones por entregas

“Esta es la fase principal en el ciclo de desarrollo de XP. Las funcionalidades

son desarrolladas en esta fase, generando al final de cada una un entregable

funcional que implementa las historias de usuario asignadas a la iteración.

Como las historias de usuario no tienen suficiente detalle como para permitir su

análisis y desarrollo, al principio de cada iteración se realizan las tareas

necesarias de análisis, recabando con el cliente todos los datos que sean

necesarios. El cliente, por lo tanto, también debe participar activamente durante

esta fase del ciclo. Las iteraciones son también utilizadas para medir el

progreso del proyecto. Una iteración terminada sin errores es una medida clara

de avance” (Joskowicz , 2008).

Producción

En esta fase de debe realizar las pruebas funcionales antes que el sistema sea

entregado al cliente; generalmente aparecen nuevos requerimiento y cambios

que deben ser priorizados para validar su inclusión dentro del alcance inicial del

proyecto o se dejarán como requerimientos para la fase de mantenimiento. Las

iteraciones en esta etapa se suelen reducir de tres semanas a una.

21

Mantenimiento

En esta fase los programadores deben dedicar más esfuerzo al proyecto con la

finalidad de satisfacer los requerimientos del cliente. Generalmente la velicidad

de desarrollo disminuye en esta etapa.

Muerte

Es la última fase y se puede decir que inicia cuando el cliente ya no cuenta con

historias de usuario para ser implementadas. Aquí se prioriza aspectos como la

mejora del rendimiento y la confiabilidad. Durante esta etapa es un buen

momento para realizar la documentación del proyecto.

3.5. Roles y Responsabilidades

La metodología XP establece algunos roles que se deben considerar en la

conformación del equipo del proyecto.

Cliente.- Es quien establece los requerimientos del sistema y el nivel de

importancia de los mismos, de modo que se determina cuando deberá

implementarse. El cliente escribe las Historias de Usuario y los test funcionales.

Coach.- Asegura el cumplimiento de las prácticas de la metodología a través de

sus conocimientos y compartiendo sus experiencias a los demás miembros del

equipo.

Consultant.- Es una persona externa al equipo que posee conocimientos

técnicos para apoyar en la solución de ciertos problemas.

Manager.- Es el responsable de la toma de decisiones en el equipo además de

mantener comunicado al equipo respecto al avance del proyecto y distinguir

cualquier dificultad durante el desarrollo para poder solucionarlo.

Programador.- Es el responsable del desarrollo del sistema, incluyendo los test

del mismo.

22

Tester.- Los tester ayudan al cliente en la redacción de los test funcionales del

sistema. Son los responsables de la ejecución de los test y de notificar al equipo

los resultados de los mismos.

Tracker.- Es el responsable de medir el progreso del proyecto y comparar los

resultados con las estimaciones realizadas. Además observa el desempeño del

equipo enfatizando el cumplimiento de plazos y validando una adecuada

gestión de cambio.

3.6. Aplicación de metodología

3.7. Exploración

Durante la fase de exploración se ha realizado la inducción al equipo del

negocio sobre la metodología de desarrollo que se va a aplicar para el

desarrollo del proyecto; además se ha acordado la colaboración en la

construcción de Historias de Usuario, priorización de las historias, validación de

requerimientos y pruebas funcionales previas a la entrega del proyecto.

En esta fase debido a la dificultad de trabajar directamente con el equipo de la

Facultad de Cultura Física se ha establecido un modelo de trabajo basado en

reuniones quincenales para la revisión de historias y del estado del proyecto.

La tabla 2 muestra el resumen de las historias de usuario levantadas con el

equipo de la Facultad de Cultura Física:

Tabla 2. Historias de Usuario

No. Nombre (Historia de Usuario)

1 Autenticación de usuarios

2 Administración de jugadores

3 Administración de árbitros

23

4 Administración de canchas

5 Administración de equipos

6 Administración de campeonatos

7 Registro de resultados de los partidos

8 Generación de partidos

9 Administración de catálogos

10 Programación de fechas y horarios

11 Conformación de equipos

12 Envió de e-mail con información de Campeonatos

13 Administración y seguimiento de deportistas

14 Reportes de fechas de juego

15 Reporte de máximos anotadores

16 Reporte de resultados de partidos

17 Reporte de tabla de posiciones

18 Generación de carnets de jugadores

19 Reporte de lesionados

20 Reporte de amonestados

21 Autenticación de usuarios

22 Diseño de interfaz

24

Para revisar el detalle de las historias de usuario construidas ver ANEXO 1.

En primera instancia el cliente ha identificado 22 historias de usuario donde ha

plasmado los principales requerimientos que necesita para solventar las

complicaciones que actualmente el proceso de administración de los

campeonatos está presentando al llevarse a cabo de forma manual.

Cada una de las historias descritas será analizada y priorizada en la fase de

planificación para ser distribuidas entre las tres iteraciones previstas para el

desarrollo del proyecto.

3.8. Planificación del proyecto

Figura 7. Fase de Planificación

En esta etapa se detalla la planificación establecida para el desarrollo del

proyecto junto con cada uno de los requerimientos solicitados, incidencias

presentadas y los diarios e actividades de cada uno de los miembros del

equipo.

Planificación

Planificación Inicial

Iteración 1

Iteración 2

Iteración 3Diario de actividades

25

3.8.1. Planificación Inicial

En esta etapa se establecen los integrantes del equipo y sus roles, además se

priorizan las historias de usuario según el nivel de importancia y el orden en el

que el cliente desea que sean implementadas.

Igualmente por parte del equipo técnico se establece el nivel de complejidad de

modo que se puedan cumplir las iteraciones en los plazos establecidos.

3.8.2. Integrantes del equipo

Debido a que el presente desarrollo constituye el proyecto previo al proceso de

titulación para la carrera de Ingeniería Informática de la Universidad Central del

Ecuador no es factible constituir un equipo con varios miembros que cumplan

cada uno de los roles establecidos en la metodología de desarrollo XP; ante

esta restricción se ha distribuido los roles de la siguiente manera:

Tabla 3. Integrantes y roles del equipo

Miembro Rol Grupo Metodología


Manager

Programador

Tester y Tracker

Técnico

XP

Magister Efrén Palacios Cliente

Negocio

(Facultad de

Cultura Física)

3.8.3. Prototipos

La construcción de prototipos es una buena práctica que ayuda a presentar de

forma visual el requerimiento del usuario y permite afinar los criterios de las

historias de usuario.

A continuación se muestran los prototipos de cada uno de los requerimientos de

usuario:

26

Autenticación de usuarios

Figura 8. Prototipo de autenticación

Todos los funcionarios, jugadores y demás personas que requieran acceder al

sistema deberán contar con un usuario y una clave que deberán ingresar

previamente en la pantalla de autenticación.

Administración de equipos

Figura 9. Prototipo de administración de equipos

27

Para los funcionarios con permisos requeridos, el sistema permitirá crear,

actualizar y eliminar equipos de fútbol, básquet y vóley.

Administración de Catálogos

Figura 10. Prototipo de administración de catálogos

El sistema contará con catálogos de parametrización general, los usuarios que

tengan los permisos requeridos podrán actualizar los valores de los mismos.

Administración de detalle de catálogos

Figura 11. Prototipo de administración de detalle de catálogos

28

El sistema contará con detalle de catálogos, los mismos que tendrán la

información detallada de los catálogos generales, los usuarios que tengan

permisos podrán crear, actualizar y eliminar estos detalles de catálogo.

Administración de deportistas y árbitros

Figura 12. Prototipo de administración de deportistas y árbitros

Los usuarios que cuenten con los permisos requeridos podrán realizar el

registro, edición y eliminación de personas en el sistema, las mismas que serán

catalogadas como Estudiantes, Profesores, Docentes o Árbitros.

29

Administración de jugadores por equipo

Figura 13. Prototipo de jugadores por equipo

Los usuarios que tengan los permisos necesarios podrán parametrizar el

número máximo y mínimo de jugadores, que se podrán inscribir en cada una de

las disciplinas deportivas contempladas dentro del sistema.

Conformación de equipos

Figura 14. Prototipo de conformación de equipos

30

Los usuarios que posean los permisos necesarios para conformar equipos,

tendrán que seleccionar a los deportistas de una lista e ir agregandolos a los

diferentes equipos que estén registrados en el sistema, de esta forma se

conformarán los equipos con sus respectivos jugadores.

Campeonatos

Figura 15. Prototipo de campeonatos

Los usuarios que posean los permisos requeridos para crear campeonatos,

tendrán que registrar los parámetros básicos del campeonato e ir agregando los

equipos al mismo para conformar de manera correcta un torneo.

31

Asignación de fechas

Figura 16. Prototipo de visualización de fechas asignadas

Figura 17. Prototipo de asignación de fechas

Los usuarios que posean los permisos necesarios para acceder a la asignación

de fechas podrán ver todos los encuentros generados de un campeonato y de

forma individual deberán asignar fecha y hora a los encuentros mencionados.

32

Administración de canchas

Figura 18. Prototipo de administración de canchas

Los usuarios que cuenten con los permisos necesarios podrán crear, actualizar

o eliminar las canchas para las diferentes disciplinas deportivas contempladas

en el sistema.

Reportes

Tabla de Posiciones

En el reporte de tablas de posiciones se visualizará la siguiente información:

Nombre del campeonato

Tipo de deporte

Nombres de los equipos

Número de partidos jugados

Número de partidos ganados

Número de partidos empatados

Número de partidos perdidos

Número de anotaciones a favor (Sólo fútbol y básquet)

33

Número de anotaciones en contra (Sólo fútbol y básquet)

Número de puntos

Máximos anotadores

En el reporte de máximos anotadores, se mostrará la siguiente información:


Nombres y Apellidos del jugador

Equipo al que pertenece el jugador

Número de anotaciones registradas

Lesionados

En el reporte de lesionados se podrá visualizar la siguiente información:

Nombre de campeonato

Tipo de deporte

Equipo a que pertenece

Nombres y apellidos del jugador

Descripción de la lesión

Amonestados

En el reporte de amonestados se visualizará la siguiente información:


Tipo de deporte



Tipo de amonestación

Seguimiento de jugadores

En el reporte para el seguimiento de jugadores se podrá observar la siguiente

información:

34

Datos generales del jugador

Equipos en los que ha jugado

Campeonatos en los que ha participado

Número de goles por campeonato

Número de amonestaciones sancionadas por campeonato

Número de expulsiones por campeonato

Lesiones

Administración de usuarios

Figura 19. Prototipo de administración de usuarios

La administración de usuarios permitirá actualizar y generar nuevos usuarios

para que tengan acceso al sistema, el administrador otorgará los permisos

requeridos para que puedan acceder a los diferentes módulos de la aplicación.

35

Administración de roles

Figura 20. Prototipo de administración de roles

Los usuarios que cuenten con los permisos necesarios podrán administrar los

roles del sistema y asignar a cada uno de estos los diferentes accesos y

permisos para utilizar la aplicación.

3.8.4. Priorización de Historias de Usuario

De acuerdo a las historias de usuario desarrolladas en la fase de exploración y

la priorización del cliente se ha establecido en la siguiente tabla la distribución

de historias por iteración:

Tabla 4. Priorización y distribución de Historias de Usuario

No. Nombre Prioridad Riesgo Esfuerzo Iteración

1 Administración de usuarios Alta Alto 5 2

2 Administración de jugadores Alta Bajo 3 1

3 Administración de árbitros Media Bajo 2 1

4 Administración de canchas Alta Bajo 2 1

36

5 Administración de equipos Alta Medio 4 1

6 Administración de campeonatos Alta Medio 5 2

7 Registro de resultados de los

partidos

Media Medio 8 2

8 Generación de partidos Media Bajo 5 2

9 Administración de catálogos Alta Alto 4 1

10 Programación de fechas y

horarios

Media Medio 3 2

11 Conformación de equipos Media Medio 3 2

12 Envió de e-mail con información

de Campeonatos

Baja Alto 3 3

13 Administración y seguimiento de

deportistas

Media Alto 4 3

14 Reportes de fechas de juego Media Medio 3 3

15 Reporte de máximos

anotadores

Baja Medio 3 3

16 Reporte de resultados de

partidos

Media Medio 3 3

17 Reporte de tabla de posiciones Baja Medio 3 3

18 Generación de carnets de

jugadores

Baja Bajo 4 3

19 Reporte de lesionados Baja Medio 3 3

20 Reporte de amonestados Baja Medio 3 3

37

21 Autenticación de Usuarios Alta Alta 5 1

22 Diseño de interfaz Media Bajo 6 1

Además de la priorización y distribución de las historias de usuario se ha

identificado el nivel de riesgo que tiene la implementación del requerimiento

considerando los niveles, Alto, Medio, Bajo, y la valoración del esfuerzo que

deberá dedicar el desarrollador.

El desarrollo del sistema se ha dividido en tres iteraciones debido a la cantidad

de requerimientos y al tiempo con el que se cuenta para la entrega del proyecto

de titulación; La priorización realizada por el usuario ha proporcionado la

información necesaria para distribuir las historias dentro de las 3 iteraciones

previstas, considerando el orden otorgado por el usuario y el nivel de prioridad

Alto como los requerimientos más urgentes.

La valoración del esfuerzo permite determinar los puntos que costará cada una

de las iteraciones, además de mantener alerta al equipo del proyecto en caso

de que existan dificultades en el cumplimiento de los plazos y se pueda ejecutar

cambios es las iteraciones siguientes para cumplir con todos los requerimientos

priorizados por el cliente.

3.8.5. Plan de entrega

El plan de entrega o Release Planning contiene los plazos de entrega de cada

uno de los “mini-productos” generados en cada iteración.

El desarrollo del sistema contempla la programación de 3 iteraciones previa a la

entrega formal del producto solicitado.

Cada una de las iteraciones cuenta con un número de historias y puntos que

cubrir en un plazo previamente establecido. Los avances de cada una de las

historias son verificados periódicamente por el usuario y de ser necesario es

posible la modificación de los requerimientos o el cambio de la prioridad de la

38

misma, además, de la posibilidad de reportar incidencias respecto al

incumplimiento de los criterios detallados por el usuario en cada una de las

historias de la iteración.

La valoración del producto generado en cada iteración se realiza a través de la

presentación de un demo, donde se muestra las nuevas funcionalidades

desarrolladas.

3.8.6. Iteración 1

La iteración 1 pretende cubrir las funcionalidades de administración,

autenticación de usuarios y diseño de interfaz del sistema.

Las historias priorizadas permitirán cubrir los siguientes requerimientos:

Gestionar el registro, edición y demás acciones solicitadas por el usuario

sobre los jugadores, árbitros, canchas, equipos, catálogos.

Acceso al sistema previa autenticación a través de un usuario y

contraseña.

Diseño de la interfaz del sistema (estilos, menú, estructura de las

páginas).

Los resultados de esta iteración facilitarán el desarrollo de las funcionalidades

priorizadas para la iteración 2.

La tabla 5 muestra la planificación de las historias priorizadas para esta

iteración:

Tabla 5. Historias de Usuario a implementar en la Iteración 1

No. Nombre Esfuerzo Fecha de entrega

2 Administración de jugadores 3 17/12/2014

39

3 Administración de árbitros 2 17/12/2014

4 Administración de canchas 2 17/12/2014

5 Administración de equipos 4 17/12/2014

9 Administración de catálogos 4 15/12/2014

21 Autenticación de Usuarios 5 15/12/2014

22 Diseño de interfaz 6 15/12/2014

Plazo

La iteración 1 ha comprometido 26 puntos de esfuerzo que deberán ser

cubiertos en un plazo de 4 semanas para entregar los productos de la iteración.

El esfuerzo se ha medido en base a la complejidad y el tiempo estimado para el

desarrollo de las siete historias de usuario priorizadas para esta iteración. La

figura a continuación muestra la distribución de las tareas en el tiempo de

acuerdo a su nivel de prioridad.

Figura 21. Distribución de Historias Iteración 1

40

Existen requerimientos que podrán ser desarrollados de forma paralela debido a

la coincidencia en las tareas identificadas para cada historia de usuario. Por

cada una de las historias de usuarios se ha identificado las tareas que ayudarán

a cubrir el requerimiento, ver ANEXO 2. A continuación se muestra el resumen

de las tareas identificadas:

Tabla 6. Historias de Usuario: Diseño de interfaz

Descripción:

Se requiere la estructuración y desarrollo de la interfaz del sistema, se

tomar en cuenta las siguientes consideraciones:

Diseño de menú desplegable en base a la distribución de las

opciones establecidas por el usuario

Colores y tipo de letra en base a los requerimientos del usuario

Puntos: 6

No. Tarea Puntos Fecha Inicio Fecha Fin

29 Configuración de componentes JEE6 6 27/10/2014 14/11/2014

Tabla 7. Historias de Usuario: Administración de catálogos

Descripción:

Como usuario Administrador de Campeonatos, se requiere administrar

los parámetros generales del sistema, los catálogos que se deben

manejar son los siguientes:

Facultades

Estado Civil

Colores

Canchas de Juego

Fases de Juego (IDA, VUELTA)

En cada uno de los catálogos anteriormente descritos el usuario

únicamente puede editar el nombre de los mismos.

Para la administración del detalle de los catálogos generales del sistema,

Puntos: 4

41

el usuario administrador de campeonatos podrá crear, actualizar y

eliminar los siguientes registros

Descripción

Detalle

Además el usuario deberá administrar el catálogo de:

Jugadores por Equipo

Este catálogo brinda la facilidad de parametrizar el mínimo y máximo

número de jugadores que podrán tener los equipos de fútbol, básquet o

vóley, se podrá actualizar los registros de mínimo y máximo de

jugadores.


6 Administración de catálogos generales 4 24/11/2014 15/12/2014

Tabla 8. Historias de Usuario: Administración de canchas

Descripción:

El usuario administrador de campeonatos puede gestionar las canchas

deportivas que se registran en el sistema, los datos que se deben

guardar de una cancha deportiva son los siguientes:

Nombre

Descripción

Tipo de deporte (Fútbol, Básquet o Vóley)

Puntos: 2


4 Parametrización de canchas de juego 2 01/12/2014 08/12/2014

Tabla 9. Historias de Usuario: Administración de equipos

Descripción:

Como usuario administrador de campeonatos se requiere el registro,

edición y eliminación de equipos:

Para el registro se debe considerar los siguientes campos:

Nombre

Color principal

Puntos: 4

42

Color secundario

Tipo de deporte

Fecha de inscripción

Para la edición se debe considerar todos los campos mencionados a

excepción de la Fecha de inscripción.

El tipo de deporte se deberá mostrar en una lista permitiendo seleccionar

solo una categoría.

Tanto el Color principal como el Color secundario deberán ser

seleccionados de una lista


5 Administración Equipos 4 09/12/2014 15/12/2014

Tabla 10. Historias de Usuario: Administración de jugadores

Descripción:

Como usuario Administrador del sistema se requiere gestionar los

deportistas registrados.

Para el registro y edición de deportistas se deben tomar en cuenta los

siguientes campos:

Número de identificación (cédula, pasaporte)

Apellidos y nombres

Fecha de nacimiento

Tipo de deportista (Estudiante, Docente, Árbitro, Administrativo)

Facultad a la que pertenece

Números de contacto (convencional, celular)

Dirección del domicilio

Puntos: 3


1 Diseño de base de datos 1 17/11/2014 21/11/2014

2 Administración de deportistas 2 30/11/2014 17/12/2014

Tabla 11. Historias de Usuario: Administración de árbitros

43

Descripción:

El usuario administrador de campeonatos tiene acceso para administrar

a los árbitros registrados en el sistema los campos que se deben

registrar o editar son los siguientes:


Apellidos y nombres

Fecha de nacimiento





Puntos: 2


3 Parametrización de árbitros 2 30/11/2014 17/12/2014

Tabla 12. Historias de Usuario: Autenticación de Usuarios

Descripción:

Los usuarios deberán ser notificados por el Administrador del sistema

respecto a los permisos de acceso al sistema.

Puntos: 5


7 Configuración en la base de datos 3 24/11/2014 7/12/2014

30 Desarrollo de funcionalidad 2 7/12/2014 15/12/2014

Gestión de cambios

Durante la iteración 1 no se presentaron solicitudes de cambio respecto a la

prioridad de las historias de usuario.

La planificación de la iteración 1 se mantuvo hasta la presentación de los

resultados, por lo que no se presentó la necesidad de mover historias a las

siguientes iteraciones.

Los cambios solicitados por el usuario se enmarcaron en aspectos de

visualización de los datos en pantalla y orden de los componentes.

44

Pruebas de aceptación

Las pruebas de aceptación muestran los resultados de las validaciones

realizadas con el usuario durante y después del desarrollo de una historia de

usuario.

A continuación se describe las pruebas realizadas:

Tabla 13. Pruebas de aceptación por historia de usuario

Historia Prueba Resultado

Historia 2 Creación y edición de deportistas Deportistas creados y actualizados de manera exitosa

Historia 3 Creación y edición de árbitros Árbitros creados y actualizados de forma exitosa

Historia 4 Creación y administración de canchas de futbol, básquet y vóley

Creación y edición de canchas realizada con éxito

Historia 5 Creación y edición de nuevos equipos de todos los deportes

Equipos actualizados y creados de forma exitosa

Historia 9 Actualización de catálogos generales y creación y edición de detalles de catálogos

Operaciones ejecutadas de manera exitosa

Historia 21 Pruebas de autenticación de diferentes usuarios

Pruebas realizadas de manera exitosa

Historia 22 Levantamiento del proyecto base para el desarrollo del sistema

Proyecto generado de manera exitosa

3.8.7. Iteración 2

La iteración 2 pretende cubrir algunas funcionalidades de administración que no

se priorizaron para la iteración 1 y las funcionalidades para la gestión y

administración de campeonatos.


Administrar el registro de usuarios.

45

Conformar equipos, gestionar partidos, programar fechas y horarios.

Administrar la creación de campeonatos para cada uno de los tipos de

deportes considerados en el alcance del proyecto.

Los resultados de esta iteración permitirán consolidar la información necesaria

para la generación de reportes cuyo desarrollo ha sido priorizado para la

iteración 3.


iteración:



1 Administración de usuarios 5 09/03/2015

6 Administración de campeonatos 8 13/03/2015

7 Registro de resultados de los partidos 8 13/03/2015

8 Generación de partidos 5 13/03/2015

10 Programación de fechas y horarios 3 13/03/2015

11 Conformación de equipos 3 13/03/2015

Plazo


cubiertos en un plazo de 12 semanas para entregar los productos de la

iteración.

46


desarrollo de las seis historias de usuario priorizadas para esta iteración. La





la coincidencia en las tareas identificadas para cada historia de usuario. A

continuación se muestra el resumen de las tareas identificadas por cada historia

de usuario:

Tabla 15. Historias de Usuario: Conformación de equipos

Descripción:

El usuario administrador de partidos podrá realizar la conformación de

los equipos que participen en un campeonato, tendrá que seleccionar a

los deportistas registrados y ubicarlos en el equipo correspondiente,

tomando en cuenta el número mínimo y máximo de jugadores que puede

tener de acuerdo al deporte que seleccione.

Puntos: 3


16 Conformación de Equipos 2 21/02/2015 13/03/2015

47

17 Validación de deportistas en Equipos 1 01/03/2015 13/03/2015

Tabla 16. Historias de Usuario: Generación de partidos

Descripción:

El usuario administrador, podrá generar los encuentros entre todos los

equipos que conforman un campeonato, el sistema debe realizar el

emparejamiento de todos los participantes y debe generar el número de

partidos para formar el campeonato.

Puntos: 5


14 Algoritmos de clasificación de partidos 2 28/12/2014 10/01/2015

Tabla 17. Historias de Usuario: Programación de fechas y horarios

Descripción:

El usuario administrador de partidos, puede programar las fechas y

horarios de todos los encuentros de un campeonato.

Para realizar esta tarea, debe seleccionar de una lista la cancha y el

nombre del árbitro, para el registro del tiempo de juego, el administrador

de partidos deberá registrar la fecha y hora del inicio y finalización del

encuentro.

Puntos: 3


15 Programación de encuentros 3 25/02/2015 03/03/2013

Tabla 18. Historias de Usuario: Administración de campeonatos

Descripción:

Como usuario administrador de campeonatos se requiere la creación de

campeonatos.

Para la creación se debe considerar los siguientes campos:

Nombre

Tipo de campeonato

Tipo de deporte

Puntos: 8

48

El nombre deberá ser registrado en un campo de texto

El Tipo de campeonato al igual que el Tipo de deporte deberá ser

seleccionado de una lista previamente provista a través de la

Administración de catálogos del sistema.

Para mantener el histórico de los datos se debe considerar un campo de

estado que permitirá mostrar los datos del campeonato


10 Administración de Campeonatos 8 28/12/2014 20/02/2015

Tabla 19. Historias de Usuario: Registro de resultados de los partidos

Descripción:

Como usuario Administrador de campeonatos se requiere el registro de

los resultados de los partidos celebrados durante un campeonato.

Los campos que se deben considerar son los siguientes:


Fecha

Partido

Equipos

Jugadores

Anotaciones

Amonestaciones

Expulsados

El nombre del campeonato, la fecha, el partido serán seleccionados de

una lista, y se permitirá la selección de un solo campo

Puntos: 8


11 Resultados de partidos de fútbol 3 13/02/2015 23/02/2015

12 Resultados de partidos de básquet 3 23/02/2015 01/03/2015

13 Resultados de partidos de vóley 2 23/02/2015 03/03/2015

49

Tabla 20. Historias de Usuario: Administración de usuarios

Descripción:

Como usuario administrador se requiere administrar el registro,

activación y desactivación de usuarios del sistema.

Los campos que se deben registrar son los siguientes:

Nombre

Cédula de identidad

Unidad

Correo electrónico

Usuario

Estado

Para la búsqueda de usuarios se requiere contar con 2 opciones: Cédula

y Nombre. Los resultados deberán mostrarse en una lista que muestre la

opción para editar el registro. Todos los campos indicados son editables.

A todos los usuarios creados se les asignará una clave mismas que

deberá ser enviada por correo al usuario creado.

El usuario contará con la opción para modificar su clave desde el

sistema.

Puntos: 5


9 Administración de usuarios 5 23/02/2015 09/03/2015

Gestión de Cambios

Durante el desarrollo de la iteración 2 se presentaron dos requerimientos

para cambiar el orden de desarrollo y los puntos estimados para esfuerzo de

las siguientes historias:

Administración de campeonatos, se cambió de prioridad 5 a 8 y se

movió su desarrollo antes de la historia de usuario “Administración de

usuarios”.

50

Administración de Usuarios, se cambió de prioridad 8 a 5 y se dejó la

historia usuario para desarrollarse al final de la iteración.


resultados, por lo que no fue necesario mover historias a la siguiente

iteración.

Los cambios solicitados por el usuario en esta iteración fueron los

siguientes:

Cambio de prioridad de las historias de usuario

Cambios en los criterios de la historia de usuario Registro de

resultados:

o Se requiere que los resultados de los partidos se registren a

través de una misma pantalla.

Cambios de visualización y orden de los objetos en pantalla.




usuario.




Historia 1 Creación y edición de nuevos usuarios para el sistema

Operaciones ejecutadas con éxito

Historia 6 Creación de campeonatos de fútbol, básquet y vóley.

Campeonatos creados de manera exitosa

Historia 7 Se registra el resultado de una partido de fútbol para alimentar a los diferente reportes

Registro de partido almacenado con éxito

51

Historia 8 Se realiza la generación de partidos de un campeonato de 9 equipos

Generación exitosa de los encuentros por equipo

Historia 10 Se registran las fechas y horarios para los partidos de la fecha uno de un campeonato de futbol

Programación de fechas realizada con éxito

Historia 11 Se conforma un equipo de básquet con el máximo número de jugadores

Conformación realizada con éxito

3.8.8. Iteración 3

En la iteración 3 se ha priorizado el desarrollo de los reportes del sistema al

igual que la configuración de envío de correos electrónicos, el seguimiento de

deportistas y la generación de las plantillas para los carnets de los jugadores.


Imprimir la plantilla de carnet para los jugadores.

Envío de correos para informar sobre los campeonatos.

Visualización de información a través de reportes en formato PDF.

Luego de finalizar el desarrollo de la iteración 3 se procederá con las pruebas

funcionales para validar el correcto funcionamiento de todo el sistema.


iteración:



12 Envió de e-mail con información de

Campeonatos 3 03/07/2015

52

13 Administración y seguimiento de deportistas 4 25/06/2015

14 Reportes de fechas de juego 3 29/06/2015

15 Reporte de máximos anotadores 3 03/07/2015

16 Reporte de resultados de partidos 3 03/07/2015

17 Reporte de tabla de posiciones 3 29/06/2015

18 Generación de carnets de jugadores 4 25/06/2015

19 Reporte de lesionados 3 03/07/2015

20 Reporte de amonestados 3 03/07/2015

Plazo


cubiertos en un plazo de 16 semanas para entregar los productos de la

iteración.


desarrollo de las nueve historias de usuario priorizadas para esta iteración. La



53



la coincidencia en las tareas identificadas para cada historia de usuario. Por

cada una de las historias de usuarios se ha identificado las tareas que ayudarán

a cubrir el requerimiento, ver ANEXO 2. A continuación se muestra el resumen

de las tareas identificadas:

Tabla 23. Historias de Usuario: Envió de e-mail con información de Campeonatos

Descripción:

El usuario administrador de campeonatos podrá enviar vía e-mail el

resultado de los partidos, tabla de posiciones y principales estadísticas

de los encuentros disputados en un campeonato, a cada uno de los

jugadores involucrados en dicho certamen.

Puntos: 3


1 Configuración de correos electrónicos 2 15/03/2015 31/03/2015

2 Envío de correos electrónicos 1 19/03/2015 31/03/2015

54

Tabla 24. Historias de Usuario: Administración y seguimiento de deportistas

Descripción:

Todos los usuarios, podrán consultar mediante el número de cédula o

nombres y apellidos, la información relevante de los jugadores, los datos

que se publicarán se describen a continuación:

Datos Generales






Lesiones

Puntos: 4


1 Seguimiento de deportistas 4 31/03/2015 06/04/2015

Tabla 25. Historias de Usuario: Reportes de fechas de juego

Descripción:

Todos los usuarios, podrán consultar los partidos y las fechas de juego

programadas en el campeonato, la información que se visualizará se

describe a continuación:

Nombre campeonato

Tipo de deporte

Número de equipos participantes

Fechas y horarios de los encuentros

Para que los usuarios tengan una mejor visualización de la información

requerida, se dispondrá de un filtro por equipo participante.

Puntos: 3


1 Reporte de fechas de juego 3 06/04/2015 18/04/2015

55

Tabla 26. Historias de Usuario: Reporte de máximos anotadores

Descripción:

Todos los usuarios, podrán ver la información de los quince máximos

anotadores de cada campeonato de fútbol o básquet, los datos que se

presentarán se describen a continuación:





Puntos: 3


1 Reporte de máximos anotadores 3 23/04/2015 30/04/2015

Tabla 27. Historias de Usuario: Reporte de resultados de partidos

Descripción:

Todos los usuarios, podrán ver el resultado de los partidos que se llevan

a cabo dentro de un campeonato, la información que se presentará se

describe a continuación:


Nombre de los equipos

Numero de anotaciones por equipo

Nombres de los jugadores que anotaron de cada equipo

Nombres de los jugadores amonestados de cada equipo

Nombres de los jugadores expulsados de cada equipo

Nombres de los jugadores lesionados de cada equipo

Nombre del árbitro

Nombre de la cancha

Puntos: 3


1 Reporte de resultados de partidos 3 01/05/2015 15/05/2015

56

Tabla 28. Historias de Usuario: Reporte de tabla de posiciones

Descripción:

Todos los usuarios, podrán visualizar la tabla de posiciones de los

equipos participante de un campeonato, la información que se

visualizará se enumera a continuación:


Tipo de deporte








Número de puntos

Puntos: 3


1 Reporte de tablas de posiciones 3 15/05/2015 29/05/2015

Tabla 29. Historias de Usuario: Generación de carnets de jugadores

Descripción:

El usuario administrador, podrá generar la información necesaria para

imprimir el carnet de cada deportista, los datos que se visualizarán se

definen a continuación:

Número único del carnet




Tipo de deportista (Docente, Árbitro, Estudiante, Administrativo)

Universidad Central del Ecuador

Puntos: 4

57


1 Carnets de jugadores 4 29/05/2015 13/06/2015

Tabla 30. Historias de Usuario: Reporte de lesionados

Descripción:

Todos los usuarios tendrán acceso a ver la información de los

deportistas que han sufrido lesiones durante los diferentes campeonatos

en que han participado, los datos que se presentarán se definen a

continuación:


Tipo de deporte




Puntos: 3


1 Lesionados 3 15/05/2015 01/07/2015

Tabla 31. Historias de Usuario: Reporte de amonestados

Descripción:

Todos los usuarios podrán visualizar la información de los deportistas

amonestados por diferentes circunstancias del juego, los datos que se

presentarán se definen a continuación:


Tipo de deporte




Puntos: 3


1 Amonestaciones 3 18/05/2015 03/07/2015

58

Gestión de Cambios

Durante el desarrollo de la iteración 3 se presentaron dos requerimientos

para cambiar el orden de desarrollo de las siguientes historias de usuario:

Se solicitó iniciar la iteración con el desarrollo de la historia de usuario

“Envió de e-mail con información de Campeonatos”, en lugar de la

“Generación de carnets de jugadores”.

Se ordenó en base a nivel de importancia para el negocio el

desarrollo de los reportes.


resultados, por lo que no fue necesario eliminar historias del alcance o

planificar otra iteración.

Los cambios solicitados por el usuario en esta iteración fueron los

siguientes:

Reordenamiento para el desarrollo de las historias de usuario.

Cambios en los criterios de la historia de usuario Generación de

carnets de jugadores:

o El carnet del jugador se imprimirá en formato pdf.

Cambios de visualización y orden de los objetos en pantalla y en los

reportes.




usuario.


59



Historia 12 Validación del envío de correos Correo enviado exitosamente

Historia 13 Validación de información de deportistas

Información validada con éxito

Historia 14 Generación del reporte de fechas de juego de un campeonato

Información generada con éxito

Historia 15 Visualización de los máximos anotadores por campeonato

Información visualizada de forma correcta

Historia 16 Generación del reporte de resultados de varios partidos

Información generada de manera exitosa

Historia 17 Visualización de tabla de posiciones de campeonatos

Visualización correcta de la información

Historia 18 Generación e impresión de un carnet

Generación e impresión correcta de la información del deportista en el carnet

Historia 19 Visualización de los lesionados de un campeonato

Información mostrada e manera exitosa

Historia 20 Visualización de los amonestados de un campeonato

Información visualizada de forma correcta

3.8.9. Diario de Actividades

El Diario de actividades permite visualizar una bitácora de las tareas que cada

uno de los miembros del equipo ha desarrollado.

Para el caso del presente proyecto se ha considerado el diario de actividades

del Programador y se muestra a continuación:

Tabla 33. Diario de actividades Iteración 1

Nombre: Roberto David Salazar Asanki

Rol: Programador

60

ITERACIÓN 1

Fecha de Inicio: 27 de octubre de 2014

Fecha de finalización: 17 de diciembre de 2014

ACTIVIDADES REALIZADAS T(s) OBSERVACIONES

Reunión con las personas que

manejan la calendarización de

juegos deportivos de la

Facultad de cultura Física.

Comparación de herramientas

de programación y motores de

bases de datos.

Investigación y comparación

de servidores de aplicaciones.

Modelamiento de base de

datos

Generación de proyecto base

para la aplicación

Configuración de

componentes de la

arquitectura JEE6

Configuración del servidor de

aplicaciones en temas de

seguridad

Configuración de esquemas,

usuarios, secuencias y

catálogos de la base de datos

Desarrollo de la administración

de deportistas, canchas,

equipos, catálogos y usuarios

del sistema

8

Se mantiene reuniones con

los usuarios del negocio y se

define las principales

características del sistema.

Se define la arquitectura para

el proyecto.

Se definen las herramientas

para el desarrollo y el

modelamiento de base de

datos.

Aceptación de logos y colores

del sistema por parte del

cliente

Aceptación del avance

presentado en la primera

iteración

61



Rol: Programador

ITERACIÓN 2

Fecha de Inicio: 16 de diciembre de 2014

Fecha de finalización: 13 de marzo de 2015


Modelamiento de la base de datos

para cumplir con las necesidades de

la iteración 2

Desarrollo de la administración de

usuarios

Desarrollo de la administración de

campeonatos

Investigación de los algoritmos de

emparejamiento de equipos para

generar campeonatos

Reunión con el cliente para definir

los tipos de juegos que se van a

realizar


excepciones en el registro de

resultados de fútbol, básquet y vóley

Desarrollo del registro de fútbol,

básquet y vóley


como se manejará la programación

de fechas de los juegos

Desarrollo de la programación de

horarios y fechas de los juegos

Desarrollo de la conformación de

equipos

14

Se presenta al cliente el

sistema con autenticación de

usuarios

El cliente define que en el

vóley no se debe registrar

anotadores

El cliente define que se va a

realizar el sistema de juego

todos contra todos y el

campeón será el que obtenga

mayor puntaje

Se define con el cliente que

las fechas y horas las

asignará de forma manual el

usuario

62



Rol: Programador

ITERACIÓN 3

Fecha de Inicio: 16 de marzo de 2015 Fecha de finalización: 06 de julio de 2015


Configuración de una cuenta de

correo electrónico con el dominio

de la Universidad Central para

enviar los e-mails a los jugadores

inscritos en los campeonatos

Configuración de la herramienta en

java para enviar correos

electrónicos de manera automática

Desarrollo del seguimiento a los

deportistas

Pruebas de las iteraciones 1 y 2

con el cliente

Definición de cambios en las

iteraciones 1 y 2 por parte del

cliente

Validación del seguimiento de

deportistas por parte del cliente

Desarrollo del reporte de máximos

anotadores

Desarrollo del reporte de

amonestados

Desarrollo del reporte de tabla de

posiciones y resultados de

encuentros

Desarrollo del reporte de

expulsados y amonestados

Generación de carnets de los

jugadores

16

El cliente define que para la

visualización de tablas de

posiciones, máximos anotadores,

lesionados, amonestados, etc. Se

deben crear usuarios para que

puedan acceder al sistema y

visualizar la información definida.

E usuario solicita cambios de

presentación en las iteraciones 1 y

2

El cliente define la información que

se debe presentar en el carnet de

los jugadores

El cliente define la información y el

orden que deben mantener los

reportes

El cliente queda conforme con las

tres iteraciones del sistema

El cliente se compromete a revisar

manuales de usuario del sistema

63

3.9. Implementación

Figura 24. Fase de Implementación

La fase de implementación es la más larga del proyecto, y donde se requiere de

mayor comunicación entre el equipo técnico y los usuarios funcionales.

Durante esta fase el equipo técnico dedica sus esfuerzos en la construcción del

modelo de base de datos, desarrollo de funcionalidades, construcción de

pantallas y documentación del proyecto.

Para el desarrollo de las historias de usuario es necesario contar con el apoyo

de los usuarios funcionales, pues, ellos son los responsables de la transferencia

de conocimiento sobre los procesos que se van a automatizar. Además deben

ofrecer todas las facilidades para que el desarrollador pueda acceder a la

información y documentos necesarios para la implementación de una historia de

usuarios.

Implementación

Base de Datos

Manual de Usuario

Manual Técnico

64

3.9.1. Diagrama de Base de Datos

Fig

ura

25.

Dia

gra

ma

de

Ba

se

de

Da

tos

65

3.9.2. Diagramas por sección de negocio

Figura 26. Administración de usuarios

66

Figura 27. Administración de campeonatos

67

Figura 28. Administración de jugadores

68

Figura 29. Registro de partidos

69

Figura 30. Administración de catálogos

Figura 31. Administración de canchas

70

Figura 32. Conformación de equipos

71

3.9.3. Diccionario de Datos

Simbología

NN.- Admite campos nulos

Descripción de Tablas

propiedades_deporte.- Estructura que contiene los parámetros de

máximos y mínimo de jugadores por deporte.

canchas.- Estructura que contiene la información de las canchas

deportivas.

ad_catalogo.- Estructura que contiene la información de los parámetros

generales del sistema.

campeonatos.- Estructura que contiene la información de campeonatos

deportivos.

partidos.- Estructura que contiene la información de los partidos.

ad_detalle_catalogo.- Estructura que contiene la información del detalle

de los parámetros generales del sistema.

ad_deportista.- Estructura que contiene la información personales de los

deportistas.

deportista_x_equipo.- Estructura que contiene la conformación de los

equipos.

amonestados.- Estructura que contiene la información de los jugadores

amonestados.

anotadores.- Estructura que contiene la información de los deportistas

que han realizados anotaciones.

72

expulsados.- Estructura que contiene la información de los deportistas

expulsados de los partidos.

resultados.- Estructura que contiene la información de los resultados de

los partidos.

ad_equipos.- Estructura que contiene la información de los equipos.

ad_opciones_sistema.- Estructura que contiene las diferentes opciones

del sistema.

ad_rol_opciones_sistema.- Estructura que contiene los roles definidos

en el sistema.

ad_usuario.- Estructura que contiene la información personal de los

usuarios del sistema.

ad_rol_usuario.- Estructura que contiene los roles del sistema.

ad_roles.- Estructura que contiene la información de los roles de usuario

del sistema.

Detalle de Tablas

AD_CATALOGO

Columna Tipo dato NN Descripción

descripcion varchar SI Descripción del catálogo

estado varchar SI Estado del registro del catálogo

cod_catalogo int4 NO Clave primaria

deporte varchar SI Especifica si el contenido del catálogo es un deporte

AD_DEPORTISTA


cod_deportista Serial NO Clave primaria de la tabla

Identificación varchar SI Número de cédula

Nombres varchar SI Nombres

Apellidos varchar SI Apellidos

73

fec_nacimiento Date SI Fecha de nacimiento

TelefoNo Varchar SI Número de teléfono convencional

celular1 Varchar SI Número de celular 1

celular2 Varchar SI Número de celular 2

e_mail Varchar SI Correo electrónico

dirección Varchar SI Dirección del domicilio

cod_facultad int4 SI Clave foránea de detalle de catálogos

cod_estado_civil int4 SI Clave foránea de detalle de catálogos

cod_tipo_deportista int4 SI Clave foránea de detalle de catálogos

num_carnet Varchar SI Número único de carnet

Estado Varchar SI estado del registro

si_futbol Varchar SI Especifica si el deportista pertenece a un equipo de fútbol

si_basquet Varchar SI Especifica si el deportista pertenece a un equipo de básquet

si_voley Varchar SI Especifica si el deportista pertenece a un equipo de vóley

AD_DETALLE_CATALOGO


descripcion Varchar SI Descripción del detalle catálogo

Detalle Varchar SI Detalle del detalle de catálogo

Estado Varchar SI Estado

cod_det_catalogo Serial NO Clave primaria

cod_catalogo int4 SI Clave foránea de la tabla de catálogo

AD_EQUIPOS


cod_equipo Serial NO Clave primaria

nombre Varchar SI Nombre del equipo

fec_inscripcion Date SI Fecha de inscripción

estado Varchar SI Estado del registro

cod_color int4 SI Clave foránea de la tabla de detalle de catálogos

cod_deporte int4 SI Clave foránea de la tabla de detalle de catálogos

cod_color_sec int4 SI Clave foránea de la tabla de detalle de catálogos

en_campeonato Varchar SI Identifica si el equipos está inscrito en un campeonato

con_partido Varchar SI Identifica si el equipo ya tiene partidos programados

74

AD_OPCIONES_SISTEMA


op_id Serial NO Clave primaria

ad_op_id int4 SI Código padre de la tabla

op_descripcion Varchar SI Descripción del link de acceso al menú

op_directorio Varchar SI Link de acceso

op_img Varchar SI Imagen para el acceso del menú

AD_ROL_OPCIONES_SISTEMA


rop_id Serial NO Clave primaria

rol_id int4 SI Clave foránea del Rol

op_id int4 SI Clave foránea de la opción del sistema

AMONESTADOS


cod_amonestado serial NO Clave primaria

cod_resultado int4 SI Clave foránea de la tabla de resultados

cod_deportista int4 SI Clave foránea de la tabla de deportistas

minuto int4 SI Minuto en que es amonestado

motivo varchar SI Motivo por el cual es amonestado

estado varchar SI Estado del registro

observacion varchar SI Observaciones

ANOTADORES


cod_anotador Serial NO Clave primaria



observacion Varchar SI Observaciones

minuto int4 SI Minuto de anotación

estado Varchar SI Estado del registro

75

CAMPEONATOS


cod_campeonato serial NO Clave primaria

cod_tipo_campeonato int4 SI Clave foránea de la tabla de detalle catálogo

fec_creacion date SI Fecha de creación


cod_tipo_deporte int4 SI Clave foránea de la tabla de detalle catálogo

nombre varchar SI Nombre del campeonato

CANCHAS


cod_cancha serial NO Clave primaria

nombre varchar SI Nombre de la cancha

cod_deporte int4 SI Clave foránea de la tabla de detalle de catálogo

comentario varchar SI Comentarios u observaciones


DEPORTISTA_X_EQUIPO


cod_jugador_equipo Serial NO Clave primaria

cod_equipo int4 SI Clave foránea de la tabla de equipos


estado varchar SI Estado de Registro

EXPULSADOS


cod_expulsado serial NO Clave primaria



minuto int4 SI Minuto en que es expulsado

motivo varchar SI Motivo de la expulsión

observacion varchar SI Observaciones


76

PARTIDOS


cod_partido Serial NO Clave primaria

cod_campeonato int4 SI Clave foránea de la tabla de campeonato

cod_arbitro int4 SI Clave foránea de la tabla de deportistas

cod_cancha int4 SI Clave foránea de la tabla de canchas

cod_eq_local int4 SI Clave foránea de la tabla de equipos

cod_eq_visitante int4 SI Clave foránea de la tabla de equipos

fecha_juego int4 SI Fecha de juego

fase varchar SI fase del juego


fecha_hora_inicio timestamp SI Fecha y hora de inicio del partido

fecha_hora_fin timestamp SI Fecha y hora del término del partido

PROPIEDADES_DEPORTE


cod_propiedad_deporte serial NO Clave primaria

min_jugadores int4 SI Número mínimo de jugadpres por deporte

max_jugador int4 SI Número máximo de jugadores por deporte

cod_catalogo int4 SI Clave foránea de la tabla catálogos


RESULTADOS


cod_resultado serial NO Clave primaria

anotacion_eq_local int4 SI Anotación del equipo local

anotacion_eq_visita int4 SI Anotación del equipo visitante

eq_ganador int4 SI Clave foránea de la tabla de equipos

eq_perdedor int4 SI Clave foránea de la tabla de equipos

empate varchar SI Identifica si se registra un empate

num_periodos int4 SI número de periodos del partido


77

AD_ROL_USUARIO


ru_id Serial NO Clave primaria

usu_id int4 SI Clave foránea de usuarios

rol_id int4 SI Clave foránea de roles

op_id int4 SI Clave foránea de opciones

AD_ROLES


rol_id Serial NO Clave primaria

rol_nombre varchar SI Nombre del rol

rol_estado int4 SI Estado del registro

AD_USUARIO


usu_id Serial NO Clave primaria

fun_cedula Varchar SI Número de cédula

usu_name Varchar SI Nombre de usuario

usu_pass Varchar SI Contraseña encriptada

usu_estado int4 SI Estado del registro

usu_nombre Varchar SI Nombre de usuario

usu_unidad Varchar SI Unidad del usuario

usu_mail Varchar SI Correo electrónico

78

3.10. Manual Técnico

Introducción

El presente documento tiene la finalidad de proveer la información técnica

necesaria para la administración y mantenimiento del “SISTEMA DE

ADMINISTRACIÓN DEPORTIVA PARA LA UNIVERSIDAD CENTRAL DEL

ECUADOR”.

El presente manual ayuda a la comprensión de la arquitectura del sistema para

posibles cabios de funcionalidad o nuevos desarrollos del mismo.

Contenido

Para el desarrollo de la aplicación y cumplimiento de la arquitectura se utilizaron las

siguientes herramientas y componentes:

Eclipse Kepler, Herramienta de desarrollo para JAVA

JBoss Community 7.1, Servidor de Aplicaciones

jdk1.7.0_67, Máquina virtual de JAVA

PostgreSQL 9.3, Base de Datos

Arquitectura

El sistema está dividido en dos capas para su mejor manejo y mantenimiento, está

desarrollada utilizando los siguientes patrones de diseño y estándares:

Capa de Presentación

En la capa de presentación se define la interface que se va a mostrar al usuario para

que interactúe con el sistema, para construir la capa de presentación del sistema se

utilizaron las siguientes herramientas:

Rich Faces 4.2

JFS 2.0

Backing Beans

79

Capa de Negocio y Aplicación

En esta capa se define el negocio de la aplicación, aquí se concretan los métodos que

se utilizan para solventar los incidentes que se tienen en la resolución del problema de

la administración deportiva, también se tienen las entidades mapeadas de la base de

datos para utilizarlas dentro de la aplicación, para construir esta capa se utilizaron los

siguientes componentes:

Entidades JPA 2.0

EJB 3.1

Inyección de dependencias JTA

Principales métodos utilizados en la aplicación

Método Descripción

public List<Campeonato> buscarCampeonatos(String estado, Integer idDeporte);

Método que permite realizar la

búsquedas de campeonatos por

estado

public List<Integer> buscarFechasPorCampeonato(String estado, Integer idCampeonato);

Método que busca las fechas de los

campeonatos por esto

public List<Partido> buscarPartidosPorFecha(Integer fecha, String estado, Integer idCampeonato);

Método que consulta todos los

partidos que tiene un campeonato

de acuerdo a la fecha de juego

public List<AdDeportista> buscarJugadoresPorEquipo(Integer idEquipo);

Método que permite la búsqueda de

los integrantes de un equipo

determinado

public List<Partido> buscarPartidosActivos(String estado, Integer codCampeonato);


búsqueda de los partidos que

pueden incluirse en un nuevo

campeonato

public List<Cancha> listarCanchasPorDeporte(Integer codCatalogo, String estado);

Método que consulta las canchas

disponibles que tiene el sistema por

estado

public List<AdDeportista>

buscarDeportistasPorTipo(Integer

Método que permite la búsqueda de

los deportistas por tipo

80

codDeportista, String estado);

public void actualizarPartido(Partido partido) throws EntidadNoGuardadaException;

Método que permite programar las

fechas de un partido

public List<AdDeportista> buscarDeportistaPorIdentificacion(String identificacion);


consulta de los deportistas

mediante su número de

identificación o cédula

public List<AdEquipo> listarEquiposPorDeporte(String estado, AdCatalogo catalogo);

Método que consulta todos los

equipo por deporte seleccionado

public List<AdDeportista> buscarDeportistasLibres(Integer deporte);

Método que consulta a los

deportistas que no pertenecen a

ningún equipo

public void eliminarDeportista(AdDeportista deportista) throws EntidadNoGuardadaException;

Método que permite inactivar a un

deportista

public List<AdDeportista> listarDeportistas(String estado);

Método que busca a todos los

deportistas

public void guardarDeportista(AdDeportista deportista) throws EntidadNoGuardadaException;

Método que realiza el

almacenamiento de un deportista

public void guardarEquipo(AdEquipo

equipo) throws

EntidadNoGuardadaException;

Método que permite guardar un

nuevo equipo

public List<AdEquipo> listarEquipos(String

estado);

Método que consulta los equipos

registrados en el sistema por estado

public List<Object[]>

crearFechasCampeonato(List<String>

listaEquipos);

Método que crea las fechas y horas

de los campeonatos registrados

public void guardarPerfilOpcionesSistema(AdRolOpcionesSistema perfilOpciones) throws ServicioException;

Método que almacena los perfiles

creados para os usuarios.

public void

actualizarPerfilUsuario(AdRolUsuario ru)

throws ServicioException;

Método que realiza la actualización

de perfiles de usuarios

public List<AdRolUsuario> Método que permite buscar los

81

listarPerfilUsuario(Integer usuario) throws

ServicioException;

perfiles de un usuario

public List<AdRolUsuario>

listaRolUsuario(Integer perfil) throws

ServicioException;

Método que realiza la búsqueda de

los roles de usuarios

public void borrarRol(Object codigoRol,

Integer o) throws ServicioException;

Método que permite borrar los roles

de usuarios

public AdRolOpcionesSistema obtenerRolPorPerfilRecurso(Object codigoPerfil, Object codigoRecurso) throws ServicioException;

Método que permite consultar los

roles mediante el código del recurso

registrado

Diagramas de Clases

edu.ec.uce.culturaFisica.servicios

86

edu.ec.uce.culturaFisica.servicios.imp

90

edu.ec.uce.culturaFisica.entidades

Catálogos

91

Equipos

92

Partidos

Deportistas

93

Usuarios

94

3.11. Manual de Usuario

Introducción

El sistema de Administración Deportiva para la Universidad Central del

Ecuador, tiene una interfaz amigable e intuitiva para que el usuario no tenga

inconvenientes en realizar las acciones que requiera, por este motivo en el

presente manual de usuario se detalla la funcionalidad de las principales

pantallas como ayuda para el uso correcto del resto de la aplicación.

Para acceder al Sistema de Administración Deportiva para la Universidad

Central del Ecuador, ingresamos en la página de inicio con el usuario y

contraseña que el administrador del sistema tiene que otorgar a cada usuario

registrado dentro del mismo.

95

Pantalla de Bienvenida

La primera pantalla que se visualiza en el Sistema de Administración Deportiva

para la Universidad Central del Ecuador, presenta el menú contraído en la parte

izquierda dónde se puede verificar cada una de las opciones que maneja la

aplicación.

Administración de Equipos para Campeonatos

96

En la administración de equipos para campeonatos se puede manejar las

siguientes opciones:

Registro de un nuevo equipo

Al seleccionar la opción de nuevo se deben registrar los siguientes campos para

crear un nuevo equipo:

o Nombre del equipo

o Color principal

o Color secundario

o Tipo de deporte al que pertenece

o Fecha de registro (automático del sistema)

o Estado (automático del sistema)

Al registrar estos campos se debe seleccionar la opción guardar y se registra un

nuevo equipo en el sistema.

Actualización de un equipo existente

Al seleccionar la opción editar, el sistema permite al usuario actualizar los

siguientes campos del equipo seleccionado:

o Nombre del equipo

o Color principal

o Color secundario

o Tipo de deporte al que pertenece

Al actualizar los campos de los registros que permite el sistema, se debe

seleccionar la opción actualizar y se almacenan los nuevos valores

seleccionados.

Inactivación de un equipo existente

Para inactivar un quipo se debe seleccionar la opción eliminar, el sistema

preguntará si está seguro de eliminar el registro, si se selecciona la opción “SI”,

97

el registro quedará inactivo y visible únicamente en auditorías, caso contrario no

se realiza ninguna acción.

Conformar equipo

Para conformar equipos, se deben tener creados jugadores y equipos, para

realizar esta acción el sistema permite seleccionar de la lista izquierda los

jugadores que no tienen equipo, para pasarlos al grupo de la derecha que será

el listado final de jugadores del equipo seleccionado.

El sistema se asegura que el número de jugadores seleccionados no sea

menor al mínimo requerido y superior al máximo admitido.

El sistema visualiza el número de jugadores que ya están registrados en

el equipo.

Una vez seleccionados a los jugadores para el equipo, se hace uso de la opción

guardar, la misma que almacena el equipo con sus respectivos jugadores.

98

Crear campeonatos

Para crear los campeonatos dentro del sistema, es necesario registrar y

seleccionar los siguientes campos:


Tipo de campeonato

Tipo de deporte

Una vez seleccionados y registrados los campos requeridos por el sistema, se

hace uso de la opción guardar para registrar el campeonato.

99

Asignación de fechas

Para realizar la asignación de fechas de os aprtidos de un campeonato de

fútbol, básquet y/o vóley, se requiere seleccionar de una lista el nombre del

campeonato.

El sistema visualizará una lista general con todos los partidos del campeonato,

divididos en fechas de juego, y de cada uno de los encuentros el sistema

muestra la siguiente información:

Tipo de deporte

Equipos que se enfrentan

Fase de juego

Número de fecha de juego

Opción “Programar fecha”

100

Programar fechas de partidos

Para programar una fecha y hora para un partido, hacemos uso de la opción

programar fecha, en esta pantalla se debe definir todos los parámetros para

programar el encuentro, se deben seleccionar o registrar los siguientes campos:

Nombre de la cancha de juego

Nombre del árbitro del partido

Fecha y hora del inicio del encuentro

Fecha y hora del final del encuentro

El sistema valida que los árbitros que se muestren en la lista estén

disponibles para el juego

El sistema se asegura que las canchas que se muestren en la lista estén

disponibles para el juego.

Una vez seleccionados los campos requeridos, hacemos uso de la opción

programar fecha y el sistema automáticamente registra los datos del encuentro,

también bloquea a la cancha y árbitro seleccionado por el tiempo que dure el

partido.

101

Catálogos

El sistema utiliza parámetros generales que se administran dentro de los

catálogos del sistema, los mismos que están definidos en base al negocio, los

catálogos generales del sistema son los siguientes:

Facultades

Estado Civil

Canchas de juego

Fases de juego

Colores

Para administrar los catálogos generales el sistema únicamente permite la

actualización del nombre del catálogo.

102

Detalle de catálogos

En el detalle de catálogos se puede visualizar la información definida por los

usuarios con respecto a cada uno de los catálogos generales, por ejemplo:

Si el catálogo general es Facultades, el detalle de catálogos será:

o Facultad de Ingeniería Ciencias Físicas y Matemática

o Facultad de Cultura Física

o Etc.

Para la administración del detalle de catálogos, el sistema permite realizar las

siguientes acciones:

Registrar un nuevo detalle de catálogo

Para crear un nuevo detalle de catálogo se debe seleccionar la opción

Nuevo y registrar o seleccionar los siguientes campos:

o Seleccionar el catálogo general

o Descripción del detalle de catálogo

o Detalle

103

o Estado (automático del sistema)

Se hace uso de la opción guardar y se almacena la información

correspondiente al nuevo detalle de catálogo.

Actualizar un detalle de catálogo

Para actualizar un detalle de catálogo se debe seleccionar la opción editar

del sistema la que permite editar los siguientes campos:

o Descripción del detalle de catálogo

o detalle

Se hace uso de la opción actualizar y el sistema registra la información

del detalle de catálogo actualizado.

Inactivación de un detalle de catálogo

Para eliminar un detalle de catálogo, es necesario seleccionar la opción

eliminar, seguido de esto el sistema mostrará un mensaje confirmando que

se va a eliminar el registro, si se escoge la opción si el campo quedará

inhabilitado caso contrario no se realiza ninguna acción.

104

Deportistas y árbitros

Para la administración de deportistas y árbitros se debe registrar o seleccionar

los siguientes campos:

Identificación.- Número de cédula

Nombres

Apellidos

Fecha de nacimiento

Número de teléfono convencional

Número de celular uno

Número de celular dos

Correo electrónico

Dirección

Seleccionar facultad

Seleccionar estado civil

Seleccionar de una lista el tipo de deportista

o Docente

o Estudiante

105

o Administrativo

o Árbitro

Se hace uso de la opción guardar y el sistema almacena todos los datos

necesarios para registrar a los deportistas.

Jugadores por equipo

El sistema permite parametrizar el número máximo y mínimo de jugadores por

cada deporte.

Para crear esta parametrización el usuario debe seleccionar y registrar los

siguientes campos:

Nombre del deporte

Número mínimo de jugadores

Número máximo de jugadores

Se debe hacer uso de la opción guardar para que el sistema almacene los

registros y estos puedan ser utilizados dentro de toda la aplicación.

106

3.12. Pruebas Funcionales

El desarrollo de pruebas funcionales ayuda a verificar el cumplimiento de los

criterios establecidos en las historias de usuario construidas en la fase de

exploración.

Las pruebas funcionales se han construido en base a las siguientes

consideraciones:

Descripción.- Detalle del contenido de la prueba.

Condiciones de ejecución.- Criterios previos que deben considerarse

antes de ejecutar la prueba.

Entrada.- Pasos que debe seguir el usuario para ejecutar la prueba

Resultado esperado.- Valores o acciones que deben ser verificados

luego de finalizar la ejecución de la prueba.

Evaluación de la prueba.- Resultado de la ejecución de la prueba.

A continuación se detallan las pruebas funcionales realizadas:

Tabla 36. Prueba 1

Descripción

El usuario una vez que ingrese en el sistema con sus credenciales,

debe ingresar en las opciones del sistema de administración de

jugadores, árbitros, canchas y catálogos.

Debe crear un registro por cada opción del sistema, también debe

actualizar el mismo campo y eliminarlo para validar la funcionalidad.

Condiciones

de ejecución El usuario debe tener acceso al sistema

Entrada

El usuario ingresará con usuario y contraseña

Ingresa a la opción de canchas y crea, actualiza y elimina un

registro

Ingresa a la opción jugadores y crea, actualiza y elimina un

registro

Ingresa a la opción de catálogos y actualiza el nombre de un

registro

107

Ingresa a la opción de detalle de catálogo y crea, actualiza y

elimina un registro

Resultado

esperado

Durante y después de las pruebas con el usuario se valida en la

base de datos que los registros se encuentren actualizados.

Evaluación

de la prueba Satisfactoria

Tabla 37. Prueba 2

Descripción

Cuando el usuario este en el sistema, debe seleccionar la opción de

creación de campeonatos, y realizar el registro de un nuevo

campeonato

Condiciones

de ejecución Tener acceso al sistema

Entrada

Ingresar con las credenciales

Seleccionar la opción de creación de campeonato

Ingresar el nombre del nuevo campeonato

Seleccionar de una lista el tipo de deporte

Seleccionar de una lista el tipo de campeonato

Seleccionar de una lista los equipos que van a disputar el

campeonato

Guardar

Resultado

esperado

Generar el emparejamiento de los equipos participantes y validar en

la base de datos que se haya creado el campeonato con los

mencionados equipos.

Evaluación


Tabla 38. Prueba 3

Descripción

Cuando el usuario este en el sistema, debe ingresar a la opción de

registro de partidos de fútbol y registrar toda la información que se

genera luego de un encuentro.

Condiciones Tener acceso al sistema

108

de ejecución

Entrada

Ingresar al sistema y escoger la opción de registro de

partido de futbol

Seleccionar de una lista el nombre del campeonato

Seleccionar de una lista el encuentro que se va a registrar

Para registrar los goles, se debe seleccionar de la lista de

jugadores y usar la opción gol.

Para registrar a los amonestados, se debe seleccionar de la

lista de jugadores y usar la opción amonestado.

Para registrar a los lesionados, se debe seleccionar de la

lista de jugadores y usar la opción lesionado.

Para registrar a los expulsados, se debe seleccionar de la

lista de jugadores y usar la opción expulsado.

Resultado

esperado

Registrar en la base de datos el resultado del encuentro de fútbol y

verificar que queden almacenados los lesionados, amonestados y

expulsados en caso de existir.

Evaluación


Tabla 39. Prueba 4

Descripción


registro de partidos de básquet y registrar toda la información que

se genera luego de un encuentro.

Condiciones


Entrada


partido de básquet



Para registrar los aros, se debe seleccionar de la lista de

jugadores y usar la opción aro.


109






Resultado

esperado

Registrar en la base de datos el resultado del encuentro de básquet

y verificar que queden almacenados los lesionados, amonestados y


Evaluación


Tabla 40. Prueba 5

Descripción


registro de partidos de vóley y registrar toda la información que se

genera luego de un encuentro.

Condiciones


Entrada


partido de vóley









Resultado

esperado

Registrar en la base de datos el resultado del encuentro de vóley y

verificar que queden almacenados los lesionados, amonestados y


Evaluación


110

Tabla 41. Prueba 6

Descripción


asignar fechas para validar la generación de partidos de un

campeonato de cualquier deporte

Condiciones


Entrada

Ingresar al sistema y seleccionar la opción de asignación de

fechas

Seleccionar de una lista el nombre del campeonato, el

sistema mostrará de manera inmediata el tipo de deporte al

que pertenece.

Se desplegarán todos los encuentros divididos por fecha.

En cada partido el sistema permite registrar la programación

del encuentro

Seleccionar de un lista el nombre del árbitro

Seleccionar de una lista el nombre de la cancha de juego

Registrar la fecha y hora del inicio del compromiso

Registrar la fecha y hora de la finalización del compromiso

Hacer uso de la opción programar fecha.

Resultado

esperado

Comprobar las validaciones de fechas, árbitros y canchas, validar el

registro de la programación de un encuentro de cualquier tipo de

deporte.

Evaluación


Tabla 42. Prueba 7

Descripción Cuando el usuario este en el sistema, debe ingresar a la opción de

conformar equipo registrar un nuevo equipo.

Condiciones


Entrada Ingresar al sistema

Seleccionar de una lista el tipo de deporte

111

Seleccionar de una lista el nombre del equipo

El sistema presenta el número mínimo y máximo de

jugadores que se pueden registrar

El sistema presenta el número de jugadores registrados en

el equipos seleccionado

Se debe seleccionar a los jugadores que van a conforma el

mencionado equipo

Hacer uso de la opción guardar

Resultado

esperado

Comprobar la validación de ingreso del número mínimo y máximo

de jugadores, y validar que se registren la información de manera

correcta en la base de datos.

Evaluación


Tabla 43. Prueba 8


enviar información por e-mail.

Condiciones


Entrada

Ingresar al sistema

Seleccionar la opción comprobar envío de correos

electrónicos

Hacer uso de la opción enviar

Resultado

esperado

Comprobar que el e-mail enviado desde el sistema llego al

destinatario de pruebas.

Evaluación


Tabla 44. Prueba 9


reportes y seleccionar el opción máximos anotadores.

Condiciones Tener acceso al sistema

112

de ejecución

Entrada

Ingresar al sistema

Seleccionar la opción de máximos anotadores

Seleccionar de una lista en tipo de deporte


Validar la información que presenta el sistema

Resultado

esperado

Verificar que se visualice la información requerida por el usuario en

el reporte desplegado.

Evaluación


Tabla 45. Prueba 10


reportes y seleccionar el opción amonestados.

Condiciones


Entrada

Ingresar al sistema

Seleccionar la opción de amonestados




Resultado

esperado



Evaluación


Tabla 46. Prueba 11


reportes y seleccionar el opción lesionados.

Condiciones


113

Entrada

Ingresar al sistema

Seleccionar la opción de lesionados




Resultado

esperado



Evaluación


Tabla 47. Prueba 12


reportes y seleccionar el opción tabla de posiciones.

Condiciones


Entrada

Ingresar al sistema

Seleccionar la opción de tabla de posiciones




Resultado

esperado



Evaluación


Tabla 48. Prueba 13


reportes y seleccionar el opción resultado de partidos.

Condiciones


Entrada Ingresar al sistema

114

Seleccionar la opción de resultado de partidos



Seleccionar de una lista el número de la fecha del

campeonato

Seleccionar de una lista el partido requerido


Resultado

esperado



Evaluación


Tabla 49. Prueba 14


reportes y seleccionar el opción seguimiento de deportistas.

Condiciones


Entrada

Ingresar al sistema

Seleccionar la opción de seguimiento de deportistas

Ingresar el número de cédula o los nombres y apellidos del

jugador


Resultado

esperado



Evaluación


115

CAPÍTULO 4

4.1. CONCLUSIONES

El sistema de administración deportiva es una herramienta de apoyo para el

personal de la Facultad de Cultura Física que administra los campeonatos

deportivos de la Universidad Central del Ecuador; esta herramienta cuenta

con funcionalidades que permitirán cubrir y gestionar de forma más rápida la

creación de un campeonato y asegurar el almacenamiento de la información

agregando características como integridad y disponibilidad.

La gestión de los deportistas es otro beneficio que ofrece el sistema de

administración deportiva, pues, cuenta con las facilidades para registrar la

información de los jugadores y asignarlos a una categoría de deporte, equipo

y campeonato.

La administración del sistema además permite gestionar toda la información

necesaria para la creación de un campeonato, como el registro de árbitros,

canchas, equipos y la parametrización de los partidos.

El sistema permite además parametrizar la generación de partidos a través

del uso de algoritmos que facilitan la creación de los campeonatos.

El uso de esta aplicación web permitirá que los servicios de administración

de campeonatos eleven su nivel de transparencia y probablemente

disminuyan el tiempo que actualmente dedican los funcionarios de la

Facultad de Cultura Física a la creación, configuración y parametrización de

los mismos.

El acceso en línea a la información a través de reportes permitirá que la

Facultad de Cultura Física pueda mostrar la información de los campeonatos

en cualquier lugar y en cualquier momento.

116

El almacenamiento seguro de los datos es uno de los beneficios más

importantes que el desarrollo del sistema ha entregado a la Facultad de

Cultura Física, pues garantiza la integridad y calidad de los datos.

El sistema facilitará el seguimiento de los deportistas, permitiendo acceder a

su información en línea y mantener un registro actualizado de sus

participaciones en los campeonatos administrados por la Facultad de Cultura

Física.

El sistema ha sido desarrollado sobre herramientas de código abierto entre

las que se encuentran JBOSS, eclipse, postgresql, con lo que se ha

minimizado la inversión para la implementación y el mantenimiento del

sistema.

Para el desarrollo del presente proyecto se ha trabajado en base a un

entorno ágil aplicando la metodología XP, por lo cual se debe concluir que el

uso de este tipo de metodologías es de gran utilidad para enfocar el uso de

recursos en el desarrollo del sistema y reducir el tiempo dedicado a la

documentación realizando de esta última solamente lo que sea estrictamente

necesario.

4.2. RECOMENDACIONES

Se recomienda la revisión detallada de cada uno de los documentos

relacionados con el sistema y que ha sido entregados a la Facultad de

Cultura Física antes de iniciar el uso de la aplicación o si se requiere levantar

un ambiente de mantenimiento.

Es recomendable contar con al menos una persona con conocimientos en

arquitecturas JEE, administración de JBOSS 7, y postgresql para el

desarrollo de nuevas funcionalidad o la resolución de incidentes relacionados

con las tecnologías mencionadas.

117

Para garantizar el acceso al sistema es recomendable que se designe un

usuario administrador que se encargue del registro y notificación de los datos

de acceso a los funcionarios que requieran acceder al mismo.

Para mantener la disponibilidad del sistema es necesario que la Facultad de

Cultura Física garantice la disponibilidad de red y de servicio de internet.

Es recomendable que el desarrollo y construcción de las historias de usuario

sea una responsabilidad directa del o los usuarios funcionales debido a que

esto garantiza que los criterios plasmados se enfoquen en la necesidad del

negocio.

Para determinar el orden en el que deben desarrollar las historias de usuario

se recomienda realizar una o varias reuniones donde el usuario junto con el

personal técnico priorice cada uno de los requerimiento y de igual forma el

equipo técnico valore el nivel de esfuerzo a través de puntos.

Para facilitar el desarrollo de las historias de usuario es recomendable que

todos los miembros del equipo que sean asignados a una historia de usuario

desarrolle las tareas que sean necesarias para cubrir el requerimiento, con

esto se garantiza que se divida el problema en partes pequeñas volviéndolo

más sencillo para resolver.

Se recomienda mantener la comunicación en todo momento con los usuarios

del sistema para solventar cualquier duda o vacío de las historias de usuario,

no se recomienda las asunciones o suposiciones pues pueden generar

problemas de retardo y trabajo no planificado.

Es necesario que las historias de usuario sean distribuidas en iteraciones y

las iteraciones sean planificadas en base a las habilidades y tiempo que se

establezca para cada una de ellas.

Los proyectos que apliquen metodologías ágiles deben mantener una

adecuada gestión de cambios y de riesgo para evitar que los nuevos

118

requerimientos, cambio de priorización, salida de miembros del equipo, u

otros factores que pueden afectar al proyecto, impacten sobre la planificación

de la misma.

Se recomienda el desarrollo de pruebas unitarias para elevar la calidad del

código desarrollado y el mantenimiento del mismo.

Es recomendable el desarrollo de pruebas funcionales por parte del usuario

en base a los criterios establecidos en las historias de usuario, verificando

que los resultados esperados se cumplan satisfactoriamente.

Es necesario que el equipo técnico mantenga una adecuada planificación

para soportar la gestión y resolución de los incidentes durante la fase de

implementación y en la etapa de mantenimiento.

119

BIBLIOGRAFÍA

1. BUSTAMANTE, D., & Rodríguez, J. (2014). UNIVERSIDAD NACIONAL

EXPERIMENTAL DE LOS LLANOS. Recuperado el Enero de 2015, de

http://blogs.unellez.edu.ve/dsilva/files/2014/07/Metodologia-XP.pdf

2. CALABRIA, L., & Píriz, P. (2003). fi.ort.edu.uy. Recuperado el Enero de

2015, de http://fi.ort.edu.uy/innovaportal/file/2021/1/metodologia_xp.pdf

3. CANÓS, J., Letelier, P., & Penad, M. (s.f.). noqualityinside. Recuperado

el Enero de 2015, de noqualityinside:

http://noqualityinside.com/nqi/nqifiles/XP_Agil.pdf

4. JOSKOWICZ, J. (2008). Universidad de Vigo. Recuperado el Enero de

2015, de http://iie.fing.edu.uy/~josej/docs/XP%20-

%20Jose%20Joskowicz.pdf

5. MENTORING, G. (12 de Julio de 2012). Global Mentoring. Recuperado el

Enero de 2015, de http://globalmentoring.com.mx/cursos-java/java-

empresarial/arquitectura-multicapas/

6. ORACLE. (2010). Oracle. Recuperado el Diciembre de 2014, de

http://docs.oracle.com/javaee/5/tutorial/doc/bnbpz.html

7. RAFAELMA. (02 de Octubre de 2010). PostgreSQL. Recuperado el

Febrero de 2015, de http://www.postgresql.org.es/sobre_postgresql

8. WIKIPEDIA. (6 de Abril de 2015). wikipedia. Recuperado el Abril de

2015, de https://es.wikipedia.org/wiki/Java_EE

120

ANEXOS

121

A. Historias de Usuario

Historia de Usuario

Número: 1 Usuario: Administrador

Nombre historia: Administración de Usuarios

Prioridad en negocio: Alta Riesgo en desarrollo: Alto

Puntos estimados: 5 Iteración asignada: 2

Programador responsable: Roberto Salazar

Descripción:

Como usuario administrador se requiere administrar el registro, activación y

desactivación de usuarios del sistema.

Los campos que se deben registrar son los siguientes:

Nombre

Cédula de identidad

Unidad

Correo electrónico

Usuario

Estado

Para la búsqueda de usuarios se requiere contar con 2 opciones: Cédula y

Nombre. Los resultados deberán mostrarse en una lista que muestre la opción

para editar el registro. Todos los campos indicados son editables.

A todos los usuarios creados se les asignará una clave mismas que deberá

ser enviada por correo al usuario creado.

El usuario contará con la opción para modificar su clave desde el sistema.

Observaciones:

Para solicitar la activación o desactivación de usuarios se deberá enviar un

correo al Administrador del sistema con la justificación respectiva.

122

El correo de notificación de la creación del usuario y clave de acceso deberá

ser enviado por el Administrador; esto no se realizará directamente desde el

sistema.

Historia de Usuario


Nombre historia: Administración de jugadores

Prioridad en negocio: Alta Riesgo en desarrollo: Bajo



Descripción:

Como usuario Administrador del sistema se requiere gestionar los deportistas

registrados.

Para el registro y edición de deportistas se deben tomar en cuenta los

siguientes campos:


Apellidos y nombres

Fecha de nacimiento





Observaciones:

El número de identificación tiene que ser único

123

Historia de Usuario

Número: 3 Usuario: Administrador de campeonatos

Nombre historia: Administración de árbitros

Prioridad en negocio: Media Riesgo en desarrollo: Bajo



Descripción:

El usuario administrador de campeonatos tiene acceso para administrar a los

árbitros registrados en el sistema los campos que se deben registrar o editar

son los siguientes:


Apellidos y nombres

Fecha de nacimiento





Observaciones:

El número de identificación debe ser único, un árbitro no puede ser un jugador.

Historia de Usuario


Nombre historia: Administración de canchas

Prioridad en negocio: Alta Riesgo en desarrollo: Bajo


124


Descripción:

El usuario administrador de campeonatos puede gestionar las canchas

deportivas que se registran en el sistema, los datos que se deben guardar de

una cancha deportiva son los siguientes:

Nombre

Descripción

Tipo de deporte (Fútbol, Básquet o Vóley)

Observaciones:

Historia de Usuario


Nombre historia: Administración de equipos

Prioridad en negocio: Alto Riesgo en desarrollo: Medio



Descripción:

Como usuario administrador de campeonatos se requiere el registro, edición y

eliminación de equipos:

Para el registro se debe considerar los siguientes campos:

Nombre

Color principal

Color secundario

Tipo de deporte

Fecha de inscripción

Para la edición se debe considerar todos los campos mencionados a

125

excepción de la Fecha de inscripción.

El tipo de deporte se deberá mostrar en una lista permitiendo seleccionar solo

una categoría.

Tanto el Color principal como el Color secundario deberán ser seleccionados

de una lista

Observaciones:

Se deberá mantener el histórico de los equipos registrados en el sistema y que

hayan participado en algún campeonato

Historia de Usuario


Nombre historia: Administración de campeonatos

Prioridad en negocio: Alta Riesgo en desarrollo: Medio



Descripción:

Como usuario administrador de campeonatos se requiere la creación de

campeonatos.

Para la creación se debe considerar los siguientes campos:

Nombre

Tipo de campeonato

Tipo de deporte

El nombre deberá ser registrado en un campo de texto

El Tipo de campeonato al igual que el Tipo de deporte deberá ser seleccionado

de una lista previamente provista a través de la Administración de catálogos

126

del sistema.

Para mantener el histórico de los datos se debe considerar un campo de

estado que permitirá mostrar los datos del campeonato

Observaciones:

Historia de Usuario


Nombre historia: Registro de resultados de partidos

Prioridad en negocio: Media Riesgo en desarrollo: Medio



Descripción:

Como usuario Administrador de campeonatos se requiere el registro de los

resultados de los partidos celebrados durante un campeonato.

Los campos que se deben considerar son los siguientes:


Fecha

Partido

Equipos

Jugadores

Anotaciones

Amonestaciones

Expulsados

El nombre del campeonato, la fecha, el partido serán seleccionados de una

lista, y se permitirá la selección de un solo campo

127

Observaciones:

De la información almacenada en el registro de resultados de los partidos, se

obtendrán los reportes de máximos anotadores, tablas de posiciones,

expulsados, etc.

Historia de Usuario


Nombre historia: Generación de partidos




Descripción:

El usuario administrador, podrá generar los encuentros entre todos los equipos

que conforman un campeonato, el sistema debe realizar el emparejamiento de

todos los participantes y debe generar el número de partidos para formar el

campeonato.

Observaciones:

En caso que el número de equipos sea impar se debe dar descaso a un

equipo por fecha.

Historia de Usuario


Nombre historia: Administración de catálogos

Prioridad en negocio: Alta Riesgo en desarrollo: Alto


128


Descripción:

Como usuario Administrador de Campeonatos, se requiere administrar los

parámetros generales del sistema, los catálogos que se deben manejar son

los siguientes:

Facultades

Estado Civil

Colores

Canchas de Juego

Fases de Juego (IDA, VUELTA)

En cada uno de los catálogos anteriormente descritos el usuario únicamente

puede editar el nombre de los mismos.

Para la administración del detalle de los catálogos generales del sistema, el

usuario administrador de campeonatos podrá crear, actualizar y eliminar los

siguientes registros

Descripción

Detalle

Además el usuario deberá administrar el catálogo de:

Jugadores por Equipo

Ese catálogo brinda la facilidad de parametrizar el mínimo y máximo número

de jugadores que podrán tener los equipos de fútbol, básquet o vóley, se

podrá actualizar los registros de mínimo y máximo de jugadores.

Observaciones:

Se debe registrar un histórico de los campos eliminados.

129

Historia de Usuario

Número: 10 Usuario: Administrador de Partidos

Nombre historia: Programación de fechas y Horarios




Descripción:

El usuario administrador de partidos, puede programar las fechas y horarios de

todos los encuentros de un campeonato.

Para realizar esta tarea, debe seleccionar de una lista la cancha y el nombre

del árbitro, para el registro del tiempo de juego, el administrador de partidos

deberá registrar la fecha y hora del inicio y finalización del encuentro.

Observaciones:

No deben existir encuentros a la misma fecha y hora con árbitros o canchas

iguales.

Historia de Usuario

Número: 11 Usuario: Administrador de Partidos

Nombre historia: Conformación de equipos




Descripción:

El usuario administrador de partidos podrá realizar la conformación de los

130

equipos que participen en un campeonato, tendrá que seleccionar a los

deportistas registrados y ubicarlos en el equipo correspondiente, tomando en

cuenta el número mínimo y máximo de jugadores que puede tener de acuerdo

al deporte que seleccione.

Observaciones:

Historia de Usuario


Nombre historia: Envío de e-mail con información de campeonatos

Prioridad en negocio: Baja Riesgo en desarrollo: Alto



Descripción:

El usuario administrador de campeonatos podrá enviar vía e-mail el resultado

de los partidos, tabla de posiciones y principales estadísticas de los encuentros

disputados en un campeonato, a cada uno de los jugadores involucrados en

dicho certamen.

Observaciones:

Todos los deportistas deberán tener un correo electrónico registrado en el

sistema para recibir la información del campeonato.

Historia de Usuario

Número: 13 Usuario: Todos

Nombre historia: Administración y seguimiento de deportistas

Prioridad en negocio: Media Riesgo en desarrollo: Alto

131



Descripción:

Todos los usuarios, podrán consultar mediante el número de cédula o nombres

y apellidos, la información relevante de los jugadores, los datos que se

publicarán se describen a continuación:

Datos Generales






Lesiones

Observaciones:

Historia de Usuario


Nombre historia: Reporte de fechas de juego

Prioridad en negocio: Media Riesgo en desarrollo: Media



Descripción:

Todos los usuarios, podrán consultar los partidos y las fechas de juego

programadas en el campeonato, la información que se visualizará se describe

a continuación:

132

Nombre campeonato

Tipo de deporte

Número de equipos participantes

Fechas y horarios de los encuentros

Para que los usuarios tengan una mejor visualización de la información

requerida, se dispondrá de un filtro por equipo participante.

Observaciones:

La información que se presenta se podrá guardar en un archivo de formato

PDF.

Historia de Usuario


Nombre historia: Reporte de máximos anotadores

Prioridad en negocio: Baja Riesgo en desarrollo: Medio



Descripción:

Todos los usuarios, podrán ver la información de los quince máximos

anotadores de cada campeonato de fútbol o básquet, los datos que se

presentarán se describen a continuación:





Observaciones:

133

No se mostrará jugadores con menos de una anotación.


PDF.

Historia de Usuario


Nombre historia: Reporte de resultados de partidos




Descripción:

Todos los usuarios, podrán ver el resultado de los partidos que se llevan a

cabo dentro de un campeonato, la información que se presentará se describe

a continuación:


Nombre de los equipos

Numero de anotaciones por equipo

Nombres de los jugadores que anotaron de cada equipo

Nombres de los jugadores amonestados de cada equipo

Nombres de los jugadores expulsados de cada equipo

Nombres de los jugadores lesionados de cada equipo

Nombre del árbitro

Nombre de la cancha

Observaciones:


PDF.

134

Historia de Usuario


Nombre historia: Reporte de tabla de posiciones




Descripción:

Todos los usuarios, podrán visualizar la tabla de posiciones de los equipos

participante de un campeonato, la información que se visualizará se enumera

a continuación:


Tipo de deporte








Número de puntos

Observaciones:


PDF.

135

Historia de Usuario

Número:18 Usuario: Usuario Administrador

Nombre historia: Generación de carnets de jugadores

Prioridad en negocio: Baja Riesgo en desarrollo: Bajo



Descripción:

El usuario administrador, podrá generar la información necesaria para imprimir

el carnet de cada deportista, los datos que se visualizarán se definen a

continuación:

Número único del carnet




Tipo de deportista (Docente, Árbitro, Estudiante, Administrativo)

Universidad Central del Ecuador

Observaciones:

El número de carnet lo genera el sistema y es único para cada jugador

registrado.

Historia de Usuario

Número:19 Usuario: Todos

Nombre historia: Reporte de lesionados


136



Descripción:

Todos los usuarios tendrán acceso a ver la información de los deportistas que

han sufrido lesiones durante los diferentes campeonatos en que han

participado, los datos que se presentarán se definen a continuación:


Tipo de deporte




Observaciones:

Se permitirá buscar la información descrita mediante el ingreso del número de

cédula o nombres y apellidos del jugador.

Historia de Usuario


Nombre historia: Reporte de amonestados




Descripción:

Todos los usuarios podrán visualizar la información de los deportistas

amonestados por diferentes circunstancias del juego, los datos que se

presentarán se definen a continuación:

137


Tipo de deporte




Observaciones:

Se permitirá buscar la información descrita mediante la selección del equipo.

Historia de Usuario


Nombre historia: Autenticación de usuarios

Prioridad en negocio: Alta Riesgo en desarrollo: Alta



Descripción:

Para el acceso a la aplicación se requiere contar con un usuario y contraseña

previamente registrados en el sistema.

Observaciones:

Los usuarios deberán ser notificados por el Administrador del sistema respecto

a los permisos de acceso al sistema.

Historia de Usuario


Nombre historia: Diseño de interfaz


138



Descripción:

Se requiere la estructuración y desarrollo de la interfaz del sistema, se tomar

en cuenta las siguientes consideraciones:

Diseño de menú desplegable en base a la distribución de las opciones

establecidas por el usuario

Colores y tipo de letra en base a los requerimientos del usuario

Observaciones:

139

B. Tareas Historias de Usuario

Tarea

Número tarea: 1 Número historia: 2

Nombre tarea: Diseño de base de datos para iteración 1

Tipo de tarea : Desarrollo Puntos estimados: 1

Fecha inicio: 17 de noviembre de 2014 Fecha fin: 21 de noviembre de 2014


Descripción:

Para realizar la administración de usuarios, canchas, equipos, deportistas y

catálogos de la iteración 1, se requiere realizar el diseño y modelamiento de la

base de datos, teniendo en cuenta siempre la integridad de la información.

Para realizar el modelamiento se debe seguir los siguientes puntos:

Crear una estructura de tablas para almacenar la información de

deportistas, tomando en cuenta que los árbitros también lo son.

Crear una estructura de tablas para almacenar los equipos de los

diferentes tipos de deporte, esta estructura debe tomar en cuenta el

nombre del equipo, colores primarios y secundarios del mismo.

Para la administración de catálogos generales se debe crear una

estructura de tablas que se manejen como cabecera y detalle, de tal

forma que en la cabecera se tengan los nombres de los catálogos

generales como Tipo de Deportista, Colores, Estado Civil, etc. Y en el

detalle se pueda almacenar todo el contenido de los catálogos

generales.

Para la administración de canchas de juego se debe crear una relación

con la tabla de detalle catálogos para poder guardar el tipo de deporte

al que pertenece, y permitir el registro del nombre de la cancha.

Para la administración de equipos se debe crear relaciones con la tabla

140

de detalle de catálogos para que se pueda registrar el tipo de deporte y

los colores primarios y secundarios del equipo.

Para la autenticación de usuarios se debe generar una estructura de

tablas que permita el almacenamiento de los datos de los usuarios, de

acuerdo a los roles que mantengan cada uno para el acceso a las

diferentes opciones del sistema.

Generar un script de base de datos que almacene en la tabla de

cabecera del catálogo general, los parámetros generales que se

requiere dentro del sistema.

Tarea


Nombre tarea: Administración de deportistas


Fecha inicio: 30 de noviembre de 2014 Fecha fin: 17 de diciembre de 2014


Descripción:

Para la administración de usuarios se requiere realizar las siguientes acciones:

Realizar una interface para que el usuario pueda registrar, actualizar e

inactivar los datos personales de cada deportista.

Se debe respetar la programación capas de la arquitectura JEE6.

Permitir que se escoja de listas el tipo de deportista, estado civil y

facultad a la que pertenece el deportista.

Realizar la validación de la información que registra el usuario, en caso

de haber errores, el sistema debe informar mediante mensajes de

advertencia o error.

Luego de validar la información se debe almacenar en la estructura de

base de datos, para confirmar que la información fue guardada se debe

141

mostrar mensaje de información.

Validar que no se registre números de cédulas duplicados.

Realizar un método que genere números de carnet aleatorio y único

para asignar a cada deportista.

Tarea


Nombre tarea: Parametrización de árbitros




Descripción:

Para la administración de usuarios se requiere realizar las siguientes acciones:

Realizar una interface para que el usuario pueda registrar, actualizar e

inactivar los datos personales de los árbitros.


Permitir que se escoja de listas el tipo de deportista, estado civil y

facultad a la que pertenece el deportista.

Realizar la validación de la información que registra el usuario, en caso

de haber errores, el sistema debe informar mediante mensajes de

advertencia o error.

Luego de validar la información se debe almacenar en la estructura de

base de datos, para confirmar que la información fue guardada se debe

mostrar mensaje de información.

Validar que no se registre números de cédulas duplicados.

142

Tarea


Nombre tarea: Parametrización de canchas de juego


Fecha inicio: 01 de diciembre de 2014 Fecha fin: 08 de diciembre de 2014


Descripción:

Para realizar la administración de las canchas de juego se deben tomar en

cuenta los siguientes puntos:

Realizar una interface de usuario que permita registrar, actualizar e

inactivar los registros de canchas de juego.


El sistema debe permitir registrar el nombre y una descripción de la

cancha.

Se debe seleccionar de una lista el tipo de deporte al que pertenece la

cancha de juego.

Realizar la validación de los datos para el registro de la información.

En caso de errores el sistema debe emitir mensajes de advertencia o

error.

Cuando la validación de la información es correcta se debe registrar los

datos en las tablas respectivas y el sistema debe emitir mensajes de

información.

143

Tarea


Nombre tarea: Administración Equipos




Descripción:

Para la administración de equipos se debe tener en cuenta los siguientes

puntos a seguir:

Realizar una interface de usuario que permita el registro, edición e

inactivación de los registros de equipos.

Se debe respetar la programación en capas de la arquitectura JEE6.

El sistema debe permitir el registro del nombre, seleccionar de una lista

los colores primarios y secundarios y tipo de deporte del equipo.

Realizar las validaciones respectivas, y en caso de existir errores emitir

mensajes de advertencia o error dependiendo del caso.

Cuando las acciones culminen con éxito se deben emitir mensajes de

información que evidencien los hechos.

Tarea


Nombre tarea: Administración de catálogos generales




144

Descripción:

Para la administración de catálogos del sistema se deben tener en cuenta dos

puntos:

Administración de la cabecera de los catálogos

o Se debe realizar una interface de usuario que permita

únicamente la edición del nombre del catálogo.

o El sistema debe emitir mensaje de advertencia, confirmación o

error dependiendo del caso.

o Se debe respetar la programación en capas de la arquitectura

JEE6 de programación.

Administración del detalle de los catálogos

o Se debe realizar una interface de usuario que permita el registro,

edición e inactivación de la descripción del detalle de catálogo.

o El sistema debe realizar la validación correspondiente para

permitir el registro de la información.

o El sistema debe emitir mensajes de advertencia, confirmación o

error dependiendo del caso y cuando sea necesario.

o Se debe respetar la programación en capas de la arquitectura

JEE6.

Tarea


Nombre tarea: Desarrollo de funcionalidad




Descripción:

145

Construcción de pantalla para autenticación.

Codificación para validar autenticación desde el sistema

Tarea


Nombre tarea: Configuración en la base de datos




Descripción:

Creación de tablas y scripts para validar la autenticación de los usuarios.

Tarea


Nombre tarea: Diseño de base de datos de la Iteración 2




Descripción:

Para la administración de usuarios, campeonatos, partidos, horarios y

calendarios, es necesario modificar el esquema de base de datos y adecuar

las nuevas estructuras de tablas, se debe tomar en consideración los siguiente

puntos:

Crear la estructura de tablas para partidos que permita registrar la fase,

146

fecha de inicio, fecha de finalización del partido, también que mantenga

integridad referencial con las canchas, árbitros, equipos y campeonatos.

Crear la estructura de las tablas para campeonatos que permita el

registro del nombre del partido, fecha de creación, estado y mantenga

integridad referencial con el tipo de deporte y canchas.

Crear una tabla que permita el registro de deportistas por equipo, que

mantenga integridad referencial con las tablas de equipos y deportistas,

y además permita el almacenar el estado del registro.

Tarea


Nombre tarea: Administración de usuarios


Fecha inicio: 23 de febrero de 2015 Fecha fin: 09 de marzo de 2015


Descripción:

Se requiere la creación de objetos en la base para almacenar la

información de los usuarios

Es necesario desarrollar la funcionalidad para realizar las siguientes

acciones desde el sistema:

o Búsqueda por cédula y nombre

o Guardar nuevos usuarios

o Editar los datos de los usuarios del sistema

147

Tarea


Nombre tarea: Administración de Campeonatos


Fecha inicio: 28 de diciembre de 2014 Fecha fin: 20 de febrero de 2015


Descripción:

Realizar la interface de usuario para realizar el registro de los

campeonatos que organice la Facultad de Cultura Física.


Se debe visualizar los nombres de los equipos y la fase de juego.

Se debe permitir el registro del nombre del campeonato

Se debe permitir seleccionar de una lista el tipo de campeonato que se

va a generar con su respectivo algoritmo de clasificación.

Se debe permitir seleccionar de una lista el tipo de deporte al que

pertenece.

Se debe mostrar todos los equipos registrados y el usuario debe

seleccionar los equipos que van a conformar el campeonato.

El sistema debe ejecutar el algoritmo de clasificación de partidos y

almacenar en la base de datos los partidos generados para ese

campeonato

El sistema debe emitir mensajes de error, advertencia o información

dependiendo de cada caso.

148

Tarea


Nombre tarea: Resultados de partidos de fútbol


Fecha inicio: 13 de febrero de 2015 Fecha fin: 23 de febrero de 2015


Descripción:

Realizar la interface de usuario para realizar el registro de los partidos

de fútbol.


Se debe permitir seleccionar de una lista el nombre del campeonato.

En base al campeonato el sistema debe desplegar el número de fechas

En base a la fecha seleccionada el sistema debe desplegar los

encuentros.

En base a los encuentros el sistema debe desplegar a los jugadores de

cada equipo.

El sistema debe permitir seleccionar un jugador y registrar si anotó un

gol.

El sistema debe permitir seleccionar un jugador y registrar si se lesionó.

El sistema debe permitir seleccionar un jugador y registrar si fue

amonestado.

El sistema debe permitir seleccionar un jugador y registrar si fu

expulsado.


dependiendo de cada caso

149

Tarea


Nombre tarea: Resultados de partidos de básquet

Tipo de tarea :

Desarrollo Puntos estimados: 3



Descripción:


de básquet.





encuentros.


cada equipo.

El sistema debe permitir seleccionar un jugador y registrar si anotó un

aro.



amonestado.


expulsado.



150

Tarea


Nombre tarea: Resultados de partidos de vóley




Descripción:


de vóley.





encuentros.


cada equipo.



amonestado.


expulsado.



151

Tarea


Nombre tarea: Algoritmos de clasificación de partidos


Fecha inicio: 28 de diciembre de 2014 Fecha fin: 10 de enero de 2015


Descripción:

Realizar el algoritmo del tipo de campeonato para que el sistema realice

el emparejamiento de los equipos para conformar los partidos en las

diferentes fases.


Tarea


Nombre tarea: Programación de encuentros




Descripción:

Realizar la interface de usuario para realizar el registro de la

programación de partidos, se debe permitir almacenar la fecha de inicio

y finalización del partido, teniendo en cuenta que la fecha de inicio no

debe ser mayor a la fecha de finalización.

152


Se debe visualizar los nombres de los equipos y la fase de juego.

Se debe seleccionar de una lista las canchas disponibles.

Se debe seleccionar de una lista los árbitros disponibles.

Se debe validar que las canchas y árbitros estén disponibles para dirigir

el encuentro.



Tarea


Nombre tarea: Conformación de Equipos




Descripción:

Realizar la interface de usuario para realizar la conformación de

equipos.


Se debe seleccionar el tipo de deporte de una lista.

De acuerdo con el tipo de deporte seleccionado, se debe escoger de

una lista desplegable el equipo que se desea conformar.

El sistema debe mostrar el número mínimo de jugadores por tipo de

deporte.

El sistema debe mostrar el número máximo de jugadores por tipo de

deporte.

El sistema debe mostrar el número de jugadores inscritos en ese

153

equipo.

El sistema debe dar la facilidad al usuario a que este seleccione a los

jugadores que van a jugar en el equipo y seleccionarlos.

Se debe validar que el número de jugadores no sea menor al mínimo de

jugadores requeridos.



Tarea


Nombre tarea: Validación de deportistas en Equipos


Fecha inicio: 01 de marzo de 2015 Fecha fin: 13 de marzo de 2015


Descripción:


Se debe validar que el número de jugadores no sea menor al mínimo de

jugadores requeridos.

Se debe validar que el número de jugadores no sea mayor al máximo

de jugadores requeridos.



154

Tarea


Nombre tarea: Configuración de correos electrónicos




Descripción:

Solicitar a la facultad de Cultura Física una cuenta de correo electrónico

para el Sistema.

Configuración de cliente de correo electrónico para que sea el

encargado de realizar el envío de los e-mails a los deportistas

registrados dentro de un campeonato.

Configuración de la cuenta de correo electrónico en java para utilizarlo

dentro del sistema.

Validación del envío de e-mails mediante el cliente creado.

Respetar la programación en capas de la arquitectura JEE6.

Tarea


Nombre tarea: Envío de correos electrónicos




Descripción:

155

Incluir en el sistema el método de envío de e-mails para que se realice

de manera automática en el momento del registro total de encuentros

en una fecha determinada.

Validar que los correos electrónicos sean enviados con éxito.

En caso de errores al envío de correos electrónicos enviar alertas al

administrador del sistema para que tome los correctivos necesarios.


Tarea


Nombre tarea: Seguimiento de deportistas


Fecha inicio: 31 de marzo de 2015 Fecha fin: 06 de abril de 2015


Descripción:

Realizar una interface gráfica para que el usuario pueda realizar el

seguimiento de los deportistas registrados en el sistema.


Para la búsqueda de los deportistas, se debe ingresar el número de

cédula y el sistema mostrará toda la información requerida del

deportista.

Otra forma de búsqueda también será el ingreso de apellidos y nombres

del deportista.

La información que se presente al usuario será únicamente de lectura,

es decir no se podrá modificar ningún campo dentro de la interface de

usuario.

El sistema tiene que dar la opción de guardar el reporte como un

156

documento en formato PDF.

Se presentará la siguiente información del deportista

o Número de cédula

o Nombres y apellidos

o Dirección del domicilio

o Correo electrónico

o Número de celular

o Nombre del Campeonato

o Tipo de deporte

o Nombre del equipo

o Nombre de la facultad

o Lesiones

o Amonestaciones

o Expulsiones

o Anotaciones

o Número de partidos disputados

Tarea


Nombre tarea: Reporte de fechas de juego


Fecha inicio: 06 de abril de 2015 Fecha fin: 18 de abril de 2015


Descripción:

En caso de ser necesario, realizar una vista en la base de datos que

contenga la información necesaria para generar un reporte con las

fechas de juegos de un campeonato predeterminado.

Realizar una interface gráfica para que el usuario pueda consultar las

157

fechas de juego del campeonato en el que se encuentra inscrito.


Para la búsqueda de los deportistas, se debe seleccionar de una lista el

nombre del campeonato.

Para facilitar la visualización de la información, el sistema debe permitir

seleccionar la el número de fecha de juego, para que se muestren los

encuentros a disputarse en la misma.



usuario.



Se presentará la siguiente información

o Nombre del campeonato

o Tipo de deporte

o Número de equipos participantes

o Fechas y horarios por encuentros

o Árbitros de cada encuentro

o Nombre de la cancha en la que se jugará el partido

Tarea


Nombre tarea: Reporte de fechas de juego




Descripción:


158

contenga la información necesaria para generar un reporte con los

máximos anotadores por campeonato.

Realizar una interface gráfica para que el usuario pueda consultar

quienes son los máximos anotadores de cada campeonato.






usuario.

Se presentará únicamente a los 15 primeros deportistas que registren

más anotaciones.

No se visualizarán jugadores con menos de una anotación.





o Tipo de deporte

o Nombres y apellidos del deportista

o Número de anotaciones realizadas a la fecha

Tarea


Nombre tarea: Reporte de máximos anotadores




Descripción:

159


contenga la información necesaria para generar un reporte con los

máximos anotadores por campeonato.

Realizar una interface gráfica para que el usuario pueda consultar

quienes son los máximos anotadores de cada campeonato.






usuario.

Se presentará únicamente a los 15 primeros deportistas que registren

más anotaciones.

No se visualizarán jugadores con menos de una anotación.

Sólo aplica para los deportes de fútbol y vóley.





o Tipo de deporte

o Nombres y apellidos del deportista

o Número de anotaciones realizadas a la fecha

Tarea


Nombre tarea: Reporte de resultados de partidos


Fecha inicio: 01 de mayo de 2015 Fecha fin: 15 de mayo de 2015

160


Descripción:

Se debe realizar un reporte que permita al usuario visualizar el

resultado que se ha registrado en cada uno de los partidos disputados.

Respetar la programación en capas de la arquitectura JEE6





o Tipo de deporte

o Nombres de los equipos

o Número de anotaciones por equipo (Fútbol y Vóley)

o Nombres de los jugadores que anotaron por cada equipo (Fútbol

y Vóley)

o Nombres de los jugadores amonestados de cada equipo

o Nombres de los jugadores expulsados de cada equipo

o Nombre del árbitro

o Nombre de la cancha de juego

Tarea


Nombre tarea: Reporte de tablas de posiciones


Fecha inicio: 15 de mayo de 2015 Fecha fin: 29 de mayo de 2015


Descripción:

161


contenga la información necesaria para generar un reporte las tablas de

posiciones.

Se debe realizar un reporte que permita al usuario visualizar la tabla de

posiciones de los equipos participantes del torneo.






o Tipo de deporte

o Nombres de los equipos

o Número de partidos jugados

o Número de partidos ganados

o Número de partidos empatados

o Número de partidos perdidos

o Número de anotaciones a favor (Sólo fútbol y básquet)

o Número de anotaciones en contra (Sólo fútbol y básquet)

o Número de puntos

Tarea


Nombre tarea: Carnets de jugadores


Fecha inicio: 29 de mayo de 2015 Fecha fin: 13 de junio de 2015


Descripción:

Se debe generar un método que emita números aleatorios que no se

162

repitan para identificar a cada uno de los jugadores registrados en el

sistema.

Se debe realizar un reporte que permita al usuario visualizar una ficha

con la información necesaria para imprimir un carnet de jugador.





o Número único del carnet

o Nombres y apellidos del jugador

o Equipo al que pertenece el jugador


o Tipo de deportista (Docente, Árbitro, Estudiante, Administrativo)

o Universidad Central del Ecuador

Tarea


Nombre tarea: Lesionados


Fecha inicio: 15 de mayo de 2015 Fecha fin: 01 de julio de 2015


Descripción:

Se debe crear una interface de usuario que permita la visualización de

los deportistas que han sufrido lesiones durante el campeonato.




163


o Nombre de campeonato

o Tipo de deporte

o Equipo a que pertenece


o Descripción de la lesión

Tarea


Nombre tarea: Amonestaciones


Fecha inicio: 18 de mayo de 2015 Fecha fin: 03 de julio de 2015


Descripción:

Se debe crear una interface de usuario que permita la visualización de

los deportistas que sido amonestados o expulsados durante el

campeonato.





o Nombre de campeonato

o Tipo de deporte

o Equipo a que pertenece


o Tipo de amonestación

164

Tarea


Nombre tarea: Configuración de componentes JEE6


Fecha inicio: 27 de octubre de 2014 Fecha fin: 14 de noviembre de 2014


Descripción:

El ambiente para la configuración del proyecto va a constar de los

siguientes componentes:

o IDE de Desarrollo Eclipse Juno

o Java Persistence Api (JPA 2.0)

o Enterprice JavaBeans (EJB 3.1)

o Java Server Faces (JSF 2.0)

o RichFaces 4.2

o Base de Datos PostgreSQL 9.3

o Servidor de aplicaciones JBoss Community 7.1

universidad central del ecuador - repositorio digital ... · facultad de ingenierÍa, ciencias...

Documents