Desarrollo de una aplicación web que permita controlar la gestión deportiva by Pontificia Universidad Católica del Ecuador sede Santo Domingo PUCE SD

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

Dirección Académica – Escuela de Sistemas

DESARROLLO DE UNA APLICACIÓN WEB QUE PERMITA CONTROLAR LA GESTIÓN DEPORTIVA DE LA FEDERACIÓN PROVINCIAL DE LAS LIGAS BARRIALES Y PARROQUIALES DE SANTO DOMINGO; EN EL PERIODO 2016-2017

Trabajo de Titulación previo a la obtención del título de Ingeniero de Sistemas y Computación.

Línea de investigación: Estudio, diseño e implementación de software

Autores: JEFFERSON GEOVANNY ZAMBRANO ZAMBRANO VALERIA ESTEFANÍA MONTENEGRO HERNÁNDEZ

Director: MG. LUIS JAVIER ULLOA MENESES Santo Domingo – Ecuador Agosto, 2017

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

Dirección Académica – Escuela de Sistemas HOJA DE APROBACIÓN

DESARROLLO DE UNA APLICACIÓN WEB QUE PERMITA CONTROLAR LA GESTIÓN DEPORTIVA DE LA FEDERACIÓN PROVINCIAL DE LAS LIGAS BARRIALES Y PARROQUIALES DE SANTO DOMINGO; EN EL PERIODO 2016-2017 Línea de Investigación: Estudio, diseño e implementación de software

Autores: JEFFERSON GEOVANNY ZAMBRANO ZAMBRANO VALERIA ESTEFANÍA MONTENEGRO HERNÁNDEZ

Luis Javier Ulloa Meneses, Mg

DIRECTOR DE LA DISERTACIÓN DE GRADO

José Luis Centeno Lara, Mg

CALIFICADOR

Margareth Viviana Hurtado Quiroz, Mg

CALIFICADOR

Margoth Elisa Guaraca Moyota, Mg

DIRECTORA DE LA ESCUELA DE SISTEMAS Santo Domingo – Ecuador Agosto, 2017

iii

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, Jefferson Geovanny Zambrano Zambrano portador de la cédula de ciudadanía Nº 235008558-1 declaro que los resultados obtenidos en la investigación que presento como informe final, previo a la obtención del Grado de Ingeniería de Sistemas y Computación son absolutamente originales, auténticos y personales.

En tal virtud, declaro que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de mi sola y exclusiva responsabilidad legal y académica.

Jefferson Geovanny Zambrano Zambrano CI. 2350085581

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, Valeria Estefanía Montenegro Hernández portador de la cédula de ciudadanía Nº 172228318-9 declaro que los resultados obtenidos en la investigación que presento como informe final, previo a la obtención del Grado de Ingeniería de Sistemas y Computación son absolutamente originales, auténticos y personales.

Valeria Estefanía Montenegro Hernández CI. 1722283189

AGRADECIMIENTO

Le agradezco a Dios por haberme acompañado y guiado a lo largo de mi carrera, siendo mi fortaleza en los momentos de debilidad, por haberme brindado salud y una vida llena de aprendizajes, experiencias, y felicidad. Le doy gracias a mis padres Elieser y Benita por haberme brindado el apoyo paternal y económico en todo momento, por los valores que me han inculcado, y haberme dado la oportunidad de tener una excelente educación en el transcurso de mi vida. Sobre todo por ser un excelente ejemplo de vida a seguir. Quisiera agradecer a mi director de tesis, el Mg. Luis Javier Ulloa Meneses, por su paciencia, motivación, dedicación y rigor. Me siento privilegiado haber contado con su tiempo, apoyo y guía. Gracias también a mis queridos compañeros y amigos, que me apoyaron y me permitieron ser parte de sus vidas, con quienes conviví dentro y fuera del salón de clase, por haber compartido momentos de alegría, de compañerismo, de respeto. Gracias a todos. Zambrano Geovanny

AGRADECIMIENTO A la culmiacion de estre trabajo agradesco a Dios por haberme guiado por este camino que a sido de felicidad; luego a cada uno de los que son parte de mi familia a mi PADRE Jorge, mi MADRE Ligia, a mis hermanos Paty, Leo y Letty y a mis pequeños angelitos, mis sobrinos; por siempre haberme dado su fuerza y apoyo incondicional que me han ayudado y llevado hasta donde estoy ahora. Por último a mis compañeros por ese compañerismo sano que siempre estuvo presente dentro y fuera de las aulas de clase y a mi director de tesis quién nos brido su ayuda en todo momento, Msc. Luis Ulloa.

Montenegro Valeria

vii

DEDICATORIA

Dedico esta tesis principalmente a Dios, por haberme dado la vida y permitirme haber llegado hasta este momento tan importante de mi formaciĂłn profesional. A mis padres, por ser las personas mĂĄs importantes de mi vida, por demostrarme siempre su cariĂąo y su apoyo incondicional. Zambrano Geovanny

viii

DEDICATORIA

Dedico este proyecto de tesis a Dios y a mis padres. A Dios porque ha estado conmigo en cada paso de mi vida, cuidándome y dándome fortaleza para continuar, a mis padres, las personas mas importates en mi vida, quienes con su ejemplo me han eseñado a luchar a pesar de todo por lo que queremos, quienes siempre han velado por mi bienestar y educación siendo mi apoyo incondiconal en todo momento. Mi padre quien es ese apoyo fuerte, el que me a inculcado todos los valores que ahora poseo, quien a pesar de tener un carácter fuerte siempre tiene una sonrisa, un abrazo y un buen consejo para mi. Mi madre que más que eso es mi mejor amiga, mi apoyo incondicional ante todo, quien dedica todo su ser al bienestar de su familia. Esto es por ellos que confiaron siempre en mí y en mis capacidades y son mi inspiracion para cada paso que doy y seguire dando. Y tambien es por ellos que soy lo que soy ahora. Los amo con mi vida y me dedicare toda ella a retribuirles todo lo que me an dado.

Montenegro Valeria

RESUMEN La presente disertación de grado comprende el desarrollo de una aplicación web que permite controlar la gestión deportiva de la FEDELIGAS-SDT (Federación Provincial de las Ligas Barriales y Parroquiales de Santo Domingo de los Tsáchilas), mediante la cual se busca la optimización de recursos como: tiempo y dinero. La aplicación web está conformada por tres módulos: de negocio, del sistema y del sitio web. El módulo de negocio, abarca los procesos de la FEDELIGAS-SDT; los que tienen mayor relevancia son: los registros y modificación de deportistas, campeonatos, actuaciones, pases y reportes de ficha de jugador y de carnets. El módulo del sistema comprende en la asignación de privilegios que se les da a los usuarios ingresados en el sistema. Y por último el del sitio web encargado de los registros y administración de noticias y enlaces de interés. Para el desarrollo de la aplicación web se utilizó la metodología ágil XP (Extreme Programming). Además, se implementó una arquitectura de programación por capas, con la finalidad de separar la capa de presentación (interfaz), negocio y datos (base de datos). El resultado del proyecto es una aplicación web que como herramienta es indispensable para lograr el control de la gestión deportiva de la FEDELIGAS-SDT, aportando a la comunidad del deporte un servicio ágil y eficiente.

ABSTRACT This degree dissertation includes the development of a web application that allows controlling the sports management of FEDELIGAS-SDT (Provincial Federation of the Neighborhood and Parish Leagues of Santo Domingo de los Tsรกchilas), which seeks to optimize resources as: time and money. The web application is made up of three modules: business, system and website. The business module, covers the processes of FEDELIGAS-SDT; The ones that have more relevance are: the registrations and modification of athletes, championships, performances, passes and reports of player card and licenses. The system module comprises in the allocation of privileges that are given to users entered into the system. And finally the one of the website responsible for the registration and administration of news and links of interest. For the development of the web application we used the Agile XP methodology (Extreme Programming). In addition, a layered programming architecture was implemented, in order to separate the presentation layer (interface), business and data (database). The result of the project is a web application that as a tool is indispensable to achieve the control of the sports management of FEDELIGAS-SDT, contributing to the sport community an agile and efficient service.

ÍNDICE DE CONTENIDOS 1.

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

PLANTEAMIENTO DEL PROBLEMA ........................................................................... 2

2.1.

Antecedentes ................................................................................................................... 2

2.2.

Problema de investigación .............................................................................................. 3

2.3.

Justificación de la investigación ..................................................................................... 4

2.4.

Objetivos de la Investigación .......................................................................................... 5

2.4.1.

Objetivo General ......................................................................................................... 5

2.4.2.

Objetivos Específicos: ................................................................................................. 5

MARCO REFERENCIAL ................................................................................................. 6

3.1.

Revisión de la Literatura o Fundamentos Teóricos ........................................................ 6

3.1.1.

Sistema Informático .................................................................................................... 6

3.1.2.1.

Calidad de Sistema Informático .............................................................................. 6

3.1.2.1.1. Componentes de la Calidad ..................................................................................... 6 3.1.2.1.2. Normas ISO 25000 .................................................................................................. 7 3.1.2.1.2.1. Modelo de calidad interna y externa .................................................................... 8 3.1.2.2.

Tecnologías, herramientas a utilizar y Desarrollo web ........................................... 9

3.1.1.2.1. HTML ...................................................................................................................... 9 3.1.1.2.2. PHP .......................................................................................................................... 9 3.1.1.2.3. JavaScript................................................................................................................. 9 3.1.1.2.4. CSS ........................................................................................................................ 10 3.1.1.2.5. ¿Qué es un Framework? ........................................................................................ 10 3.1.1.2.5.1. BOOTSTRAP .................................................................................................... 11 3.1.2.

Base de datos ............................................................................................................. 12

3.1.2.1.

Modelo de datos conceptuales ........................................................................... 12

3.1.2.2.1. Modelo entidad-relación .................................................................................... 12 3.1.2.2.2. Modelo orientado a objetos ................................................................................... 13

xii

3.1.2.2.

Modelo de datos lógicos ........................................................................................ 14

3.1.2.2.1. Modelo jerárquico.................................................................................................. 14 3.1.2.2.2. Modelo en red ........................................................................................................ 14 3.1.2.2.3. Modelo relacional .................................................................................................. 15 3.1.2.3.

Sistema gestor de base de datos ............................................................................. 16

3.1.2.3.1. MariaDB ................................................................................................................ 16 3.1.2.3.2. PostgreSQL ............................................................................................................ 16 3.1.2.3.3. Oracle..................................................................................................................... 17 3.1.3.

Ingeniería de Software .............................................................................................. 18

3.1.3.1.

Especificación de requerimientos de software (SRS)............................................ 18

3.1.3.1.1. Requerimientos funcionales y no funcionales ....................................................... 18 3.1.3.2.

Modelos Prescriptivos ........................................................................................... 20

3.1.3.1.1. Cascada .................................................................................................................. 20 3.1.3.1.2. Incremental ............................................................................................................ 21 3.1.3.1.3. Evolutivo ............................................................................................................... 22 3.1.3.1.4. Concurrente ........................................................................................................... 22 3.1.3.3.

Desarrollo Ágil ...................................................................................................... 23

3.1.3.2.1. Programación Extrema (XP) ................................................................................. 23 3.1.3.2.2. Scrum ..................................................................................................................... 24 3.1.4.

Institución pública ..................................................................................................... 24

3.1.4.1.

Administración Pública ......................................................................................... 24

3.1.4.3.1. Gestión administrativa ........................................................................................... 25 3.1.4.3.1.1. Control de Gestión Deportiva ............................................................................ 25 3.1.4.3.1.2. Desarrollo de una aplicación web que permita controlar la gestión deportiva .. 25 3.1.4.3.1.3. Reglamento de la administración de la FEDELIGAS-SDT .............................. 26 4. 4.1.

METODOLOGÍA DE INVESTIGACIÓN ...................................................................... 28 Diseño / Tipo de investigación ..................................................................................... 28

xiii

4.1.1.

Diseño de la investigación......................................................................................... 28

4.1.1.1. 4.1.2.

Diseño experimental .............................................................................................. 28 Tipos de la Investigación........................................................................................... 28

4.1.3.1.

Investigación Aplicada: Descriptiva ...................................................................... 28

4.1.3.2.

Investigación bibliográfica .................................................................................... 29

4.2.

Población / Universo ..................................................................................................... 29

4.2.1.

Población ................................................................................................................... 29

4.3.

Muestra ......................................................................................................................... 29

4.4.

Técnicas/ Instrumentos de recogidas de datos .............................................................. 30

4.4.1.

Técnicas de recogida de datos ................................................................................... 30

4.4.2.

Instrumentos de recogida de datos ............................................................................ 30

4.5.

Técnicas de análisis de datos ........................................................................................ 31

4.5.1.

Análisis estadístico .................................................................................................... 31

4.5.2.

Análisis cualitativo .................................................................................................... 31

4.5.3.

Metodología de desarrollo de software ..................................................................... 31

4.6.1.

Programación Extrema (XP) ..................................................................................... 32

4.6.1.1. 5.

Etapas del modelo .................................................................................................. 33

RESULTADOS ................................................................................................................ 35 5.1.

Discusión y Análisis de los resultados ...................................................................... 35

5.1.1.

Entrevista dirigida al presidente y secretaria de la FEDELIGAS-SDT................. 35

5.1.2.

Encuesta dirigida a los jugadores de la FEDELIGAS-SDT .................................. 37

5.2.

Proceso de desarrollo de software usando Programación Extrema (XP) .................. 45

5.2.1.

Etapa 1: Planeación ............................................................................................... 45

5.2.1.1.

Exploración ........................................................................................................ 45

5.2.1.2.

Módulos del Sistema .......................................................................................... 45

5.2.1.3.

Historias de Usuario ........................................................................................... 46

5.2.1.3.1. Especificación de Historias de Usuarios. ........................................................... 46

xiv

5.2.1.3.2. Plan de Iteraciones ............................................................................................. 54 5.2.1.3.3. Plan de entrega ................................................................................................... 55 5.2.2.

Etapa 2: Diseño ...................................................................................................... 56

5.2.2.1.

Tarjetas CRC ...................................................................................................... 56

5.2.2.2.

Diseño de la base de datos ................................................................................. 57

5.2.2.1.1. Diseño conceptual de la Base de Datos ............................................................. 58 5.2.2.1.2. Diseño lógico de la Base de Datos ..................................................................... 59 5.2.2.1.3. Diseño físico de la Base de Datos ...................................................................... 60 5.2.2.3. 5.2.3.

Etapa 3: Codificación ............................................................................................ 65

5.2.3.1. 5.2.4.

Diccionario de Datos.......................................................................................... 65

Script de la Base de Datos ................................................................................. 65 Etapa 4: Pruebas .................................................................................................... 66

5.3.

Conclusiones ............................................................................................................. 77

5.4.

Recomendaciones ...................................................................................................... 78

LISTA DE REFERENCIAS .................................................................................................... 79 Bibliográfica ............................................................................................................................ 79 Lincográfica ............................................................................................................................. 79 GLOSARIO ............................................................................................................................. 82 ANEXOS……………………………………………………………………………………. 83

ÍNDICE DE TABLAS Tabla 1. Comparativa entre Metodologías Tradicionales y ágiles ........................................... 32 Tabla 2. Grado de agilidad en XP y Scrum ............................................................................. 33 Tabla 3. Proceso de software en XP y Scrum .......................................................................... 33 Tabla 4. Tiempo de espera de atención en la FEDELIGAS-SDT ........................................... 37 Tabla 5. Inconvenientes en la obtencion de infomacion en la FEDELIGAS-SDT ................. 38 Tabla 6. Dificultad al trasladarse por informacion a la FEDELIGAS-SDT ............................ 39 Tabla 7. Motivos que dificultan el traslado hacia la FEDELIGAS-SDT ................................ 40 Tabla 8. Metodos de obtencion de informacion futura ............................................................ 41 Tabla 9. Utilidad de las aplicaciones web en la FEDELIGAS-SDT ....................................... 42 Tabla 10. Importancia de la implementacion de una aplicacion web en la FEDELIGAS-SDT .................................................................................................................................................. 43 Tabla 11. Importancia de la generacion de fichas del jugador en la web ................................ 44 Tabla 12. Módulos y métodos de la aplicación web ................................................................ 46 Tabla 13. Historia de usuario, Registro de usuario .................................................................. 46 Tabla 14. Historia de usuario, Administración de usuario....................................................... 47 Tabla 15. Historia de usuario, Registro de ligas ...................................................................... 47 Tabla 16. Historia de usuario, Administración de ligas ........................................................... 48 Tabla 17. Historia de usuario, Registro de club ....................................................................... 48 Tabla 18. Historia de usuario, Administración de club ........................................................... 48 Tabla 19. Historia de usuario, Registro de deportistas ............................................................ 49 Tabla 20. Historia de usuario, Administración de los deportistas ........................................... 49 Tabla 21. Historia de usuario, Registro de categorías ............................................................. 50 Tabla 22. Historia de usuario, Administración de categorías .................................................. 50 Tabla 23. Historia de usuario, Registros de campeonatos ....................................................... 50 Tabla 24. Historia de usuario, Administración de campeonatos ............................................. 51 Tabla 25. Historia de usuario, Registro de carnet .................................................................... 51 Tabla 26. Historia de usuario, Administración de carnet ......................................................... 51 Tabla 27. Historia de usuario, Administración de campeonatos ............................................. 52 Tabla 28. Historia de usuario, Búsqueda de las actuaciones de los deportistas....................... 52 Tabla 29. Historia de usuario, Registro de Pases ..................................................................... 52 Tabla 30. Historia de usuario, Reporte de ficha de jugadores registrados ............................... 53 Tabla 31. Historia de usuario, Parametrización del sistema .................................................... 53

xvi

