Organizacion_y_administracion_deportiva

Vista previa del material en texto

“ SISTEMA DE INFORMACIÓN PARA 
LA ORGANIZACIÓN Y ADMINISTRACION DE 
CAMPEONATOS PARA DEPORTES DE CONJUNTO 
SPORTACUS”  
FUNDACION UNIVERSITARIA KONRAD LORENZ 
FACULTAD DE INGENIERIA DE SISTEMAS 
PROYECTO DE GRADO 
BOGOTÁ D.C. 
2007
“ SISTEMA DE INFORMACIÓN PARA 
LA ORGANIZACIÓN Y ADMINISTRACION DE 
CAMPEONATOS PARA DEPORTES DE CONJUNTO 
SPORTACUS”  
JEISON ANTONIO MURILLO CRUZ 
JORGE ERNESTO ROA TORRES 
Director 
HECTOR ARTURO FLOREZ FERNANDEZ 
Ingeniero Electrónico, Ingeniero de Sistemas 
MSc en Ciencias de Información y Comunicaciones 
FUNDACION UNIVERSITARIA KONRAD LORENZ 
FACULTAD DE INGENIERIA DE SISTEMAS 
BOGOTÁ D.C. 
2007
“ SISTEMA DE INFORMACIÓN PARA 
LA ORGANIZACIÓN Y ADMINISTRACION DE 
CAMPEONATOS PARA DEPORTES DE CONJUNTO 
SPORTACUS”  
JEISON ANTONIO MURILLO CRUZ 
JORGE ERNESTO ROA TORRES 
Director 
HECTOR ARTURO FLOREZ FERNANDEZ 
Ingeniero Electrónico, Ingeniero de Sistemas 
MSc en Ciencias de Información y Comunicaciones 
Trabajo presentado para optar al 
Titulo de Ingeniero de Sistemas 
FUNDACION UNIVERSITARIA KONRAD LORENZ 
FACULTAD DE INGENIERIA DE SISTEMAS 
BOGOTÁ D.C. 
2007
NOTA DE ACEPTACION 
JURADO: 
JURADO: 
DIRECTOR:
RESUMEN 
Para  esta  nueva  era  donde  se  requiere  dominar  los  nuevos  conceptos  de 
informática, comunicaciones, multimedia, realidad virtual, las artes y el diseño que 
se  desprenden  de  los  sistemas  digitales  y  tridimensionales.  El  Sistema  de 
Información  para  la  Organización  y  Administración  de  Campeonatos  para 
Deportes  de  Conjunto  “Sportacus”  facilita  la  organización  de  los  procesos  y 
apoyos logísticos en la realización de eventos deportivos. El programa contribuye 
a  la  optimización  del  trabajo,  agilización  y  la  exactitud  en  el  manejo  de  los 
resultados  estadísticos  en  cualquier  disciplina  deportiva.,  desarrollado  bajo 
ambiente WEB utilizando metodología SCRUM y aplicando  los conocimientos de 
desarrollo en ingeniería de software como proyecto de grado. 
ABSTRACT 
For  this  new  era  which  requires  mastering  new  concepts  of  computer, 
communications,  multimedia,  virtual  reality,  the  arts  and  design  that  flow  from 
digital systems and three­dimensional. 
The  information system  for  the organization and administration of  championships 
for  sports  package  "Sportacus"  facilitates  the  organization  of  processes  and 
Logistic support in the organization of sporting events. The program contributes to 
the optimization of work, streamlining and accuracy in handling statistical results of 
any  sport,  developed  under  Web  environment  using  methodology  scrum  and 
applying knowledge for development in software engineering and project level.
DEDICATORIA 
A mis padres porque tuvieron toda la paciencia para saberme comprender cuando no 
tenia tiempo para ellos, gracias por su apoyo, gracias por guiarme por el camino correcto 
y por inculcarme tan excelentes valores con los que fui formado y de nuevo gracias 
porque sin ellos no hubiese sido posible cumplir este sueño la ayuda que me brindaron 
para poder hacer realidad este sueño. 
Jeison Murillo 
A mis hijos Santiago y Juan Pablo por que me fortalecen cada día con su amor y 
camaradería, a mi querida esposa Paola, quien con su apoyo incondicional y calidez ha 
estado siempre presente, a mi madre quien con esfuerzo y sacrificio logro llevarme 
siempre por el mejor camino. Este es un paso más de la larga travesía que de ahora en 
adelante continúa. Una meta se ha cumplido y el esfuerzo da frutos con este logro. 
Jorge Roa
AGRADECIMIENTOS 
Quiero expresar mis agradecimientos a Dios quien nos fortaleció en cada uno de esos 
momentos en que sentíamos desfallecer, a mi amigo Jeison por acompañarme 
incondicionalmente, a mi familia que soporto muchas ocasiones de mis ausencias, al 
Ingeniero Héctor Florez por guiarnos y brindarnos su apoyo y gran conocimiento, gracias a 
quien de una u otra forma colaboro para que lográramos nuestro objetivo a todos ellos 
muchas gracias. 
Jorge Roa 
A Dios por darnos todo su apoyo, la oportunidad y la sabiduría para poder alcanzar este 
objetivo y un sueño tan anhelado, gracias a mi gran amigo el “chato Roa” por sus 
concejos, colaboración y apoyo incondicional, gracias por ser mi compañero de 
proyecto y trabajar juntos día y noche para lograr nuestro objetivo, gracias al Ingeniero 
Héctor Florez por su apoyo, por compartir su conocimiento, por su colaboración, por la 
paciencia que nos tuvo y por ser parte de este gran equipo de trabajo, a todos mis 
amigos y familiares por apoyarme, por la ayuda que me brindaron para poder hacer 
realidad este sueño. 
Jeison Murillo 
Queremos expresar nuestro especial agradecimiento a: 
A el Ingeniero Pervys Rengifo Por inculcarnos la constancia y tenacidad pues las cosas no 
son difíciles y menos para un estudiante de la Konrad. 
“Difícil NO Sencillo” 
A todos nuestros compañeros y amigos que de una u otra forma nos llenaron de 
experiencias y sentimientos, su constante apoyo, sus innumerables y valiosas orientaciones 
en este último proceso académico y formativo de nuestra carrera. 
A todos ellos mil gracias y cuentan con nosotros.
1 
1.  INTRODUCCION 
Los encuentros deportivos toman un carácter específico cuando nos ponemos en 
la  tarea  de  comparar  rendimientos  mediante  la  caracterización  de  situaciones 
concretas  en  las  competiciones,  es  aquí  donde  dichos  resultados  toman 
importancia cuando se cuantifican y se traducen en récords o registros. 
El ganador de una competición y el  rendimiento del mismo deben ser abstraídos 
de la persona o equipo y se deben traducir en cifras, fechas, tiempos y distancias. 
Que deberán ser almacenadas y posteriormente comparadas con otros  registros 
para  generar  listados  de  posiciones,  rankings,  mejores  tiempos  y  marcas,  para 
que deportistas entrenadores y las diferentes organizaciones puedan consultarlas 
y tomar decisiones en la gestión de su labor deportiva. 
Dentro  de  las  diversas  funciones  que  las  competiciones  deportivas  conllevan 
encontramos  la  de  la  organización  y  gestión  deportiva,  que  es  en  la  cual  nos 
enfocaremos es decir;  tomar  todos  los registros e  información útil, organizarlos y 
presentarlos  de  tal  manera  que  sean  claros,  exactos  y  en  tiempo  oportuno 
procurando siempre el aprovechamiento máximo de  los  recursos con un manejo 
eficiente y facilitando los procesos de la administración como son la planificación, 
organización, dirección y control. 
El propósito del presente trabajo de grado es demostrar el conocimiento adquirido 
a  lo  largo de nuestro  recorrido  académico  en  la  Fundación Universitaria Konrad 
Lorenz,  desarrollando  una  aplicación  que  permita  facilitar  la  organización  y 
administración  de  campeonatos  para  deportes  de  conjunto  básicos  como  son el 
Baloncesto, Fútbol, Futsal y Voleibol. Mediante el adecuado proceso de análisis, 
diseño, desarrollo, e implantación de una herramienta basada en las Tecnologías 
de  Información  el  aprovechamiento  de  los  avances  tecnológicos  y  con  altos 
estándares de calidad.
2 
2.  MARCO DE REFERENCIA. 
2.1.  ANTECEDENTES 
“Ya  desde  1830  comenzó  la  formación  en  todos  los  países  de  asociaciones 
deportivas especializadas y con el desarrollo de una entidad oficial de medidas y 
de  récords  (asociaciones  deportivas)  se  creó,  primero  en  Gran  Bretaña  y  en 
Estados  Unidos,  un  sistema  de  competición  nacional  en  los  tipos  de  deporte 
típicos nacionales. 
Como consecuencia de la orientación hacía los records, se llegó rápidamente a la 
creación de los primeros campeonatos mundiales, en los que casi exclusivamente 
había participación anglosajona. 
La continua extensión de la competición deportiva y el ansia de las capas sociales 
más  bajas  por  tomar  parte  en  las  competiciones  acarrearonla  reacción  de 
limitaciones sociales por parte de los gentleman y bourgeois (nobles y burgueses). 
Las  reglas  amateurs  (por  primera  vez  en  1864)  prohibieron  que  los  deportistas 
profesionales,  los  artesanos  y  los  trabajadores  tomaran  parte  en  las 
competiciones. 
Pero  en  el  plano  nacional,  junto  a  esas  asociaciones  amateurs,  también  se 
crearon asociaciones donde no estaba excluida la población trabajadora y la gente 
de oficio, así como las asociaciones puras de deporte profesional” 1  (texto tomado 
y modificado de Teoría y Metodología de la Competición Deportiva). 
1 Günter Thies, Peter Tschiene, Helmut Nicket; Teoría y Metodología de la Competición Deportiva. 
Editorial Paidotribo.
3 
Estos  cambios  fundamentales  en  el  deporte  dieron  paso  a  la  modernización  y 
aplicación de métodos y herramientas para la administración de esta información. 
A nivel internacional son muchas las aplicaciones existentes para tal fin, pero en el 
ámbito nacional son escasas y por no decirlo nulas,  las herramientas apropiadas 
para el manejo y control de estos resultados. 
Es así como organismos como el Instituto Colombiano del Deporte Coldeportes, el 
Instituto Distrital para la Recreación y el Deporte IDRD o cajas de compensación 
familiar  como  Confenalco  o  Compensar  que  están  trabajando  en  el  ámbito 
deportivo no cuentan con aplicaciones diseñadas  específicamente para este tipo 
de  trabajo,  sino  que  aprovechan de  las  bondades de programas  como hojas  de 
calculo o aplicaciones rudimentarias para el manejo de  su información. 
Es  también  importante  recalcar  que  muchas  de  las  ligas  deportivas  tampoco 
cuentan con este tipo de aplicaciones y que son muy pocas las que lo tienen.
4 
2.2.  JUSTIFICACIÓN 
En  la  actualidad  las  personas  que  tienen  el  manejo  del  deporte,  tanto  en  los 
organismos deportivos del sector   privado, como en el de los entes estatales, se 
enfrentan diariamente a situaciones que no son  fáciles de  resolver y en algunas 
oportunidades se están tomando decisiones afectando a deportistas y procesos en 
la actividad deportiva bien sea por desconocimiento de la normatividad, las pocas 
oportunidades de capacitación o las diversas interpretaciones de la norma. 
Con  el  manejo  de  las  tecnologías  de  la  información  y  la  utilización  de  nuevos 
avances  tecnológicos  es  necesario  contar  con  herramientas  que  permitan  el 
correcto y efectivo manejo de la información de una competencia deportiva. Como 
ingenieros  de  sistemas  enfocamos  nuestras  acciones  en  el  desarrollo  de 
aplicaciones  que  puedan  satisfacer  las  necesidades  que  se  presentan  en 
diferentes ámbitos, es así como vemos que para la administración deportiva es de 
mucha utilidad la aplicación de herramientas  tecnológicas que  faciliten la gestión 
de  organización  y  control  de  campeonatos,  equipos,  jugadores,  estadísticas  e 
informes.  De  igual  forma se pretende que  los   profesionales del área deportiva, 
cuenten  con  algunas  técnicas  administrativas  puesto  que  hoy  la  actividad 
deportiva no se encuentra al margen de la actividad empresarial. 
Como parte de nuestra formación académica, aprovecharemos los conocimientos 
adquiridos  en  las  diferentes  asignaturas  para  desarrollar  una  aplicación  que 
permita facilitar las tareas que  cualquier organización deportiva realiza, el manejo 
de  bases  de  datos,  el  desarrollo  de  software,  la  utilización  de  lenguajes  de 
programación  modernos  y    el  aprovechamiento  de  los  ambientes  Web  nos 
permitirán  presentar  un  producto  con  altos  estándares  de  calidad  y  de  esta 
manera obtener nuestra titulación.
5 
Creemos que un programa para la organización y administración de campeonatos 
para  deportes  de  conjunto  es  una  herramienta  útil  para  las  organizaciones 
deportivas  y  un  excelente  motivo  para  demostrar  nuestras  capacidades  como 
ingenieros.
6 
3.  FORMULACIÓN DEL PROBLEMA 
Desde  siempre  se  ha  definido  la  competición  deportiva  como  una  comparación 
entre  el  rendimiento  de  deportistas  individuales  o  de  grupos  de  deportistas 
(equipos), buscando alcanzar metas o  logros deportivos, que solo son  reflejados 
en las marcas o resultados estadísticos que estos puedan alcanzar. 
Pero a lo largo del transcurso del desarrollo deportivo se han añadido, cambiado, 
vuelto  a  proponer  o  también  se  han  suprimido,  diferentes  aspectos  que  han 
servido  para  una  definición  más  pormenorizada  de  la  competición.  Así,  por 
ejemplo, a partir de los juegos modernos en el siglo XIX, se han introducido y se 
ha hecho de obligado  cumplimiento  el manejo  de estadísticas  e  informes  de  las 
competiciones deportivas. En la actualidad, los siguientes rasgos y características 
son fundamentales y decisivos para la esencia de las competiciones. 
Es por esto que se hace necesario la utilización de diferentes herramientas para la 
organización  y  administración  de  las  competencias,  en  nuestro  país  son  muy 
pocas las organizaciones deportivas que cuentan con este tipo de aplicaciones o 
si las tienen no han sido ajustadas a las necesidades propias de nuestro entorno. 
Basándonos en consultas  realizadas a diferentes organizaciones  tanto del orden 
privado  como  oficial  vemos  que  en  muchos  de  los  casos  se  utilizan  hojas  de 
cálculo u otro tipo de programas para este fin y que no cuentan con una aplicación 
adecuada para el manejo de la información. 
Como parte de nuestro proceso de formación y cumpliendo con los requerimientos 
para  la  obtención  del  titulo  de  ingenieros  de  sistemas,  desarrollaremos  una 
aplicación  que  permita  a  los  diferentes  profesionales  en  las  áreas  del  deporte 
manejar  de  manera  efectiva  los  procesos  de  gestión  en  las  competiciones 
deportivas
7 
4.  OBJETIVOS 
4.1.  OBJETIVO GENERAL 
Realizar  la  investigación,  diseño  y  desarrollo  de  un  sistema  de  información  con 
altos estándares de calidad, aprovechando los últimos avances tecnológicos, para 
la organización y administración de competiciones deportivas que permita facilitar 
las tareas que se deben realizar para la correcta gestión deportiva. 
4.2.  OBJETIVOS ESPECÍFICOS 
• Desarrollar  una  aplicación  dinámica  con  altos  estándares  de  calidad  que 
permita  el  adecuado  manejo  de  la  gestión  deportiva,  por  parte  de 
profesionales en las áreas del deporte. 
• Aplicar la metodología  (Scrum) para Desarrollo de Software  y evaluar sus 
resultados. 
• Realizar  el  diseño  del  sistema  de  información,  utilizando  el  lenguaje  de 
modelado unificado UML. 
• Hacer  uso  de  bases  de  datos  relacionales  con  licencia  de  software  libre 
para el almacenamiento de la Información pertinente al sistema. 
• Desarrollar  un  sistema  de  información  en  entorno  WEB  utilizando 
herramientas de software libre. 
• Desarrollar  módulos  de  gestión  aplicables  al  ambiente  Web,  para  la 
administración  de  los  diferentes  elementos  como:  incorporación  de  los
8 
deportes,  creación  de  campeonatos,  inscripción  de  equipos  y  jugadores, 
acreditaciones  de  jugadores  y  personal  técnico,  manejo  de  resultados, 
control  de  estadísticas  y  reportes,  necesarios  para  la  correcta  gestión 
deportiva. 
• Permitir  que  la  aplicación  nos  presente  estadísticas  e  informes,  de 
jugadores, equipos, campeonatos, escenarios, datos interesantes, etc. 
• Incorporar  información  referente  a  cada  disciplina  deportiva  con  sus 
aspectos  fundamentales  como  historia,  reglamentación,  sistemas  de 
competencia, generación de torneos y datos de interés social. 
• Implantar el sistema de  información mediante  la publicación de la base de 
datos  y  módulos  del  mismo,  utilizando  un  servidor Web  con  un  dominio 
propio.• Realizar  pruebas  parciales  y  globales  de  cada  modulo  o  producto 
entregable, para el aseguramiento de la calidad del sistema de información. 
• Elaborar la documentación suficiente del sistema de  información con el  fin 
de  revelar  a  la  comunidad  las  técnicas  y  metodologías  utilizadas  en  el 
proceso de desarrollo.
9 
5.  ALCANCES Y LIMITACIONES 
El uso de las Tecnologías de la Información en proyectos como el aquí propuesto 
nos permiten desarrollar nuestras capacidades y demostrar  los  logros adquiridos 
en  el  transcurso  de  nuestro  aprendizaje  en  la  Fundación  Universitaria  Konrad 
Lorenz. 
El lograr implementar una herramienta informática para el desarrollo de la gestión 
en  organizaciones  deportivas  y  más  importante  aun  la  obtención  de  nuestra 
titulación  son  los  incentivos  primordiales  en  la  elaboración  de  este  proyecto.  El 
aprovechamiento de los recursos tecnológicos, permitirán un mejor desempeño en 
las labores realizadas por los profesionales del área del deporte 
En  este  contexto,  los  resultados  de    este  proyecto  beneficiarán  directamente  a 
profesionales del área del deporte, deportistas, entrenadores organismos estatales 
y  privados,  especialmente  en aquellos  casos en que dichos  usuarios  no posean 
capacidad ni el conocimiento suficiente para organizar campeonatos completos. El 
beneficio a estos destinatarios consiste en que se les proveerá de una herramienta 
capaz  de  apoyar  su  gestión,  permitiendo  así  el  buen  manejo  de  estadísticas, 
controles, inscripciones entre otras. 
Sabemos que nuestras  limitaciones son muchas, por eso planteamos un análisis 
donde  podamos  determinar  cuales  son  nuestras  oportunidades,  amenazas 
fortalezas  y  debilidades,  y  de  esta  manera  organizar  de  manera  optima  el 
desarrollo de nuestro proyecto.
10 
5.1.  ANALISIS DOFA 
5.1.1. OPORTUNIDADES: 
• Los grandes  desarrollos  en  ciencia,  tecnología  e  innovación,  demandarán 
nuevos programas y mayor creación y transferencia de conocimiento puro y 
aplicado. 
• Demanda de  recursos  humanos  altamente  calificados  en el  análisis  de  la 
información,  capaces  de  abordar  y  enfrentar  nuevos  problemas  y  buscar 
soluciones creativas 
• Las  crecientes  tendencias  de  integración  y  de  cooperación  nacional  e 
internacional en la transferencia adecuada de información. 
• La  creciente  demanda  de  nuevos  conocimientos  y  de  servicios 
especializados por parte de organizaciones nacionales e internacionales. 
• El  surgimiento  de  nuevas  formas  de  aprendizaje  y  apropiación  del 
conocimiento generado por el avance vertiginoso de  las  tecnologías de  la 
información y la comunicación. 
5.1.2. AMENAZAS: 
• El  surgimiento  de  nuevas  organizaciones  y  centros  de  investigación 
científica y tecnológica nacionales e internacionales más competitivos. 
• La rapidez con que se renueva el conocimiento en el mundo.
11 
• La poca credibilidad en la empresa nacional. 
5.1.3.  FORTALEZAS: 
• El conocimiento y manejo de la información que se desea evaluar. 
• El liderazgo con que cuenta nuestro equipo de trabajo. 
• El acceso a nuevas tecnologías y el avance informático. 
• La adecuada gestión de los recursos. 
5.1.4. DEBILIDADES: 
• Poca experiencia en la realización de proyectos. 
• Incipiente  incorporación  de  las  nuevas  tecnologías  de  información  y 
comunicación en los procesos. 
• Incipiente desarrollo de la gestión tecnológica. 
• Limitaciones de espacios físicos  para prácticas y pruebas.
12 
6.  RECURSOS. 
Para el desarrollo del presente proyecto se  contara con los siguientes  recursos: 
6.1.  RECURSOS DE TIEMPO 
El  proyecto  se  desarrollará  durante  el  segundo  semestre  del  año  en  curso  y  se 
estima que la fecha límite para la entrega final sea el 30 de Noviembre de 2007. 
Para  lograr alcanzar el objetivo propuesto dentro de este margen de  tiempo,  los 
integrantes del grupo dedicarán 4 horas diarias. 
El  director  del  proyecto  supervisará  periódicamente  los  avances  con  una 
dedicación de 2 horas por semana. 
6.2.  RECURSO HUMANO 
Los Estudiantes que presentan el proyecto 
JEISON ANTONIO MURILLO CRUZ 
JORGE ERNESTO ROA TORRES 
HECTOR ARTURO FLOREZ FERNANDEZ  DIRECTOR DE PROYECTO 
Y  compañeros o personal auxiliar para el desarrollo de las pruebas.
13 
6.3.  RECURSOS  TECNOLOGICOS 
6.3.1. Recursos de Hardware (Equipos de Computo). 
Para  el  desarrollo  de  la  aplicación  contaremos,  en  primera  instancia  con  los 
computadores personales y por su puesto con las diferentes salas con que cuenta 
la universidad. En las etapas finales, la facultad  brindara  un servicio de acceso a 
sus servidores para las etapas de pruebas finales. 
6.3.2. Recursos de Software. 
Necesarios para llevar adelante el proyecto. 
• Easy PHP 5.2.3. 
• My SQL 5.0. 
• SERVIDOR WEB APACHE 
• Adobe DreamWeaver CS3. 
• Dezing Databases 4.0. 
• Rational Rose 2000. 
• Adobe Flash CS3.
14 
7.  MARCO CONCEPTUAL 
7.1.  MARCO TEORICO 
7.1.1. UML 
Son las siglas del Unified Modeling Language o Lenguaje Unificado de Modelado. 
Es  un  lenguaje  de  modelado  visual  que  se  usa  para  Especificar,  Visualizar, 
Construir y Documentar artefactos de un sistema de software. 
El  lenguaje  de  modelado  es  la  notación  (principalmente  gráfica)  que  usan  los 
métodos para expresar un modelo de software, proceso que indica los pasos que 
se deben seguir para llegar a un diseño. 
UML,  es  un  Lenguaje  para:  Visualizar,  Especificar,  Construir,  Documentar 
Software.  UML  es  un  Lenguaje:  Porque  proporciona  el  vocabulario  y  las  reglas 
para combinar las palabras de ese vocabulario para lograr la comunicación. UML 
es un lenguaje estándar para los planos de software. 
UML es un Lenguaje para visualizar porque proporciona símbolo gráficos con una 
semántica bien definida, la notación es la parte gráfica que se ve en los modelos y 
representa  la  sintaxis  del  lenguaje  de  modelado.  UML  es  un  lenguaje  para 
especificar es  decir  construye modelos  no ambiguos  y  completos para  lograr  un 
sistema  con  alta  calidad.  UML  es  un  Lenguaje  para  construir  porque  establece 
correspondencias entre diferentes lenguajes de programación permitiendo realizar 
Ingeniería  directa  es  decir    generar  código  a  partir  de  un  modelo  UML  en  un 
lenguaje  de  programación  ó  ingeniería  inversa  es  decir  construir  el  modelo  en 
UML partiendo del código implementado en un Lenguaje de  Programación.
15 
UML es un Lenguaje para documentar porque permite cubrir la documentación  de 
todo el sistema desde su concepción hasta su implementación y puesta en marcha 
del  mismo  pasando  por  los  requisitos,  Arquitectura,  Diseño,  Código  fuente, 
Planificación del proyecto, pruebas, prototipos y Versiones. 
Modelo Conceptual de UML. 
El modelo conceptual de UML cuenta con tres elementos básicos: 
• Bloques de construcción 
• Reglas que dictan como relacionar esos bloques. 
• Mecanismos  comunes:  facilidades  de  comunicación  ampliación  de 
definiciones básicas. 
Bloques de construcción de UML 
UML incluye tres bloques de construcción: 
Elementos: Abstracciones de primera clase. 
Relaciones: Que ligan elementos con clases. 
Diagramas:  Son  conjuntos  de  elementos    y  relaciones  que  representan  un  fin 
particular.
16 
Elementos en UML 
Existen cuatro tipos, son los bloques básicos construcción orientados a objetos de 
UML. Son utilizados para escribir modelos bien formados. 
• Elementos estructurales 
• Elementos de comportamiento 
• Elementos de agrupación 
• Elementos de anotación 
Elementos Estructurales 
Son  los  nombres  de  los  modelos  UML.  Existen  siete  tipos  de  elementos 
estructurales, a saber 
Relaciones UML 
Hay cuatro tipos de relaciones en UML. 
• Dependencia 
• Asociación 
• Agregación 
•Generalización 
• Realización
17 
Diagramas UML. 
Un  diagrama  es  la  representación  gráfica  de  un  conjunto  de  elementos  y  sus 
relaciones.  En  la  anterior  descripción  de  los  elementos,  no  solo  se  describió  el 
elemento,  sino  que  se  asocio  con  una  relación  para  mejorar  la  semántica  del 
marco teórico. 
Los diagramas que establece UML como básicos para especificar la estructura y el 
comportamiento de un modelo son los siguientes: 
Reglas de UML 
Un modelo bien formado es aquel que es semánticamente auto consistente y está 
en armonía  con  todos  sus modelos  relacionados. UML    tiene  reglas  semánticas 
para: 
Nombres:  Se deben asignar nombres a los elementos, relaciones y diagramas. 
Alcance:  El contexto que da un significado específico a un nombre. (establece 
el contexto). 
Visibilidad:  Cómo se puede ver y utilizar los elementos. 
(#) Visibilidad protegida: protegida para la clase y sus hijos 
(­) Visibilidad privada: solo para la clase 
(+) Visibilidad Pública: Todas las clases 
Integridad:  Como  se  relacionan  apropiada  y  consistentemente  unos  elementos 
con otros.
18 
Ejecución:  Qué significa ejecutar o simular un modelo dinámico. 
Las  reglas  UML  estimulan  pero  no  obligan  a  considerar  las  cuestiones  más 
importantes  de  análisis,  diseño  e  implementación  que  llevan  a  tales  sistemas  a 
convertirse en bien formados con el paso del tiempo. 
Mecanismos Comunes en UML. 
Especificaciones:  Proporciona  una    base  semántica  que  incluye  a  todos  los 
elementos  de todos los modelos de un sistema, y cada elemento está relacionado 
con otros de manera consistente. Todos los elementos básicos están claramente 
especificados, tienen un diagrama y ese diagrama tiene una semántica. 
Adornos: Son elementos adicionales que mejoran la semántica y el significado de 
los elementos básicos. 
Divisiones Comunes: El lenguaje permite hacer representación de abstracciones 
y representaciones concretas. Abstracción: Clase, Concretas: Objeto 
Mecanismo  de  extensibilidad:  UML  es  un  lenguaje  abierto­cerrado,  siendo 
posible extender el lenguaje de manera controlada. Los mecanismos de extensión 
de UML incluyen: 
Estereotipos:  Extiende  el  vocabulario,  permitiendo  añadir  nuevos  bloques  de 
construcción. 
Manejar  excepciones:  Las  excepciones  no  son  propiamente  errores  sino  sitios 
donde    pasa  el  programa que  puede  llevar un error  pueden  ser  definidos  como 
clase. 
Valores  etiquetados:  Es  información  adicional  manejo  de  un  elemento  para 
manejar su descripción. Se anota entre llaves 
19 
Restricciones:  Limitan  o  detallan  una  condición.  Extiende  la  semántica  de  un 
bloque  de construcción UML. 
En  conjunto  estos  tres  mecanismos  de  extensibilidad  permiten  configurar  y 
extender UML para  las necesidades de un proyecto. Estos mecanismos  también 
permiten a UML adaptarse a nuevas tecnologías de software. 
Arquitectura del Software 
Muestra  diferentes  puntos  de  vista  del  modelo  es  un  conjunto  de  vistas.  Su 
objetivo  es:  Detallar  o  especificar  la  estructura  del  sistema,  Especificar  como 
interactúan los componentes del sistema, Especificar subsistemas, Documentar el 
proceso de diseño y desarrollo. 
Figura 1.  Modelado de la Arquitectura de un sistema 
Vista de Diseño: Las clases, diagramas de clases, colaboraciones, interfaces que 
atienden requisitos funcionales. 
Vista  de  Implementación:  Comprenden  diagramas  de  componentes  y  archivos 
que se utilizan. 
Vista de despliegue: Como se debe montar la aplicación: .exe, .dll. Comprende el 
diagrama de despliegue donde se indica como se debe instalarse y ejecutarse la 
aplicación.
20 
Vista de Procesos: Similar a  la vista de diseño pero centrada en  los procesos, 
clases activas comprenden varios hilos. 
Vista de casos de uso: Primero  los requerimientos que son las necesidades de 
los  usuarios,  segundo:  caso  de  uso  y  tercero:  diagramas  de  casos  de  uso. 
Describe el comportamiento del sistema tal cual es percibido por usuarios finales. 
Ciclo de Vida Del Desarrollo De Software 
Dirigido  a  casos  de  usos:  Significa  que  los  casos  de  uso  se  utilizan  como  un 
artefacto  básico  para  establecer  el  comportamiento  deseado  del  sistema,  para 
verificar  y  validar  la  arquitectura  del  sistema,  para  las  pruebas  y  para  la 
comunicación de las personas involucradas al proyecto. 
Centrado en  la arquitectura: Significa que  la arquitectura del sistema se utiliza 
como un artefacto básico para conceptuar, construir, gestionar y hacer evolucionar 
el sistema en desarrollo. 
Iterativo e incremental: El proceso iterativo es aquel que involucra la gestión de 
un flujo de ejecutables del sistema. Un proceso incremental es aquél que involucra 
la  continua  integración  de  la  arquitectura  del  para  producir  esos  ejecutables, 
donde cada nuevo ejecutable incorpora mejoras increméntales sobre los otros. 
El anterior proceso puede ser descompuesto en fases, una fase es definida como 
el intervalo de tiempo entre dos etapas importantes del proceso, ya cumplidos los 
objetivos se procede a pasar a la siguiente  fase. Existen cuatro  fases en el ciclo 
del desarrollo de software a saber: 
La Iniciación: Es la primera fase del proceso y es el fundamento de la idea inicial 
La  elaboración  es  le  segunda  fase  del  proceso,  cuando  se  define  la  visión  del 
producto  y  la  arquitectura.  Aquí  es  se  expresan  con  claridad  los  requisitos  del 
sistema.
21 
La Elaboración: Se define la arquitectura. En esta fase se expresan con claridad 
los requisitos, los cuales son priorizados con el fin de establecer una sólida base 
de la arquitectura. Se tiene en cuenta fundamentalmente los requisitos, los cuales 
pueden variar de generales a precisos. 
La  Construcción:  Es  la  tercera  fase  del  proceso,  cuando  el  software  se  lleva 
desde  una  base  arquitectónica  ejecutable  hasta  su  disponibilidad  para  la 
comunidad de usuarios. En esta fase no solo los requisitos sino la evaluación son 
reexaminados. 
La  transición: Es  la cuarta  fase del proceso, aquí el software es entregado a la 
comunidad  de  usuarios.  No  es  una  fase  de  finalización    sino  una  fase  de 
mejoramiento y evolución del software producido. 
Figura 2.  Ciclo de vida del software. 
7.1.2. Herramientas Case Para Modelado 
Encontramos un sin número de herramientas que nos permiten modelar nuestras 
aplicaciones, herramientas como: UML Studio 7.1, Visual Paradigm, Visual UML, 
Rational Rose, Eclipse UML, Umbrella, Argos .
22 
Herramientas  y  Lenguajes  Para  Construcción  del  Sistema  de  Información 
(Software) 
7.1.3. Programación Orientada A Objetos (OOP) 
OOP, son las siglas de  Object Oriented Programming, la programación orientada 
es  una  forma  de  programar  basada  en  la  reutilización  de  código  mediante 
herencia, encapsulamiento y polimorfismo. 
Herencia:  Una  relación  de  herencia  es  una  relación  en  la  que  un  tipo  (el  tipo 
derivado)  se  deriva  de  otro  (el  tipo  base),  de  tal  forma  que  el  espacio  de 
declaración del  tipo derivado contiene  implícitamente  todos  los miembros de  tipo 
no constructor del tipo base. Mediante el Lenguaje de Modelado Unificado (UML), 
se puede implementar la herencia a través de las relaciones de generalización. 
Encapsulamiento:  El  encapsulado  es  la  capacidad  de  contener  y  controlar    el 
acceso a un grupo de elementos asociados. Las clases proporcionan una de las 
formas más comunes de encapsular elementos, estableciendo como regla general 
que el acceso a los atributos, se debe realizar mediante métodos. 
Poliformismo:  El  polimorfismo  se  refiere  a  la  posibilidad  de  definir  múltiples 
clases con funcionalidad diferente, pero con métodos o propiedades denominados 
de  formaidéntica,  que  pueden  utilizarse  de  manera  intercambiable  mediante 
código cliente en tiempo de ejecución.
23 
7.1.4. Arquitectura de Tres (3) Capas 
Las nuevas estrategias  de  construcción de software  establecen  la necesidad de 
hacer  desarrollos  multinivel  o  multicapa.  Esta  estrategia,  separa  la  capa  de 
presentación  o  interfaz  de  usuario  con  la  capa  de  lógica  de  aplicación  o  de 
negocio y  la separa completamente de  la capa de datos,  recomendando  incluso 
que  no  se  coloque  lógica  como  procedimientos  almacenados  o  vistas  en  esta 
capa. 
Figura 3.  Modelo arquitectónico de 3 capas 
La  capa  de  presentación:  Estará  compuesta  por  formularios  PHP  y  páginas 
HTML, para la salida Web que tenga la aplicación y para interoperabilidad. 
La capa de lógica de aplicación: Consta de los procesos que se requieren para 
hacer  la  conexión  entre  los  formularios    y    la  base  de  datos,    así  como  para 
manejar  la  seguridad  de  la  aplicación,  estos  desarrollados  con  componentes 
utilizando lenguaje de programación PHP, Javascript y herramienta de desarrollo 
en Adobe DreamWeaver CS3 
La  capa  de  persistencia: Maneja  la  base  de  datos  en  la  cual  se  encuentra  la 
información sobre todas las actividades realizadas con el sistema y se utilizará el 
motor de bases de datos MYSQL 5.0 .
24 
7.1.5. Redes de Computadores 
La interconexión de dos o más computadores da origen a redes de computadores. 
Estas redes dependiendo de sus características pueden conformar Redes de Área 
Local    (LAN­Local Areal Network), Redes    de Área Extendida  (WAN­Wide Areal 
Network), sobre las cuales dependiendo de los protocolos, se pueden implementar 
Intranets, Extranets o Internet. 
La  aplicación  propuesta  tendrá  la  capacidad  de  funcionar  en  cualquiera  de  los 
sistemas  mostrados,  bien  sea  una  Red  LAN,  una  Red WAN,  una  Intranet,  una 
Extranet  o  en  Internet.  Sin  embargo  inicialmente  el  modulo  del  Sistema  de 
Información se tiene previsto que opere sobre la Internet.. 
Estas redes para efectos del manejo de los estándares internacionales se suelen 
soportar por los protocolos TCP/IP (Transport Control Protocol/Internet Protocol). 
7.1.6. Seguridad de la Información y de las aplicaciones. 
Todos  los  sistemas  informáticos  deben  proveer  un  sistema  de  seguridad,  que 
utilice políticas claras en cuanto a: Autenticación, confidencialidad, integridad y no 
repudio. 
Las  políticas  y  tecnologías  de  seguridad  se  basan  en  técnicas  criptográficas, 
sistemas  de  cifrado  como  RSA,  Kerberos,  DES,  PGP  que  permite  proteger  la 
información y las aplicaciones de personas no autorizadas. 
El  Sistema  de  Información  contará  con  políticas    de  seguridad  basadas  en  la 
ayuda  del  sistema  operativo,  dispositivos  de  control  de  acceso, mecanismos  de 
seguridad del motor de base de datos y en especial en un   sistema de gestión y 
control de usuarios.
25 
EL  Sistema  tiene  previsto  realizar  la  validación  de  todos  y  cada  uno  de  los 
usuarios del sistema, cifrar la información crítica, utilizar las facilidades que tiene el 
sistema operativo para autenticación con el fin de limitar el control de acceso a las 
estaciones de trabajo. 
7.1.7. Metodología RUP 
Para  la  investigación  sobre  el  estado  del  arte  y  debido  a  que  esta  es  una 
investigación  sobre  las  posibilidades  que  ofrecen  las  nuevas  tecnologías  de  la 
información y comunicación, la metodología que se seguirá en este aspecto tiene 
como  fundamento  la  navegación  y  exploración  a  través de    Internet,  pues  es  la 
expresión máxima de aplicación de estas tecnologías. 
Para el proceso de modelado y desarrollo del software se utilizará la metodología 
RUP  (Racional  Unified  Process)  la  cual  tiene  como  fundamento  estrategias 
debidamente probadas para la construcción de software y será quién guíe todo el 
proceso  y  que  estará  acompañada  de  la  metodología  ágil  SCRUM  para  el 
desarrollo de proyectos de software. 
RUP  describe  como  utilizar  de  forma  efectiva  procedimientos  comerciales 
probados  en  el  desarrollo  de  software  para  equipos  de  desarrollo  de  software, 
conocidos como “mejores prácticas”. 
Las Mejores Prácticas de RUP 
El  Proceso  Unificado  de  Desarrollo  es  una  metodología  creada  por  Racional 
Software, que establece una serie de procesos por realizar, con el fin de construir 
software de alta calidad en tiempo y precio justos.
26 
Figura 4.  Las seis (6) mejores prácticas de la Metodología RUP. 
La  metodología  se  soporta  en  la  administración  de  requerimientos,  entendidos 
estos como las necesidades de los usuarios de la Plataforma Virtual, vistos desde 
la perspectiva de lo que tiene que atender el software. 
Los requerimientos permiten: 
• Licitar, organizar, y documentar la funcionalidad y restricciones requeridas. 
• Llevar un registro y documentación de cambios y decisiones. 
• Los requerimientos de negocio son fácilmente capturados y comunicados a 
través de casos de uso. 
• Los casos de uso son instrumentos importantes de planeación. 
Características del desarrollo Iterativo 
Permite  un  entendimiento  incremental  del  problema  a  través  de  refinamientos 
sucesivos, habilitando una fácil retroalimentación de usuario. Se establecen metas 
específicas  que  permiten  que  el  equipo  de  desarrollo mantenga  su  atención  en 
producir  resultados,  el  progreso  es  medido  conforme  avanzan  las 
implementaciones.
27 
Figura 5.  Desarrollo Iterativo de la Metodología RUP. 
7.1.8. Desarrollo basado en componentes 
Se  caracteriza  por  utilizar  lenguajes  de  programación  orientados  a  objetos,  que 
permiten  la  implementación  de  componentes.    Sus  principales  ventajas  se 
relacionan a continuación: 
• Se enfoca en el pronto desarrollo de una arquitectura ejecutable robusta. 
• Resistente al cambio mediante el uso de interfaces bien definidas. 
• Intuitivamente comprensible. 
• Promueve un reuso más efectivo de software. 
• Es derivada a partir de los casos de uso más importantes. 
7.1.9. Modelado Visual 
Utiliza  como  lenguaje  para  el  modelado  del  software  UML  (Unified  Modeling 
Language). UML permite visualizar, especificar, construir y documentar el software 
y tiene  como características principales: 
• Captura la estructura y comportamiento de arquitecturas y componentes.
28 
• Muestra como encajan de forma conjunta los elementos del sistema. 
• Mantiene la consistencia entre un diseño y su implementación. 
• Promueve una comunicación no ambigua. 
Verificación de la calidad del software 
Se establecerán prueba para cada escenario (casos de uso) con el fin de asegurar 
que  todos  los  requerimientos  están  propiamente  implementados,  se  verificará  la 
calidad del software con respecto a los requerimientos basados en la confiabilidad, 
funcionalidad,  desempeño  de  la  aplicación  y  del  sistema.  Cada  una  de  las 
iteraciones por las que se pase será probada debidamente. 
Control de cambios 
Se  llevará  un  control,  registró  y  monitoreo  sobre  los  cambios  para  permitir  un 
desarrollo  iterativo,  que  en  todo  momento  esté  ajustado  a  la  metodología 
propuesta.
29 
7.1.10.  METODOLOGIA SCRUM 
Figura 6.  Metodología SCRUM. 
Basándonos  en  los  cuatro  principios  fundamentales  detrás  de  las  metodologías 
ágiles (no solo SCRUM) que son: 
• Los individuos y las interacciones (sobre todo cara a cara) priman por sobre 
los procesos y las herramientas. 
• El software funcionando prima por sobre la documentación detallada. 
• La colaboración con el cliente prima por sobre la negociación de contratos. 
• Responder a los cambios prima por sobre seguir un plan.
30 
Podemos determinar que para este tipo de desarrollo encontramos que: 
El futuro usuario delsoftware quiere un programa que resuelva sus problemas, no 
documentación  acerca  de  como  sería  ó  es  ese  programa.  Un  programa 
funcionando (quizá incompletamente) es una prueba de avance, la documentación 
no lo es. 
El  cliente  es  parte  (literalmente,  en  persona)  del  equipo  y  del  proceso  de 
desarrollo. 
A inicio del proyecto los requerimientos no son bien entendidos, ni siquiera por el 
cliente.  Esto  se  fundamenta  en  parte  en  la  alta  proporción  de  features  que  se 
implementan  y  nunca  son utilizadas.  Cuando  el  cliente  ve,  durante  el  desarrollo 
(del  cual  es  parte)  lo  que  cuesta  implementar  ciertas  features,  ve  el  tiempo que 
queda y ve el dinero disponible, él solo va descartando lo menos relevante y deja 
solo lo principal. 
La  Ley  de  Parkinson  nos  dice:  el  trabajo  tiende  a  expandirse  hasta  cubrir  el 
tiempo  disponible.  Fijar  un  lapso  y  atenerse  a  él,  tiene  el  efecto  psicológico  de 
enfocar el esfuerzo en ese lapso. Esto  lo comprenderá perfectamente cualquiera 
que haya rendido un examen final.
31 
¿Por qué SCRUM? 
El  nombre  proviene  de  la  posición  de  salida  del  rugby  homónima,  y  se  justifica 
diciendo que en esta metodología cada uno desde su puesto contribuye al equipo, 
haciendo todos fuerza para el mismo lado sinergia. 
Figura 7.  Campo deportivo para Rugby 
El "gol" es que al cliente le sirva el producto desarrollado. 
El "contrincante" es esa cosa ambigua o pobremente definida que tiene el software 
y que hace tortuoso su desarrollo. 
Prácticas Clave de SCRUM 
Requerimientos evolutivos. 
Desarrollo iterativo e incremental. 
El origen. 
Scrum es una metodología ágil de desarrollo de proyectos que toma su nombre y 
principios  de  los  estudios  realizados  sobre  nuevas  prácticas  de  producción  por 
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80.
32 
Aunque surgió como modelo para el desarrollo de productos tecnológicos, también 
se  emplea  en  entornos  que  trabajan  con  requisitos  inestables  y  que  requieren 
rapidez  y  flexibilidad;  situaciones  frecuentes  en  el  desarrollo  de  determinados 
sistemas de software. 
Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel 
Corporation  (Empresa  que  en  los  macro­juegos  de  compras  y  fusiones  se 
integraría  en  VMARK,  luego  en  Informix  y  finalmente  en  Ascential  Software 
Corporation). En 1996 lo presentó junto con Ken Schwaber como proceso formal, 
también  para  gestión  del  desarrollo  de  software  en OOPSLA  96. Más  tarde,  en 
2001  serían  dos  de  los  promulgadores  del  Manifiesto_ágil.  En  el  desarrollo  de 
software scrum está considerado como modelo ágil por la Agile Alliance. 
Surge del estudio de varios proyectos y productos exitosos y su adaptación a  la 
industria del software: 
• Industria japonesa: Toyota, Honda, Fuji­Xerox 
• Borland Quattro Pro 
¡¡Basado en la teoría del caos!! 
Figura 8.  Empresas que implementan  metodología SCRUM
33 
Introducción al modelo 
Scrum  es  una metodología  de desarrollo muy  simple,  que  requiere  trabajo  duro 
porque no se basa en el seguimiento de un plan, sino en la adaptación continua a 
las circunstancias de la evolución del proyecto. 
Scrum es una metodología ágil, y como tal: 
_ Es un modo de desarrollo de carácter adaptable más que predictivo. 
_ Orientado a las personas más que a los procesos. 
_  Emplea  la  estructura  de  desarrollo  ágil:  incremental  basada  en  iteraciones  y 
revisiones. 
Figura 9.  Estructura  de desarrollo Ágil 
Se comienza con  la visión general del producto, especificando y dando detalle a 
las  funcionalidades  o  partes  que  tienen  mayor  prioridad  de  desarrollo  y  que 
pueden llevarse a cabo en un periodo de tiempo breve (normalmente de 30 días).
34 
Cada  uno  de  estos  periodos  de  desarrollo  es  una  iteración  que  finaliza  con  la 
producción de un incremento operativo del producto. 
Estas iteraciones son la base del desarrollo ágil, y Scrum gestiona su evolución a 
través  de  reuniones  breves  diarias  en  las  que  todo  el  equipo  revisa  el  trabajo 
realizado el día anterior y el previsto para el día siguiente. 
Figura 10.  Control de la evolución del proyecto 
Scrum  controla  de  forma  empírica  y  adaptable  la  evolución  del  proyecto, 
empleando las siguientes prácticas de la gestión ágil: 
Revisión de las Iteraciones 
Al finalizar cada iteración (normalmente 30 días) se lleva a cabo una revisión con 
todas las personas implicadas en el proyecto. Este es el periodo máximo que se 
tarda  en  reconducir  una  desviación  en  el  proyecto  o  en  las  circunstancias  del 
producto. 
Desarrollo incremental 
Durante  el  proyecto,  las  personas  implicadas  no  trabajan  con  diseños  o 
abstracciones. 
El desarrollo incremental implica que al final de cada iteración se dispone de una 
parte del producto operativa que se puede inspeccionar y evaluar.
35 
Desarrollo evolutivo 
Los  modelos  de  gestión  ágil  se  emplean  para  trabajar  en  entornos  de 
incertidumbre e inestabilidad de requisitos. 
Intentar predecir en las  fases iniciales cómo será el producto final, y sobre dicha 
predicción  desarrollar  el  diseño  y  la  arquitectura  del  producto  no  es  realista, 
porque las circunstancias obligarán a remodelarlo muchas veces. 
Para qué predecir los estados finales de la arquitectura o del diseño si van a estar 
cambiando. En Scrum se toma a la inestabilidad como una premisa, y se adoptan 
técnicas  de  trabajo  para  permitir  esa  evolución  sin  degradar  la  calidad  de  la 
arquitectura que se irá generando durante el desarrollo. 
El  desarrollo  Scrum  va  generando  el  diseño  y  la  arquitectura  final  de  forma 
evolutiva durante  todo el proyecto. No  los considera como productos que deban 
realizarse en la primera “fase” del proyecto. 
(El desarrollo ágil no es un desarrollo en fases) 
Auto­organización 
Durante el desarrollo de un proyecto son muchos  los  factores impredecibles que 
surgen en todas las áreas y niveles. La gestión predictiva confía la responsabilidad 
de su resolución al gestor de proyectos. 
En  Scrum  los  equipos  son  auto­organizados  (no  auto­dirigidos),  con margen  de 
decisión suficiente para tomar las decisiones que consideren oportunas.
36 
Colaboración 
Las prácticas y el entorno de trabajo ágiles facilitan la colaboración del equipo. 
Ésta es necesaria, porque para que funcione la autoorganización como un control 
eficaz cada miembro del equipo debe colaborar de  forma abierta con  los demás, 
según sus capacidades y no según su rol o su puesto. 
Visión general del proceso 
Scrum denomina  “sprint”  a  cada  iteración  de  desarrollo  y  recomienda  realizarlas 
con duraciones de 30 días. 
El  sprint  es  por  tanto  el  núcleo  central  que  proporciona  la  base  de  desarrollo 
iterativo e incremental. 
§  Duración máxima: 30 días. 
§  Durante  el  sprint  no  se  puede  modificar  el  trabajo  que  se  ha 
acordado en el Backlog. 
§  Sólo es posible cambiar el curso de un sprint, abortándolo, y sólo lo 
puede hacer el Scrum Master si decide que no es viable por alguna 
de las razones siguientes: 
§  La tecnología acordada no funciona. 
§  Las circunstancias del negocio han cambiado. 
§  El equipo ha tenido interferencias.
37 
Figura 11.  Elementos que conforman el desarrollo Scrum. 
Comunicación 
La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro 
de un equipo de desarrollo es mediante la conversación cara a cara. 
Las reuniones 
Planificación de sprint:  Jornada de  trabajo previa al  inicio de cada sprint en  la 
que se determina cuál va a ser el trabajo y los objetivos que se deben cumplir en 
esa iteración. 
Reunión  del  equipo,  Scrum  Manager,  propietario  del  producto  con  todas  las 
personas implicadas en el proyecto(gallinas). 
§  Duración máxima: 4 horas. 
§  Finalidad:  presentar  al  propietario  del  producto  y  a  las  gallinas  las 
nuevas funcionalidades implementadas. 
§  Las funcionalidades no implementadas no se presentan.
38 
§  En  la  reunión,  los  miembros  del  equipo  muestran  las  nuevas 
funcionalidades. 
§  Al  final  de  la  reunión  se  interroga  individualmente  a  todos  los 
asistentes  para  recabar  impresiones,  sugerencias  de  cambio  y 
mejora, y su relevancia. 
§  El propietario del producto trata con los asistentes y con el equipo las 
posibles modificaciones en la pila de producto. 
Reunión diaria: Breve revisión del equipo del trabajo realizado hasta la fecha y la 
previsión para el día siguiente. 
Reunión del equipo con duración máxima de 15 minutos. 
§  Todos los días en el mismo sitio y a la misma hora. 
§  Se recomienda que sea la primera actividad del día. 
§  Deben acudir todos los miembros del equipo. 
§  Moderada  por  el  Scrum  Manager,  que  pregunta  a  todos  los 
asistentes 
§  ¿Cuál  ha  sido  el  trabajo  realizado  desde  la  última  revisión 
diaria? 
§  ¿Cuál es el trabajo previsto para hoy? 
§  ¿Hay algo que  necesitas,  o  que  te  impide  realizar  el  trabajo 
previsto? 
§  No se permite entrar en divagaciones o salirse del guión. 
§  Sólo habla la persona que informa de su trabajo, el resto escucha y 
no hay lugar para otras conversaciones. 
§  Cuando un miembro informa de algo de interés para otros, o necesita 
ayuda de otros, estos se reúnen al terminar la revisión diaria. 
§  Las  gallinas  no  pueden  intervenir  ni  distraer,  y  el  Scrum  Master 
puede  limitar  el  número  de  gallinas  asistentes  si  lo  considera 
oportuno.
39 
Revisión de sprint: Análisis y revisión del incremento generado. 
Acuden el equipo y el Scrum Master, y opcionalmente el Propietario del Producto. 
§  Todos los miembros del equipo responden a dos preguntas: 
§  ¿Qué cosas fueron bien en el último sprint? 
§  ¿Qué cosas se podrían mejorar? 
§  El Scrum Manager anota todas las respuestas 
§  El equipo prioriza las mejoras posibles 
§  El  Scrum  Manager  no  proporciona  respuestas,  sino  que  ayuda  al 
equipo a encontrar la mejor forma de trabajar con Scrum. 
§  Las acciones de mejora  localizadas que se puedan implementar en 
el  próximo  Sprint  deben  introducirse  en  la  pila  de  producto  como 
elementos no funcionales. 
Los elementos 
Pila del producto: lista de requisitos de usuario que se origina con la visión inicial 
del producto y va creciendo y evolucionando durante el desarrollo. 
Listado con los requisitos del sistema 
§  Es responsabilidad del dueño del producto 
§  Contenido 
§  Priorización 
§  Disponibilidad 
§  Nunca llega a ser una lista completa y definitiva 
§  El empleado para planificar el proyecto es sólo una estimación inicial 
de requisitos
40 
§  Es  un  documento  dinámico  que  incorpora  constantemente  las 
necesidades del sistema 
§  Se  mantiene  durante  todo  el  ciclo  de  vida  (hasta  la  retirada  del 
sistema). 
Figura 12.  Pila del producto (Product Backlog)
41 
Pila del sprint: Lista de los trabajos que debe realizar el equipo durante el sprint 
para generar el incremento previsto. 
Figura 13.  Pila del Sprint 
Incremento: Resultado de cada sprint 
Figura 14.  Grafico de resultados he incremento de trabajo
42 
Figura 15.  Incremento de trabajo metodología SCRUM 
Los roles 
Scrum  clasifica  a  todas  las  personas  que  intervienen  o  tienen  interés  en  el 
desarrollo  del  proyecto  en:  propietario  del  producto,  equipo,  gestor  de  Scrum 
(también Scrum Manager o Scrum Master) y “otros interesados”. 
Los  tres primeros grupos  (propietario, equipo y gestor) son  los  responsables del 
proyecto,  los  que  según  la  comparación  siguiente  (y  sin  connotaciones 
peyorativas)  serían  los  “cerdos”; mientras  que  el  resto  de  interesados  serían  las 
gallinas. 
Cerdos y gallinas. 
Esta  metáfora  ilustra  de  forma  muy  gráfica  la  diferencia  de  implicación  en  el 
proyecto entre ambos grupos: 
Una gallina y un cerdo paseaban por la carretera. La gallina dijo al cerdo: “Quieres 
abrir  un  restaurante  conmigo”. El  cerdo  consideró  la  propuesta  y  respondió:  “Sí, 
me  gustaría.  ¿Y  cómo  lo  llamaríamos?”.  La  gallina  respondió:  “Huevos  con 
beicon”.
43 
El cerdo se detuvo, hizo una pausa y contestó:  “Pensándolo mejor,  creo que no 
voy a abrir un restaurante contigo. Yo estaría  realmente comprometido, mientras 
que tu estarías sólo implicada”. 
Figura 16.  Cerdos y Gallinas SCRUM 
Tabla 1.  Comprometidos e Implicados en metodología SCRUM 
COMPROMETIDOS (cerdos)  IMPLICADOS (gallinas) 
Propietario del producto 
Equipo 
Scrum Manager 
Otros interesados 
(Dirección general 
Dirección comercial 
Marketing Usuarios, etc) 
Propietario del producto: El responsable de obtener el mayor valor de producto 
para los clientes, usuarios y resto de implicados. 
Equipo de desarrollo: grupo o grupos de trabajo que desarrollan el producto. 
Scrum Manager: gestor de los equipos que es responsable del funcionamiento de 
la metodología Scrum y de la productividad del equipo de desarrollo.
44 
Figura 17.  Roles metodología SCRUM 
Scrum diferencia claramente entre estos dos grupos para garantizar que quienes 
tienen la responsabilidad tienen también la autoridad necesaria para poder lograr 
el  éxito,  y  que  quienes  no  tienen  la  responsabilidad  no  producen  interferencias 
innecesarias 
Valores 
Scrum es  una  “carrocería”  para  dar  forma a  los  principios  ágiles. Es  una  ayuda 
para  organizar  a  las  personas  y  el  flujo  de  trabajo;  como  lo  pueden  ser  otras 
propuestas de formas de trabajo ágil: Cristal, DSDM, etc. 
La  carrocería  sin  motor,  sin  los  valores  que  dan  sentido  al  desarrollo  ágil,  no 
funciona. 
Delegación  de  atribuciones  (empowerment)  al  equipo  para  que  pueda  auto­ 
organizarse y tomar las decisiones sobre el desarrollo. 
Respeto entre las personas. Los miembros del equipo deben confiar entre ellos y 
respetar sus conocimientos y capacidades. 
Responsabilidad y auto­disciplina (no disciplina impuesta).
45 
Trabajo centrado en el desarrollo de lo comprometido 
Información, transparencia y visibilidad del desarrollo del proyecto 
FLUJO DE SCRUM 
Figura 18.  Flujo de trabajo
46 
Figura 19.  Proceso Completo Scrum
47 
7.2.  ESTADO DEL ARTE 
El  desarrollo  de  la  tecnología  informática  viene  ofreciendo  grandes  avances  y 
ventajas  en  el  mundo  de  hoy,  la  rapidez  con  la  que  se  puede  acceder  a  la 
información y la respuesta de las capacidades de los computadores con memorias 
y  procesadores  que  día  a  día  aumentan enormemente  de  su  rendimiento  y  que 
cada vez disminuyen sus costos afortunadamente. 
Hay  en  la  actualidad  alrededor  de  5.000  medios  diferentes  de  aprendizaje 
asistidos  por  computadores  y  aplicaciones  de  software  para  acondicionamiento 
físico,  entrenamiento  de  atletas,  manejo  de  tiempos  y  marcas,  manejo  de 
estadísticas  y  resultados,  capacitación  para  entrenadores,  deportistas, 
administradores  deportivos,  profesores  y  otras  aplicaciones  que  podemos 
descargar de  la  Internet e  instalarlas en nuestro computador, o  también a  través 
de CD Roms. 
Existen  software  capaz  de  controlar  el  movimiento  humano  (incluyendo 
animaciones  en  3­D),  programas  para  el  mantenimiento  físico  (  como  análisis 
nutricionales  y  de asesoramiento,  los  ejercicios  de  flexibilidad,  condicionamiento 
aeróbico, condiciones de fuerza): software que controla reservas de escenarios y 
horarios  de  programación,  aplicaciones  interactivas  multimediales  para  muchas 
actividades deportivas. 
Con  el  desarrollo  de  los  sistemas  operativos  con  interfases  perfeccionadas  y 
hardware  muy  rápido,  la  aplicación  de  softwarede  fácil  utilización  avanza 
vertiginosamente. En un  futuro cercano el desarrollo del deporte incluirá  realidad 
virtual o artificial y la holografía. Los sistemas de realidad virtual utilizando cascos 
con  sistemas  visuales  permitiendo  el  desenvolverse  fácilmente  en  las 
simulaciones 3­D del entorno y del equipamiento. La holografía que crea imágenes 
sin necesidad de cascos o gafas.
48 
Pronto  los  deportistas  podrán  visualizar  su  técnica  no  solo  en  cintas  de  video 
bidimensionales,  sino  también  en  una  perspectiva  tridimensional,  permitiéndoles 
mejorar  su  tiempos,  movimientos,  técnica  y  táctica,  aprovechando  dichas 
bondades que la tecnología nos ofrece en la actualidad. 
El interés por crear aplicaciones que faciliten el mejor desarrollo tanto en la parte 
deportiva  como  en  la  misma  gestión  administrativa,  ha  permitido  nuevas 
experiencias  interactivas  controladas  automáticamente,  ha  llevado  a  diseñar 
sistemas de gran alcance para la gestión administrativa de competencias, manejo 
de  escenarios,  administración  de  clubes,  ligas,  federaciones  de  diferentes 
disciplinas deportivas. 
A nivel  internacional son muchas  las aplicaciones que se pueden encontrar pero 
cada una de ellas contemplan especificaciones  para deportes o reglamentaciones 
especiales   de acuerdo a  la ubicación geográfica de  la casa desarrolladora o de 
los  programadores  o  creadores  de  dichas  aplicaciones,  vemos  el  caso  de  los 
diferentes  software  de  administración  deportiva  que  existen  donde  algunos  se 
centran  solamente  en el  control  de  inscripciones para  equipos y  jugadores  o  en 
otros casos en el control y manejo de las competencias. 
Muchos  de  estos  programas  pueden  ser  descargados  en  versiones  trial 
(demostraciones) que limitan el manejo del mismo pero dan a conocer las ventajas 
que pueden ofrecer. Entre este tipo de programas encontramos algunos como los 
siguientes: 
• Argos 2.0 gestión de competiciones 
• Splendy  City  control  de  inscripción  y  manejo  de  escenarios  y 
programaciones deportivas 
• Tennis point logger gestor de puntuación para partidos de tenis, 
• Volleyball­Point­Manager  1.0  gestor  de  puntuaciones  para  partidos  de 
VolleyBall,
49 
• SHIAI 2006 programa para competencias de Judo 
• Nitroxcalc  calculadora  de  mezclas  para  inmersiones  o  actividades 
subacuáticas, 
• TeamStats 1.5.0 Registra resultados de ligas y torneos de fútbol, 
• Aqua DiveLog 0.95 Un excelente gestor de información para submarinistas, 
• VELO 0.9.8 Gestor de tiempos y recorridos para ciclistas, 
• BFL Heart Rate 1.0 Tabla de control de ritmos cardiacos, 
• Game Day 2.0 Guarda tus partidos en esta base de datos, 
• Squash  Tennis  1.0  Manual  de  referencia  con  las  reglas  y  normas  del 
Squash, 
• ZMoto  3.0  Gestor  gratuito  de  reparaciones,  revisiones,  consumos  y 
kilometrajes de motocicletas 
Los anteriores programas vienen implementados a reglamentaciones o disciplinas 
deportivas  exclusivas  de  tal manera  que  limitan  su manejo  y  en muchos  de  los 
caso  los usuarios solo hacen uso del o  los módulos que mejor se adapten a su 
necesidad. 
A  través  de  los  años  de  ejercicio  en  la  labor  de  control  y  desarrollo  de 
competiciones deportivas en el  Instituto Distrital para  la Recreación y el Deporte 
desde el año de 1997, se observa la necesidad de una aplicación dinámica y de 
fácil  manejo  para  la  gestión  de  competencias  de  las  diferentes  disciplinas 
deportivas que se llevaban a cabo en el área de deportes específicamente en  la 
coordinación de juegos escolares e íntercolegiados. 
Fue como a si se implemento el uso de hojas de cálculo para generar los sorteos, 
programación y control de los marcadores de  los campeonatos en las disciplinas 
de conjunto como son el  fútbol, baloncesto, voleibol y  fútbol de salón, por medio 
de  unas  simples  consultas  donde  el  encargado  ingresaba  los  datos  a  los 
diferentes formularios  y utilizando las macros y funciones que las hojas de calculo
50 
ofrecían  se  obtenían  los  resultados,  clasificación  y  puntuación  de  las 
competencias. 
A este primer intento de sistematización hecho en Excel se le denomino fixtures 1, 
que  fue  diseñado  por  jorge  roa,  desconociendo  en  ese  entonces  lenguajes  de 
programación o  entornos  de diseño,  era  tan  solamente  una  hoja  de  calculo  con 
sus funciones la que hacia la labor. 
Figura 20.  Fixtures 1
51 
Algo  muy  particular  es  que  en  muchas  organizaciones  utilizan  en  la  actualidad 
hojas  de  calculo  para  el  manejo  de  sus  competencias,  diseñadas  por  sus 
coordinadores  de deporte  o  adquiridas  de otras  organizaciones. Realizando  una 
encuesta entre las diferentes ligas deportivas capitalinas observamos que son muy 
pocas  las  que  cuentas  con  software  especializado  para  manejo  de  la  gestión 
deportiva  y  las  que  lo  tienen  por  no  ser  las  aplicaciones  diseñadas  para  los 
requerimientos que dichas ligas presentan son desaprovechados y solo se utilizan 
para tareas especificas. 
Para  los  pasados  Juegos  Deportivos  Nacionales  2004  con  sede  en  Bogotá, 
Coldeportes Nacional a través de FONADE contrato el servicio de sistematización 
de competencias de una compañía cubana, que no colmo las expectativas pues el 
manejo  de  la  aplicación  además  de  ser  obsoleto,  no  contaba  con  una 
funcionalidad. 
En  la  actualidad  existe  una  firma  que  esta  incursionando  en  el  desarrollo  de 
aplicaciones de gestión deportiva,  llamada Deporte Virtual compañía colombiana 
que ya ha tenido experiencias en el manejo de la sistematización de competencias 
como  los  Juegos  Universitarios  y  los  Juegos  Íntercolegiados  Nacionales  su 
aplicación denominada “Hércules” desarrollada en ambiente Web y en lenguaje de 
programación PHP . 
Para  esta  nueva  era  donde  se  requiere  dominar  los  nuevos  conceptos  de 
informática, comunicaciones, multimedia, realidad virtual, las artes y el diseño que 
se  desprenden  de  los  sistemas  digitales  y  tridimensionales.  Creemos  que  el 
Sistema de Información para  la Organización y Administración de  Campeonatos 
para  Deportes  de  Conjunto  “sportacus”  permitirá  facilitar  la  organización  de  los 
procesos  y  apoyos  logísticos  para  la  realización  de  eventos  deportivos.  El 
programa contribuirá a la optimización del  trabajo, agilización y la exactitud en el 
manejo de los resultados estadísticos en cualquier disciplina deportiva.
52 
8.  ANALISIS DE REQUERIMIENTOS 
8.1.  Actores 
Administrador: actor encargado de la gestión de control y administración del 
sistema. 
Delegado: actor con permisos limitados para administración y control de los 
módulos autorizados. 
Usuario; actor que solo puede acceder a la visualización de la  pagina WEB 
a través del Internet. 
8.2.  Requerimientos Funcionales 
Listado de requerimientos funcionales 
Sistema  de  información  para  la  organización  y  administración  de  campeonatos 
para deportes de conjunto 
Tabla 2.  Acceso a la aplicación 
R1  Pagina inicial de acceso a la aplicación 
En esta página obtenemos la información inicial y las características del sistema 
en esta página navegaremos por los diferentes elementos. 
Tabla 3.  Control de acceso 
R2  Control de acceso a la aplicación 
Dentro de la página inicial del sistema ubicaremos un control de acceso con las 
siguientes  características:  usuario  y  password  que  serán  validados  contra  la 
base de datos, en caso de no existir el usuario permitir un registro.
53 
Tabla 4.  Registro nuevo usuario 
R3  Registro de nuevo usuario 
Este  será  un  formulario  con  los  datos  personales  del  solicitante  que  serán 
validados luego por el administrador del sistema. 
Envió de la información del registro de nuevo usuario a un correopara posterior 
verificación y autenticación de contraseñas 
Tabla 5.  Modulo administradores 
R4  Modulo administradores 
Este modulo permitirá las siguientes actividades: 
• Crear nuevo administrador 
• Consultarlos 
• Editarlos 
• Inhabilitarlos 
Tabla 6.  Modulo delegados 
R5  Modulo delegados 
Este modulo permitirá las siguientes actividades: 
• Agregar equipo 
• Agregar Jugador 
• Consultar 
• Editarlos 
Tabla 7.  Generación de Campeonatos 
R6  Generación de Campeonatos 
Este formato permitirá entre otras: 
Selección de un deporte 
• Baloncesto 
• Fútbol 
• Fútbol de salón 
• Voleibol 
Creación de campeonato: 
• Nombre del campeonato 
• Categoría (permitir establecer categorías infantil, juvenil, mayores, etc.)
54 
• Sistema de campeonato 
• Ramas: Femenina y masculina 
• Numero de Equipos 
• Numero de jugadores (permitir mínimos y máximos  por equipo) 
Tabla 8.  Generación de grupos por campeonato 
R7  Generación de grupos por campeonato 
De    acuerdo al  número  de equipos  inscritos  el  sistema  indicara    al  usuario  el 
sistema de campeonato que puede desarrollar entre los siguientes: 
• Play­Off 
• Triangular 
• Cuadrangular 
• Pentagonal 
• Hexagonal 
• Heptagonal 
• Octogonal 
Tabla 9.  Creación de Equipos 
R8  Creación de Equipos 
Este  formulario  permitirá  dependiendo  del  campeonato  seleccionado  crear  los 
equipos pertenecientes a cada campeonato. 
• Nombre del equipo 
• Jugadores 
• Categoría 
• Rama 
• Cuerpo técnico 
o  Delegados 
o  Entrenadores 
o  Capitán 
• Cuerpo medico 
o  Doctor 
o  Quinesiólogo 
o  Nutricionista 
o  Enfermera 
o  Otros 
• Administrativo 
o  Gerente
55 
o  Presidente 
o  Otros 
Tabla 10.Creación de jugadores 
R9  Creación de jugadores 
Este formulario permitirá la creación de los diferentes deportistas pertenecientes 
a un equipo inscrito. 
• Nombres 
• Apellidos 
• Documento de identidad 
• Fotografía 
• Fecha de nacimiento dd­mm­yy (verificación de la categoría) 
• Posición 
• Acreditación de lija si la tiene 
• Logros 
• Historia deportiva 
• Contacto: 
o  Dirección, teléfono, email. 
• Observaciones 
Tabla 11.Generación de programación 
R10  Generación de programación 
De  pendiendo  del  fixture  la  aplicación  genera  de  manera  automática  la 
programación  jornada  a  jornada  de  los  diferentes  encuentros  para  cada 
campeonato. 
Tabla 12.Modulo marcadores 
R11  Modulo marcadores 
El sistema permitirá al administrador o a su encargado registrar el marcador y las 
anotaciones de los diferentes encuentros en los respectivos campeonatos. 
Tabla 13.Generación cuadros de posiciones 
R12  Generación cuadros de posiciones 
El  sistema  dará  el  reporte  automático  de  la  tabla  de  posiciones  de  cada 
campeonato con sus respectivos ítems.
56 
8.3.  Requerimientos NO funcionales 
A  continuación  se  describen  los  requerimientos  básicos  para  la  adecuada 
utilización y  funcionalidad de la aplicación. 
La  característica  principal  de  la  aplicación  es  que  se  pueda  acceder  vía  Web 
desde los principales navegadores en este caso Firefox Mozilla e Internet Explorer 
para ello debemos implementar  ambientes que permitan el desarrollo, el acceso a 
la misma. 
Figura 21.  Ambientes de trabajo 
Servidor de Aplicaciones 
Inicialmente la aplicación correrá en las maquinas de cada uno de los integrantes 
del grupo de trabajo en este caso se escoge el sistema operativo Windows  por su 
fácil instalación, su interfaz grafica. 
Para  el  servidor done estará  alojada  la  aplicación para  la Web  se  implementara 
sobre sistema Operativo Linux , este sistema operativo cuyo uno de sus atributos 
es que es software libre  y cualquier persona puede libremente usarlo, estudiarlo, 
redistribuirlo  y  modificarlo,  facilita  la  interacción  con  el  usuario  ofreciéndole  una 
LINUX 
Tomcat  Mysql 
FIREFOX 
MOZILLA 
INTERNER 
EXPLORER 
Ambiente Servidor  Ambiente Cliente 
DreamWeaver 
PHP 
Tomcat  Mysql 
Ambiente Desarrollo
57 
interfaz  gráfica  agradable,  convirtiéndolo    en  un    competidor    fuertemente  con 
otros sistemas operativos como Windows 
Servidor de Aplicaciones Web 
Teniendo en cuenta que  el diseño del prototipo de la aplicación esta orientado a la 
Web se requiere de  un servidor Web 2  para transferir lo que llamamos hipertextos, 
páginas Web o páginas HTML. 
La  aplicación  estará  alojada  en  un  servidor Web Tomcat  (Apache),  servidor  de 
fácil manejo y de excelente rendimiento. 
MySQL  (versión  5.0):  “MySQL  es  un  sistema  de  gestión  de  base  de  datos, 
multihilo y multiusuario” 3 , de  los principales   motivos por el  cual se escogió este 
motor de base de datos,. 
Ambiente Cliente 
La aplicación deberá correr en los principales navegadores como son: 
FireFox (Mozilla): 
Internet Explorer : 
Ambiente de Desarrollo 
La aplicación se desarrolla en  la herramienta DreamWeaver CS3, para el diseño 
de las pagina y formularios en PHP, que es una  herramienta para programadores 
pensada para escribir, compilar, depurar y ejecutar programas. 
2 Es un programa que implementa el protocolo HTTP (hypertext transfer protocol). 
3 http://dev.mysql.com
http://dev.mysql.com/tech-resources/articles/dispelling-the-myths.html
58 
Otras Herramientas 
PhpMyAdmin: es una herramienta que se usa para administrar las bases de datos 
de Mysql,  provee una interfaz gráfica Web que  permite crear, eliminar, actualizar 
y en fin hacer todo tipo de consultas en la Base de datos.
59 
9.  DISEÑO 
9.1.  Casos de Uso 
Modulo 
Admon 
Modulo 
Campeonato 
Modulo 
Equipo 
Agregar 
Jugador 
Modulo 
Jugador 
Editar 
Equipo 
Editar 
Jugador 
<<extends>> 
Editar 
CT 
<<extends>> 
Modulo 
CT 
Agregar 
CT 
Editar 
Admon 
Editar 
Campeonato 
Delegado 
Agregar 
Admon 
Consultar 
Admon 
<<extends>> 
Agregar 
Campeonato 
Consultar 
campeonato 
<<extends>> 
Agregar 
Equipo 
<<extends>> 
<<extends>> 
Consultar 
Equipo 
<<extends>> 
Administrador 
Figura 22.  Casos de uso del sistema 
<< extends>> 
<< extends>>
60 
Modulo 
Admon 
Editar 
Admon 
Agregar 
Admon 
Consultar 
Admon 
<<extends>> 
Administrador 
Figura 23.  Caso de uso Generar administrador 
Modulo Delegado 
Editar Delegado 
Agregar Delegado 
Consultar Delegado 
<<extends>> 
Administrador 
Figura 24.  Caso de uso Generar Delegado 
Modulo Campeonato 
Editar Campeonato 
Agregar Campeonato 
Consultar Campeonato 
<<extends>> 
Administrador 
Figura 25.  Caso de uso Generar Campeonato 
<< extends>> 
<< extends>> 
<< extends>>
61 
Modulo 
Equipo 
Editar 
Equipo 
Consultar  Equipo 
<<extends>> 
Agregar 
Equipo 
Administrador 
Figura 26.  Caso de uso Generar equipo 
Modulo 
Jugador 
Editar 
Jugador 
Consultar  Jugador 
Agregar Jugador 
Administrador 
<<extends>> 
Figura 27.  Caso de uso Generar Jugado 
Modulo Escenario Agregar Escenario 
Administrador 
Consultar Escenario 
<<extends>> 
Editar Escenario 
Figura 28.  Caso de uso Generar Escenario 
<< extends>> 
<< extends>>
62 
9.2.  Documentación Casos de Uso 
Tabla 14.Caso de uso “Agregar Administrador” 
Identificador  del  Caso 
de Uso 
CA1 
Nombre Caso de Uso:  Agregar Administrador 
Actor  Administrador 
Prioridad y Tipo  Alta 
Descripción  El administrador del sistema ingresa los datos del nuevo administrador en la base de datos 
Curso Básico Eventos:  ACTOR  SISTEMA 
1. El administrador se registra en el sistema 
ingresando cedula y contraseña. 
2.  El  sistema  valida  la  información 
ingresada por el administrador 
3.  El  administrador  coloca  los  datos  del 
nuevo  administrador  en  los  campos 
correspondientes. 
4. El  sistema  valida  los  datos  incluidos  por 
el administrador. 
5.  El  sistema  verifica  que  el  nuevo 
administrador  no se encuentre registrado. 
6.  El  sistema  ingresa  el  nuevo 
administrador. 
7. El  sistema avisa  al  administrador  que  la 
operación fue exitosa. 
Caminos deExcepción:  Para el evento 2, si el sistema encuentra un error en la validación de los datos de registro del 
administrador,  el  sistema  genera  un  mensaje  de  error  y  cancela  la  operación  permitiendo  al 
administrador volver a realizar la operación. 
Para  el  evento  4,  si  el  sistema  detecta  un  error  en  la  validación  de  los  campos,  genera  un 
mensaje  de  error  y  cancela  la  operación,  permitiendo  al  administrador  volver  a  realizar  la 
operación. 
Para  el  evento  5,  si  el  sistema  encuentra  que  el  nuevo  administrador  existe  en  el  sistema, 
muestra un mensaje de alerta y cancela la operación. 
Caminos Alternos:  Para el evento 1, si el administrador decide cancelar manualmente  la operación, no  ingresa al 
sistema y el sistema se cierra. 
Para el evento 3, si el administrador decide cancelar manualmente  la operación, el sistema no 
realiza ninguno de los eventos siguientes
63 
Tabla 15.Caso de uso “Consultar Administrador” 
Identificador  del  Caso 
de Uso 
CA2 
Nombre Caso de Uso:  Consultar Administrador 
Actor  Administrador 
Prioridad y Tipo  Baja 
Descripción  El administrador del sistema consulta  los datos de un nuevo Administrador 
Curso Básico Eventos:  ACTOR  SISTEMA 
1. El administrador se registra en el sistema 
ingresando cedula y contraseña. 
2.  El  sistema  valida  la  información 
ingresada por el administrador 
3.  El  administrador  coloca  la  cedula    del 
administrador que desea consultar. 
4.  El  sistema  muestra  los  resultados 
obtenidos 
Caminos de Excepción:  Para el evento 2, si el sistema encuentra un error en la validación de los datos de registro del 
administrador,  el  sistema  genera  un  mensaje  de  error  y  cancela  la  operación  permitiendo  al 
administrador volver a realizar la operación. 
Para  el  evento  3,  si  el  sistema  detecta  un  error  en  la  validación  de  la  cedula  suministrada, 
genera  un  mensaje  de  error  y  cancela  la  operación,  permitiendo  al  administrador  volver  a 
realizar la operación. 
Caminos Alternos:  Para el evento 1, si el administrador decide cancelar manualmente  la operación, no  ingresa al 
sistema y el sistema se cierra. 
Para el evento 3, si el administrador decide cancelar manualmente  la operación, el sistema no 
realiza ninguno de los eventos siguientes
64 
Tabla 16.Caso de uso “Editar Administrador” 
Identificador  del  Caso 
de Uso 
CA3 
Nombre Caso de Uso:  Editar Administrador 
Actor  Administrador 
Prioridad y Tipo  Alta 
Descripción  El administrador del sistema edita  los datos de un Administrador 
Curso Básico Eventos:  ACTOR  SISTEMA 
1. El administrador se registra en el sistema 
ingresando cedula y contraseña. 
2.  El  sistema  valida  la  información 
ingresada por el administrador 
3.  El  administrador  coloca  la  cedula    del 
Administrador que desea editar. 
4.  El  sistema  muestra  los  resultados 
obtenidos 
5.  El administrador actualiza los datos  que 
desea editar  del Administrador 
6. El  sistema  valida  los  datos  incluidos  por 
el administrador. 
7. El sistema ingresa los datos actualizados 
del Administrador. 
8. El  sistema avisa  al  administrador  que  la 
operación fue exitosa. 
Caminos de Excepción:  Para el evento 2, si el sistema encuentra un error en la validación de los datos de registro del 
administrador,  el  sistema  genera  un  mensaje  de  error  y  cancela  la  operación  permitiendo  al 
administrador volver a realizar la operación. 
Para  el  evento  3,  si  el  sistema  detecta  un  error  en  la  validación  de  la  cedula  suministrada, 
genera  un  mensaje  de  error  y  cancela  la  operación,  permitiendo  al  administrador  volver  a 
realizar la operación. 
Para  el  evento  6,  si  el  sistema  detecta  un  error  en  la  validación  de  los  campos,  genera  un 
mensaje  de  error  y  cancela  la  operación,  permitiendo  al  administrador  volver  a  realizar  la 
operación. 
Caminos Alternos:  Para el evento 1, si el administrador decide cancelar manualmente  la operación, no  ingresa al 
sistema y el sistema se cierra. 
Para el evento 3, si el administrador decide cancelar manualmente  la operación, el sistema no 
realiza ninguno de los eventos siguientes. 
Para el evento 5, si el administrador decide cancelar manualmente  la operación, el sistema no 
realiza ninguno de los eventos siguientes
65 
Tabla 17.Caso de uso “Agregar Delegado” 
Identificador  del  Caso 
de Uso 
CA4 
Nombre Caso de Uso:  Agregar  delegado 
Actor  Administrador 
Prioridad y Tipo  Alta 
Descripción  El administrador del sistema ingresa los datos de un nuevo delegado  en la base de datos 
Curso Básico Eventos:  ACTOR  SISTEMA 
1. El administrador se registra en el sistema 
ingresando cedula y contraseña. 
2.  El  sistema  valida  la  información 
ingresada por el administrador 
3.  El  administrador  coloca  los  datos  del 
nuevo  delegado  en  los  campos 
correspondientes. 
4. El  sistema  valida  los  datos  incluidos  por 
el administrador. 
5. El sistema verifica que el nuevo delegado 
no se encuentre registrado. 
6. El sistema ingresa el nuevo delegado. 
7. El  sistema avisa  al  administrador  que  la 
operación fue exitosa. 
Caminos de Excepción:  Para el evento 2, si el sistema encuentra un error en la validación de los datos de registro del 
administrador,  el  sistema  genera  un  mensaje  de  error  y  cancela  la  operación  permitiendo  al 
administrador volver a realizar la operación. 
Para  el  evento  4,  si  el  sistema  detecta  un  error  en  la  validación  de  los  campos,  genera  un 
mensaje  de  error  y  cancela  la  operación,  permitiendo  al  administrador  volver  a  realizar  la 
operación. 
Para el evento 5, si el sistema encuentra que el nuevo delegado existe en el sistema, muestra 
un mensaje de alerta y cancela la operación. 
Caminos Alternos:  Para el evento 1, si el administrador decide cancelar manualmente  la operación, no  ingresa al 
sistema y el sistema se cierra. 
Para el evento 3, si el administrador decide cancelar manualmente  la operación, el sistema no 
realiza ninguno de los eventos siguientes
66 
Tabla 18.Caso de uso “Consultar Delegado” 
Identificador  del  Caso 
de Uso 
CA5 
Nombre Caso de Uso:  Consultar Delegado 
Actor  Administrador 
Prioridad y Tipo  Baja 
Descripción  El administrador del sistema consulta  los datos de un Delegado 
Curso Básico Eventos:  ACTOR  SISTEMA 
1. El administrador se registra en el sistema 
ingresando cedula y contraseña. 
2.  El  sistema  valida  la  información 
ingresada por el administrador 
3.  El  administrador  coloca  la  cedula    del 
delegado que desea consultar. 
4.  El  sistema  muestra  los  resultados 
obtenidos 
Caminos de Excepción:  Para el evento 2, si el sistema encuentra un error en la validación de los datos de registro del 
administrador,  el  sistema  genera  un  mensaje  de  error  y  cancela  la  operación  permitiendo  al 
administrador volver a realizar la operación. 
Para  el  evento  3,  si  el  sistema  detecta  un  error  en  la  validación  de  la  cedula  suministrada, 
genera  un  mensaje  de  error  y  cancela  la  operación,  permitiendo  al  administrador  volver  a 
realizar la operación. 
Caminos Alternos:  Para el evento 1, si el administrador decide cancelar manualmente  la operación, no  ingresa al 
sistema y el sistema se cierra. 
Para el evento 3, si el administrador decide cancelar manualmente  la operación, el sistema no 
realiza ninguno de los eventos siguientes
67 
Tabla 19.Caso de uso “Editar Delegado” 
Identificador  del  Caso 
de Uso 
CA6 
Nombre Caso de Uso:  Editar Delegado 
Actor  Administrador 
Prioridad y Tipo  Alta 
Descripción  El administrador del sistema edita  los datos de un Delegado 
Curso Básico Eventos:  ACTOR  SISTEMA 
1. El administrador se registra en el sistema 
ingresando cedula y contraseña. 
2.  El  sistema  valida