Tabla 32. Plan de Iteraciones v2.6 ........................................................................................... 54 Tabla 33. Plan de entrega v2.6 ................................................................................................. 55 Tabla 34. Tarjeta CRC.- sistema_model .................................................................................. 56 Tabla 35. Tarjeta CRC.- Negocio_model ................................................................................ 56 Tabla 36. Tarjeta CRC.- Websites_model ............................................................................... 56 Tabla 37. Prueba de Aceptación de registro de usuario. .......................................................... 66 Tabla 38. Prueba de Aceptación de administración de usuario. .............................................. 66 Tabla 39. Prueba de Aceptación de registro de ligas. .............................................................. 67 Tabla 40. Prueba de Aceptación de administración de ligas. .................................................. 68 Tabla 41. Prueba de Aceptación de registro de club. ............................................................... 68 Tabla 42. Prueba de Aceptación de administración de club. ................................................... 69 Tabla 43. Prueba de Aceptación de registro de deportistas. .................................................... 69 Tabla 44. Prueba de Aceptación de administración de deportistas. ......................................... 70 Tabla 45. Prueba de Aceptación de registro de categorías. ..................................................... 70 Tabla 46. Prueba de Aceptación de administración de categorías. ......................................... 70 Tabla 47. Prueba de Aceptación de registro de campeonatos. ................................................. 71 Tabla 48. Prueba de Aceptación de administración de campeonatos. ..................................... 71 Tabla 49. Prueba de Aceptación de registro de carnet. ............................................................ 72 Tabla 50. Prueba de Aceptación de administración de carnet. ................................................ 72 Tabla 51. Prueba de Aceptación de registro de actuaciones. ................................................... 73 Tabla 52. Prueba de Aceptación de búsqueda de actuaciones de los deportistas. ................... 73 Tabla 53. Prueba de Aceptación de registro de pases. ............................................................. 74 Tabla 54. Prueba de Aceptación de reporte de ficha del jugador. ........................................... 75 Tabla 55. Prueba de Aceptación de parametrización del sistema. ........................................... 75

xvii

ร NDICE DE FIGURAS Figura 1. Dimensiones de calidad de SI..................................................................................... 7 Figura 2. Modelo para la calidad externa e interna .................................................................... 8 Figura 3. Sitio web de Bootstrap.............................................................................................. 11 Figura 4. Esquema E-R para una biblioteca............................................................................. 13 Figura 5. Diagrama de clases para una biblioteca.................................................................... 13 Figura 6. Esquema de una base de datos jerรกrquica................................................................. 14 Figura 7. Esquema de una base de datos en red ....................................................................... 15 Figura 8. Esquema de una base de datos relacional con datos................................................. 15 Figura 9. Logo MariaDB.......................................................................................................... 16 Figura 10. Logo PostgreSQL ................................................................................................... 16 Figura 11. Logo Oracle ............................................................................................................ 17 Figura 12. Lectores de diferentes tipos de especificaciones de requerimientos. ..................... 19 Figura 13. Tipos de requerimientos no funcionales ................................................................. 20 Figura 14. Etapas del modelo cascada ..................................................................................... 21 Figura 15. Etapas del modelo incremental ............................................................................... 21 Figura 16. Etapas del modelo evolutivo .................................................................................. 22 Figura 17. Etapas del modelo concurrente ............................................................................... 22 Figura 18. Etapas del modelo XP ............................................................................................ 23 Figura 19. Etapas del modelo Scrum ....................................................................................... 24 Figura 20. Formula del muestreo ............................................................................................. 30 Figura 21. Tiempo de espera de atenciรณn en la FEDELIGAS-SDT ........................................ 37 Figura 22. Inconvenientes en la obtencion de infomacion en la FEDELIGAS-SDT .............. 38 Figura 23. Dificultad al trasladarse por informacion a la FEDELIGAS-SDT ......................... 39 Figura 24. Motivos que dificultan el traslado hacia la FEDELIGAS-SDT ............................. 40 Figura 25. Metodos de obtencion de informacion futura ......................................................... 41 Figura 26. Utilidad de las aplicaciones web en la FEDELIGAS-SDT .................................... 42 Figura 27. Importancia de la implementacion de una aplicacion web en la FEDELIGAS-SDT .................................................................................................................................................. 43 Figura 28. Importancia de la generacion de fichas del jugador en la web ............................... 44 Figura 29. Modelo conceptual de la FEDELIGAS-SDT ......................................................... 58 Figura 30. Modelo lรณgico de la FEDELIGAS-SDT ................................................................ 59 Figura 31. Modelo fisico de la FEDELIGAS-SDT ................................................................. 60

xviii

Figura 32. Interfaz web: Inicio................................................................................................. 61 Figura 33. Interfaz web: Noticias............................................................................................. 61 Figura 34. Interfaz web: GalerĂa .............................................................................................. 62 Figura 35. Interfaz web: Login ................................................................................................ 62 Figura 36. Interfaz de Consola Administrativa ........................................................................ 63 Figura 37. Reporte de Carnets por Campeonatos en Actuaciones ........................................... 63 Figura 38. Reporte de la Ficha del Jugador. ............................................................................ 64

xix

INDICE DE ANEXOS

Anexo 1. Entrevista dirigida al presidente y secretaria de la federación provincial de ligas barriales y parroquiales de santo domingo............................................................................... 83 Anexo 2. Encuesta dirigida a los deportistas pertenecientes a la federación provincial de ligas barriales y parroquiales de santo domingo............................................................................... 85 Anexo 3. Archivo para la estandarización de la base de datos de la federación provincial de ligas barriales y parroquiales de santo domingo .................................................................... 865 Anexo 4. Codificación de los módulos de pases, campeonatos y carnets .............................. 87 Anexo 5. Capacitación del personal en la administración del sistema ................................... 89 Anexo 6. Acta de entrega- recepción ...................................................................................... 91 Anexo 7. Carta de impacto...................................................................................................... 92

1. INTRODUCCIÓN

En el presente trabajo de investigación se desarrollará una aplicación web que permita controlar la gestión deportiva de la Federación Provincial de las Ligas Barriales y Parroquiales de Santo Domingo en el periodo 2016-2017; debido a los problemas presentados en la institución como: la inscripción de los jugadores, los pases de club, los eventos en las diferentes ligas, todo esto es un proceso que hasta la actualidad se lo hace de forma manual, por lo que se invierte mayor tiempo y debido a esto el proceso no se puede controlar eficientemente; además presenta errores en el proceso. El objeto de estudio en la investigación es el desarrollo de una aplicación web, en este caso una que ayude en el control de la gestión deportiva en la institución, de esta manera se optimizará tiempo y recursos; además la institución podrá tener toda la información de sus jugadores y los movimientos que realizan internamente en fecha y hora exacta. Mediante esta aplicación web la misma que estará disponible las 24 horas, permitirá a las personas allegadas conocer los historiales de jugadores, clubs y ligas, según sea el caso. El marco referencial del documento, ayuda a sustentar la creación de la aplicación web, donde se encuentra la información que está debidamente estructurada por las dos variables de investigación como son: la independiente y dependiente. En la independiente consta del contenido, el cual guiará en la elección de las herramientas a utilizar; para el correcto desarrollo de la misma, y en la variable dependiente da a conocer la información, con referencia a la institución. En la metodología de investigación se ha escogido el enfoque cuantitativo de tipo bibliográfico y aplicado: con el método descriptivo. Esta investigación se fundamenta en la aplicación de cuestionarios para las entrevistas (dos personas) y encuestas (372 deportistas). Se usó la herramienta Excel para la tabulación de los datos obtenidos en las encuestas y un documento de Word para el análisis de las opiniones obtenidas en las entrevistas. En el capítulo final se da a conocer los resultados, en función a la entrevista, cuestionario, metodología y objetivos. Para lo cual en la entrevista se hace uso del ánalisis de la misma; en el cuestionario se hace uso de la tabulación de datos; en la metodología se realiza toda la etapa

metodología

(Planificación,

Diseño,

Codificación

y Pruebas).

2. PLANTEAMIENTO DEL PROBLEMA

2.1.

Antecedentes

La Federación Provincial de Ligas Deportivas Barriales y Parroquiales de Santo Domingo de los Tsáchilas, fundada en la ciudad de Santo Domingo, provincia de Santo Domingo de los Tsáchilas, el 27 de Junio del 2011, es una institución deportiva de derecho privado, con objetivos sociales, sin fines de lucro y que goza de autonomía administrativa, técnica y económica. (FEDELIGAS-SDT, 2012) Su finalidad es dirigir y fomentar el deporte barrial y parroquial de la Provincia de Santo Domingo de los Tsáchilas y se rige por la Ley de Deporte, Educación Física y Recreación y su Reglamento General, al tenor de lo dispuesto en el artículo 4 de la Ley de deporte, Educación Física y Recreación. Es filial de la Federación Nacional de Ligas Deportivas Barriales y Parroquiales del Ecuador – FEDENALIGAS. (FEDELIGAS-SDT, 2012) La Federación Provincial de Ligas Deportivas Barriales y Parroquiales, tendrá un plazo indefinido en sus funciones, y el número de sus asociados estará en función del número de Ligas Barriales y Parroquiales constituidas y que en lo posterior se constituyan. (FEDELIGAS-SDT, 2012) Las Ligas Barriales y Parroquiales de los cantones en donde no existan Federaciones Cantonales de Ligas Barriales y Parroquiales se afiliarán directamente a la Federación Provincial de Ligas Deportivas Barriales y Parroquiales de Santo Domingo de los Tsáchilas, conocido también por su abreviatura: FEDELIGAS–SDT. (FEDELIGAS-SDT, 2012) FEDELIGAS – SDT, tendrá como objetivo principal la recreación de todos los miembros de la comunidad a través de la práctica del deporte recreativo y las actividades físicas lúdicas, debiendo ser estas, equitativas e incluyentes, tanto en género, edad, grupos de atención prioritaria y condición socioeconómica; eliminando de su práctica todo tipo de discriminación. (FEDELIGAS-SDT, 2012) Debido al avance tecnológico y la incorporación del mismo, La FEDELIGAS – SDT, ha tomado la decisión de implementar el uso de las TIC, además en la actualidad se requiere eliminar la incertidumbre de la seguridad de los datos de los deportistas, para llevar un mejor

control de la gestión de las actividades administrativas, que en la actualidad se las lleva a cabo de forma manual. Al poder contar con una herramienta informática que en este caso es un sistema a la medida, la información que se almacena no podrá ser duplicada, ni falsificada; eliminando la incertidumbre por parte de los administrativos; asimismo la entrega de información oportuna de los deportistas y sus carnets respectivos. Por tal motivo, se considera importante el desarrollo de un sistema informático que permita controlar la gestión deportiva, de una manera sistematizada, con el cual se podrá satisfacer las necesidades de la FEDELIGAS – SDT; dando así apertura al desarrollo de la provincia por medio de la tecnología.

Problema de investigación

2.2.

¿Cómo controlar la gestión deportiva de la Federación Provincial de las ligas barriales y parroquiales de Santo Domingo? La Federación Provincial de Ligas Barriales y Parroquiales de Santo Domingo de los Tsáchilas, es una institución pública que dedica sus actividades al manejo de la actividad deportiva no profesional de la provincia de Santo Domingo de los Tsáchilas, en la actualidad esta institución cuenta con una numerosa cantidad de deportistas asociados a ella y el control de los mismos no se ha automatizado aun debido a su corta vida institucional. El sistema actual que se utiliza para controlar las gestiones deportivas, ha creado grandes incertidumbres al momento de las participaciones de los campeonatos, debido al mecanismo semi-digital, no les permite tener un gran conocimiento del historial deportivo de cada jugador (ficha de jugador). Además, el no contar con una página web a la medida, no les permite conocer las actividades programadas, tanto para los conformantes de la institución en especial los jugadores, y la comunidad de Santo Domingo de los Tsáchilas. 2.2.1. Preguntas básicas Teniendo en claro el problema principal se plantean las siguientes interrogantes:  ¿Cuáles son los requerimientos institucionales para el desarrollo de la aplicación?

 ¿Qué métodología de desarrollo de software se utilizará, para la creación de la aplicación web?  ¿Qué herramientas tecnológicas se necesita para el desarrollo de la aplicación web?  ¿Qué métodos se aplicarán, para que el usuario conozca todo el manejo de la aplicación web?

2.3.

Justificación de la investigación

Actualmente las empresas o instituciones sean públicas o privadas hacen uso de los medios sociales y sitios web, ellas han adoptado esta tecnología para asegurar el manejo de grandes volúmenes de datos y garantizar la fiabilidad y la seguridad en la nube de estos, además aquí presentan los servicios que ofrecen o el trabajo realizado, al mismo tiempo que atraen nuevos clientes. Estas páginas web permiten mostrar al público lo antes mencionado y toda la información; la manera en como desarrollan sus actividades y como están constituidas, de tal manera que brindan información oportuna para las personas que las visiten o que pertenezcan a la institución. El uso de aplicaciones web permite que las empresas estén disponibles las 24 horas del día, se dirijan a consumidores, clientes, profesionales o inversores. Además que una sola persona puede manejar todos los aspectos de la aplicación. De esta manera se desarrollará una aplicación web que además de mostrar las actividades que cumple la Federación Provincial de Ligas Barriales y Parroquiales de Santo Domingo les permita a los encargados de la institución manejar toda la información de las personas asociadas a ella como son los deportistas, siendo necesario conocer de estos todo su historial deportivo y también toda la gestión que realiza internamente. Además el desarrollo de la aplicación web, promueve la inclusión social y está relacionada con el objetivo número 4 del plan del buen vivir “FORTALECER LAS CAPACIDADES Y POTENCIALIDADES DE LA CIUDADANÍA”.

Se considera viable el proyecto ya que además de la necesidad que existente en la institución, se cuenta con todo el apoyo por parte de los directivos en los ámbitos administrativos y operativos.

2.4.

Objetivos de la Investigación

2.4.1. Objetivo General Desarrollar una aplicación web que permita controlar la gestión deportiva de la Federación Provincial de las ligas barriales y parroquiales. 2.4.2. Objetivos Específicos: 

Generar un modelo matriz para llevar a cabo las historias de usuarios pertinentes, dando así a conocer los requerimientos del sistema.



Identificar la metodología de desarrollo de software, para su elaboración.



Determinar las herramientas tecnológicas adecuadas para el desarrollo del software de la federación provincial de ligas barriales y parroquiales.



Diseñar un manual de usuario para entender de mejor manera sus funcionalidades y poder dar mantenimiento de forma precisa.



Capacitar a los directivos de la federación provincial, sobre las funcionalidades de cada modulo de la aplicación web.

3. MARCO REFERENCIAL 3.1.

Revisión de la Literatura o Fundamentos Teóricos

3.1.1. Sistema Informático Un sistema informático se define según: Johansen (2013) como la capacidad de información que se sostiene por la parte primordial de los procesamientos. El sistema informático es un todo que interactúa entre sí, para resolver un problema (pp.53-54). La interrelación del hardware, software, datos y recurso humano permiten almacenar y procesar aquella información para la toma de decisiones (pp.53-54). 3.1.2.1. Calidad de Sistema Informático La calidad de los sistemas informáticos es un factor que influye en el éxito o fracaso de un programador; en el último informe “CHAOS” del Standish Group, realizado en el 2009, da a conocer datos estadísticos. “El 32% de los proyectos informáticos finalizan en el tiempo estimado, con recursos planificados y calidad aceptable, mientras un 24% no finaliza nunca. El resto (44%) lo hace pero consumiendo más recursos o menos funcionalidades de las previstas” (Piattini, García Rubio, García Rodríguez, & Pino, 2012, p.73). 3.1.2.1.1. Componentes de la Calidad Según Piattini, García Rubio, García Rodríguez, & Pino (2012) afirman que la calidad del sistema informático se divide en distintos campos que aportan a la misma, además en su investigación referente a la calidad estudian la “visión holística” propuesta por: Stylianou y Kumar (2010), en la cual esta visión de la calidad de los sistemas informáticos,es considerada en distintas dimensiones.(pp. 76-77)

Figura 1. Dimensiones de calidad de SI Fuente: Piattini, M., García Rubio, F., García Rodríguez, I., & Pino, F. (2012). Calidad de Sistema Informático. México D.F: Alfaomega.

3.1.2.1.2. Normas ISO 25000 La ISO 25000 es conocida también como: SQuaRE (Software product Quality Requirements and Evaluation); la cual está conformada por cinco apartados como son: 

ISO/IEC 2500n – División de Gestión de Calidad: “Definen todos los modelos, términos y definiciones comunes referenciados por todas las otras normas de la serie SQUARE” (Piattini, García Rubio, García Rodríguez, & Pino, 2012, p. 99).



ISO/IEC 2501n – División de Modelo de Calidad: Según: Piattini, García Rubio, García Rodríguez, & Pino (2012), representa un modelo de calidad detallada incorporando características para calidad interna, externa y en uso (p.99).



ISO/IEC 2502n – División de Medición de Calidad: “Incluye un modelo de la medición de la calidad del producto, definiciones de medidas de calidad y guías prácticas para su aplicación” (Piattini, García Rubio, García Rodríguez, & Pino, 2012, p.99).



ISO/IEC 2503n – División de Requisitos de Calidad: Piattini, García Rubio, García Rodríguez, & Pino (2012) afirman qué: esta ISO ayuda a especificar los requisitos de

calidad que pueden ser usados en el proceso extraer información del software a desarrollar (p.100.). 

ISO/IEC 2504n – División de Evaluación de Calidad: “Este apartado incluye normas que proporcionan requisitos, recomendaciones y guías para la evaluación de productos software” (Piattini, García Rubio, García Rodríguez, & Pino, 2012, p.100).

Modelo de calidad interna y externa Piattini, García Rubio, García Rodríguez, & Pino (2012), en su investigación afirman que este modelo categoriza las propiedades de la calidad de software en seis características tales como: funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad.

Figura 2. Modelo para la calidad externa e interna Fuente: Piattini, M., García Rubio, F., García Rodríguez, I., & Pino, F. (2012). Calidad de Sistema Informático. México D.F: Alfaomega.

3.1.2.2. Tecnologías, herramientas a utilizar y Desarrollo web 3.1.1.2.1. HTML Es un lenguaje de programación del lado del cliente; HTML (HyperText Markup Languaje) es un lenguaje que funciona con el uso de etiquetas, las cuales se abren y se cierran con estos símbolos (mayor que y menor que < >), este lenguaje como muchos se puede incluir atributos o parámetros. La estructura en un archivo HTML está dada por: la etiqueta <html>, cabecera <head> y cuerpo <body>, sin embargo existen más etiquetas como para la creación de títulos, tablas, formularios, entre otros. (Gauchat, 2014, pp.1-2) 3.1.1.2.2. PHP Es un lenguaje de programación del lado del servidor, además es un lenguaje interpretado, utilizado para la creación de páginas web dinámicas. PHP es un acrónimo que significa PHP Hypertext Pre-processor. Este lenguaje es extendido en la mayoría de servidores web y en la gran mayoría de sistemas operativos y plataformas gratuitas, así como otros lenguajes de programación que permiten crear aplicaciones complejas, este igual y tiene relación con MySQL, para hacer la conexión con la base de datos y poder realizar las inserciones, eliminaciones, actualizaciones y otros procesos. (Sánchez, 2012, p.10) 3.1.1.2.3. JavaScript En la investigación realizada por: Gauchat (2014) da a conocer que Javascript es un lenguaje interpretado, el cuál ha venido evolucionando con el pasar del tiempo; en la actualidad es uno de los lenguajes mas populares. Este lenguaje es de secuencias de comandos, es similar a otros lenguajes de programación tales como C++, Java, Phyton. Javascript tiene una característica significativa que lo diferencia de los demás lenguajes de programación, la cual es su naturaleza. Este lenguaje está apoyado en prototipos, por lo que se pueden desarrollar numerosas tareas, instrucciones simples hasta el cálculo de complejos algoritmos, lo mas importante de este lenguaje es que puede almacenar y procesar información, a travez de variables, al igual que otros lenguajes.(pp.111-112)

3.1.1.2.4. CSS Este lenguaje trabaja a la par con HTML y cumple la función de dar estilos a lo que se programa en HTML, por ejemplo: tipo de letra, tamaño, color de letra, fondos, imágenes de fondo, bordes, entre otros. Por lo general los navegadores asignan estilos por defecto al HTML, sin embargo muchas de las veces estos estilos no cumple con el lineamiento propuesto, para el desarrollo de nuestra página web. Cada programador tiene su propio PLUS o manera de programar, lo que hace reconocible su código; en referente a los estilos, utilizan sus propios estilos, para lograr el fin propuesto o diseño anhelado. (Gauchat, 2014, p. 34) 3.1.1.2.5. ¿Qué es un Framework? En la investigación realizada por: Clemente (2014) afirma que Framework “es un conjunto estructurado y complejo de archivos HTML, CSS, JS, etc., que proporcionan un entorno de trabajo preparado para ser utilizado como base en un proyecto”(p.169). Los frameworks son adaptativos, por lo que tienen como objetivo dar un buen diseño a un sitio web o sistema web, ayudando a los diseñadores o en muchos de los casos hasta los desarrolladores (en ocaciones desempeñan también el rol de diseñadores) a ahorarra tiempo y procesos. Gracias al ahorro de tiempo y procesos que nos ofrecen los frameworks da más tiempo al desarrollador a concentrarse y utilizar ese tiempo ahorrado, en las funcionalidades que tiene cada aplicación web. El utilizar un framework no quiere decir que el desarrollador o diseñador no sepa con referencia al tema, como por ejemplo como hacer una tabla, darle estilos, hacer el diseño responsive, etc., (Clemente, 2014, p.169) en el caso de los desarrolladores son expertos en las funcionalidades del sistema, validaciones, pruebas de errores y entre otras características; sin embargo suele ser más tedioso construir un diseño web, y se suelen generar las siguientes interrogantes: ¿Qué colores se pueden usar para este sistema?, ¿En qué posición se colocará el menú?, ¿Qué forma se le dará al menú?, ¿El diseño final será agradable para los usuarios finales?, entre otras interrogantes. Por tal motivo resulta mejor utilizar un framework. Existe una gran variedad de frameworks unos más utilizados que otros por sus funcionalidades, como por ejemplo los que da a conocer Clemente ( 2014), asegurando que son los más complejos:



Bootstrap



Foundation



Groundwork



Skeleton.

3.1.1.2.5.1. BOOTSTRAP Este es uno de los frameworks más popular, completo y complejo. Según Clemente (2014) afirma que este framework fue creado y redimido, por Twiter, que ofrece soporte a una gran aglomeración de funcionalidades. Además está constituido por: columnas, botones, desplegables, imágenes, barras de progreso, tablas, formularios, tipografía, menú, etc. La página oficial para descargar todos los ficheros de Bootstrap es: http://bit.ly//158Y3AO, en los cuales existe abundante información, para documentar el funcionamiento de Bootstrap. (p.175)

Figura 3. Sitio web de Bootstrap Fuente: Clemente, P. (2014). Diseño Web Adaptativo. España: Anaya multimedia.

3.1.2. Base de datos En la investigación llevada a cabo por: Piñeiro (2013) afirma que es la recopilación o colección de datos integrados con superfluidad controlada y con uan estructutura que muestre las interrelaciones y restricciones que se ven en el mundo real; además cuenta con procedimientos de ingreso, actualización, eliminación y recuperación de datos. Los datos es la parte más importante e integral, por lo que necesita de un sistema gestor de base de datos (SGBD), para llevar una buena administración de la base de datos.(pp3-4) 3.1.2.1. Modelo de datos conceptuales 3.1.2.2.1. Modelo entidad-relación Este modelo fue propuesto por Chen, el cuál distribuye a este modelo por entidades, relaciones y atributos. (Piñeiro, 2013, p. 11) 

Una entidad: Se define como cualquier objeto, en el cual se almacena información en la base de datos. Las entidades se representan por un rectángulo, en la parte interna del rectángulo va el nombre de la entidad por ejemplo: Si se crea una base de datos para una clínica, una entidad podría ser pacientes. (Piñeiro, 2013, p. 11)



Una relación: Es una conexión que existe entre entidades, se representa por medio de un rombo, al igual que la entidad en la parte interior del rombo se coloca el nombre de la relación, además la relación va acompañada de la cardinalidad, por ejemplo: entre dos entidades cliente y vehículo se puede establecer una relación que refleje el hecho de que “un cliente compra uno o varios vehículos”. (Piñeiro, 2013, p. 11)



Un atributo: Es una característica de muchas que tiene una entidad o relación; por ejemplo, se tiene una entidad llamada vehículo esta puede tener las siguientes características: código, color, marca, año de fabricación, modelo, etc. Se representa por medio de un óvalo, al igual que la entidad y relación su nombre va en la parte interna del óvalo; además va unida por una línea a la entidad o relación. (Piñeiro, 2013, p. 11)

Figura 4. Esquema E-R para una biblioteca Fuente: Piñeiro, J. (2013). Base de datos relacionales y modelado de datos. Madrid: Paraninfo.

3.1.2.2.2. Modelo orientado a objetos En la investigación fundada por: Piñeiro (2013) el modelo orientado a objetos es una ampliación del modelo Entidad Relación. En el año 1996 surgieron los métodos de análisis y diseño orientados a objetos, gracias a estos métodos se dio paso a la aparición del lenguaje de Modelado Unificado conocido por su abreviatura UML. Este lenguaje sirve para elaborar diagramas de clases la cual está compuesta por los siguientes elementos: las clases, con sus atributos y métodos, y las relaciones. (pp. 12-13)

Figura 5. Diagrama de clases para una biblioteca Fuente: Piñeiro, J. (2013). Base de datos relacionales y modelado de datos. Madrid: Paraninfo.

3.1.2.2. Modelo de datos lógicos 3.1.2.2.1. Modelo jerárquico Este modelo trabaja con árboles para la representación lógica de los datos, un padre es la parte primordial o el eje de un árbol, conocido también como la “raíz”, el padre puede tener muchos hijos, y así mismo los hijos pueden tener más hijos; sin embargo los hijos solo pueden tener un padre. A continuación se muestra un diagrama de estructura de árbol con dos registros: departamento y empleado. (Piñeiro, 2013, p. 14)

Figura 6. Esquema de una base de datos jerárquica Fuente: Piñeiro, J. (2013). Base de datos relacionales y modelado de datos. Madrid: Paraninfo.

3.1.2.2.2. Modelo en red Según el criterio de Piñeiro (2013), sustenta en su investigación que este modelo trabaja con una estructura no lineal, en la que cada nodo hijo puede llegar a tener algunos nodos padres, las entidades se representan por grafos y las agrupaciones entre ellos, mediante los arcos que enlazan los nodos. El modelo de red más amplio es el Codasyl, a continuación se muestra una figura con un ejemplo de modelo de datos en red. (pp. 14-15)

Figura 7. Esquema de una base de datos en red Fuente: Piñeiro, J. (2013). Base de datos relacionales y modelado de datos. Madrid: Paraninfo.

3.1.2.2.3. Modelo relacional Este modelo fue construido por Codd en 1970, en este modelo se utilizan tablas para la representación lógica de los datos y la relación que existe entre ellos. “Se llama tupla a cada fila de la tabla y campo o atributo a cada columna de la tabla. Una clave es un atributo o conjunto de atributos que identifica de manera única a cada tupla”. (Piñeiro, 2013, p. 15). A continuación se muestra una figura que muestra el esquema de una base de datos relacional.

Figura 8. Esquema de una base de datos relacional con datos Fuente: Piñeiro, J. (2013). Base de datos relacionales y modelado de datos. Madrid: Paraninfo.

3.1.2.3. Sistema gestor de base de datos 3.1.2.3.1. MariaDB

Figura 9. Logo MariaDB Fuente: Bartholomew, D. (09 de 2012). eandbsoftware. Recuperado el 20 de 11 de 2016, de http://www.eandbsoftware.org/wp-content/uploads/2015/03/MariaDB_vs_MySQL__MariaDB_White_Paper_-_08_26_13_001.pdf

MariaDB es un sistema gestor de base de datos, el cual es gratuito y es muy similar al MySQL por no decir que es un clon, “Se extiende el Sistema Gestor de Bases de Datos MariaDB para especificar y almacenar atributos Tipo 3, y procesar consultas que involucren estos atributos. Particularmente, se implementa el ordenamiento (ORDER BY) y agrupamiento (GROUP BY) basado en relaciones difusas” (Trepat, y otros, 2014, p.2). Este sistema gestor es uno de las más utilizados para almacenar la base de datos en la nube, la mayoría de hosting en especial los más reconocidos, trabajan con PHP y MySQL o MariaDB.

3.1.2.3.2. PostgreSQL

Figura 10. Logo PostgreSQL Fuente: Castellanos, L. (11 de 2013). DTyOC De Tecnología y Otras Cosas. Obtenido de https://dtyoc.com/category/ano-01/dbms/

Es un sistema gestor de base de datos SGBD, apoyado en Open Source. En la investigación realizada por: Báez (2013) especifica los beneficios de Open Source; “Esto quiere decir que el código fuente del programa está disponible a cualquier persona libre de cargos directos, permitiendo a cualquiera colaborar con el desarrollo del proyecto o modificar el sistema para ajustarlo a sus necesidades”.(p.25) PostgreSQL, es un sistema gestor muy usado gracias a que es gratuito y sus últimas versiones son muy completas, por lo que tiene todo lo que tienen otros sistemas gestores.

3.1.2.3.3. Oracle

Figura 11. Logo Oracle Fuente: Castellanos, L. (11 de 2013). DTyOC De Tecnología y Otras Cosas. Obtenido de https://dtyoc.com/category/ano-01/dbms/

En la investigación realizada por: Sigüenza (2015) presenta características objetorelacionales, que son parte del modelo evolutivo, en la que puede destacar las siguientes características fundamentales: 

Gestión de grandes base de datos.



Usuarios recurrentes.



Alto rendimiento en transacciones.



Sistema de alta disponibilidad.



Gestión de la seguridad.



Compatibilidad.



Contestabilidad.

Los sistemas gestores de base de datos se destacan unos de otros por alguna particularidad en especial, el SGBD Oracle no es la excepción por lo que Sigüenza (2015) en su investigación de Postgrado destaca a las siguientes ventajas que se tiene al usar Oracle:  Oracle es el motor de base de datos relacional más utilizado en todo el mundo.  Es multiplataforma (puede ejecutarse en todas las plataformas).  Proporciona el uso de particiones para una mejor eficiencia de replicación.  El software del servidor puede ejecutarse en casi todos los sistemas operativos.  La base de datos de Oracle, tiene más orientación hacia Internet (http).

3.1.3. Ingeniería de Software Según Somerville (2011), la Ingeniería de Software es una rama de la ingeniería que se interesa en todo lo que tenga que ver con el desarrollo de software, sea desde la etapa inicial en el planteamiento de los requerimientos del sistema hasta su última etapa la de mantenimiento del mismo cuando ya está operando. 3.1.3.1. Especificación de requerimientos de software (SRS) Para el diseño de un software se necesita en su etapa inicial de la elaboración de un documento donde se plasmen los requerimientos del software que se tienen que cumplir a lo largo de su desarrollo, a este documento se lo llama SRS, realizamos esto con el fin de garantizar que se cumpla con todas las tareas que requiere el sistema, y que al final del trabajo no se cambie lo planteado inicialmente, este documento será revisado por las partes participantes y firmado por ellas en su aceptación. (Pedraza, R., Blanco, S., Codina, L., & Cavaller, V. 2013). 3.1.3.1.1. Requerimientos funcionales y no funcionales En la investigación sustentada por: Somerville (2011), afirma que en la ingeniería de requerimientos se encarga de clasificar los requerimientos de un sistema en: funcionales y no funcionales (p.84). 

Requerimientos funcionales: Somerville (2011), en su investigación detalla a estos requerimientos como las entradas, procesos y salidas que un sistema debe hacer; en pocas palabras todas las funcionalidades dependiendo de cada sistema en particular y los requerimientos del usuario, partiendo de lo general hasta lo más específico, los requerimientos funcionales se clasifican en: requerimientos del usuario y en requerimientos del sistema. (pp.84-85)

Los requerimientos funcionales del sistema según Somerville (2011), se enfoca a la parte de las funciones que debe contener el sistema, partiendo de los requerimientos generales hasta los más específicos. Por otra parte están los requerimientos funcionales del usuario, los cuales se basan en lo que el usuario o cliente desea ¿cómo lo desea?, ¿en qué tiempo lo desea?, ¿las funciones que desea?,. Luego te obtener los requerimientos funcionales de usuarios que se lo hace por medio del levantamiento de información, se procede a construir los requerimientos del sistema. (pp.85-86)

Figura 12. Lectores de diferentes tipos de especificaciones de requerimientos. Fuente: Sommerville, I. (2011). Ingeniería de software. México D.F: PERSON EDUCACIÓN.



Requerimientos no funcionales: En la definición de Sommerville (2011), se afirma: que estos requerimientos ayudan a satisfacer los requerimientos funcionales; además proporcionan cierto grado de confiabilidad del producto final; los requerimientos no funcionales pueden estar dados por: requerimientos del producto de la organización y externos. Los requerimientos del producto son aquellos como confiabilidad, calidad, eficiencia, integridad, etc. Los requerimientos de la organización valga la redundancia son dados por la empresa. Los externos se generan desde la parte de requerimientos éticos hasta los legales. (pp.85-88)

Figura 13. Tipos de requerimientos no funcionales Fuente: Sommerville, I. (2011). Ingeniería de software. México D.F: PERSON EDUCACIÓN

3.1.3.2. Modelos Prescriptivos Los modelos prescriptivos o modelos de procesos de software son la representación del software en sí, estos ofrecen la mejor manera de trabajar en el desarrollo de un software siguiendo un proceso sistemático ya establecido en el. (Gómez, Marín, & Díaz, 2014) 3.1.3.1.1. Cascada Este modelo es uno de los más utilizados actualmente, éste recoge los procesos fundamentales del trabajo y los ordena en secuencia donde cada un posee sus objetivos. En este método la línea de trabajo es consecuente, por lo tanto una fase no puede empezarse a trabajar mientras su anterior no se haya finalizado y durante el proceso cada fase complementa a la que le sigue, tomemos en cuenta que también cada fase genera su documentación. (Somerville, 2011, pp.32-33)

Figura 14. Etapas del modelo cascada Fuente: Sommerville, I., & Galipienso, M. I. A. (2011). Ingeniería del software. Pearson Educación.

3.1.3.1.2. Incremental En este método el desarrollador trabaja en conjunto con el usuario final en el desarrollo de incrementos que dan pie al sistema final, el usuario verifica que los requerimientos se cumplan y si surgen más volverá a las etapas anteriores y juntos encontraran una solución y así sucesivamente en cada etapa hasta llegar a la versión final. Este método es recomendable para sistemas grandes donde se necesitan algunas reuniones con los usuarios finales, caso que en sistemas pequeños no es conveniente por los costos extras que se generaran. (Somerville, 2011, pp. 32-33)

Figura 15. Etapas del modelo incremental Fuente: Sommerville, I., & Galipienso, M. I. A. (2011). Ingeniería del software. Pearson Educación.

3.1.3.1.3. Evolutivo Este modelo se basa en que el desarrollo del sistema evoluciona conforme se vaya avanzando, y que en este proceso es común que los requerimientos cambien. Este modelo trabaja con la elaboración de prototipos, los cuales son versiones rápidas del software final, en muchos casos no abarcan todos los requerimientos del usuario ya que se piensa son hechos al apuro. Aunque cada vez el prototipo inicial se hace más fuerte ya que se le van añadiendo las funcionalidades que necesite o corrigiendo los errores. (Pressman, pp.37-38)

Figura 16. Etapas del modelo evolutivo Fuente: Sommerville, I., & Galipienso, M. I. A. (2011). Ingeniería del software. Pearson Educación.

3.1.3.1.4. Concurrente El modelo concurrente es recomendado para trabajar en proyectos en los que para su realización se necesita la participación de algunos equipos de trabajo, cada equipo puede trabajar en una etapa de manera simultánea al resto y no afectara al producto final ya que todos tienen el mismo objetivo final. (Pressman, 2010, pp. 41-42)

Figura 17. Etapas del modelo concurrente Fuente: Sommerville, I., & Galipienso, M. I. A. (2011). Ingeniería del software. Pearson Educación.

3.1.3.3. Desarrollo Ágil En la actualidad las empresas laboran en un entorno global y cambiente por lo tanto nosotros tenemos que adaptarnos a esto de la mejor manera, evolucionando también nosotros y con ello a nuestros productos. El software también juega una parte importante en el cambio por lo que se necesita modelos más agiles de desarrollo de software que permitan en el menor tiempo posible y con menos costo generar un software de calidad. (Somerville, 2011, p. 57)

3.1.3.2.1. Programación Extrema (XP) La programación extrema como su nombre lo dice lleva las actividades al extremo de su desarrollo, forma parte del desarrollo ágil porque trata de que todo se de en un determinado tiempo y con las debidas pruebas satisfactorias. Al hablar de programación extrema mencionamos también sobre la participación que tienen en el desarrollo los clientes, las pruebas que se realicen del software, la refactorización, y el código. (Gómez, A. R., Duarte, A. Q., & Guevara, C. D. M. 2014, p. 25)

Figura 18. Etapas del modelo XP Fuente: Pressman, R. (2010). Ingeniería del software. México D.F: McGraw-Hill.

3.1.3.2.2. Scrum El modelo Scrum se lo utiliza cuando el entorno es un poco complejo, para ello se realiza un trabajo colaborativo o en equipo, existen algunas etapas dentro de esta metodología, empezando por la planeación que es donde se establecen todos los requerimientos del software, luego vendrán las reuniones sprint, las cuales se dan con los clientes y el equipo de trabajo para mostrar los avances y nuevos requerimientos si existieran y finalmente tiene la etapa de cierre donde se presenta el software con la debida documentación. (Somerville, 2011. pp, 72-73)

Figura 19. Etapas del modelo Scrum Fuente: Pressman, R. (2010). Ingeniería del software. México D.F: McGraw-Hill.

3.1.4. Institución pública Una institución pública es un organismo que cumple con una función de interés público, benéfico sin fines de lucro. (R.A.E, 2014) 3.1.4.1. Administración Pública Según Debbasch citado por Sánchez, J. J. (2015), define a la administración pública como la que gestiona los asuntos públicos y es la encargada de que se cumplan los objetivos

propuestos por el estado, de esta depende que las instituciones públicas mantengan un equilibrio en la sociedad que se desenvuelvan. 3.1.4.3.1. Gestión administrativa Según José de Jaime Eslava (2013), la gestión administrativa es el factor de suma importancia; del cual depende que la institución brinde servicios eficaces y de calidad. Y la evolución de la tecnología permite llevar a cabo de una mejor manera todo ese proceso. 3.1.4.3.1.1. Control de Gestión Deportiva El control de gestión o la administración está presente en todas las actividades que realizamos, nuestra vida se basa en organizaciones entre ellas están las deportivas las cuales colaboran con las personas a que mantengan una buena práctica física. Estas tienen también su control interno que va desde las federaciones, las ligas y finalmente los clubes y dentro de todos estos existe una administración y alguien que la ejecuta. (Sancho, J. A. M., & Sánchez, E. G. 1997). 3.1.4.3.1.2. Desarrollo de una aplicación web que permita controlar la gestión deportiva El desarrollo de aplicaciones web hoy en día se está incrementando de manera sustancial, debido al crecimiento de necesidades por parte de empresas e instituciones; tanto en el ámbito económico y social. Las aplicaciones web ayudan a satisfacer las necesidades de problemas que surgen casi a diario. (Domínguez, 2016, p.9) Según Domínguez (2016), en el desarrollo de una aplicación web para la gestión de clubs deportivos y red social para sus miembros (Back-End), describe las características que describen el control de contabilidad del club, creación y seguimiento de estadísticas tanto a nivel individual (jugador) como grupal (equipo). La aplicación desarrollada por Domínguez se llama Yulava, la cual consta de los siguientes roles:  Administrador: Tiene control total sobre el club.  Entrenador: Tiene control total sobre el equipo que entrena.  Jugador: Puede ser asignado a uno o varios equipos. El jugador posee un perfil con sus datos en los que aparecen estadísticas personales.  Padre/Madre: Puede ser asignado a uno o varios equipos con la finalidad de estar informado de las últimas novedades del equipo al que ha sido asignado.

3.1.4.3.1.3. Reglamento de la administración de la FEDELIGAS-SDT La Federación Deportiva Provincial de las Ligas Barriales y Parroquiales de Santo Domingo, consta de un reglamento que está dado por estatutos, entre los cuales se pueden destacar los siguientes: 

El artículo.1 de los estatutos de FEDELIGAS-SDT (2012) dice que: “la federación provincial de ligas barriales y parroquiales de Santo Domingo es una institución deportiva de derecho privado, con fines sociales, sin fines de lucro y que goza de autonomía administrativa, técnica y económico”.



“El objetivo principal de la misma es la recreación de todos los miembros de la comunidad a través de la práctica del deporte recreativo y las actividades físicas lúdicas, debiendo ser estas equitativas e incluyentes”. (Estatutos de FEDELIGASSDT, 2012, Art.6)



Según el Art.7 de los estatutos de FEDELIGAS- SDT (2012), la institución tiene las siguientes atribuciones dentro de la provincia: a. Motivar la organización y participación de las y los ciudadanos de los barrios y parroquias, urbanas y rurales, a fin de lograr su formación integral y mejorar su calidad de vida; b. Masificar el deporte y la recreación de sus asociados y la comunidad en general; c. Representar al deporte barrial y parroquial de Santo Domingo de Tsachilas ante los poderes públicos y organismos deportivos nacionales; d. Organizar en forma oficial las actividades físicas recreativas a nivel provincial y conformar las selecciones respectivas; e. Reglamentar el fichaje de todos los deportistas que actúan en cada una de sus filiales; f. Mantener vinculación con las entidades deportivas barriales de la provincia o el país; g. Conceder permiso a sus instituciones afiliadas para actividades recreativas dentro de la provincia y el país o a nivel internacional; h. Capacitar en aspectos técnicos, de organización, administración, legal, etc; i. La federación provincial de ligas barriales y parroquiales consagra su autonomía administrativa, económica y deportiva de sus filiales y sus conflictos se resolverán

respetando las instancias establecidas en la ley de deporte, educación física y recreación y su reglamento respectivo; j. Impulsar convenciones del deporte barrial, para analizar sus aspectos trascendentales y proponer soluciones pertinentes; 

“La vida administrativa de FEDELIGAS-SDT, está dirigida, reglamentada por la asamblea general, por el directorio, directorio ampliado, comisiones permanentes nombradas por el directorio, de conformidad con este estatuto y reglamento interno respectivo”. (Estatutos de FEDELIGAS-SDT, 2012, Art.14)



Según el Art.22 de los estatutos de FEDELIGAS- SDT (2012), afirma que: “dentro de la institución el directorio es el organismo ejecutor de las actividades de la institución y estará integrado por: Presidente, Vicepresidente, tres Vocales Principales y tres Vocales Suplentes”.

4. METODOLOGÍA DE INVESTIGACIÓN Este capítulo se encuentra estructurado por los mé todos que se utilizan en la investigación como son: Diseño/ Tipo de investigación, Población/ Universo, Muestra, Técnicas/ Instrumentos de recogida de datos, Técnicas de análisis de datos y Metodología del desarrollo del software. Esta investigación está bajo el enfoque mixto.

4.1.Diseño / Tipo de investigación 4.1.1. Diseño de la investigación 4.1.1.1. Diseño experimental El diseño experimental tiene al menos dos significados, uno general y el otro particular. El general habla acerca de elección o realización de una acción. Y la acepción particular se refiere a la manipulación intencional de una o más variables independientes, con el fin de analizar las consecuencias sobre una o más variables dependientes. Los diseños experimentales se usan cuando el investigador desea definir el posible efecto de una causa que se manipule. (Hernández Sampieri, Férnandéz, & Baptista, 2014, pp.129-130) El diseño experimental permite cuantificar las causas del efecto de un estudio experimental; además prescribe una serie de pautas relativas en las que dá a conocer qué variables hay que manipular, de qué forma y en qué orden para así poder establecer cierto grado de confianza. (Hernández Sampieri, Férnandéz, & Baptista, 2014, pp.129-130) 4.1.2. Tipos de la Investigación 4.1.3.1. Investigación Aplicada: Descriptiva La investigación descriptiva se encarga de señalar características del fenómeno objeto de estudio; además lo más relevante de esta investigación es que muestra de forma detallada las partes, categorías o clase de objeto del mismo. Este tipo de investigación es uno de los más populares y básicos en la gran mayoría de investigaciones, esta se guía de las preguntas formuladas por el investigador o investigadores, cuando se establecen hipótesis; prueba esas hipótesis. Se soporta en técnicas como la encuesta, la entrevista, la observación y la revisión documental. (Bernal, 2010, p.113)

La investigación descriptiva permite identificar las características que se desarrollan en el problema de investigación de forma muy detallada, por lo que se realiza el análisis para interpretar las características al problema de investigación y así formular el cuestionario para las encuestas y la guía de entrevista para la entrevista. Y además tendrá un análisis exhaustivo de las funcionalidades de la aplicación web, el cuál se llevará a cabo por medio de las historias de usuarios. 4.1.3.2. Investigación bibliográfica Esta investigación se enfoca a la revisión de información existente en el marco referencial. En el desarrollo de la aplicación web para la Federación Provincial de ligas barriales y parroquiales de Santo Domingo; se analizará de manera profunda la problemática, con la finalidad de seleccionar las herramientas adecuadas para la elaboración del software y se elegir la metodología de desarrollo de software adecuada con respecto a la problemática.

4.2.Población / Universo 4.2.1. Población La población es el total de personas que existen o están relacionadas con el objeto de estudio. En esta investigación se tomará en cuenta al personal de la Federación Provincial que vaya a interactuar directamente con el sistema; como es el presidente de la liga barrial, administradora y jugadores de la FEDELIGAS-SDT, que son: aproximadamente 11.350 jugadores, entonces el universo es finito por que se conoce la población objeto de estudio. (FEDELIGAS-SDT, 2012) 4.3. Muestra En esta investigación se obtendrán dos tipos de muestra, la primera se tomarán a 2 personas; la secretaria y el presidente de la FEDELIGAS_SDT. Y la segunda muestra está enfocada a los jugadores se aplicará la fórmula que se refleja en la figura. 20 debido a que esta población es muy numerosa, lo que dificulta la recogida de datos; en el cálculo de esta muestra arroja un total de 372 jugadores.

Z2 N PQ n= (N-1)E2 + Z2 PQ Figura 20. Formula del muestreo Fuente: Martínez, C. (2012). Estadística y muestreo. Bogotá: Ecoe.

En la investigación realizada por: Martínez (2012), desgloza cada una de las variables presentadas en la fórmula con su respectivo significado.  n = tamaño de la muestra  N= tamaño de la población  E= error aceptable que varía entre 1% (0,01) y 9% (0,09)  Z= Valor obtenido mediante el nivel de confianza, si no se lo tiene, es un valor constante del 95% de confianza que equivale a 1,96 o el 99% que equivale a 2,58.  PQ= es la varianza () representa el grado de variabilidad que tiene las unidades de la población,  = PQ. P = Q, se tiene la costumbre de tomar P= 0,50.

4.4. Técnicas/ Instrumentos de recogidas de datos 4.4.1. Técnicas de recogida de datos El enfoque cuantitativo en la recolección de datos, hace uso de las encuestas como técnicas de recogida de datos. En la recolección de datos en el enfoque cualitativo utiliza las entrevistas como técnicas de recogida de datos.  Encuesta: En el proyecto de investigación se aplicará las encuestas a la muestra obtenida; la cual se llevará a cabo a los jugadores de la FEDELIGAS-SDT  Entrevista: Se realizarán a la secretaria del área administrativa y al presidente de la institución.

4.4.2. Instrumentos de recogida de datos Los instrumentos para la recogida de datos van de la mano con las técnicas que se utilicen en la recolección de datos; en la presente investigación en la encuesta se utilizará como instrumento el cuestionario y para las entrevistas se utilizará una guía de entrevista.

 Cuestionario: Se utilizará para la recogida de datos, el cual estará constituido por un banco de preguntas las cuáles serán cerradas. El fin es recolectar suficientes datos, para determinar la factibilidad de la implementación de una aplicación web, que permita el control de las gestiones deportivas, los cuales serán cuantificables en los resultados.  Guía de entrevista: Se realizará una guía de entrevista, la cual servirá como soporte para la entrevista que se le realizará a las 2 personas ya antes mencionada.

4.5. Técnicas de análisis de datos Las técnicas de análisis de datos es la forma en que se analiza los datos obtenidos en: entrevistas (guía de entrevistas), encuestas (cuestionarios), observaciones (bitácoras), entre otros. 4.5.1. Análisis estadístico Aquí se hará uso de la tabulación de datos obtenidos en la encuesta realizada a los jugadores de la FEDELIGAS-SDT. Luego se realizará el análisis global de los resultados obtenidos por cada pregunta establecida en el cuestionario. 4.5.2. Análisis cualitativo La técnica de análisis de datos que se empleará aquí será: el análisis exhaustivo de la información obtenida de las entrevistas realizadas al presidente y secretaria, pertenecientes a la FEDELIGAS-SDT 4.5.3. Metodología de desarrollo de software La importancia de seguir un modelo para el desarrollo de la aplicación web, es que ayuda al disertante o disertantes a seguir con pasos ordenados (etapas), para obtener el resultado esperado. Además se hará uso de una metodología ágil porque se caracteriza por ser rígida y se centra en el control del proceso. Para el desarrollo del sistema se ha optado por el camino de las metodologías ágiles debido a que se adapta a los requerimientos de la empresa, y nuestra disponibilidad; para esta elección se ha hecho un análisis de la tabla 1 (Comparativa entre metodologías tradicionales y ágiles).

32 Tabla 1: Comparativa entre Metodologías Tradicionales y ágiles Aspecto

Metodologías Prescriptivas

Tradicionales

Requisitos

-Requieren los requisitos detallados desde el inicio del proyecto.

Metodologías Ágiles

-Los requisitos son muy cambiantes. -La verdad es que en software los requisitos cambian continuamente, y se requiere de un feedback sobre un resultado obtenido para determinar si es lo requerido o no.

-Los requisitos no pueden cambiar

Cambios

-Hacer un cambio al alcance requiere de un proceso formal de control de cambios

-El cambio es bienvenido momento del proyecto

cualquier

Tiempo

-Existe un compromiso respecto al tiempo de entrega del proyecto

-Existe incertidumbre respecto al tiempo de entrega de todo el producto.

-(no siempre se cumple esta meta)

-Lo cierto es que máximo cada 2 meses (máximo un mes en scrum) hay entrega de producto de valor para el cliente

Documentación

-Atención exhaustiva documentación.

-Solo se genera la documentación que genera valor al cliente y al proyecto

Elaboración entregables

-Se generan entregables requieren mucho tiempo elaboración.

que de

-Se centran en hacer entregables en tiempos cortos con alta calidad inmersa

Fuente: Abad, J. H. (14 de Julio de 2014). Lecciones Aprendidas en Desarrollo de Software. Recuperado el 13 de Junio de 2014, de lecciones-aprendidas.info: http://www.lecciones-aprendidas.info/2014/07/tablacomparativa-entre-metodologias.html

4.6.1. Programación Extrema (XP) Se escogió esta metodología, en relación con la problemática expuesta en el capítulo 2. Esta metodología tiene ciertas características entre las más destacadas se presentan las siguientes: ¿es más importante que el software funcione? y la colaboración con el cliente. El modelo XP permite la programación en pareja, simplicidad de código, corrección de errores antes de incorporar nueva funcionalidad. Además se realizó un análisis entre la metodología Xp y Scrum, tomando como referencia la tabla 2 y 3.

33 Tabla 2: Grado de agilidad en XP y Scrum Valores ágiles Individuos e interacciones sobre Procesos y herramientas

Software de trabajo documentación completa

sobre

Colaboración de los clientes negociación de contrato Respondiendo al cambio siguiendo un plan

Mantener el proceso ágil

XP 1. El juego de planificación 2. La propiedad colectiva 3. Cliente en el sitio 4. Programación en pareja 1. Lanzamientos breves 2. Pruebas. 3. Integración continua 1. El juego de planificación 2. Cliente en el sitio 1. Metáfora 2. Diseño simple 3. Refactorización 4. Normas de codificación -

Scrum 1. Equipos Scrum. 2. Reunión de planificación de Sprint. 3. Reunión de Scrum diario 1. Sprint 2. Revisión de Sprint 1. Cartera de productos 2. Reunión de planificación de Sprint. 1. Revisión de Sprint 2. Reunión de planificación de Sprint.

1. Revisión de Sprint 2. Reunión diaria del scrum. Fuente: Qumer, A., & Henderson-Sellers, B. (2006). COMPARATIVE EVALUATION OF XP AND SCRUM USING THE 4D ANALYTICAL TOOL (4-DAT). In Proceedings of the European and Mediterranean conference on information systems, 1-8. Tabla 3: Proceso de software en XP y Scrum Proceso de software XP Proceso de desarrollo 1. Lanzamientos breves 2. Metáfora 3. Diseño simple 4.Testing 5.Refactorización 6. Programación en pareja 7. Propiedad colectiva Integración 8.Continuous 9. Cliente en el sitio 10. Norma de codificación Proceso de Gestión de Proyectos 1. El juego de planificación

Scrum 1. Equipos Scrum 2. Cartera de productos 3. Sprint 4. Revisión de Sprint

1. Maestro Scrum 2. Reunión de planificación de Sprint 3.Reunión de scrum diario Fuente: Qumer, A., & Henderson-Sellers, B. (2006). COMPARATIVE EVALUATION OF XP AND SCRUM USING THE 4D ANALYTICAL TOOL (4-DAT). In Proceedings of the European and Mediterranean conference on information systems, 1-8.

4.6.1.1. Etapas del modelo La programación Extrema consta con cuatro fases o etapas que son: Planeación o planificación, diseño, codificación y pruebas. (Pressman, 2010, p.62)  Planeación: Se planifica plasmar los requerimientos de usuarios en las historias de usuarios, también nos permite trabajar en equipo por su programación en pareja y nos da la apertura de reunirnos diariamente, para exponer los avances realizados y los inconvenientes que se generan.

 Diseño: En esta etapa se realiza el diseño simple; el cual permite un diseño sencillo, claro y entendible por el usuario final. La inserción de comentarios en las clases, métodos, para una mejor comprensión del diseño y así poder reutilizar el código.  Codificación: Se optimizará el código para evitar códigos basuras.  Pruebas: Se realizará las pruebas pertinentes del software, para aprobación del cliente y poder lanzar el software al mercado.

la obtener la

5. RESULTADOS Discusión y Análisis de los resultados

5.1.

5.1.1. Entrevista dirigida al presidente y secretaria de la FEDELIGAS-SDT 

¿Qué procesos se realizan dentro de la entidad?  En la institución se realizan los siguientes procesos: Ingreso de ligas, ingreso de clubes y sus respectivos jugadores, además de mantener un historial de actuaciones de cada uno de ellos como los pases o transferencias de equipo a equipo y controlan que jugadores están activos y cuales no; debido al historial de actuaciones, pases.



¿Cómo se llevan a cabo esos procesos?  En la entrevista realizada al presidente y secretaria, ambos coincidieron con su respuesta, la cual describe: “que actualmente todos están registrados en documentos de Excel y Word y los demás procesos se llevan de forma semi digital, los mencionados anteriormente son digitales y los carnet una parte digital y la otra manual”.



¿Quién está encargado de llevar a cabo los procesos?  La persona a cargo de esto es la secretaria general bajo la supervisión del presidente; sin embargo se tiene la visión de contratar a una persona capacitada para que se encargue de todos estos procesos; siempre y cuando se llegue a contar con un software a la medida.



¿Existe algún tipo de control en los procesos?  Cada actividad realizada esta bajo la supervisión del presidente y de la comisión técnica, la cual es formada por los representantes de cada liga; por tal razón el presidente deberá tener acceso al sistema, para supervisar los procesos que se realicen.



¿Piensa que es necesario automatizar los procesos que realizan?  Ambos concordaron en sus respuestas, otorgando una respuesta afirmativa, en el análisis de esta pregunta la automatización de los procesos ayudará a reducir ciertos factores como: el tiempo y recursos económicos.



¿Qué cree que necesita la institución para llevar a cabo de mejor manera los procesos institucionales?  En la actualidad vivimos en un mundo evolucionista, en que el factor ‘Tecnología’, es uno de los factores más trascendentales en la vida del ser humano, es aquel que ayuda a facilitar las labores que realiza el hombre, por lo tal la FEDELIGAS debe estar a la par con el mundo actual. En este caso la solución es una aplicación web la cuál agilitará los procesos realizados manualmente.



¿Están dispuestos a migrar a algún tipo de tecnología para la mejora de la institución y su gestión?  Si está dispuesta la institución a migrar a una tecnología que les ayude agilitar los procesos; esta tecnología se llama “Aplicación web”. La cual les será de gran ayuda, además reducirán mayor tiempo y recursos económicos, tanto la empresa como sus conformantes.

5.1.2. Encuesta dirigida a los jugadores de la FEDELIGAS-SDT Pregunta 1 ¿Qué tiempo ha tenido que esperar para ser atendido en la FEDELIGAS-SDT? Tabla 4: Tiempo de espera de atención en la FEDELIGAS-SDT ALTERNATIVA FRECUENCIA

PORCENTAJE

Al instante

1,08%

Intervalo de 2-5 minutos

22,04%

Superior a 5 minutos

286

76,88%

TOTAL

372

100%

Fuente: Los autores

¿Qué tiempo ha tenido que esperar para ser atendido en la FEDELIGAS-SDT?

80 70 60 50 76,88

40 30 20 22,04 10 1,08 0 Al instante

Intervalo de 2-5 minutos

Superior a 5 minutos

Figura 21. Tiempo de espera de atención en la FEDELIGAS-SDT Fuente: Los autores

Análisis: En los resultados obtenidos en la primera pregunta se puede ver a simple vista que el 76,88% de los encuestados para ser atendidos en la FEDELIGAS-SDT han tenido que esperar más de 5 minutos. El 22,04% ha tenido que esperar un lapso de tiempo de 2 a 5 minutos; y el 1,08% ha sido atendido al instante.

Pregunta 2 ¿Ha tenido inconvenientes para obtener información de actividades deportivas en la FEDELIGAS-SDT? Tabla 5: Inconvenientes en la obtencion de infomacion en la FEDELIGAS-SDT ALTERNATIVA FRECUENCIA

PORCENTAJE

24,19%

75,81%

TOTAL

372

100%

Fuente: Los autores

¿Ha tenido inconvenientes para obtener información de actividades deportivas en la FEDELIGAS-SDT?

80 70 60 50 75,81

40 30 20

24,19

10 0 Si

Figura 22. Inconvenientes en la obtencion de infomacion en la FEDELIGAS-SDT Fuente: Los autores

Análisis: Los resultados obtenidos en esta pregunta, arrojan que el 75,81% de los encuestados no han tenido ningún inconveniente para obtener información de las actividades deportivas que se llevan a cabo en la FEDELIGAS-SDT. Mientras que el 24,19% si han tenido inconveniente para obtener información.

Pregunta 3 ¿Se le ha dificultado trasladarse a la institución para obtener información? Tabla 6: Dificultad al trasladarse por informacion a la FEDELIGAS-SDT ALTERNATIVA FRECUENCIA

PORCENTAJE

220

59,14%

152

40,86%

TOTAL

372

100%

Fuente: Los autores

¿Se le ha dificultado trasladarse a la institución para obtener información?

60 50 40 59,14 30 40,86

20 10 0 Si

Figura 23. Dificultad al trasladarse por informacion a la FEDELIGAS-SDT Fuente: Los autores

Análisis: Los resultados obtenidos de la encuesta, muestran en esta pregunta que el 59,14% de los encuestados se les ha dificultado trasladarse a la institución para obtener información; por otra parte el 40,86% no se les han dificultado, debido a que estos deportistas viven cerca de la institución.

Pregunta 4 ¿Cuáles son los motivos que le dificultan, para trasladarse a la FEDELIGAS? Tabla 7: Motivos que dificultan el traslado hacia la FEDELIGAS-SDT ALTERNATIVA FRECUENCIA Vive fuera de provincia

PORCENTAJE

0,42%

Vive en una zona muy retirada a la FEDELIGAS-SDT

165

68,75%

No cuenta con el suficiente tiempo para hacerlo

30,83

TOTAL

240

100%

Fuente: Los autores

¿Cuáles son los motivos que le dificultan, para trasladarse a la FEDELIGAS?

70 60 50

68,75

30 30,83

20 10

0,42

Vive fuera de provincia

Vive en una zona muy retirada a la FEDELIGAS-SDT

No cuenta con el suficiente tiempo para hacerlo

Figura 24. Motivos que dificultan el traslado hacia la FEDELIGAS-SDT Fuente: Los autores

Análisis: En los resultados adquiridos de las encuestan reflejan en la Figura 24 que el 68,75% tienen inconvenientes en trasladarse a la institución, debido a que viven en zonas muy retiradas, donde en la mayoría de casos gastan mucho tiempo en trasladarse y cuentan con uno a tres trasportes por día. El 30,83% no cuentan con el suficiente tiempo para trasladarse a la institución, esto se da porque muchos estudian y trabajan y por último el 0,42% equivalente a un deportista, vive fuera de la provincia, lo cual le dificulta más trasladarse a la FEDELIGAS-SDT.

Pregunta 5 Para obtener información de actividades futuras en la FEDELIGAS-SDT. ¿Cómo le gustaría a usted realizarlo? Tabla 8: Metodos de obtencion de informacion futura ALTERNATIVA

FRECUENCIA

PORCENTAJE

Ir personalmente a la FEDELIGAS-SDT

5.38%

Informarme por medio de una aplicación web

352

94.62%

372

100%

(internet) TOTAL Fuente: Los autores

Para obtener información de actividades futuras en la FEDELIGAS-SDT. ¿Cómo le gustaría a usted realizarlo?

100 80 60

94,62

5,38

0 Ir personalmente a la FEDELIGAS-SDT

Informarme por medio de una aplicación web (internet)

Figura 25. Metodos de obtencion de informacion futura Fuente: Los autores

Análisis: En los resultados adquiridos en las encuestas reflejan en la Figura 25 que el 5,38% tiene inconvenientes con ir personalmente a la FEDELIGAS-SDT por algún tipo de información sobre jugadores, equipos o campeonatos ya que no tienen mucho tiempo disponible. El 94.62% menciono que preferirían obtener la información en internet mediante una aplicación web ya que esto lo pueden realizar a cualquier hora y momento del día simplemente necesitan estar conectados a internet.

Pregunta 6 ¿Considera usted que las aplicaciones web son de utilidad y necesarias para las institución como la FEDELIGAS-SDT? Tabla 9: Utilidad de las aplicaciones web en la FEDELIGAS-SDT ALTERNATIVA FRECUENCIA

PORCENTAJE

359

96.51%

3.49%

TOTAL

372

100%

Fuente: Los autores

¿Considera usted que las aplicaciones web son de utilidad y necesarias para las institución como la FEDELIGAS-SDT?

100 80 60

96,51

40 3,49

20 0 SI

Figura 26. Utilidad de las aplicaciones web en la FEDELIGAS-SDT Fuente: Los autores

Análisis: En los resultados adquiridos en las encuestas reflejan en la Figura 26 que el 96,51% Consideran que las aplicaciones web serían necesarias para una institución como la FEDELIGAS-SDT ya que cuenta con una gran acogida en la comunidad. Un 3.49% no ve la necesidad de una aplicación web en esta institución, ya que lo consideran irrelevante.

Pregunta 7 ¿Considera usted que se debería implementar una aplicación web para la FEDELIGAS-SDT? Tabla 10: Importancia de la implementacion de una aplicacion web en la FEDELIGAS-SDT ALTERNATIVA FRECUENCIA PORCENTAJE SI

360

96.77%

3.23%

TOTAL

372

100%

Fuente: Los autores

¿Considera usted que se debería implementar una aplicación web para la FEDELIGAS-SDT?

100 80 60

96,51

40 3,49

20 0 SI

Figura 27. Importancia de la implementacion de una aplicacion web en la FEDELIGAS-SDT Fuente: Los autores

Análisis: En los resultados adquiridos en las encuestas reflejan en la Figura 27 que el 96,77% Consideran que la implementación de una aplicación web en la FEDELIGAS-SDT debe hacerse debido al análisis de la pregunta anterior. Un 3.23% no ve la necesidad de la implementación de una aplicación web en esta institución, ya que lo consideran irrelevante y esto generaría costos innecesarios.

Pregunta 8 ¿Considera usted que es importante la generación de la ficha del jugador, en la aplicación web? Tabla 11: Importancia de la generacion de fichas del jugador en la web ALTERNATIVA FRECUENCIA Muy importante 300

PORCENTAJE 80.65%

Importante

16,67%

Poco importante

0,27

Sin importancia

2,41

372

100%

TOTAL Fuente: Los autores

¿Considera usted que es importante la generación de la ficha del jugador, en la aplicación web?

90 80 70 60 50 40 30 20 10 0

80,65

16,67 Muy importante

Importante

2,41

0,27 Poco importante

Sin importancia

Figura 28. Importancia de la generacion de fichas del jugador en la web Fuente: Los autores

Análisis: En los resultados adquiridos en las encuestas reflejan en la Figura 27 que el 80,65% Consideran que la generación de las fichas de los jugadores en una aplicación sería una muy buena opción para la optimización de tiempo y recursos ya que si desean consultar algo no es necesario imprimirla sino solo verla. Un 16,67% supo mencionar que sería bueno tener esta opción y así no tener que ir a las oficinas. En cambio un mínimo 0,27% manifestó que no tiene mucha importancia ya que no necesitan obtener la ficha. Finalmente un 2,41% no le dio importancia a la implementación de este proceso del jugador, en la aplicación web. ?

5.2.

Proceso de desarrollo de software usando Programación Extrema (XP)

5.2.1. Etapa 1: Planeación 5.2.1.1. Exploración La fase de exploración, empieza por las entrevistas realizadas a la secretaria y al presidente de la FEDELIGAS-SDT, con el propósito de conocer los procesos en relación a la gestión deportiva. No obstante, para profundizar estos procesos se desarrollaron historias de usuarios, en las cuales se detallan los requerimientos funcionales uno a uno, que servirán para la construcción de la aplicación web. 5.2.1.2. Módulos del Sistema En la tabla 12 se especifican los módulos que contendrá el proyecto, detallando las funciones que cumplirá cada módulo, dichas funciones se especificarán de forma más detallada en el apartado de Historias de Usuario.

46 Tabla 12: Módulos y métodos de la aplicación web N°

Módulos

Módulo del Sistema

Módulo de Administración

III Fuente: Los autores

Historias de Usuario

Módulo de la aplicación Web

Registro de usuario Administración de usuario Registro de ligas Administración de ligas Registro de club Administración de club Registro de deportistas Administración de los deportistas Registro de categorías Administración de carnet Registros de campeonatos Administración de categorías Registro de carnet Administración de campeonatos Registro de Actuaciones Búsqueda de las actuaciones de los deportistas Registro de Pases Reporte de ficha del jugador Parametrización del sistema

5.2.1.3. Historias de Usuario Las historias de usuario están desarrolladas en función de los requerimientos de la institución, las cuales están estimadas por “DIAS IDEALES”.

5.2.1.3.1. Especificación de Historias de Usuarios. Tabla 13: Historia de usuario, Registro de usuario Historia de Usuario Número: 1

Usuario: Administrador

Nombre: Registro de usuarios Prioridad en negocio: Medio Puntos estimados: 30 Descripción:

Riesgo en desarrollo: Medio Iteración Asignada: Primera

Como administrador quiero que el software me permita registrar usuarios al sistema. Además que a ese nuevo usuario se le asigne el rol que va a desempeñar, para que así solo pueda realizar los procesos que la institución le asigne. Criterios de aceptación:  Ingresar los datos de un usuario y verificar que se ejecute dicha acción, además que muestre un mensaje informando que se realizó el ingreso con éxito.  Asignar privilegios al nuevo usuario y verificar que se ejecutó la acción con éxito. Fuente: Los autores

Tabla 14: Historia de usuario, Administración de usuario Historia de Usuario Número: 2

Usuario: Administrador

Nombre: Administración de usuarios Prioridad en negocio: Medio Puntos estimados: 20 Descripción:

Riesgo en desarrollo: Bajo Iteración Asignada: Primera

Como administrador quiero que el sistema me permita realizar cambios o actualizaciones del usuario; excepto el nick y la contraseña, el estado del usuario, y los privilegios a cada usuario. Criterios de aceptación:  Actualizar datos de un usuario y comprobar que indique que la actualización fue exitosa. Además verificar que los campos del Nick y Password no sean editables.  Cambiar el estado del usuario y comprobar que sea éxito el cambio.  Modificar los privilegios asignados a un usuario y verificar que la modificación se realizó con éxito. Fuente: Los autores

Tabla 15: Historia de usuario, Registro de ligas Historia de Usuario Número: 3

Usuario: Administrador

Nombre: Registro de ligas Prioridad en negocio: Medio Puntos estimados: 6 Descripción:

Riesgo en desarrollo: Bajo Iteración Asignada: Primera

Como administrador del sistema quiero ingresar registros de ligas, la cual contenga los siguientes atributos:  Nombre  Fecha de fundación  Color  Campeonato local Criterios de aceptación:  Registrar una liga y verificar que se ejecutó la acción con éxito  Al momento de realizar el registro, dejar un campo vacío, al presionar el botón de ingreso, comprobar que muestre un mensaje informativo, sobre el campo vacío, pidiendo que se complete dicho campo. Fuente: Los autores

48 Tabla 16: Historia de usuario, Administración de ligas Historia de Usuario Número: 4

Usuario: Administrador

Nombre: Administración de ligas Prioridad en negocio: Medio Puntos estimados: 3,5 Descripción:

Riesgo en desarrollo: Bajo Iteración Asignada: Primera

Como administrador quiero realizar cambios en los campos de las ligas y el estado de las ligas, para así poder realizar cualquier actualización que la institución lo amerite. Criterios de aceptación:  Realizar cambios de una liga y comprobar que el cambio se realizó exitosamente. Fuente: Los autores

Tabla 17: Historia de usuario, Registro de club Historia de Usuario Número: 5

Usuario: Administrador

Nombre: Registro de club Prioridad en negocio: Medio Puntos estimados: 4 Descripción:

Riesgo en desarrollo: Bajo Iteración Asignada: Segunda

Como administrador quiero registrar los clubs pertenecientes a la FEDELIGAS-SDT, los cuales tendrán los siguientes campos:  Nombre  Color  Acuerdo ministerial  Fecha de fundación  Liga Criterios de aceptación:  Ingresar un club correctamente y comprobar que se ejecute dicha acción.  Ingresar un club, con un campo vacío, al presionar el botón de ingreso, comprobar que muestre un mensaje informativo, sobre el campo vacío, pidiendo que se complete dicho campo. Fuente: Los autores

Tabla 18: Historia de usuario, Administración de club Historia de Usuario Número: 6

Usuario: Administrador

Nombre: Administración de club Prioridad en negocio: Medio Puntos estimados: 4 Descripción:

Riesgo en desarrollo: Bajo Iteración Asignada: Segunda

Como administrador del sistema quiero realizar cambios en los campos de los clubs y también en su estado. Criterios de aceptación:  Realizar cambios de un club y comprobar que el cambio se realizó exitosamente. Fuente: Los autores

Tabla 19: Historia de usuario, Registro de deportistas Historia de Usuario Número: 7

Usuario: Administrador

Nombre: Registro de deportistas Prioridad en negocio: Medio Puntos estimados: 10 Descripción:

Riesgo en desarrollo: Bajo Iteración Asignada: Segunda

Como administrador quiero ingresar registros de los nuevos deportistas, para lo cual los deportistas deberán tener los siguientes campos:  Cédula  Nombres  Apellidos  Género  Fecha de Nacimiento  Nacionalidad  Teléfono  Provincia  Correo electrónico  Dirección  Ciudad  Club  Es profesional  Una foto, para la portada Criterios de aceptación:  Registrar correctamente a un deportista y verificar que se realizó con éxito el registro.  Comprobar que si falta un campo de llenar, muestre un mensaje que lo especifique.  Ingresar un número incorrecto de cédula y comprobar que la cédula ingresada es inválida. Fuente: Los autores

Tabla 20: Historia de usuario, Administración de los deportistas Historia de Usuario Número: 8

Usuario: Administrador

Nombre: Administración de los deportistas Prioridad en negocio: Medio Riesgo en desarrollo: Bajo Puntos estimados: 4 Iteración Asignada: Segunda Descripción: Como administrador quiero poder hacer cambios en los campos de los deportistas y también en su estado. Criterios de aceptación:  Realizar cambios de un deportista y comprobar que el cambio se realizó exitosamente. Fuente: Los autores

50 Tabla 21: Historia de usuario, Registro de categorías Historia de Usuario Número: 9

Usuario: Administrador

Nombre: Registro de categorías Prioridad en negocio: Medio Puntos estimados: 3 Descripción:

Riesgo en desarrollo: Bajo Iteración Asignada: Tercera

Como administrador quiero ingresar registros de las categorías de deportes; para lo cual la categoría de deportes deberá tener el siguiente campo:  Nombre Criterios de aceptación:  Ingresar registro de una categoría correctamente y comprobar que dicha acción se realizó exitosamente. Fuente: Los autores

Tabla 22: Historia de usuario, Administración de categorías Historia de Usuario Número: 10

Usuario: Administrador

Nombre: Administración de categorías Prioridad en negocio: Medio Puntos estimados: 2 Descripción:

Riesgo en desarrollo: Bajo Iteración Asignada: Tercera

Como administrador del sistema quiero realizar los cambios del campo de categorías y su estado; para satisfacer las necesidades de actualizaciones que presente la institución. Criterios de aceptación:  Realizar cambios de una categoría y comprobar que el cambio se realizó exitosamente. Fuente: Los autores

Tabla 23: Historia de usuario, Registros de campeonatos Historia de Usuario Número: 11

Usuario: Administrador

Nombre: Registros de campeonatos Prioridad en negocio: Alto Puntos estimados: 6 Descripción:

Riesgo en desarrollo: Alto Iteración Asignada: Tercera

Como administrador del sistema quiero ingresar registros de los campeonatos que se llevarán a cabo en la institución; para lo cual los campeonatos tendrán los siguientes atributos:  Nombre  Categoría  Tipo Criterios de aceptación:  Ingresar registro de un campeonato correctamente y comprobar que el registro se ejecutó exitosamente. Fuente: Los autores

51 Tabla 24: Historia de usuario, Administración de campeonatos Historia de Usuario Número: 12

Usuario: Administrador

Nombre: Administración de campeonatos Prioridad en negocio: Alto Puntos estimados: 3 Descripción:

Riesgo en desarrollo: Bajo Iteración Asignada: Cuarta

Como administrador quiero poder realizar cambios de los campos de los campeonatos, el estado. Criterios de aceptación:  Modificar un campo de un campeonato y verificar que se realizó con éxito. Fuente: Los autores

Tabla 25: Historia de usuario, Registro de carnet Historia de Usuario Número: 13

Usuario: Administrador

Nombre: Registro de carnet Prioridad en negocio: Alto Puntos estimados: 50 Descripción:

Riesgo en desarrollo: Alto Iteración Asignada: Cuarta

Como administrador quiero poder realizar registros de carnets, no obstante estos se generan por cada campeonato; los carnets constarán con los siguientes campos:  Campeonato  Color de título  Color de los datos  Imagen de logo  Tipo de fondo (color o imagen)  Fuente de fondo (selecciona el color o elegir la imagen). Criterios de aceptación:  Ingresar datos de forma correcta, de un carnet y verificar que el ingreso sea exitoso  Dejar un campo vacío y comprobar que el ingreso no se realice, arrojando un mensaje especificando que hay un campo sin completar. Fuente: Los autores Tabla 26: Historia de usuario, Administración de carnet Historia de Usuario Número: 14

Usuario: Administrador

Nombre: Administración de carnet Prioridad en negocio: Alto Puntos estimados: 37,5 Descripción:

Riesgo en desarrollo: Medio Iteración Asignada: Cuarta

Como administrador quiero poder realizar cambios en los carnets existente, para satisfacer las necesidades de actualización que presente la institución Criterios de aceptación:  Realizar una actualización en algún campo y comprobar que se realice con éxito dicha acción. Fuente: Los autores

52 Tabla 27: Historia de usuario, Administración de campeonatos Historia de Usuario Número: 15

Usuario: Administrador

Nombre: Registro de actuaciones Prioridad en negocio: Medio Puntos estimados: 37,5 Descripción:

Riesgo en desarrollo: Medio Iteración Asignada: Quinta

Como administrador del sistema quiero registrar actuaciones, las cuales se generan dentro de los campeonatos activos, para lo cual vale recalcar que según el campeonato, siendo estos “local” e ”interligas”, se debe agregar las ligas y clubs que van a estar actuando en el campeonato. Para las actuaciones con campeonatos locales actúan solo los clubs pertenecientes a una sola liga. Y para las actuaciones con campeonatos de interligas; actúan entre ligas. Criterios de aceptación:  Empezar una actuación, de un campeonato activo, de tipo interligas; agregar unas dos ligas que estén registradas, con dos clubs de cada liga y verificar que los clubs se puedan escoger en función de las ligas agregadas.  Empezar una actuación, de un campeonato activo, de tipo local y comprobar que se reflejen solo los clubs de la liga que va a estar actuando. Fuente: Los autores

Tabla 28: Historia de usuario, Búsqueda de las actuaciones de los deportistas Historia de Usuario Número: 16

Usuario: Administrador

Nombre: Búsqueda de las actuaciones de los deportistas Prioridad en negocio: Medio Riesgo en desarrollo: Medio Puntos estimados: 12,5 Iteración Asignada: Quinta Descripción: Como administrador quiero realizar búsquedas de las actuaciones por medio del número de cédula, para conocer si está participando en algún campeonato; además poder imprimir el reporte de las actuaciones. Criterios de aceptación:  Realizar la búsqueda de un deportista e imprimir la actuación del deportista y verificar que se visualice el reporte de la actuación del jugador, para luego ser descargada. Fuente: Los autores

Tabla 29: Historia de usuario, Registro de Pases Historia de Usuario Número: 17

Usuario: Administrador

Nombre: Registro de Pases Prioridad en negocio: Alto Puntos estimados: 50 Descripción:

Riesgo en desarrollo: Alto Iteración Asignada: Quinta

Como administrador quiero registrar los pases de los jugadores, siempre y cuando no estén participando en algún campeonato. El registro de pases debe constar de los siguientes campos:

53  Número de cédula del deportista  Club nuevo  Fecha de incorporación Criterios de aceptación:  Ingresar un pase de un jugador correctamente y comprobar que se realice con éxito.  Ingresar un número de cédula de un jugador que esté activo en un campeonato y verificar que el sistema arroje un mensaje informativo diciendo que “No se pudo cargar el registro porque el deportista no se encuentra disponible”. Fuente: Los autores

Tabla 30: Historia de usuario, Reporte de ficha de jugadores registrados Historia de Usuario Número: 18

Usuario: Administrador

Nombre: Reporte de ficha del jugador Prioridad en negocio: Alto Puntos estimados: 37,5 Descripción:

Riesgo en desarrollo: Medio Iteración Asignada: Sexta

Como deportista o jugador quiero poder imprimir una ficha de jugador que contenga las siguientes variables:  Campeonato que está participando si es el caso  Fecha del campeonato  Categoría en la que está participando  Liga a la que pertenece  Club en el que está registrado.  Y sus datos personales tales como: nombre, cédula, género, fecha de nacimiento y la foto de perfil. Criterios de aceptación:  Colocar un número de cédula correcto y comprobar que se visualice la ficha del jugador.  Colocar un número incorrecto de jugador y verificar que el sistema arroje un mensaje que ese número de cédula no pertenece a los jugadores de la FEDELIGAS-SDT. Fuente: Los autores

Tabla 31: Historia de usuario, Parametrización del sistema Historia de Usuario Número: 19

Usuario: Administrador

Nombre: Parametrización del sistema Prioridad en negocio: Medio

Riesgo en desarrollo: Medio

Puntos estimados: 50

Iteración Asignada: Sexta

Descripción: Como administrador quiero que el sistema me permita la:  Configuración de los datos informativos de la institución.  Configuración de enlace de interés.  Configuración de galería de imágenes.  Configuración de noticias.  Configuración de la portada. Para poder estar al día con los acontecimientos que ocurren en la FEDELIGAS-SDT, tanto en noticias, imágenes y enlaces de interés. Criterios de aceptación:

54 

Ingresar registros de noticias y verificar que se guarden correctamente y se muestren en la página principal.  Modificar los datos de las noticias guardadas y verificar que se ejecuten los cambios realizados.  Registrar un enlace de interés y verificar que ejecuten dicha acción. Fuente: Los autores

5.2.1.3.2. Plan de Iteraciones Tabla 32: Plan de Iteraciones v2.6 Módulos

Historias de Usuario

Registro de usuario Módulo del Sistema

Módulo de Administración

Administración de usuario Registro de ligas Administración de ligas Registro de club Administración de club Registro de deportistas Administración de los deportistas Registro de categorías Administración de categorías Registros de campeonatos Administración de campeonatos Registro de carnet Administración de carnet Registro de Actuaciones Búsqueda de las actuaciones de los deportistas Registro de Pases Reporte de ficha del jugador Parametrización del sistema

Módulo de la aplicación Web Total de tiempo estimado Fuente: Los autores

Iteración Tiempo Estimado Asignada 1 2 3 4 5 6 H D Semanas X 24 5 2 Semanas X 16 5 X X X X X X X X X X X X X X

8 7 8 8 10 8 4 4 8 6 40 30 30 10

3 2 2 2 4 2 3 2 3 2 5 5 5 5

40 30 40

5 5 5

331

1 Semana

2 Semanas

3 Semanas X X X

2 Semanas 14

5.2.1.3.3. Plan de entrega Tabla 33: Plan de entrega v2.6 Módulos

Módulo del Sistema

Módulo de Administración

Módulo de la aplicación Web Fuente: Los autores

Historias de Usuario Registro de usuario Administración de usuario Registro de ligas Administración de ligas Registro de club Administración de club Registro de deportistas Administración de los deportistas Registro de categorías Administración de carnet Registros de campeonatos Administración de categorías Registro de carnet Administración de campeonatos Registro de Actuaciones Búsqueda de las actuaciones de los deportistas Registro de Pases Reporte de ficha del jugador Parametrización del sistema

Tiempo Estimado Semanas 2 Semanas 1 Semana

2 Semanas

Release Asignada 1 X X X X X X X X X X X X

X X X X

3 Semanas

2 Semanas

X X X

5.2.2. Etapa 2: Diseño 5.2.2.1. Tarjetas CRC Tabla 34: Tarjeta CRC.- sistema_model Tarjeta CRC sistema_model Clase: Colaboradores: Vistas -Roles de usuario -Usuarios -Registro de módulos Controlador sistema_controller

N°1 Responsabilidad: -Insertar o modificar Roles de usuario -Insertar o modificar Usuarios -Visualizar el registro de módulos

Fuente: Los autores

Tabla 35: Tarjeta CRC.- Negocio_model Tarjeta CRC Negocio_model Clase: Colaboradores: Vistas -Actuaciones (campeonatos) -Búsqueda de actuaciones (deportistas) -Campeonatos -Carnets -Categorías -Clubs -Deportistas -Ligas -Pases Controlador Negocio_controller

N°2 Responsabilidad: -Insertar o modificar las actuaciones por campeonatos. - Búsqueda de las actuaciones de los deportistas. -Insertar y modificar las actuaciones de los campeonatos. -Insertar y modificar los campeonatos. -Insertar y modificar los carnets. -Insertar y modificar las categorías. -Insertar y modificar los clubes. -Insertar y modificar los deportistas. -Insertar y modificar las ligas. -Insertar y modificar los pases

Fuente: Los autores

Tabla 36: Tarjeta CRC.- Websites_model Tarjeta CRC Websites_model Clase: Colaboradores: Vistas -Configuración -Enlaces de interés -Eventos -Galería de imágenes -Noticias -Portada Controlador Websites_controller Fuente: Los autores

N°3 Responsabilidad: -Insertar y modificar los enlaces de interés. -Insertar y modificar las noticias. -Insertar y modificar los eventos. -Insertar y modificar la galería de imágenes. -Insertar y modificar las imágenes de portada. -Insertar y modificar el tema, nombre, correo de la institución.

5.2.2.2. Diseño de la base de datos El diseño de la base de datos representa la situación real de la Federación Provincial de las Ligas Barriales y Parroquiales de Santo Domingo, la cual tiene limitaciones y restricciones, por ejemplo una tabla con asignación a datos enteros, específicamente será para ingresar enteros, si son datos booleanos de igual manera true o false. Para la construcción de la base de datos se tomó como guía una tabla de deportistas seleccionados de la FEDELIGAS-SDT, la cual se estandarizó para obtener el modelo conceptual (ver anexo 3).Esta base de datos cuenta con sus respectivas entidades, atributos, relaciones y cardinalidades. A continuación se presenta los modelos conceptual, lógico y físico; el lógico parte del modelo conceptual, el físico del modelo lógico.

5.2.2.1.1. DiseĂąo conceptual de la Base de Datos

Figura 29. Modelo conceptual de la FEDELIGAS-SDT Fuente: Los autor

5.2.2.1.2. Diseño lógico de la Base de Datos

Figura 30. Modelo lógico de la FEDELIGAS-SDT Fuente: Los autores

5.2.2.1.3. Diseño físico de la Base de Datos

Figura 31. Modelo fisico de la FEDELIGAS-SDT Fuente: Los autores

5.2.2.3. DiseĂąo de Interfaces de la pĂĄgina web

Figura 32. Interfaz web: Inicio Fuente: Los autores

Figura 33. Interfaz web: Noticias Fuente: Los autores

Figura 34. Interfaz web: GalerĂa Fuente: Los autores

Figura 35. Interfaz web: Login Fuente: Los autores

Figura 36. Interfaz de Consola Administrativa Fuente: Los autores

Figura 37. Reporte de Carnets por Campeonatos en Actuaciones Fuente: Los autores

Figura 38. Reporte de la Ficha del Jugador. Fuente: Los autores

5.2.2.4. Diccionario de Datos Luego de analizar los requerimientos, y construir la base de datos se procede a la obtención del diccionario de datos, el propósito de este es presentar la información que posee la aplicación web de forma lógica. 5.2.3. Etapa 3: Codificación En esta fase se mostrará la codificación de los módulos que tienen mayor peso, en la aplicación web, estos son: módulo de pases, módulo de campeonatos y módulos de carnets (ver en anexo 4). 5.2.3.1. Script de la Base de Datos El script es un archivo que se genera a partir del diseño de la base de datos el cual representa las mismas entidades, atributos y relaciones, sin embargo el script sirve para facilitar la construcción de la base de datos en el sistema gestor, en este caso MySQL, se crea la base de datos luego solo se importa el archivo que contiene el script, no existirá la necesidad de crear las tablas ni los campos de cada una en el sistema gestor.

5.2.4. Etapa 4: Pruebas Tabla 37: Prueba de Aceptación de registro de usuario. Prueba de Aceptación Nombre: Registro de usuario

Prueba n°1

Propósito: Verificar la creación de usuario y la asignación de privilegios Responsabilidad: El registro y asignación de privilegios, solo puede realizarse por el administrador del sistema. Entradas: 1. 2. 3. 4. 5. 6. 7. 8. 9.

El administrador ingresa al módulo de Sistemas, luego entra al usuario. Clip en el botón “Agregar registro”. Ingresar el nombre, Nick, password, rol, email, teléfono, foto y el estado (Activo- Inactivo). Dar clic en el botón Ingresar. Clic en Roles de usuario, en el rol que se asignó al usuario, cliquear en administrar permisos. Clic en agregar módulo. En el campo de módulo, seleccionar el proceso al que se le vaya a dar privilegios, ejemplo Ligas. Luego seleccionar el tipo de permiso que tendrá dicho proceso los cuales son: leer, cambiar de estado, crear, actualizar y eliminar. Dar clip en el botón Ingresar.

Salidas esperadas:  Registro ingresado con éxito. (Registro de usuarios)  Registro ingresado con éxito. (Asignación de privilegios) Evaluación:  El registro del nuevo usuario se encuentra asentado en el módulo de usuarios.  Los privilegios asignados a las Ligas se encuentra asentado en el módulo de permisos, que está situado dentro de Roles de usuario. Fuente: Los autores

Tabla 38: Prueba de Aceptación de administración de usuario. Prueba de Aceptación Nombre: Administración de usuario

Prueba n°2

Propósito: Comprobar que la administración de usuarios, cumpla con los criterios de aceptación y verificar la modificación de privilegios. Responsabilidad: La administración y asignación de privilegios, solo puede realizarse por el administrador del sistema. Entradas: 1. 2. 3. 4.

Ingresar en el módulo del Sistema, clic en usuario. Escoger un usuario y dar clic en el botón del lápiz el cual es de color naranja. El registro del usuario permite modificar los campos de nombre, rol, email, teléfono, foto y estado; excepto los de password y Nick. Modificar el campo del teléfono.

67 5. 6. 7. 8. 9. 10.

Clic en el botón de Actualizar. Clic en el botón del candado, de cualquier usuario. Dentro del módulo de sistema, dar clic en roles de usuario. En el rol que se le asignó al usuario, dar clic en administrar permisos. Luego dar clic en el botón naranja que tiene figurado un lápiz. Modificar los permisos de un módulo el cual solo pueda leer, cambiar estado, crear, actualizar, menos eliminar; por tanto desmarcar la opción de eliminar. 11. Clic en el botón Actualizar. Salidas esperadas:  Transacción completada: ¡Registro actualizado con éxito! (Administración de usuario)  Transacción completada: ¡Estado cambiado con éxito! (Administración del estado de usuario)  Transacción completada: ¡Registro actualizado con éxito! (Administración de privilegios)

Evaluación:  El registro del usuario se encuentra en el módulo de usuario, con su nueva actualización.  El usuario que se le cambio el estado, se encuentra inactivo en el módulo usuario.  En el módulo de permisos se encuentra actualizado los privilegios del módulo en que se operó. Fuente: Los autores

Tabla 39: Prueba de Aceptación de registro de ligas. Prueba de Aceptación Nombre: Registro de ligas

Prueba n°3

Propósito: Verificar que se lleve con éxito el registro de una liga y que no permita guardar el registro si existe algún campo vacío. Responsabilidad: El registro de ligas solo puede realizarse por el administrador del sistema. Entradas: 1. Ingresar al Módulo de los procesos de la FEDELIGAS-SDT que se llama “Módulos”. 2. Clic en el botón de Ligas, luego en el botón de “Agregar registro”. 3. Ingresar datos en los campos de nombre, fecha de fundación, color, campeonato local y estado (Activo-Inactivo), antes del ingreso de los campos dejar uno sin llenar y dar clic en el botón “Ingresar”. 4. Completar el campo que se encuentra vacío y dar clic en el botón “Ingresar”. Salidas esperadas:  Completa este campo. (Campo sin completar de la Liga que se está intentando crear).  Transacción completada: ¡Registro ingresado con éxito! (Registro de ligas) Evaluación:  El registro de la liga que se creó se encuentra en el módulo de “Ligas”. Fuente: Los autores

68 Tabla 40: Prueba de Aceptación de administración de ligas. Prueba de Aceptación Nombre: Administración de ligas

Prueba n°4

Propósito: Comprobar si se llevan con éxito los cambios en una liga Responsabilidad: La administración de ligas solo puede realizarse por el administrador del sistema. Entradas: 1. Entrar al fichero de módulos 2. Dar clic en ligas 3. Se escoge una liga, a la cual se le va actualizar su información, dando clic en el botón de color naranja. 4. Modificar su color o cualquier otro campo. 5. Hacer clic en el botón Actualizar. Salidas esperadas:  Transacción completada: ¡Registro actualizado con éxito! (Administración de ligas) Evaluación:  La administración de la liga se encuentra en el módulo de “Ligas”, con su última actualización. Fuente: Los autores

Tabla 41: Prueba de Aceptación de registro de club. Prueba de Aceptación Nombre: Registro de club

Prueba n°5

Propósito: Comprobar que los registros de club se ingresen con éxito, siempre y cuando estén completos todos los campos. Responsabilidad: El registro de club solo puede realizarse por el administrador del sistema. Entradas: 1. Se ingresa al módulo de los procesos de la FEDELIGAS-SDT (Módulos), se escoge el módulo “Club”. 2. Clic en el botón agregar registros. 3. Completar los campos de: nombre, color, acuerdo ministerial, fecha de fundación, liga e inactivar o dejar el estado activo; en el caso de no completar un campo, el sistema no permite guardar el registro. 4. Clic en el botón Ingresar Salidas esperadas:  Completa este campo (Campo sin completar del Club)  Transacción completada: ¡Registro ingresado con éxito! (Registro de club) Evaluación:  El registro ingresado se encuentra ahora en el módulo “Club” Fuente: Los autores

69 Tabla 42: Prueba de Aceptación de administración de club. Prueba de Aceptación Nombre: Administración de club

Prueba n°6

Propósito: Comprobar que se lleven con éxito los cambios de club. Responsabilidad: La administración de club solo puede realizarse por el administrador del sistema. Entradas: 1. En el registro del nuevo club, dar clic el botón de color naranja. 2. Modificar un dato de cualquier campo. 3. Clic en el botón Actualizar Salidas esperadas:  Transacción completada: ¡Registro actualizado con éxito! (Administración de club) Evaluación:  El registro se encuentra en el módulo de “Club”, con sus datos actualizados. Fuente: Los autores

Tabla 43: Prueba de Aceptación de registro de deportistas. Prueba de Aceptación Nombre: Registro de deportistas Prueba n°7 Propósito: Verificar que el proceso de registro de deportistas se lleve con éxito y comprobar que el número de cédula sea correcto. Responsabilidad: El registro de deportistas solo puede llevarse a cabo, por el administrador del sistema. Entradas: 1. Clic donde dice “Módulos”, escoger “Deportistas” y cliquear. 2. Ingresar al botón de “Agregar registro”. 3. Completar algunos campos de deportistas y dar clic en el botón “Ingresar” 4. En el campo de “Cédula”, ingresar un número de cédula incorrecta y dar clic en el botón del ojo (Verificar cédula) o dar clic en “Ingresar”. 5. Cambiar el número de cédula, por el correcto y clic en el botón “Ingresar”. Salidas esperadas:  Completa este campo (Campo sin completar de Deportistas).  La cédula ingresada es invalida (Cédula errónea).  Transacción completada: ¡Registro ingresado con éxito! (Registro de jugador) Evaluación:  No se ha guardado el registro, porque no están completos todos sus campos.  No se ha guardado el registro, porque la cédula ingresada es incorrecta.  El registro se encuentra guardado en el módulo de deportistas. Fuente: Los autores

70 Tabla 44: Prueba de Aceptación de administración de deportistas. Prueba de Aceptación Nombre: Administración de los deportistas

Prueba n°8

Propósito: Comprobar que los cambios de deportistas, se ejecuten con éxito. Responsabilidad: La administración de deportistas solo puede llevarse a cabo, por el administrador del sistema. Entradas: 1. En el registro creado anteriormente de la prueba n°7, dar clic en botón de color naranja. 2. Actualizar cualquier campo de jugadores. 3. Clic en el botón “Actualizar”. Salidas esperadas:  Transacción completada: ¡Registro actualizado con éxito! (Administración de jugador) Evaluación:  El registro se encuentra en el módulo de deportistas, con sus datos actualizados. Fuente: Los autores

Tabla 45: Prueba de Aceptación de registro de categorías. Prueba de Aceptación Nombre: Registro de categorías

Prueba n°9

Propósito: Comprobar que el ingreso de categorías se lleve con éxito. Responsabilidad: El registro de categorías solo puede ejecutarse, por el administrador del sistema. Entradas: 1. Clic en “Módulos”, escoger la opción de “Categorías”. 2. Dar clic en el botón de “Agregar registro”. 3. Ingresar el nombre de la categoría y clic en el botón “Ingresar”. Salidas esperadas:  Transacción completada: ¡Registro ingresado con éxito! (Registro de categorías) Evaluación:  El registro creado se encuentra guardado en el módulo de “Categorías”. Fuente: Los autores

Tabla 46: Prueba de Aceptación de administración de categorías. Prueba de Aceptación Nombre: Administración de categorías

Prueba n°10

Propósito: Comprobar que los cambios que se realicen en “Categorías”, se ejecuten con éxito. Responsabilidad: La administración de categorías solo puede ejecutarse, por el administrador del sistema. Entradas: 1. El registro creado en la prueba n°9, dar clic en el botón de color naranja, que se encuentra situado a la derecha del mismo registro. 2. Modificar el nombre o el estado. 3. Clic en el botón “Actualizar”.

71 Salidas esperadas:  Transacción completada: ¡Registro actualizado con éxito! (Administración de categorías). Evaluación:  El registro se encuentra en el módulo de categorías, con sus datos actualizados. Fuente: Los autores

Tabla 47: Prueba de Aceptación de registro de campeonatos. Prueba de Aceptación Nombre: Registros de campeonatos

Prueba n°11

Propósito: Comprobar que el registro de campeonato se efectué con éxito. Responsabilidad: El registro de campeonatos solo puede realizarse, por el administrador del sistema. Entradas: 1. Ingresar a “Módulos”, escoger “Campeonatos”. 2. Clic en el botón “Agregar registro”. 3. Ingresar el nombre del campeonato y seleccionar la categoría y el tipo. 4. Clic en el botón “Ingresar”. Salidas esperadas:  Transacción completada: ¡Registro ingresado con éxito! (Registro de campeonatos). Evaluación:  El registro de campeonato se encuentra guardado en el módulo “Campeonatos” (nivel de front end). Fuente: Los autores

Tabla 48: Prueba de Aceptación de administración de campeonatos. Prueba de Aceptación Nombre: Administración de campeonatos

Prueba n°12

Propósito: Verificar que la modificación de un campeonato se realice con éxito. Responsabilidad: La administración de campeonatos solo puede ejecutarse, por el administrador del sistema. Entradas: 1. En el registro creado en la prueba n°11, cliquear el botón de color naranja que se encuentra en la parte derecha del registro. 2. Modificar cualquier campo, clic en el botón “Actualizar”. Salidas esperadas:  Transacción completada: ¡Registro actualizado con éxito! (Administración de campeonatos). Evaluación:  En el módulo de campeonatos se encuentra actualizado el registro. Fuente: Los autores

72 Tabla 49: Prueba de Aceptación de registro de carnet. Prueba de Aceptación Nombre: Registro de carnet

Prueba n°13

Propósito: Verificar que el registro se lleve con éxito y comprobar que no quede un campo sin datos. Responsabilidad: El registro de carnet solo puede ejecutarse, por el administrador del sistema. Entradas: 1. Ingresar a “Módulos”, dar clic a “Carnets”. 2. Clic en el botón de “Agregar registro”. 3. Seleccionar los datos convenientes tales como: campeonato, color de título, color de datos, logo, Tipo de Fondo, Fuente de Fondo. 4. Si no se escoge el campeonato y se da clic en guardar. 5. Seleccionar el campo restante y dar clic en el botón de “Ingresar”. Salidas esperadas:  Completa este campo (Campo sin completar de Carnet).  Transacción completada: ¡Registro ingresado con éxito! (Registro de carnet). Evaluación:  No se guardó el carnet a registrar, debido a que faltaba seleccionar el campo de campeonatos.  El registro creado se encuentra almacenado a nivel de front end, en el módulo de carnet. Fuente: Los autores

Tabla 50: Prueba de Aceptación de administración de carnet. Prueba de Aceptación Nombre: Administración de carnet

Prueba n°14

Propósito: Comprobar que la actualización del carnet se generé con éxito. Responsabilidad: La administración de carnets solo puede ejecutarse, por el administrador del sistema. Entradas: 1. En el registro creado en la prueba n°13, cliquear el botón de color naranja que está al lado derecho de dicho registro. 2. Actualizar o modificar cualquier campo en específico. 3. Clic en el botón “Actualizar”. Salidas esperadas:  Transacción completada: ¡Registro actualizado con éxito! (Administración de carnet). Evaluación:  En el módulo de “Carnets”, se encuentra actualizado el registro. Fuente: Los autores

73 Tabla 51: Prueba de Aceptación de registro de actuaciones. Prueba de Aceptación Nombre: Registro de actuaciones

Prueba n°15

Propósito: Verificar que una actuación de tipo interligas permita seleccionar los clubs a jugar. Y comprobar que una actuación de tipo local, muestre solo los clubes de la liga que está actuando. Responsabilidad: El registro de actuaciones solo puede ejecutarse, por el administrador del sistema. Entradas: 1. Ingresar a “Módulos”, escoger “Campeonatos”, de un campeonato de tipo “Interliga”, darle clic al botón de “Actuaciones”. 2. Clic en el botón “Empezar la actuación”. 3. Completar los campos de: Género, lugar y fecha de inicio. 4. Clic en “Ingresar”. 5. Clic en el botón de ligas que está inmerso en el registro de la actuación. 6. Luego dar clic en el botón “Agregar registro”. Seleccionar una liga y dar clic en “Ingresar”. 7. Repetir el paso seis. 8. Regresar al campeonato en el que se está digitando las ligas. 9. Clic en el botón de clubs, que está inmerso en la actuación. 10. Clic en el botón “Agregar registro”, Seleccionar la liga (solo se muestran las 2 que fueron agregadas anteriormente en el paso 6 y 7), el club e “Ingresar”. 11. Repetir el paso 10 tres veces más. 12. Regresar al módulo de campeonatos, escoger un registro de campeonato de tipo local, clic en actuaciones del mismo registro. 13. Clic en “Empezar actuación”. Llenar sus campos y clic en el botón de “Ingresar”. 14. Sale un mensaje informativo, darle “OK”. 15. Clic en el botón de “Clubs”. Salidas esperadas:  ¿Está seguro que desea realizar esta acción? (Mensaje de confirmación).  Transacción completada: ¡Registro ingresado con éxito! (Registro de actuaciones).  Transacción completada: ¡Registro ingresado con éxito! (Seleccionar liga, primer selección).  Transacción completada: ¡Registro ingresado con éxito! (Seleccionar liga y club primer selección).  Transacción completada: ¡Registro ingresado con éxito! (Seleccionar liga y club segunda selección).  Transacción completada: ¡Registro ingresado con éxito! (Seleccionar liga y club tercera selección).  Transacción completada: ¡Registro ingresado con éxito! (Seleccionar liga y club cuarta selección).  ¿Está seguro que desea realizar esta acción? (Mensaje de confirmación).  Transacción completada: ¡Registro ingresado con éxito! (Registro de actuaciones). Evaluación:  Los clubes se pudieron escoger en función a las dos ligas que se añadieron a la actuación de tipo Interliga.  Se muestran los clubes que pertenecen a la liga que está en un campeonato local. Fuente: Los autores

Tabla 52: Prueba de Aceptación de búsqueda de actuaciones de los deportistas. Prueba de Aceptación Nombre: Búsqueda de las actuaciones de los deportistas

Prueba n°16

Propósito: Verificar que el reporte de actuaciones de un jugador se pueda visualizar, para luego ser

74 imprimida. Responsabilidad: Las búsquedas de actuaciones solo puede ejecutarse, por el administrador del sistema. Entradas: 1. 2. 3. 4.

Ingresar a “Módulos”, seleccionar “Actuaciones (Deportista)”. Ingresar un número de cédula y clic en la lupita. Clic en el botón con la figura de impresora. Seleccionar Página actual o Todo y por último clic en el botón “Imprimir”.

Salidas esperadas:  Sale una ventana emergente de selección, para elegir el tipo de impresión. Evaluación:  El reporte de las actuaciones de un jugador que se buscó, se visualizaron sin ningún inconveniente. Fuente: Los autores

Tabla 53: Prueba de Aceptación de registro de pases. Prueba de Aceptación Nombre: Registro de Pases

Prueba n°17

Propósito: Comprobar que el pase de un jugador que no esté en un campeonato actuando, se ejecute con éxito y verificar que no se puede hacer pase de un jugador que esté en un campeonato actuando. Responsabilidad: El registro de pases solo puede ejecutarse, por el administrador del sistema. Entradas: 1. Ingresar a “Módulos”, seleccionar “Pases”. 2. Clic en el botón “Agregar registro”. 3. Ingresar un número de cédula de un jugador que esté actuando y clic en la lupita. 4. Ingresar un número de cédula de un jugador que no esté actuando, elegir el club al que va a realizar el pase y la fecha de Incorporación. 5. Clic en el botón “Ingresar”. Salidas esperadas:  No se puede cargar el registro: El deportista no se encuentra disponible.  Transacción completada: ¡Registro ingresado con éxito! (Registro de pases). Evaluación:  El pase del jugador que estaba en una actuación no se realizó.  El pase del jugador que no estaba en una actuación se realizó con éxito. Fuente: Los autores

75 Tabla 54: Prueba de Aceptación de reporte de ficha del jugador. Prueba de Aceptación Nombre: Reporte de ficha del jugador

Prueba n°18

Propósito: Comprobar que el número de cédula pertenezca o no pertenezca a un deportista de la FEDELIGAS-SDT y verificar que se visualice la ficha del jugador. Responsabilidad: Tanto el administrador del sistema como los deportistas (usuarios finales), puedan acceder a esta información. Entradas: 1. En la página principal del sistema se da clic en el botón “FICHA DEL JUGADOR”. 2. Ingresar un número de cédula de una persona que no pertenezca a los deportistas de la FEDELIGAS-SDT. 3. Ingresar el número de cédula de un deportista de la FEDELIGAS-SDT. 4. Clic en la lupita. Salidas esperadas:  Arroja una barra, para buscar.  No existe registro. Evaluación:  No se mostró la ficha de algún jugador, debido a que no está registrado en el sistema.  Se mostró la ficha del jugador, debido a que este está registrado en el sistema. Fuente: Los autores

Tabla 55: Prueba de Aceptación de parametrización del sistema. Prueba de Aceptación Nombre: Parametrización del sistema

Prueba n°19

Propósito:   

Verificar que los registros de noticias se guarden correctamente y se visualicen en la página principal. Verificar que se actualicen sin ningún inconveniente los datos de noticias y se visualicen, en función a lo actualizado. Verificar que se registren los enlaces de interés y se visualicen en la página principal.

Responsabilidad: La parametrización del sistema solo puede ejecutarse, por el administrador del sistema. Entradas: 1. Ingresar al módulo “Website” y seleccionar “Noticias”. 2. Clic en el botón “Agregar registro”. 3. Ingresar los datos y seleccionar la imagen de la noticia. 4. Se da clic en el botón de “Ingresar”. 5. En el módulo de noticias, en el registro creado anteriormente, dar clic en el botón de color naranja. 6. Se modifica un campo o varios y se da clic en “Actualizar”. 7. Salir del módulo “Noticias” y entrar al de “Enlace de interés”. 8. Se da clic en el botón “Agregar registro”. 9. Ingresa datos en los campos de: Nombre, Descripción, url. 10. Clic en el botón “Ingresar”. Salidas esperadas:  Transacción completada: ¡Registro ingresado con éxito! (Registro de Noticias).

76  Transacción completada: ¡Registro actualizado con éxito! (Administración de Noticias).  Transacción completada: ¡Registro actualizado con éxito! (Registro de enlaces de interés). Evaluación:  La noticia registrada, se encuentra visible en la página principal y está en primer lugar de las noticias.  La noticia se encuentra actualizada y visible en la página principal y está en primer lugar de las noticias.  El enlace de interés se encuentra en la página principal, al final de la página. Fuente: Los autores

5.3.

Conclusiones

El resultado del presente proyecto es una aplicación web que como herramienta es indispensable para lograr el control de la gestión deportiva de la FEDENALIGAS-SDT, aportando a la comunidad del deporte un servicio ágil y eficiente. La generación de un modelo matriz, para todas las historias de usuario sirvió para dar a conocer los requerimientos de los procesos de negocio y además colaborar con la idea de diseño de la interfaz principal. La identificación de una metodología de desarrollo de software conveniente se dio por medio de un análisis entre las metodologías prescriptivas o tradicionales y las ágiles, las cuales fueron definidas en el marco referencial. Se pudo determinar las herramientas tecnológicas adecuadas, tomando en cuenta las necesidades de la empresa, la infraestructura que posee la institución y los recursos con los que cuenta la FEDELIGAS-SDT, con las herramientas escogidas se procedió al desarrollo del software. Con la elaboración de un manual de usuario y la capacitón al personal de la FEDELIGASSDT, se dio a conocer todo el funcionamiento de la aplicación web, como por ejemplo la ejecución de los procesos dados por módulos, los cuales están estructurados por procesos de: ingreso, administración, búsquedas y reportes.

5.4.

Recomendaciones

Para el diseño de las historias de usuario se sugiere, hacerlo siempre bajo un modelo matriz, ya que estas ayudan a una correcta organización sobre lo que se debe desarrollar, basándose siempre en los requerimientos del cliente. Al momento de desarrollar un sistema, se recomienda analizar a fondo las metodologías, con el fin de conocer cuál de ellas se adapta a los requerimientos, al alcance y demás factores tales como tiempo y costo. Analizar siempre los recursos económicos e infraestructura tecnológica, de la institución donde se va a trabajar, esto ayudará a tomar la decisión de las herramientas idóneas con las que se trabaje. Se sugiere dar las debidas capacitaciones al personal de la institución y además entregarle un manual de usuario, estos dos factores ayudan a solventar futuros inconvenientes en el correcto uso del sistema.

LISTA DE REFERENCIAS

Bibliográfica Bernal, C. (2010). Metodología de la investigación. Colombia: Person Educación. Clemente, P. (2014). Diseño Web Adaptativo. España: Anaya multimedia. FEDELIGAS-SDT. (2012). Estatuto de la Federación Provincial de Ligas Deportivas Barriales y Parroquiales de Santo Domingo de lo s Tsáchlila. Santo Domingo. Gauchat, J. D. (2014). El gran libro de HTML5, CSS3 & Javascript. España: Macrocombo. Hernández Sampieri, R., Férnandéz, C., & Baptista, M. (2014). Metodología de la investigación. México D.F.: McGraw-Hill. Johansen, O. (2013). Introducción a la teoría General de Sistemas. México D.F: Limusa. Martínez , C. (2012). Estadística y muestreo. Bogotá: Ecoe. Piattini, M., García Rubio, F., García Rodríguez, I., & Pino, F. (2012). Calidad de Sistema Informático. México D.F: Alfaomega. Piñeiro, J. (2013). Base de datos relacionales y modelado de datos. Madrid: Paraninfo. Pressman, R. (2010). Ingeniería del software. México D.F: McGraw-Hill. Sommerville, I. (2011). Ingeniería de software. México D.F: PERSON EDUCACIÓN.

Lincográfica Abad, J. H. (14 de Julio de 2014). Lecciones Aprendidas en Desarrollo de Software. Recuperado el 13 de Junio de 2016, de lecciones-aprendidas.info: http:// 14 de Julio de 2014www.lecciones-aprendidas.info/2014/07/tabla-comparativa-entremetodologias.html Báez, M. (2013). Implementación de un Geovisor web para la información geográfica del MIES utilizando base de datos espaciales y plataformas OpenGIS. Quito. Recuperado el 14 de 11 de 2016, de http://repositorio.usfq.edu.ec/handle/23000/1670 Bartholomew, D. (09 de 2012). eandbsoftware. Recuperado el 20 de 11 de 2016, de http://www.eandbsoftware.org/wp-content/uploads/2015/03/MariaDB_vs_MySQL__MariaDB_White_Paper_-_08_26_13_001.pdf Castellanos, L. (11 de 2013). DTyOC De Tecnología y Otras Cosas. Obtenido de https://dtyoc.com/category/ano-01/dbms/

Domínguez, J. (2016). RiuNet. Desarrollo de una aplicación web para la gestión de clubs deportivos y red social para sus miembros (Back-End) (Doctoral dissertation). Recuperado el 03 de 01 de 2017, de https://riunet.upv.es/handle/10251/68979 Eslava, J. (2013). La gestión del control de la empresa. ESIC Editorial. Recuperado en https://books.google.com.ec/books?hl=es&lr=&id=XWi8AQAAQBAJ&oi=fnd&pg=P A9&dq=la+gestion+del+control+de+la+empresa+jose+de+jaime+eslava&ots=SJWsse AZkv&sig=i0ZImh9j0nBXieZE0hDhCiazQJI#v=onepage&q=la%20gestion%20del%2 0control%20de%20la%20empresa%20jose%20de%20jaime%20eslava&f=false Gómez, J., Marín, H., & Díaz, E. (2014). Enfoque metodológico para el diseño de interfaces durante el ciclo de vida de desarrollo de software. REVISTA GTI, 12(34). Recuperado en http://revistas.uis.edu.co/index.php/revistagti/article/view/3846

Gómez, R., Duarte, A., & Guevara, C. (2014). Desarrollo ágil de software aplicando programación extrema. Revista Ingenio UFPSO, 5(1), 24-29. Recuperado en http://revistas.ufpso.edu.co/index.php/ringenio/article/view/23 Pedraza, R., Blanco, S., Codina, L., & Cavaller, V. (2013). Diseño conceptual y especificación de requerimientos para el desarrollo y rediseño de sitios web. El profesional

información,

22(1),

74-79.

Recuperado

http://eprints.rclis.org/18666/ Qumer, A., & Henderson-Sellers, B. (2006). COMPARATIVE EVALUATION OF XP AND SCRUM USING THE 4D ANALYTICAL TOOL (4-DAT). In Proceedings of the European and Mediterranean conference on information systems, 1-8. Recuperado el 13 de Junio de 2017, de https://www.researchgate.net/profile/Brian_HendersonSellers2/publication/264869569_Comparative_evaluation_of_XP_and_Scrum_using_th e_4D_Analytical_Tool_4DAT_COMPARATIVE_EVALUATION_OF_XP_AND_SCRUM_USING_THE_4D_ ANALYTICAL_TOOL_4-DAT/links/53f6eb030cf2fcea RAE. (1956). Diccionario de la Lengua Española vol. I. Madrid. Recuperado en http://s3.amazonaws.com/academia.edu.documents/36422894/Diccionario_de_la_Leng ua_Espanola.pdf?AWSAccessKeyId=AKIAJ56TQJRTWSMTNPEA&Expires=147996 8046&Signature=ea4XWZ7tS9Eoq4OquNpDxaV7XeQ%3D&response-contentdisposition=inline%3B%20filename%3DDiccionario_de_la_Lengua_Espanola.pdf Sánchez, J. (2015). La administración pública como ciencia. Recuperado en https://books.google.com.ec/books?hl=es&lr=&id=XWi8AQAAQBAJ&oi=fnd&pg=P A9&dq=la+gestion+del+control+de+la+empresa+jose+de+jaime+eslava&ots=SJWsse AZkv&sig=i0ZImh9j0nBXieZE0hDhCiazQJI#v=onepage&q=la%20gestion%20del%2 0control%20de%20la%20empresa%20jose%20de%20jaime%20eslava&f=false

Sánchez, M. (2012). Manual de Desarrollo Web basado en ejercicios y supuestos prácticos. Málaga: Copyright Agent Createspace Legal Department. Obtenido de https://books.google.com.ec/books?id=Td_jAwAAQBAJ&pg=PA10&dq=PHP:+prog ramación+web+para+profesionales&hl=es-419 Sancho, M., & Sánchez, G. (1997). La gestión del deporte municipal (Vol. 602). Inde. Recuperado en https://books.google.com.ec/books?hl=es&lr=&id=5MJQ1LPYLG4C&oi=fnd&pg=PA 9&dq=Control+de+Gesti%C3%B3n+Deportiva&ots=a0xxEcAidB&sig=GGrwAh9bJC 86yHQWXey21w_Z2dg#v=onepage&q=Control%20de%20Gesti%C3%B3n%20Depor tiva&f=false Sigüenza, C. (2015). Desarrollo de un sistema informático para la gestión estratégica de la Subgerencia de Informática de la Empresa Municipal de Telecomunicaciones, Agua Potable, Alcantarillado y Saneamiento ETAPA EP. 65. Cuenca, Ecuador. Recuperado el 17 de 11 de 2016, de http://www.dspace.ups.edu.ec/handle/123456789/7852

Trepat, R. P., García, M., Palao, M., de la Calle, J., Valentine, E., Stewart, G., & van Grembergen, W. (2014). Gobierno y gestión TI (La fuerza con control). NOVATICA(229), 91-97. Recuperado el 16 de 11 de 2016, de https://www.researchgate.net/profile/Rosseline_Rodriguez/publication/271273556_Ex tension_de_MariaDB_para_ordenamiento_y_agrupamiento_difuso/links/57ace78e08a e7a6420c32e87.pdf

GLOSARIO

 FEDELIGAS-SDT: Federación Provincial de las Ligas Barriales y Parroquiales de Santo Domingo.- Es una Institución deportiva de derecho privado, con objetivos sociales, sin fines de lucro y que goza de autonomía administrativa, técnica y económica, cuya finalidad es dirigir y fomentar el deporte barrial y parroquial del cantón Santo Domingo.  Html: HyperText Markup Language (lenguaje de marcas de hipertexto), es un lenguaje de marcado, que funciona por lado del cliente o conocido también como el FrontEnd.  Php: Hypertext Preprocessor, es un lenguaje de programación por lado der servidor o también pertenece al BackEnd. Php es un lenguaje de código abierto (Open Source).  JavaScript: Es un lenguaje que funciona por lado del cliente, cuenta con un compilador, por lo que se puede crear aplicaciones independientes o como apoyo de Html.  Css: Hojas de estilo en cascada, sirve para asigar colores, animaciones, tablas; es decir sirve para embellecer la parte del FrontEnd (interfaz).  Framework: Ofrece librerías, plantillas o esqueletos, se utiliza para crear las interfaces de los software, evitando la codificación a la interfaz.  Bootstrap: Es un framework que tiene como propósito facilitar el diseño web. Permite crear de manera sencilla interfaces; además sus diseños son adaptables.  SGBD: Es un sistema de gestor de base de datos, sirve para administrar y gestionar la información que se encuentra en la base de datos.

ANEXOS ANEXO 1. ENTREVISTA DIRIGIDA AL PRESIDENTE Y SECRETARIA DE LA FEDERACIÓN PROVINCIAL DE LIGAS BARRIALES Y PARROQUIALES DE SANTO DOMINGO

Pontificia Universidad Católica del Ecuador Sede Santo Domingo Escuela de Ingeniería de Sistemas

Objetivo de la entrevista: La presente entrevista tiene como objetivo recolectar información acerca de los procesos que se realizan en la institución, para determinar todos los parámetros que tendrá inmerso la aplicación web, para el control de las gestiones deportivas. La información recolectada será utilizada con fines académicos.

GUÍA DE ENTREVISTA 1. ¿Qué procesos se realizan dentro de la entidad? _____________________________________________________________________ _____________________________________________________________________ 2. ¿Cómo se llevan a cabo esos procesos? _____________________________________________________________________ _____________________________________________________________________ 3. ¿Quién está encargado de llevarlos a cabo? _____________________________________________________________________ _____________________________________________________________________ 4. ¿Existe algún tipo de control en los procesos? _____________________________________________________________________ _____________________________________________________________________ 5. ¿Piensa que es necesario automatizar los procesos que realizan? Si

______________

¿Por qué?_____________________________________________________________ Si respondió si a la pregunta 5 siga con la 6. Caso contrario siga a la 7 6. ¿Qué cree que necesita la institución para llevar a cabo de mejor manera los procesos institucionales? _____________________________________________________________________ _____________________________________________________________________ 7. ¿Están dispuestos a migrar a algún tipo de tecnología para la mejora de la institución y su gestión? Si

______________

¿Por qué? ______________________________________________________________

ANEXO 2. ENCUESTA DIRIGIDA A LOS DEPORTISTAS PERTENECIENTES A LA FEDERACIÓN PROVINCIAL DE LIGAS BARRIALES Y PARROQUIALES DE Pontificia Universidad Católica del Ecuador Sede Santo Domingo Escuela de Ingeniería de Sistemas

SANTO DOMINGO Objetivo de la encuesta: La presente encuesta tiene como objetivo medir la factibilidad de la implementación de una aplicación web para el control de las gestiones deportivas en la institución. La información recolectada será utilizada con fines académicos. Instrucciones: Lea detenidamente cada una de las preguntas y marque con una ‘x’ una respuesta de acuerdo a su criterio.

1. ¿Qué tiempo ha tenido que esperar para ser atendido en la FEDELIGAS-SDT? [ ] Al instante [ ] Intervalo de 2-5 minutos [ ] Superior a 5 minutos 2. ¿Ha tenido inconvenientes para obtener información de actividades deportivas en la FEDELIGAS-SDT? [ ] SI [ ] NO 3. ¿Se le ha dificultado trasladarse a la institución para obtener información? [ ] SI [ ] NO Si su respuesta es SI responda la pregunta 4, sino siga con la 5. 4. Cuáles son los motivos que le dificultan, para trasladarse a la FEDELIGAS? [ ] Vive fuera de provincia. [ ] Vive en una zona muy retirada a la FEDELIGAS-SDT. [ ] No cuenta con el suficiente tiempo para hacerlo. 5. Para obtener información de actividades futuras en la FEDELIGAS-SDT. ¿Cómo le gustaría a usted realizarlo? [ ] Ir personalmente a la FEDELIGAS-SDT [ ] Informarme por medio de una aplicación web (internet) 6. ¿Considera usted que las aplicaciones web son de utilidad y necesarias para las institución como la FEDELIGAS-SDT? [ ] SI [ ] NO 7. ¿Considera usted que se debería implementar una aplicación web para la FEDELIGASSDT? [ ] SI [ ] NO 8. ¿Considera usted que es importante la generación de la ficha del jugador, en la aplicación web? [ ] MUY IMPORTANTE [ ] IMPORTANTE [ ] POCO IMPORTANTE [ ] SIN IMPORTANCIA GRACIAS POR SU COLABORACIÓN

ANEXO 3. ARCHIVO PARA LA ESTANDARIZACIÓN DE LA BASE DE DATOS DE LA FEDERACIÓN PROVINCIAL DE LIGAS BARRIALES Y PARROQUIALES DE SANTO DOMINGO

ANEXO 4. CODIFICACIÓN DE LOS MÓDULOS DE PASES, CAMPEONATOS Y CARNETS MODELO DE LA CLASE “PASE”

GESTOR DE IMPRESIÓN DE LOS CARNETS

UNA VISTA DEL CAMPEONATO

ANEXO 5. CAPACITACIÓN DEL PERSONAL EN LA ADMINISTRACIÓN DEL SISTEMA

ANEXO 6. ACTA DE ENTREGA- RECEPCIÃ&#x201C;N

ANEXO 7. CARTA DE IMPACTO