Sistes web para el registro de calificaciones y control de asistencia para la UE “Iberoamericano 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

SISTEMA WEB PARA EL REGISTRO DE CALIFICACIONES Y CONTROL DE ASISTENCIA PARA LA UNIDAD EDUCATIVA “IBEROAMERICANO” EN EL CANTÓN SANTO DOMINGO DURANTE EL PERÍODO 2017-2018

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: BRYAN ADRIÁN AGUDELO CASTRO BYRON ALEXANDER GARCÍA LÓPEZ Director: Mg. RODOLFO SIRILO CÓRDOVA GÁLVEZ

Santo Domingo – Ecuador Agosto, 2018

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

Dirección Académica - Escuela de Sistemas

HOJA DE APROBACIÓN SISTEMA WEB PARA EL REGISTRO DE CALIFICACIONES Y CONTROL DE ASISTENCIA PARA LA UNIDAD EDUCATIVA “IBEROAMERICANO” EN EL CANTÓN SANTO DOMINGO DURANTE EL PERÍODO 2017-2018

Línea de Investigación: Estudio, Diseño e Implementación de Software.

Autor: BRYAN ADRIÁN AGUDELO CASTRO BYRON ALEXANDER GARCÍA LÓPEZ

Rodolfo Sirilo Córdova Gálvez, Mg.

DIRECTOR DE LA DISERTACIÓN DE GRADO

José Luis Centeno Lara, Mg.

CALIFICADOR

Carlos Vicente Galarza Macancela, Mg.

CALIFICADOR

Luis Javier Ulloa Meneses, Mg.

DIRECTOR DE LA ESCUELA DE SISTEMAS Santo Domingo – Ecuador Agosto, 2018

iii

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, Bryan Adrián Agudelo Castro portador de la cédula de ciudadanía Nº 1719287854 declaro que los resultados obtenidos en la investigación que presento como informe final, previo a la obtención del Grado de Ingeniero 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.

Bryan Adrián Agudelo Castro CI 1719287854

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, Byron Alexander García López portador de la cédula de ciudadanía Nº 2300114374 declaro que los resultados obtenidos en la investigación que presento como informe final, previo a la obtención del Grado de Ingeniero 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.

Byron Alexander García López CI 2300114374

AGRADECIMIENTO Mi exorbitante agradecimiento va dirigido para las personas completamente ideales en mi vida, aquellas que con su apoyo incondicional han sido parte de este estupendo y majestuoso peldaño. Un escalón más que sin lugar a dudas ha compuesto en mí unas de las mejores experiencias asentadas a lo largo de los años. Papá, mamá y hermano gracias por el ilimitado soporte que me han brindado. Y amigo Byron te agradezco por ser un excelente amigo y compañero de tesis, gracias por tu incondicional apoyo. Bryan Agudelo Puedo asegurar que el mundo no todo es felicidad, es un lugar donde he encontrado desafíos día a día, y uno de ellos ha sido la universidad. Al haber estado dentro de ella, puedo asegurar, que, por más responsable en mis estudios, hubo momentos en los que desistí, me frustré y quise dejar todo a un lado. Es por esto que agradezco a Dios, a mi padre Franklin, mi madre Blanca, a mi hermano Frank y a mi gran amigo Bryan por su apoyo incondicional, por los consejos, la confianza y todo el amor que me han brindado estos 5 años en la universidad, ya que sin ellos; mi objetivo de ser ingeniero no se hubiera hecho realidad. Byron García

DEDICATORIA Anhelando con total dignidad, es un honor dedicar este trabajo de titulación a las personas que amo y adoro con mi vida; papá, mamá, ustedes quienes son mi fortaleza, amor y guías ante la vida, aquellos que con sus enseñanzas a diario han perpetuado en mí el ansia por conservar ese humanismo. Y hermano tú con quien he compartido toda la vida, has sido mi fundamento y ejemplo ideal para seguir cumpliendo más hazañas. Se los dedico a ustedes tres, quienes han estado en las buenas, malas y peores. Bryan Agudelo Dedico esta disertación de grado con todo el amor y cariño del mundo a una mujer en especial, que con sus defectos y virtudes me ha enseñado lo bonito que es la vida al tenerla cerca, porque desde el primer día que la conocí jamás vi nada tan perfecto. Por creer en mí, por ser la única mujer que me motiva a ser mejor, a pensar en grande y a superar cada obstáculo que se presente, para algún día forjar un futuro maravilloso a su lado, por ser el motivo más grande de mi vida, dedico esta disertación a ella y solamente a ella. Byron García

vii

RESUMEN El presente trabajo de titulación comprende una propuesta de innovación con bases conceptuales, investigación descriptiva, aplicada y de campo permitiendo la vinculación con la sociedad; en base a esto, se procedió al desarrollo e implementación de un sistema web para el registro de calificaciones y control de asistencias de los estudiantes de la Unidad Educativa Particular Iberoamericano del cantón Santo Domingo, cabe indicar que el sistema aportó con la automatización de los procesos manuales de la unidad educativa. El sistema está compuesto por los módulos: apertura y cierres de periodos académicos, creación de usuarios, asignaturas cursos, cátedras (asociación entre profesores, asignaturas y cursos), inscripciones para matricular a discentes, reportes de notas y asistencias, asignación de perfiles de usuario con respectivos permisos a docentes, secretaria, rector y representantes. Para el desarrollo del sistema web se empleó el marco de trabajo SCRUM con una arquitectura basada en el Modelo Vista Controlador. Además, para la parte de diseño del front-end se utilizó HTML5 y CSS3 con el framework Bootstrap v3.0; en el back-end para la programación de los módulos se desarrolló con PHP v7.1.9 y JavaScript con jQuery v3.2.1, para la base de datos se utilizó PostgreSQL v9.3 y Sublime Text v3 como editor de código. Palabras Claves: Automatización, lenguaje de programación, sistema informático, software de código abierto.

viii

ABSTRACT The current titration work includes a proposal of innovation with conceptual bases, descriptive, applied and field research allowing the linking with the society; based on this, we proceeded to the development and implementation of a web system for the grades registration and attendance control of the students of the Iberoamericano Private Educational Unit of Santo Domingo, it should be noted that the system contributed with the automation of the manual processes of the Educational Unit. The system consists of the modules: opening and closing of academic periods, creation of users, subjects courses, chairs (association between teachers, subjects and courses), registration to enroll students, grades and attendance reports, assigning of user profiles with respective permits to teachers, secretary, headmaster and parents. For the development of the web system, the SCRUM framework was used with an architecture based on the Controller.Vista Model. In addition, for the design part of the front-end, HTML5 and CSS3 were used with the Bootstrap v3.0 framework; in the back-end for the programming of the modules was developed with PHP v7.1.9 and JavaScript with jQuery v3.2.1, for the database PostgreSQL v9.3 and Sublime Text v3 were used as code editor. Keywords: Automation, programming language, computer system, open source software.

ÍNDICE DE CONTENIDOS 1.

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

PLANTEAMIENTO DEL PROBLEMA ......................................................................... 3

2.1. Problema de Investigación ............................................................................................... 3 2.2. Justificación de la Investigación ....................................................................................... 4 2.3. Objetivos de Investigación ............................................................................................... 5 2.3.1. Objetivo General. ............................................................................................................. 5 2.3.2. Objetivos Específicos. ...................................................................................................... 5 3.

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

3.1. Antecedentes..................................................................................................................... 6 3.2. Revisión de la Literatura o Fundamentos Teóricos .......................................................... 8 3.2.1. Sistema Informático Orientado a la Web. ........................................................................ 8 3.2.2. Gestión Educativa. .......................................................................................................... 21 3.3. Comparativas entre Metodologías Ágiles ...................................................................... 23 3.4. Comparativas entre Sistemas Gestores de Base de Datos .............................................. 24 3.5. Comparativa de Lenguajes de Programación ................................................................. 26 4.

METODOLOGÍA DE INVESTIGACIÓN .................................................................... 28

4.1. Diseño/Tipo de Investigación ......................................................................................... 28 4.1.1. Enfoque de la Investigación. .......................................................................................... 28 4.1.2. Diseño de la Investigación.............................................................................................. 28 4.1.3. Tipo de Investigación. .................................................................................................... 28 4.2. Población/Universo ........................................................................................................ 29 4.3. Muestra ........................................................................................................................... 29 4.4. Técnica e Instrumentos de Recogida de Datos ............................................................... 30 4.5. Técnica de Análisis de los Datos .................................................................................... 30 5.

RESULTADOS .............................................................................................................. 31

5.1. Análisis y Discusiones de los Resultados ....................................................................... 31 5.1.1. Análisis situacional de la población para el uso del sistema. ......................................... 31 5.2. Propuesta de Intervención .............................................................................................. 38 5.2.1. Fase de desarrollo del sistema web utilizando el marco de trabajo SCRUM. ................ 39 5.2.2. Diseño Relacional de Base de Datos. ............................................................................. 69 5.2.3. Acta entrega-recepción. .................................................................................................. 71 5.3. Análisis del Impacto ....................................................................................................... 72

5.3.1. Impacto Social. ............................................................................................................... 73 5.3.2. Impacto Tecnológico. ..................................................................................................... 73 5.3.3. Impacto Ambiental. ........................................................................................................ 74 5.3.4. Impacto Económico ........................................................................................................ 74 5.3.5. Impacto General. ............................................................................................................ 75 5.3.6. Carta de impacto ............................................................................................................. 76 5.4. Discusiones ..................................................................................................................... 77 5.4.1. Discusión de la Entrevista. ............................................................................................. 77 5.4.2. Discusión de la Encuesta. ............................................................................................... 77 5.4.3. Discusión de la Fase de Desarrollo. ............................................................................... 77 6.

CONCLUSIONES .......................................................................................................... 79

RECOMENDACIONES ................................................................................................ 80

LISTADO DE REFERENCIAS ..................................................................................... 81

GLOSARIO DE TÉRMINOS ........................................................................................ 84

10.

ANEXOS ........................................................................................................................ 85

ÍNDICE DE TABLAS

Tabla 1. Comparación de metodologías agiles: Crystal, Scrum, XP ....................................... 24 Tabla 2. Comparación de sistemas gestores de base de datos: MaríaDB y Postgresql ........... 26 Tabla 3. Comparativa entre los lenguajes de programación: PHP, Python, Ruby................... 27 Tabla 4. Conocimientos sobre el uso del internet .................................................................... 33 Tabla 5. Acceso al internet....................................................................................................... 34 Tabla 6. Necesidad de implementar un sistema online ............................................................ 35 Tabla 7. Beneficio en la institución por la automatización de procesos .................................. 36 Tabla 8. Seguridad en el almacenamiento de las calificaciones y asistencias ......................... 37 Tabla 9. Roles de trabajo bajo Scrum ...................................................................................... 39 Tabla 10. Product Backlog ....................................................................................................... 40 Tabla 11. Sprint backlog 1 ....................................................................................................... 45 Tabla 12. Burndown chart 1..................................................................................................... 46 Tabla 13. Pruebas de aceptación sprint 1 ................................................................................. 50 Tabla 14. Prueba de aceptación 2 ............................................................................................ 51 Tabla 15. Sprint backlog 2 ....................................................................................................... 52 Tabla 16. Burndown chart sprint 2 .......................................................................................... 53 Tabla 17. Prueba de aceptación 3 ............................................................................................ 57 Tabla 18. Sprint backlog 3 ....................................................................................................... 58 Tabla 19. Burndown chart 3..................................................................................................... 59 Tabla 20. Prueba de aceptación 4 ............................................................................................ 62 Tabla 21. Prueba de aceptación 5 ............................................................................................ 63 Tabla 22. Sprint backlog 4 ....................................................................................................... 64 Tabla 23. Burndown chart sprint 4 .......................................................................................... 65 Tabla 24. Niveles del impacto ................................................................................................. 72 Tabla 25. Fórmula para calcular el impacto............................................................................. 72 Tabla 26. Impacto social .......................................................................................................... 73 Tabla 27. Impacto tecnológico ................................................................................................. 73 Tabla 28. Impacto ambiental.................................................................................................... 74 Tabla 29. Impacto económico .................................................................................................. 74 Tabla 30. Impacto general........................................................................................................ 75

xii

ÍNDICE DE FIGURAS Figura 1. El Proceso de la Programación Extrema. ................................................................. 12 Figura 2. Ciclo de Aplicación y Valores de Scrum. ................................................................ 14 Figura 3. Modelo Vista Controlador. ...................................................................................... 15 Figura 4. Diagrama de Procesos de registro de notas. ............................................................. 32 Figura 5. Diagrama de Procesos de Control de Asistencia. ..................................................... 33 Figura 6. Conocimientos sobre el Uso del Internet.................................................................. 34 Figura 7. Acceso al Internet. ................................................................................................... 35 Figura 8. Necesidad de Implementar un Sistema Online. ....................................................... 36 Figura 9. Beneficio en la Institución por la automatización de procesos. ............................... 37 Figura 10. Seguridad de llevar la información en un Sistema Web......................................... 38 Figura 11. Burndown Chart 1. ................................................................................................. 47 Figura 12. Captura de Pantalla del Login. ............................................................................... 49 Figura 13. Captura de Pantalla de Perfiles de Usuarios. .......................................................... 49 Figura 14. Captura de Pantalla de Ingreso de Usuarios. .......................................................... 49 Figura 15. Burndown Chart 2. ................................................................................................. 54 Figura 16. Captura de Pantalla del Ingreso de Periodo Académico. ....................................... 55 Figura 17. Captura de Pantalla del Ingreso del Curso. ............................................................ 56 Figura 18. Captura de Pantalla del Ingreso de Docentes e Ingreso de Materias. ..................... 56 Figura 19. Burndown Chart 3. ................................................................................................. 60 Figura 20. Captura de Pantalla del menú para la asociación de Estudiantes. .......................... 61 Figura 21. Captura de Pantalla del Ingreso de la Inasistencia. ................................................ 62 Figura 22. Burndown Chart 4. ................................................................................................. 66 Figura 23. Captura de Pantalla de Reporte de Calificaciones. ................................................. 68 Figura 24. Captura de Pantalla del Ingreso de Calificaciones. ................................................ 68 Figura 25. Captura de Pantalla del Listado de Estudiantes. ..................................................... 69 Figura 26. Captura de Pantalla del Ingreso de Estudiantes. ..................................................... 69 Figura 27. Modelo Relacional de la Base de Datos.. ............................................................... 70 Figura 28. Acta de Entrega-Recepción. ................................................................................... 71 Figura 29. Carta de impacto. .................................................................................................... 76

xiii

ÍNDICE DE ANEXOS ANEXO 1. Entrevista .............................................................................................................. 85 ANEXO 2. Encuesta ................................................................................................................ 86 ANEXO 3. Historias de Usuario .............................................................................................. 87 ANEXO 4. Diccionario de la Base de Datos ........................................................................... 96 ANEXO 5. Manual Técnico .................................................................................................. 102 ANEXO 6. Manual de Usuario .............................................................................................. 102

1. INTRODUCCIÓN El presente trabajo de titulación tiene como objetivo principal, brindar a la Unidad Educativa Iberoamericano un sistema web informático para el registro de calificaciones y control de asistencia en la modalidad presencial, permitiendo a los docentes optimizar el proceso de registro de calificaciones y control de la asistencia; y a los representantes, tener el acceso a dicha información de forma rápida y segura. Para brindar respuestas precisas a las interrogantes planteadas en el desarrollo del trabajo de disertación, se optó por la utilización de diferentes fuentes de información como Google Académico, Scielo, Redalyc, Buscabiografías, etc.; de los que se logró obtener artículos científicos, tesis, fuentes de estudio, libros y bibliografía. Como complemento a lo mencionado anteriormente, también se utilizó las fuentes de información que brinda la PUCESD a los estudiantes, permitiendo sustentar el trabajo con fuentes bibliográficas de forma fidedigna. El presente trabajo de disertación está compuesto de cinco etapas que se describen a continuación: La primera etapa presenta la introducción, en donde se describe de manera general las partes que tiene la disertación de grado, previo al desarrollo del sistema web. La segunda etapa está el planteamiento del problema que se encuentra constituido de tres partes, el problema de la investigación, la justificación y los objetivos que expresarán el desarrollo de toda la disertación. La tercera etapa contiene al marco referencial en el que se evidencian todos los temas que sustentan la investigación realizada en tres partes, primero se encuentran los antecedentes, segundo la revisión de la literatura constando de dos partes una la variable independiente y la otra por la variable dependiente, y como tercera parte están las comparativas entre metodologías, sistemas gestores de base de datos y lenguajes de programación. La cuarta etapa está establecida por la metodología de investigación, en la que se describe el diseño de la investigación, la población y la muestra con la que se trabajará, los instrumentos y las técnicas para el análisis de la información, además de la selección de la metodología o marco de trabajo para el desarrollo de software.

La quinta y última etapa se realiza el análisis y discusión de los resultados obtenidos, además se presenta las conclusiones y recomendaciones que se obtuvo de la actual investigación, con los anexos que ayudarán a comprender de mejor manera el presente trabajo de titulación.

2. PLANTEAMIENTO DEL PROBLEMA 2.1. Problema de Investigación El presente proyecto de investigación se fundamenta con la necesidad de brindar a los docentes de la Unidad Educativa Particular Iberoamericano del cantón Santo Domingo, un mejor proceso para el control de asistencias y registro de notas de las asignaturas ofrecidas en cada curso, además de generar reportes de las calificaciones de los estudiantes. Como remedio al problema establecido en el párrafo anterior, es necesario establecer la siguiente pregunta que dé inicio a la investigación: ¿Cómo mejorar el registro de calificaciones y control de asistencias en la Unidad Educativa Particular Iberoamericano del cantón Santo Domingo? Pese a la creación tecnológica para la gestión educativa, siendo desarrollada e implementada por el Ministerio de Educación del Ecuador que según ElComercio.com (2014) informa que, el proyecto plantea un modelo de gestión educativa que integra a profesores, estudiantes y padres de familia en una misma plataforma virtual a la que han denominado Educar Ecuador. Por lo tanto, hay que destacar que esta nombrada plataforma de gestión escolar, está disponible únicamente para instituciones educativas públicas, es decir, las instituciones de sostenimiento particular, fiscomisional y municipal podrán escoger cualquier herramienta informática para registrar notas y controlar asistencias. Según Sánchez (2009), define a una plataforma como un amplio rango de aplicaciones informáticas instaladas en un servidor cuya función es la de facilitar al profesorado la creación, administración, gestión y distribución de cursos a través de Internet. Teniendo en cuenta el problema principal se procede a dividirlo en las siguientes interrogantes para lograr un mayor entendimiento: ¿Cuáles son los procesos para el registro de calificaciones y control de asistencias en la Unidad Educativa Particular Iberoamericano?

¿Cuál es la metodología o marco de trabajo para el desarrollo de software que se aplican para el desarrollo de sistemas web? ¿Cómo mejorar el registro de calificaciones y control de asistencias en la Unidad Educativa Particular Iberoamericano?

2.2. Justificación de la Investigación Esta investigación tiene relación con el cumplimiento del objetivo número cinco, inmerso en el segundo de los tres enfoques establecidos por la Secretaría Nacional de Planificación y Desarrollo (Senplades), de los nueve objetivos presentes en el Plan Nacional del Buen Vivir para el período 2017-2021. El objetivo 5 consiste en: “Impulsar la productividad y competitividad para el crecimiento económico sustentable de manera redistributiva y solidaria”, el mismo que pretende, fomentar la producción nacional con responsabilidad social y ambiental, impulsando el control total y eficaz de los recursos naturales, con el uso de tecnologías que perduren con el tiempo y sean ambientalmente limpias, para asegurar el mantenimiento de bienes y servicios de calidad posicionando como meta para el 2021, incrementar de 4,6 a 5,6 el desarrollo de las Tecnologías de la Información y Comunicación. (Secretaria Nacional de Planificación y Desarrollo, 2017) Debido a que existe la necesidad de brindar una herramienta informática que sea confiable, segura y práctica a la Unidad Educativa Particular Iberoamericano, dado que no posee una aplicación que le permita dirigir un buen registro de calificaciones y un mejor control de la información que se obtiene del registro de asistencias de los estudiantes. El proceso de control de la asistencia se lo realiza de forma manual, obteniendo la información en hojas con nóminas de los estudiantes en la que se registra la hora de ingreso a cada clase; esto hace que el proceso en la manipulación de la información de asistencia sea lento dado que todos los registros se los apunta de manera manual y se pierda tiempo de las horas clases para los estudiantes. Por otro lado, el hecho de portar el registro de asistencias en hojas y a la vista de todos, encamina a los estudiantes a no tomar conciencia y responsabilidad sobre la hora de ingreso, pues en ocasiones hace que los discentes modifiquen las nóminas de asistencia, o a su vez que se extravíen o dañen los documentos.

Por estos motivos es necesario la implementación de un sistema web informático para la institución, en el que se logrará optimizar el registro de calificaciones, haciendo que cada docente se encargue de llevar el registro de notas en cualquier lugar con acceso a internet y, por ende, permita descartar el trabajo a la persona que estaba encargada de este proceso. Así mismo, este sistema automatizado permitirá el control de la asistencia y así evitar la manipulación, duplicación y pérdida de las nóminas de los estudiantes, logrando que quede en el pasado el uso de hojas de papel. Además, existe otros beneficios que el sistema web presentará, como lo son: la visualización de las notas desde cualquier navegador web y la generación de reportes de calificaciones y asistencias. Al implementar el proyecto de disertación de grado se logrará satisfacer y beneficiar directa e indirectamente a todas las personas que constituyen la Unidad Educativa Particular Iberoamericano, directamente en relación a los docentes e indirectamente a los padres de familia, puesto que, con el sistema web se ayudará a generar un buen ambiente de cooperación y comunicación entre docentes, y padres de familia. Además, ayudará a oprimir la utilización de papel aportando con el medio ambiente.

2.3. Objetivos de Investigación 2.3.1. Objetivo General. Implementar el sistema web para el registro de calificaciones y control de asistencia para la Unidad Educativa “Iberoamericano” en el cantón Santo Domingo durante el período 2017-2018. 2.3.2. Objetivos Específicos. 

Determinar los procesos del registro de calificaciones y control de asistencia en la Unidad Educativa Iberoamericano.



Definir la metodología de desarrollo de software con la que se va a trabajar en el desarrollo del sistema web para el registro de calificaciones y control de asistencia.



Desarrollar el sistema web para el registro de calificaciones y control de asistencia en la Unidad Educativa “Iberoamericano”, que cumpla con todos los requerimientos establecidos.

3. MARCO REFERENCIAL 3.1. Antecedentes La Unidad Educativa Iberoamericano fue creada en el año 2006 con el nombre “Sultana de los Andes”, a cargo del Dr. Eggar Frías; sin embargo, en el año 2008 por motivos externos fue nombraba “Iberoamericano” a cargo del Director General Ipólito Borja, con la finalidad de buscar un beneficio en la sociedad para las personas que busquen la forma de sobresalir en el estudio y tengan acceso a ello. Dentro de su misión institucional, es ser una institución con principios éticos y valores humanos, formando bachilleres técnicos con excelente calidad humana, aptos para la inserción laboral y altamente preparados para continuar con sus estudios en la universidad, aprovechando todas las bondades que ofrece la tecnología moderna. Además, su visión es convertirse en una institución que lidere en nuestra provincia la formación de bachilleres técnicos, excelentemente preparados para enfrentar los retos del futuro, primordialmente con alta calidad humana. Aprovechando al máximo las herramientas tecnológicas disponibles y el alto profesionalismo de su planta docente. A continuación, se hace referencia a trabajos de investigación relacionados con la presente disertación de grado que sirve de guía para tener una idea de cómo se trató el problema en dichas situaciones: En la Universidad de Guayaquil en la Facultad de Ciencias Matemáticas y Físicas de la carrera de Ingeniería en Sistemas Computacionales, se encuentra la disertación de grado con el nombre “Desarrollo de una Aplicación en Ambiente Web para el Control de Asistencia y Calificaciones de los Estudiantes de la Unidad Educativa Particular Santa Ana”, desarrollado en el año 2018 por los estudiantes ahora ingenieros, Aguirre Martha y De la Cruz David, el cual permite a los profesores registrar diariamente la asistencia y las calificaciones de los estudiantes, logrando obtener un mejor control y seguimiento de las calificaciones con una opción de consulta web, tanto para los estudiantes como los representantes.

La Universidad de Guayaquil, en la Facultad de Ingeniería Industrial de la carrera con Licenciatura en Sistemas de Información, se encuentra la disertación de grado con el nombre “Desarrollo de un sistema de control asistencia y calificaciones para los alumnos del Jardín Mundo de Aventuras”, desarrollado en el año 2016 por la estudiante ahora ingeniera, Quijano Mariela, el cual se basa en un sistema web que permita controlar la asistencia y llevar un registro de las calificaciones para brindar un mejor servicio con información de los estudiantes al padre de familia. Se utilizó la metodología ICONIX que define un 80% del desarrollo de software utilizando el 20% restante de los modelos establecidos UML. En la Escuela Politécnica Nacional del Ecuador en la facultad de ingeniería de sistemas se encuentra la disertación de grado con el nombre “Desarrollo e Implantación del Sistema de Gestión Académica y Administrativa Vía Web” desarrollado en el Colegio Modelo Politécnico de Quito, en el año 2010 por los estudiantes ahora ingenieros, Jarrín María y Valarezo Edgar, este sistema se enfocó en reducir los tiempos empleados en la administración y gestión de los procesos académicos, utilizando la metodología de desarrollo ágil “XP” y lenguajes de programación que se adaptaron al mismo. La Pontificia Universidad Católica del Ecuador Sede Santo Domingo, en la escuela de sistemas de la carrera de Ingeniería de Sistemas y Computación, se encuentra la disertación de grado con el nombre “Desarrollo de un sitio Web para el registro de notas y control de asistencia” desarrollado en la Unidad Educativa Jacques Cousteau del Cantón Santo Domingo de los Colorados, en el año 2014 -2015, por los estudiantes ahora ingenieros, Lema Richard y Pineda Cristian, este sistema se basó en la mejora a los procesos en dicha institución utilizando la metodología de desarrollo ágil “XP”, junto con los lenguajes de programación web PHP y JavaScript, etc. La Pontificia Universidad Católica del Ecuador Sede Santo Domingo, en la escuela de sistemas de la carrera de Ingeniería de Sistemas y Computación, se encuentra la disertación de grado con el nombre “Desarrollo de un sitio Web con un sistema informático para el registro de calificaciones, control de asistencia, que vincule a la comunidad de la Unidad Educativa "Alessandro Volta" para la inclusión tecnológica”, desarrollado en la institución ya nombrada del Cantón Santo Domingo, en el año 2015, por los estudiantes ahora ingenieros, Cabrera Hugo y Carrera Paúl, este sistema que se enfoca en el registro de calificación y control de asistencia de los estudiantes, utilizando el paradigma de desarrollo de software en cascada, junto con los lenguajes de programación web PHP, con una base de datos desarrollada en PostgreSQL.

3.2.

Revisión de la Literatura o Fundamentos Teóricos

3.2.1. Sistema Informático Orientado a la Web. 3.2.1.1. Ingeniería de software. La Ingeniería de Software es relativamente una profesión joven, que aún está por madurar pero que sirve de gran apoyo en lo que respecta al desarrollo de software aplicando metodologías y buenas prácticas de programación. Sommerville (2011) asegura que la ingeniería de software es un área de estudio de ingeniería que presta interés y se enfoca en todos los ámbitos acerca de la producción del software, a partir de la fase en la que se especifica el sistema hasta llegar al mantenimiento del mismo, una vez que se haya puesto en marcha. 3.2.1.1.1 Desarrollo de software. Para realizar un desarrollo de software es importante la cooperación del grupo de trabajo, para ello, se debe tener un balance en las metodologías que derivan en las entregas rápidas de software, es decir avances que muestren la funcionalidad que pretende hacer el software. Dichos incrementos o entregas deben satisfacer las perspectivas de los usuarios finales. Con ello, se minimiza los riesgos y se mejoran las relaciones en el grupo de trabajo (Jacobson, Ng, McMahon, Spence & Lidman, 2013). 3.2.1.1.1.1 Ciclo de vida del software. Comunicación: es la etapa más importante en el desarrollo de un proyecto, en donde el desarrollador del software se comunica con el cliente u otros participantes con la finalidad de recabar información que permita tener éxito al finalizarlo. Pressman (2010) que la comunicación tiene como fin comprender los objetivos de las personas que participan en el proyecto, y recabar todos los requerimientos que faciliten a definir las correctamente las particularidades y funcionalidades del software. Planeación: con la especificación de requerimientos definidos en la etapa de comunicación, realizar el proyecto se facilita si se tiene a disposición un plan o mapa de trabajo que dirija al equipo por un buen camino, el nombrado plan de proyecto de software concreta las actividades de ingeniería de software especificando las acciones a desarrollar, los inconvenientes que puede existir, los materiales que necesiten, los beneficios del trabajo desarrollado y todo el cronograma de actividades (Pressman, 2010).

Modelado: elaborar un prototipo o esquema del software a desarrollar con la finalidad de entender a plenitud los objetivos del proyecto de forma general. Pressman (2010) aclara que un ingeniero de software realiza de la misma forma un esquema con la finalidad de comprender detalladamente las especificaciones que se necesitan y el diseño que lo ayudará. Si es necesario se modifica el esquema a tal punto que se comprenda totalmente el problema y la solución al mismo. Construcción: la etapa en donde la generación de código y las pruebas necesarias se hacen uno solo para encontrar y corregir errores (Pressman, 2010). Despliegue: la etapa final en la que se entrega al consumidor el software de forma completa y terminado, el mismo que lo revisa y da seguimiento, establecido en el proceso de evaluación (Pressman, 2010). 3.2.1.1.1.2 Paradigma orientado a objetos. Un paradigma de programación simboliza el enfoque y la forma de cómo se realizará el software, Según López (2013) establece que un paradigma orientado a objetos es una metodología de desarrollo de software que consta de esquemas, conceptos, y las técnicas en que la estructura de sus elementos está orientado a la abstracción del mundo real mediante objetos. 3.2.1.1.1.2.1 Características de programación orientada a objetos. La Programación Orientada a Objetos se basa en la caracterización de entidades, y la forma como se desenvuelven dentro del sistema, es por esto que Pérez (2015) presenta algunas características de la POO (programación Orientada a Objetos) como lo son: Abstracción: es el proceso que el desarrollador obtiene la información del mundo real hacia un modelo computacional cuando se desea elaborar un software satisfaciendo las insuficiencias del sistema. Encapsulación: son los métodos que los usuarios de los objetos pueden saber, pero que no es preciso que los conozcan y entiendan la manera de como la clase puede llegue a implementarlos.

Modularidad: es la capacidad de que el sistema es dividido en varias partes con la finalidad de entenderlo mejor y desarrollarlo eficientemente al trabajar con tanta información. Jerarquización: es el proceso en el que se identifican las clases, ya sea estas superclase y clase, en donde superclase es la que contiene otras clases es decir las subclases están contenidas en estas. 3.2.1.1.2 Metodologías de desarrollo. 3.2.1.1.2.1 Metodologías de desarrollo ágil. En el año 1990 surge el término “métodos agiles” debido a la poca acogida de los enfoques de ingeniería de software con los que se trabajaba en aquella época, permitiendo que los desarrolladores precisen sus ideas en el software en vez del diseño y la documentación, estos métodos se complementan principalmente con el enfoque incremental sea para las especificaciones, el desarrollo y la entrega del sistema. Están enfocados más en los sistemas en los que los requerimientos varían (Sommerville, 2011). 3.2.1.1.2.2 Programación extrema. La programación extrema es un método de desarrollo ágil aplicables a proyectos cambiantes pequeños o medianos, está enfocado tanto para las personas que elaboran el sistema como para los clientes y se amolda perfectamente a cambios recurrentes que ellos dispongan, Álvarez, De las Heras y Lasa (2012) sugiere desarrollar y perfeccionar el código, de manera que su esquema, estructura y codificación permitan obtener mejoras y aumentar una nueva funcionalidad sin que repercuta tanto a la calidad del software. 3.2.1.1.2.2.1 Valores de la programación extrema. La programación extrema presenta un conjunto de trabajo de 5 valores: comunicación, simplicidad, retroalimentación, valentía y respeto, en la que cada uno complementan las acciones y tareas de esta metodología ágil. A continuación, según Pressman (2010) describe los cinco valores mencionados. Comunicación: XP presenta es valor, como método de comunicación de forma informal es decir de manera (verbal) entre los clientes, usuarios finales y los desarrolladores, para expresar información importante, en la retroalimentación, y así evadir el hecho de

comunicarse por medio de extensos documentos. Simplicidad: limita a los desarrolladores a que elaboren el esquema de software de forma rápida y eficaz, evitando tener extensas complicaciones a futuro, con la finalidad de tener un diseño del sistema simple que se pueda aplicar fácilmente. Retroalimentación: del sistema implementado, la retroalimentación se logra obtener de tres maneras, el cliente y los miembros del equipo de software, al momento de diseñar e implementar una estrategia eficiente, el software por medio de los resultados de las pruebas da lugar a la retroalimentación. Además, existe la posibilidad de ciertas destrezas que XP requiere para ser totalmente eficaz como los es la valentía que va de la mano con disciplina, el equipo ágil al apegarse a cada uno de estos valores está generando respeto entre sus miembros, otros participantes y los integrantes del equipo. 3.2.1.1.2.2.2 Etapas de la programación extrema. La etapa de planeación radica en escuchar y reunir todos los requerimientos, para que los desarrolladores del equipo XP comprendan el valor del negocio del software y así puedan definir correctamente las salidas, características y funcionalidades del sistema. La etapa de Diseño se enfoca en un diseño en el que no se represente de forma compleja, además tiene como objetivo la elaboración de tarjetas CRC junto con la implementación de las historias de usuario. Una vez que las historias has sido elaboradas junto con el diseño, entra la etapa de Codificación, dando lugar a las pruebas unitarias una vez que el código esté finalizado, obteniendo mejoras debido a la retroalimentación que se obtiene por cada prueba unitaria, por otra parte, XP propone la codificación por parejas teniendo como beneficio un método para resolver problemas en tiempo real. Y, por último, la Etapa de Pruebas, como se mencionó en la etapa de codificación, en que las pruebas unitarias deben implementarse, para después organizarse en forma universal (Pressman, 2010).

Figura 1. El Proceso de la programación extrema. Adaptado de “Ingeniería de Software. Un Enfoque Práctico” por R. S. Pressman, 2010. México: Mc Graw Hill, p. 11.

3.2.1.1.2.3 Scrum. Scrum forma parte de la metodología ágil como marco de trabajo fomentando la innovación con grupos de trabajo auto-gestionados, presentando en iteraciones cortas o sprint resultados estables y confiables que van desde una a cuatro semanas, además, presenta una característica en particular como la aplicación de buenas prácticas de manera continua, las mimas que unas a otras se apoyan fomentado la forma de trabajar como grupos altamente productivos (Brito, Sosa & Héctor, 2015). 3.2.1.1.2.3.1 Principios de Scrum. Según Álvarez et al., (2012) expresa que Scrum se basa en los siguientes principios: Inspección y Adaptación: cada iteración en el proceso Scrum culmina con un producto entregable, que se indica al cliente dando su opinión del mismo, luego de esto el equipo se reúne para analizar, lo que se está haciendo y asimilará con mayor conocimiento y así mejorar la iteración. Auto-organización y colaboración: El equipo se es responsable y se compromete a colaborar estrictamente con el trabajo en equipo, resolviendo y eliminando los problemas que se pueda tener.

Priorización: para no perder dinero y tiempo en actividades innecesarias para el producto, se necesita definir y priorizar los requisitos. Mantener un Latido: mantener el hilo del en el proceso del desarrollo, permitirá optimizar el trabajo a realizar por parte de los desarrolladores. 3.2.1.1.2.3.2 Valores de Scrum. Scrum como marco de trabajo de metodología ágil, presenta muchos valores que deben estar presentes en un sitio, Sim embargo Brito et al., (2015) manifiesta que no se trata de tenerlos en memoria, sino de ser consciente de cada uno de ellos y así poder verificar su cumplimiento. La Mejora continua con la identificación de puntos de mejorar y aplicarlos hacia un futuro, la calidad como mecanismo innegociable, responsabilidad que se comparte y que todos los miembros del equipo deben tener, la multidisciplina en los desarrolladores al punto que se desenvuelvan eficientemente en cualquier área de trabajo, el compromiso por lo acordado, el respeto para tener mejor las relaciones personales entre cada integrante, el coraje de tomar decisiones complejas ante cualquier situación y las personas como centro de atención. 3.2.1.1.2.3.3 Etapas del proceso Scrum. Según Álvarez et al., (2012) manifiesta que el proceso Scrum se divide en dos etapas: el Sprint 0, o las siguientes iteraciones o Sprints detalladas a continuación: Sprint 0: tiene como objetivo establecer las condiciones que permita llegar al alcance del proyecto, es decir todos los recursos, personas y herramientas que permitan elaborarlo, como segundo objetivo tiene definir el contenido del proyecto, realizando la primera versión del Product Backlog en el que está contenido la lista del labores y tareas que se realizaran en el desarrollo del proyecto. Sprints: son iteraciones que siguen reuniones concretas que duran de 1 a 4 semanas, las mismas que aseguran es su totalidad las responsabilidades del trabajo y del Product Owner, el alcance de cada sprint está determinado por los objetivos que establecidos por el Product Owner, las preferencias de las tareas en el Product Backlog y el cumplimiento de equipo de trabajo, sin embargo, un Sprint está definido por tres etapas: Sprint Planning: se divide en dos etapas, la primera en la que el product Owner examina cada historia priorizada del Product Backlog, las menciona, puntualiza los parámetros

de aceptación que las validaran y atiende preguntas, de acuerdo a esto el equipo estima las historias lo que ayuda al alcance el proyecto, al llegar al número apto de historias para completar el Sprint, el equipo divide esas historias en tareas manejables, las historias junto con las tareas que se desprende de ellas conforman el Sprint Backlog. Daily Meeting: es una reunión diaria que participan los miembros del equipo y el Scrum Master, en la que cada integrante especificará cada tarea realizada, que en un futuro tomará y las complejidades que no le permitan realizar bien su trabajo. Por la general estas reuniones son breves y buscan tomar el control de trabajo y encontrar problemas a tiempo para solucionarlos. Review: es una reunión que la integran, el Scrum Master, el equipo, el Product Owner, y los stakeholders, en la que se revisa el trabajo atreves de resultados, que tanto el Product Owner y los stakeholders decidirán si han cumplido con los objetivos propuestos en los criterios de aceptación. Retroespectiva: se enfoca en analizar el trabajo de forma crítica, detallando las debilidades, fortalezas del equipo e identificando la forma de corregirlos, un punto que se toma a consideración es la valoración de la velocidad del grupo de trabajo encargada por el Scrum Master, con la finalidad de obtener un indicador de mejora o humillación del proceso del desarrollo del trabajo realizada por el equipo.

Figura 2. Ciclo de aplicación y valores de Scrum. Adaptado de “Métodos Ágiles y Scrum”, A. Álvarez, R. de las Heras, & C. Lasa, 2012, Madrid: Anaya, p. 86.

3.2.1.1.2.3.4 ¿Por qué utilizar Scrum para desarrollar aplicaciones web? Scrum es un proceso que se lo aplica de forma regular siendo así un conjunto de mejoras prácticas para trabajar en grupo y obtener los mejores resultados, esta metodología también trabaja con requisitos inestables y que demandan rapidez y flexibilidad. Presenta ventajas como en la entrega del producto, existe la posibilidad de ajustar la funcionalidad, la visualización del proyecto es diaria y su alcance es acotado y viable. Según Brito et al., (2015) expresa que XP es útil en proyectos de software a corto tiempo, a su vez no resultaría que fuese más cómodo que el tradicional, se tiene que tener en cuenta que los usuarios no siempre necesitan de pequeños releases haciendo que se obtenga un justo y adecuado ajuste a los principios XP. 3.2.1.1.3 Modelado. 3.2.1.1.3.1 Patrón modelo vista controlador. El patrón Modelo Vista Controlador es una separación de los objetos que componen la abstracción del mundo real de la aplicación. Flórez (2012) describe al patrón (MVC) como un modelo para las tres interfaces graficas que el usuario separa a la aplicación, una de ellas es el modelo el mismo que abarca la arquitectura de los datos que tienen el estado del software, vista es la parte gráfica, es decir la forma de como se muestra la información al usuario de la aplicación y por último el controlador, como su nombre lo indica son los controles que los usuarios de la aplicación utilizan en la parte gráfica.

Figura 3. Modelo Vista Controlador. Adaptado de Flórez, H. (2012). “Programación Orientada a Objetos Usando Java”. Bogotá: Ecoe Ediciones, p. 314.

3.2.1.2. Base de datos. Al momento que una empresa requiere implementar un sistema informático, el equipo de análisis y diseño toma a consideración las especificaciones y necesidades de la empresa, en la que se pretende almacenar sin números de archivos, los mismos que a veces quedan aislados unos de otros, es por esto que es necesario la creación de una base de datos que es un grupo de información estructurada que están establecidos por procesos específicos, evitando la redundancia y que se guardara en algún medio de almacenamiento extensivo (Reinosa, Maldonado, Muñoz, Damiano & Abrutsky, 2012). 3.2.1.2.1 Lenguaje SQL. Los lenguajes SQL o Lenguajes de Consulta Estructurada, como comúnmente se los conoce, son lenguajes estándar específicamente de consulta, los mismos que permite definir, manipular y llegar a un control total de las bases de datos relacionales, estos lenguajes disponen de ciertos elementos que lo conforman como las instrucciones, restricciones, operadores y las debidas funciones, que pueden ser combinados al a crear, actualizar y manipular las bases de datos (Gómez, Villar & Alcayde, 2011). 3.2.1.2.2 Diagrama entidad relación. El modelo de Datos Entidad-Relación se desenvolvió para ayudar y mejorar el diseño de las bases de datos logrando obtener la especificación del bosquejo de cualquier empresa constituyéndose de forma lógica y global de toda la base de datos, además de esto, este modelo permite corresponder los conceptos y las debidas interacciones que las empresas poseen en la realidad con el esquema conceptual, es por esto que existen varias herramientas para el modelado de las base de datos se fundamentan en este modelo Entidad-Relación (Silberschatz, Korth y Sudarshan, 2011). 3.2.1.2.2.1 MySQL Workbench. MySQL Workbench es una aplicación de trabajo visual que utilizan los constructores de las bases de datos, así como los programadores y administradores, brinda la posibilidad de realizar el modelado de datos, trabajar con lenguajes de consulta estructurada, además cuenta con equipos de gerencia para la configuración del servidor, otro beneficio de esta aplicación es que está disponible para trabajar con Windows, Linux y Mac OS X (MySQL, 2017).

3.2.1.2.3 Sistemas gestores de bases de datos. Se denomina Sistema Gestor de Base de Datos al grupo de aplicaciones informáticas que interactúan de cierto modo con un grupo de programas aglomerados, siendo una herramienta de software que se dispone a controlar todos los permisos para entrar a una base de datos, es aplicable a diferentes fines, como gestión de clientes de un supermercado, en una institución educativa, un sistema bancario, etc. Implementan instrucciones establecidas por los diferentes usuarios siendo estas de lenguaje de definición de datos, manipulación de datos y control de los mismos (Reinosa et al., 2012) 3.2.1.2.3.1 MaríaDB. MaríaDB es un Sistema Gestor de Base de Datos que no se encuentra amparado bajo alguna licencia, preservando el uso de algunos derechos de autor, en pocas palabras es opensource. Tiene sus inicios al ser desarrollada por los mismos que fundaron MySQL, pensado y creado con la finalidad de sustituir a MySQL que hoy en día es de Oracle, sim embargo tiene la capacidad de ser compatible con su antecesor, en vista que pose ciertas características que lo hacen semejantes como su organización, interfaz, las diferentes bibliotecas que posee, etc., otra característica especial de MaríaDB es qué proporciona facilidades al momento de cambiar de un servidor directamente a otro, en si es un SGBD muy variable al usarlo (MaríaDB, 2017). 3.2.1.2.3.2 PostgreSQL. Es un Sistema Gestor de Base de Datos Relacional, en la actualidad es el más avanzado debido su gran crecimiento que ha pasado de ser una base de datos relacional a ser hibrida, es decir su enfoque es relacional y objetos lo que le hacen diferentes a otros SGBD, además presenta características con en la que varios usuarios pueden utilizarla simultáneamente, y puede ejecutarse en diferentes sistemas operativos. Resulta favorable al tratar con una herramienta de mapeo de objeto relacional (ORM). Además, incluye herencia de tablas, un sistema de reglas y eventos de base de datos, es compatible con el almacenamiento de objetos grandes binarios, incluyendo imágenes, sonidos o video (Martínez, 2015).

3.2.1.3. Aplicativos webs. 3.2.1.3.1 Ingeniería web. Es ya una tradición y una buena práctica el aplicar metodologías en el desarrollo de software, debido a que se basa en los principios de la ingeniería. La Ingeniería Web surge para ayudar a desarrollar software y así evitar fracasar en el intento, además de aplicar otras características como el enfoque sistémico, lo que nos permitirá desplegar y dar mantenimiento al software basándose en los principios de calidad (Hincapié & Duitama, 2012). 3.2.1.3.1.1 Aplicaciones web. Podríamos definir a una aplicación web como una extensión dinámica de un servidor de aplicaciones web, a esto, existen dos tipos de generalidades sobre ellas, las de tipo que se enfocan en la presentación, las cuales están compuestas de páginas web interactivas en lenguajes de marcado de texto como HTML, XML, etc., y de contenido dinámico a las peticiones que generan los clientes, por otro lado están las aplicaciones web que se enfocan al servicio, que es la parte final de un servicio web brindado (Roldan, Valderas & Pastor, 2010) 3.2.1.3.1.2 Arquitectura Cliente/Servidor. La arquitectura Cliente-Servidor actualmente es el modelo que más se utiliza en el desarrollo de software para aplicaciones web, presenta una característica en particular como la división en capas en donde la capa que va de lado del cliente solicita todo tipo de información o servicios que necesite y así, la capa servidor al recibir estas peticiones envía la respuesta correspondiente al cliente (Cusik, 2013). 3.2.1.3.2 Aplicaciones web dinámicas. Las aplicaciones web dinámicas se identifican por su enfoque interactivo con los usuarios finales, es decir es una página web en donde existen elementos que permiten una comunicación rápida entre la aplicación y el usuario, logrando que el contenido que se muestra al usuario sea a partir de lo que él solicite en la página web, pueden hacer peticiones de correo, introducción de contenido en formularios, etc. (Zofío, 2013).

3.2.1.4. Herramientas de desarrollo web. 3.2.1.4.1 Editores de texto. 3.2.1.4.1.1 SublimeText3. Sublime Text es un elegante editor de contenido para código, se lo puede acceder de forma gratuita en su página, algunas de sus características principales es que posee un amplio despliegue de documentación y soporte por parte del equipo de desarrollador, al momento de usar información de definiciones de sintaxis, SublimeText3 genera automáticamente un índice de todo el proyecto de cada clase, método y función, por si fuera poco en él es posible realizar diez cambios al mismo tiempo, no un cambio diez veces. Las selecciones múltiples le permiten cambiar de forma interactiva muchas líneas a la vez, cambiar el nombre de las variables con facilidad y manipular los archivos más rápido que nunca (Sublime Text, 2017). 3.2.1.4.1.2 NotePad++. Notepad++ es un editor de texto y de código fuente de acceso libre escrito en C++ y remplazo de Bloc de notas que admite varios idiomas, funcionando en el entorno de MS Windows, su uso se rige por la licencia GPL, utiliza API Win32 pura y STL que asegura una mayor velocidad de ejecución y un tamaño de programa más pequeño. Al optimizar tantas rutinas como sea posible sin perder la facilidad de uso (NotePad++, 2017). 3.2.1.4.2 Lenguajes de programación. 3.2.1.4.2.1 FrontEnd. 3.2.1.4.2.1.1 HTML5 y CSS. HTML5 es la última versión mejorada del lenguaje original HTML, reúne un grupo de etiquetas que brindan un nuevo concepto semántico a la web, posee mejoras al trabajar con formularios ya que estos vienen con nuevas funcionalidades y controles, algo característico de esta versión es que viene incorporado para tolerar audio y video a diferencia de las versiones anteriores en las que se necesitaba instalar complementos para que esto funcione, además cabe recalcar algo importante en esta versión es que su sintaxis ya no es tan robusta y estricta (Rubiales, 2013).

Por otra parte tenemos a las Hojas de Estilo en Cascada (CSS), que vienen siendo la forma en como emplear estilo al contenido en las páginas web, de manera que pone aparte la forma en que se observa el contenido (el diseño), de las líneas de código que forma a la página web y que hace que cualquier buscador web la represente (su estructura), en sí con las hojas de estilo es posible aplicar efectos a todo el contenido, como tablas, hiperenlaces, formularios, etc., obteniendo páginas web más accesibles y asombrosas (Peña, 2010). 3.2.1.4.2.1.2 JavaScript. Es un lenguaje de programación interpretado, lo que permite que no haya necesidad de llegar a compilarlo antes de su ejecución, es decir que se ejecuta en un navegador, se define como orientado a objetos ya que posee funciones de primera clase. De acuerdo con Rubiales (2013) JavaScript no solo está establecido en el mundo del desarrollo web, sino que hoy en día coexisten sin número de aplicaciones de escritorio y proyectos importantes que usan JavaScript para desarrollar ciertas funcionalidades. 3.2.1.4.2.2 BackEnd. 3.2.1.4.2.2.1 PHP. Es un lenguaje interpretado que va de mano con el servidor permitiendo la construcción de páginas web dinámicas, hoy en día es el más utilizado y extendido por su topología por ser simple y tener un gran potencial en el diseño web, SQL y PHP nos brindan la oportunidad de escribir menos líneas, aunque con mayor costo en el procesamiento, el código HTML que será ejecutado en el servidor, Gómez et al., (2010) expresa que uno de sus puntos fuertes en la inclusión de un gran número de funciones para la explotación de base de datos, junto a SQL, de una forma sencilla. 3.2.1.4.3 Framework. 3.2.1.4.3.1 Responsive web design. Conforme el acceso a Internet se va extendiendo, crece de forma paralela la cantidad de dispositivos que tienen acceso a la Web, por lo cual existe una gran demanda de contenido web que sea adaptable al dispositivo desde donde se accede, sean estos ordenadores de mesa, laptops, smartphones, tablets, entre otros. De este modo, la forma tradicional de desarrollar y diseñar aplicaciones web resulta poco atractivo.

Implementando diseños adaptativos en nuestros proyectos, estamos asegurando que estos serán capaces de ejecutarse desde cualquier dispositivo capaz de ejecutar un navegador web. Pero esto a su vez, de una u otra manera hace compleja la tarea del desarrollador, así como lo señala acertadamente Gardner (2011), conforme aumentan los dispositivos capaces de acceder a Internet, el comportamiento y actitud del usuario resulta cada vez más difícil de predecir, además, el trabajar sobre un tamaño fijo de pantalla conlleva problemas a futuro. Ciertas técnicas, como por ejemplo el correcto empleo de CSS3 permiten habilitar efectos visuales agradables al usuario. 3.2.1.4.3.2 Framework de diseño. 3.2.1.4.3.2.1 Bootstrap. Bootstrap actualmente el framework más popular para la construcción y diseño de aplicaciones web, permite desarrollar en HTML5, JS y CSS, facilita y logra el desarrollo de proyectos receptivos y de primer nivel en dispositivos móviles en la web. En su página web oficial brinda la documentación necesaria para el equipo o desarrollador que vaya a trabajar con él, además es posible hacer un prototipo rápido con nuestras ideas y a su vez crear una aplicación completa con variables Sass, mixins, sistema de cuadrícula sensible, componentes pre compilados extensos y potentes complementos basados en jQuery que este framework presenta. (Bootstrap, 2017). 3.2.2. Gestión Educativa. 3.2.2.1. Funciones de la educación. En la actualidad no existe un modo de clasificar a la educación de acuerdo a sus funciones. Sin embargo, Gómez (2000) define a las funciones de dos formas: Las funciones individuales que se basan directamente en la persona del educando, y los beneficios que resulta la educación individual es el aumento del ingreso laboral, espacio social, y la debida capacidad de tomar decisiones propias. Sin embargo, existe un aspecto importan en esta funcionalidad y esta es la función de lograr entrenar para la ciencia y la tecnología enfocándose con los papeles de la inteligencia. Las funciones sociales que son de carácter indirecto, se basan del saber y la mejora continua de los individuos con la sociedad.

3.2.2.2. Educación y Sistema Educativo. La educación sucede adentro de la escuela, no obstante, en las sociedades actuales, la escuela y el sistema educativo es el único encargado de compartir el conocimiento y acercar a la persona a futuros roles, por otra parte, el sistema educativo estrictamente tiene como característica de ser un instrumento eficaz de manera dispareja para cumplir con las diferentes funciones de la educación que se vio en el apartado anterior (Gómez, 2000). 3.2.2.3. Cambio en la educación con las nuevas tecnologías. Las tecnologías de la información y de la comunicación son de mucha ayuda en los escenarios educativos, ya que brindan facilidades en el acceso y manejo de la información, además es necesario tener en cuenta tanto la cantidad y calidad, por otra parte la vía o canal tecnológico/digital por el cual la información es tratada brinda ciertas especificaciones como ser entornos de comunicación más ricos, activa la comunicación síncrona y asíncrona, establece modelos visuales que presente la información en general, etc., (Amar, 2008). 3.2.2.4. Modalidades del sistema nacional de educación. Según la Ley Orgánica De Educación Intercultural (2017) el Sistema Nacional de Educación en el Ecuador presenta tres modalidades como se presenta a continuación: Presencial: esta modalidad está manejada por el acatamiento de medidas de asistencia regular a la institución educativa, basada en parámetros como la edad, sucesión de niveles, los grados y cursos pertinentes. Semipresencial: esta modalidad se encuentra establecida por no obligar asistir a los estudiantes a la institución educativa, requiere de trabajo autónomo por parte del estudiante por diferentes medios de comunicación, hay que tener en cuenta que esta modalidad aplica a personas con 15 años en adelante. A Distancia: esta modalidad solo aplica a personas con mayoría de edad, proponiendo así un proceso autónomo en el aprendizaje, sin la presencia del estudiante a clases para la completar el currículo nacional de educación, es importante tener en cuenta que esta modalidad debe cumplir con los mismos estándares de la modalidad presencial.

3.2.2.5. Funciones y características de las personas que intervienen en el sistema educativo. Según la Ley Orgánica De Educación Intercultural (2017) existen diferentes personas cada una de ellas con funciones distintas y únicas que intervienen en el proceso educativo a continuación se presentan los más relevantes: Rector: tiene como función principal cumplir los objetivos del Sistema Nacional de Educación, las normativas educativas, las obligaciones y derechos de las personas en la institución educativa, la administra y controla los recursos de la misma. Vicerrector: es el encargado de liderar el proceso y la ejecución de proyectos en la institución, además dirige las diferentes áreas y controla el trabajo de los docentes. Docente tutor de curso: es la persona que se asigna al inicio del año, convirtiéndose en el medio de comunicación entre la institución y los representantes de los estudiantes, además coordina todo tipo de actividades que se realizaran en año lectivo. Secretaría: es la persona encargada de llevar los registros oficiales y poner su responsabilidad ante ellos, ingresa con precisión la información académica y brinda todo tipo de documentos siempre y cuando el rector u vicerrector les autorice.

3.3. Comparativas entre Metodologías Ágiles La comparativa se realizó entre las metodologías Extreme Programming (XP) y el marco de trabajo Scrum. Para realizar la calificación de las características, se tomó en cuenta los siguientes parámetros de calificación: 

Si la metodología cumple con el 100% de las características escogidas para el trabajo de titulación, se asignó: 5 puntos.



Si la metodología cumple con al menos el 50% de las características escogidas para el trabajo de titulación, se asignó: 2.5 puntos.



Si la metodología no cumple con ninguna característica escogida para el trabajo de titulación, se asignó: 0 puntos.

En la actualidad no solo se busca una metodología ágil que permita el éxito de un proyecto de software, sino que también se adapte a ciertas particularidades con las que se desea trabajar en el trabajo de titulación. A continuación, se detallan las características que se compararse: 

Comunicación. - la forma en cómo se comunica el equipo desarrollo para tener buenos resultados en el desarrollo del proyecto.



Simplicidad. - simplificación de procesos, código y cualquier aspecto que afecte al trabajo.



Programación en Parejas. - trabajo en equipo entre dos personas que desarrollan el proyecto.



Mejora continua. - corregir y perfeccionar el trabajo que se está llevando en la actualidad y en un futuro.



Respeto. - valor que genera productividad en el desarrollo de un proyecto.

Tabla 1. Comparación de metodologías ágiles: Scrum, XP Características Scrum Comunicación 2.5 Simplicidad 5 Programación en parejas 5 Mejora Continua 5 Respeto 5 Total: 22.5/25 Porcentaje: 90%

Xtreme Programming (XP) 5 2.5 5 2.5 5 20/25 80%

Nota: Adaptado de “Métodos Ágiles y Scrum” por Álvarez, A., De las Heras, R. y Lasa, C. (2012). Madrid, España: Anaya Multimedia.

Una vez evaluada y realizada la respectiva comparativa de las características que se establecieron de acuerdo al proyecto, se tomó la decisión de utilizar el marco de trabajo Scrum debido que se obtuvo un 90%, a diferencia de XP con un 80%.

3.4. Comparativas entre Sistemas Gestores de Base de Datos La comparativa se realizó entre los siguientes sistemas gestores de base de datos: MaríaDB y PostgreSQL.

Para realizar la calificación de las características, se tomó en cuenta los siguientes parámetros de calificación: 

Si el gestor de base de datos cumple con el 100% de las características escogidas para el trabajo de titulación, se asignó: 5 puntos.



Si el gestor de base de datos cumple con al menos el 50% de las características escogidas para el trabajo de titulación, se asignó: 2.5 puntos.



Si el gestor de base de datos no cumple con ninguna característica escogida para el trabajo de titulación, se asignó: 0 puntos.

A continuación, se detallan las características a evaluarse sobre los sistemas gestores de base de datos: 

Consultas no predefinidas y complejas. - hacer consultas de cualquier tipo y complejidad directamente al SGBD. Por lo tanto, el SGBD tendrá que responder inmediatamente sin que estas consultas estén preestablecidas; es decir, sin que se tenga que escribir, compilar y ejecutar un programa específico para cada consulta.



Flexibilidad e independencia. - obtener la máxima independencia posible entre los datos y los procesos usuarios para que se pueda llevar a cabo todo tipo de cambios tecnológicos y variaciones en la descripción de la base de datos, sin que se deban modificar los programas de aplicación ya escritos ni cambiar la forma de escribir las consultas (o actualizaciones) directas.



Prevención a problemas de redundancia. – eludir riesgo de inconsistencia o incoherencia de los datos; es decir, la pérdida de integridad que las actualizaciones pueden provocar cuando existe redundancia.



Integridad de los datos. – para mantener calidad de los datos, cuando el SGBD detecte que un programa quiere hacer una operación que va contra las reglas establecidas al definir la base de datos, no se lo deberá permitir, y le tendrá que devolver un estado de error.



Concurrencia de usuarios. - permitir que varios usuarios puedan acceder concurrentemente a la misma base de datos.



Seguridad. - definir autorizaciones o derechos de acceso a diferentes niveles: al nivel global de toda la BD, al nivel entidad y al nivel atributo.

Tabla 2. Comparación de sistemas gestores de base de datos: MaríaDB y PostgreSQL Características MaríaDB PostgreSQL Consultas no predefinidas y complejas 5 5 Flexibilidad e independencia 2.5 5 Prevención a problemas de redundancia 5 5 Integridad de los datos 2.5 5 Concurrencia de usuarios 2.5 5 Seguridad 2.5 5 Total: 20/30 30/30 Porcentaje: 66.67% 100% Nota: Adaptado de “Base de Datos” por Camps, R., (2005). Obtenido de http://www.uoc.edu/masters/oficiales/img/913.pdf

Una vez evaluada y realizada la respectiva comparativa de las características que se establecieron de acuerdo al proyecto, se tomó la decisión de utilizar el sistema gestor de base de datos PostgreSQL debido a que se obtuvo un 100%, a diferencia de MaríaDB con un 66.67%.

3.5. Comparativa de Lenguajes de Programación La comparativa se realizó entre los lenguajes: PHP, Python y Ruby. Para realizar la calificación de las características, se tomó en cuenta los siguientes parámetros de calificación: 

Si el lenguaje de programación cumple con el 100% de las características escogidas para el trabajo de titulación, se asignó: 5 puntos.



Si el lenguaje de programación cumple con al menos el 50% de las características escogidas para el trabajo de titulación, se asignó: 2.5 puntos.



Si el lenguaje de programación no cumple con ninguna característica escogida para el trabajo de titulación, se asignó: 0 puntos. En la actualidad existen varios lenguajes programación, cada uno con características

diferentes, sin embargo, existen medidas por los cuales se pueden evaluar de manera conjunta y así, poder seleccionar cual es el mejor según sus características para llegar al éxito de un

proyecto. A continuación, se detallan las características a evaluarse sobre los lenguajes de programación: 

Informes de errores. - posee una constante información de errores predestinados para organizar un aviso de falla o advertencia.



Rapidez en expresiones de script. agilidad para expresiones de scripting que son compuestas en funciones, campos y operadores, combinados en una sintaxis.



Integración con entornos web. - conformidad para trabajar con un ambiente de desarrollo, ejecución de programas o servicios en el marco de la web en general.



Incorporación de controladores para abstracción de acceso a datos. – oportunidad de activación de extensiones en la capa de abstracción para acceder a datos con distintos sistemas gestores de bases de datos.

Tabla 3. Comparativa entre los lenguajes de programación: PHP, Python, Ruby Características PHP Python Informes de errores 5 5 Rapidez en expresiones 5 5 de script Integración con 5 2.5 entornos web Incorporación de 5 2.5 controladores para abstracción de acceso a datos Total: 20/20 15/20 Porcentaje: 100% 75%

Ruby 2.5 5 2.5 2.5

12.5/20 62.5%

Nota: Adaptado de “PHP vs. Python vs. Ruby – The web scripting language shootout” por Purer, K.. Compilers and Languages Group.

Una vez evaluada y realizada la respectiva comparativa de las características que se establecieron de acuerdo al proyecto, se tomó la decisión de utilizar el lenguaje de programación PHP debido que se obtuvo un 100%, a diferencia de Python con un 75% y Ruby con un 62.5%.

4. METODOLOGÍA DE INVESTIGACIÓN 4.1. Diseño/Tipo de Investigación 4.1.1. Enfoque de la Investigación. El presente trabajo de disertación posee un enfoque mixto, por el motivo de la problemática expuesta anteriormente. Los métodos mixtos de acuerdo con Hernández, Fernández & Baptista (2010), son la agrupación de procesos metódicos y experimentales en donde se recolecta y analiza tanto datos cuantitativos como cualitativos. Conforme a ello, se emplea el método cuantitativo al emplear encuestas para la recolección de información que arrojaran resultados cuantificables acerca de la productividad de la institución educativa. Además, se aplicará el enfoque cualitativo que permitirá profundizar el estudio y tener una idea general del funcionamiento de la unidad educativa en estudio mediante la aplicación de una entrevista al rector de la misma. 4.1.2. Diseño de la Investigación. El diseño de investigación que se ha elegido para el desarrollo de la investigación, es el diseño no experimental, teniendo como objeto o motivación de uso el no realizar manipulaciones con las variables, sino un estudio de las mismas como tal, además, dentro de este diseño, se usará el tipo transversal por lo que la información que se recabe se lo hará en un solo momento la que servirá de base para el desarrollo del presente documento. 4.1.3. Tipo de Investigación. Para el desarrollo del estudio del presente proyecto se hará uso de diferentes tipos de investigación como investigación descriptiva, aplicada y de campo. 4.1.3.1. Investigación descriptiva. La investigación descriptiva brinda la posibilidad de especificar las características y propiedades más relevantes del objeto de estudio que se esté sometiendo al análisis recolectando información sobre las variables, mas no especifica cómo se relacionan estas (Hernández et al., 2010). De este modo se agrupa de forma global las causas y consecuencias que generan la problemática en la empresa. Las características se detallan por medio de encuestas y entrevistas que servirán para la recolección de información.

4.1.3.2. InvestigaciĂłn aplicada. La investigaciĂłn aplicada permitirĂĄ hacer uso de los conocimientos adquiridos durante el proceso de formaciĂłn profesional y posteriormente plasmarlos en la elaboraciĂłn del sistema el cual permitirĂĄ mejorar la interacciĂłn entre los padres de familia y docentes de la instituciĂłn. 4.1.3.3. InvestigaciĂłn de campo. AquĂ se procederĂĄ a asistir a la unidad educativa para recopilar datos directamente de las personas que entienden sobre el funcionamiento y operatividad en la instituciĂłn que son: la secretaria y el rector. Esto, a travĂŠs de una temĂĄtica estructurada se enfatizarĂĄ en conocer los datos mĂĄs relevantes del funcionamiento de los procesos emitidos en la instituciĂłn y de esta manera dirigir el desarrollo de nuestro proyecto de investigaciĂłn.

4.2. PoblaciĂłn/Universo SegĂşn HernĂĄndez et al., (2010) la poblaciĂłn o universo es el grupo de todas las personas que coinciden en ciertas caracterĂsticas, por lo que, para evitar errores en ella el primer paso es delimitarla correctamente. La poblaciĂłn que se toma en cuenta en el presente trabajo de disertaciĂłn compete a los representantes, personal docente y personal administrativo de la Unidad Educativa â&#x20AC;&#x153;Iberoamericanoâ&#x20AC;? ubicada en Santo Domingo, la cual estĂĄ compuesta de 560 representantes, 25 docentes y 5 de personal administrativo, dando una suma total en poblaciĂłn de 590 personas.

4.3. Muestra SegĂşn HernĂĄndez et al., (2010) la muestra es un subconjunto de la poblaciĂłn con la que se trabajarĂĄ y sobre la cual se procederĂĄ a extraer los datos, para ser definida con exactitud. Considerando lo anteriormente mencionado, se procede a aplicar el mĂŠtodo de muestreo aleatorio simple con la fĂłrmula:

đ?&#x2019;?=

đ?&#x2019; Â˛đ?&#x2018;ˇđ?&#x2018;¸đ?&#x2018;ľ đ?&#x2019; đ?&#x;? đ?&#x2018;ˇđ?&#x2018;¸ + đ?&#x2018;ľđ?&#x2019;&#x2020;Â˛

Donde: n = muestra

Q = probabilidad de no ocurrencia = 0.5

P = probabilidad de ocurrencia = 0.5

e = nivel de significaciĂłn = 0.05

Z = nivel de confianza 95% = 1.96

N = poblaciĂłn = 590

Reemplazando los valores en las variables de la fĂłrmula se obtiene:

đ?&#x2019;?=

(đ?&#x;?. đ?&#x;&#x2014;đ?&#x;&#x201D;)đ?&#x;? (đ?&#x;&#x17D;. đ?&#x;&#x201C;)(đ?&#x;&#x17D;. đ?&#x;&#x201C;)(đ?&#x;&#x201C;đ?&#x;&#x2014;đ?&#x;&#x17D;) (đ?&#x;?. đ?&#x;&#x2014;đ?&#x;&#x201D;)đ?&#x;? (đ?&#x;&#x17D;. đ?&#x;&#x201C;)(đ?&#x;&#x17D;. đ?&#x;&#x201C;) + (đ?&#x;&#x201C;đ?&#x;&#x2014;đ?&#x;&#x17D;)(đ?&#x;&#x17D;. đ?&#x;&#x17D;đ?&#x;&#x201C;)2 đ?&#x2019;?=

đ?&#x;&#x201C;đ?&#x;&#x201D;đ?&#x;&#x201D;. đ?&#x;&#x201D;đ?&#x;&#x2018;đ?&#x;&#x201D; đ?&#x;?. đ?&#x;&#x2019;đ?&#x;&#x2018;đ?&#x;&#x201C;đ?&#x;&#x2019;

đ?&#x2019;? = đ?&#x;?đ?&#x;&#x2018;đ?&#x;?. đ?&#x;&#x201D;đ?&#x;&#x201D;đ?&#x;&#x201D; â&#x20AC;Ś Aplicada la fĂłrmula para obtener el tamaĂąo de la muestra, se obtuvo como resultado 233 encuestas; estas ayudarĂĄn a recolectar los datos mĂĄs relevantes que permitirĂĄn conocer los principales problemas e inconvenientes de la poblaciĂłn con respecto al desarrollo del sistema web.

4.4. TĂŠcnica e Instrumentos de Recogida de Datos Para el presente trabajo de disertaciĂłn se harĂĄ el uso de tĂŠcnicas como: Encuestas, las cuales abarcarĂĄn preguntas cerradas que ayudarĂĄn a la recolecciĂłn de la informaciĂłn necesaria para el estudio de la problemĂĄtica, las cuales se las realizarĂĄ a los docentes de la instituciĂłn. Entrevista, que se encuentra organizada con preguntas abiertas, por lo tanto, se acudirĂĄ a la instituciĂłn y se le aplicarĂĄ a la persona con mayor conocimiento del proceso de gestiĂłn educativa, en este caso el rector.

4.5. TĂŠcnica de AnĂĄlisis de los Datos Para el anĂĄlisis de los datos recabados por las encuestas se harĂĄ uso de la tĂŠcnica de tabulaciĂłn de datos y por medio de estadĂsticas representar la informaciĂłn plasmĂĄndola grĂĄficamente para su posterior interpretaciĂłn, por otro lado, las entrevistas o reuniones que se realicen con el cliente servirĂĄn para plasmar las funcionalidades del sistema, que serĂĄn representadas a travĂŠs de historias de usuario, propias del marco de trabajo Scrum.

5. RESULTADOS 5.1. Análisis y Discusiones de los Resultados 5.1.1. Análisis situacional de la población para el uso del sistema. 5.1.1.1. Entrevista con el rector de la unidad educativa particular Iberoamericano, para conocer los procesos con el manejo de información de la institución. En la determinación de los procesos que lleva la institución respecto a la información de los estudiantes, se efectuó una entrevista con el rector de la UEPI para percatarse de los procesos con las siguientes preguntas: 1. ¿Cuáles son los procesos que se deben automatizar dentro de la UEPI? Se obtuvo la información de que, los procesos más destacados en automatizar son los siguientes: 

Ingreso de periodos académicos



Ingreso de alumnos



Ingreso de docentes



Ingreso de materias, cursos



Ingreso de calificaciones



Ingreso de inasistencias



Habilitación de calificación y recalificaciones



Generar reportes de alumnos



Asociaciones de materias a los alumnos y docentes



Justificaciones de inasistencias

2. ¿Cómo se acostumbra a llevar la información anteriormente mencionada? Se comprendió en la entrevista, que pocos procesos esenciales se llevan con el uso de ficheros en Microsoft Excel para la mayoría de los procesos se manejan de manera manual, para el conocimiento de las calificaciones de los alumnos aún permanecen el uso de los boletines de notas, mismos que son entregados a cada representante del alumno.

3. ¿Cuántas y cuáles personas están encomendadas para llevar los procesos anteriormente mencionados? La mayoría de los procesos son encargados a la secretaria de la institución como: ingreso de calificaciones e ingreso de docentes, cabe resaltar que estos procedimientos lo realizan de forma manual. 4. ¿Considera la necesidad de automatizar los procesos de la UEPI? En concreto la respuesta por parte del entrevistado fue positiva, añadiendo énfasis para ofrecer información necesaria y clara para el desarrollo del sistema, con esto se logrará obtener una planificación correcta en la metodología de desarrollo de software. Discusión de la entrevista: Con los temas tratados con el entrevistado se conoció que la mayoría de los procesos son manejados de manera manual, por esta razón es necesario la automatización de los mismos para agilitar el manejo de información en la institución, y de este modo minorar el uso de recursos. A continuación, se presenta el diagrama de procesos Diagrama de Procesos.

Figura 4. Diagrama de procesos de registro de notas.

Figura 5. Diagrama de procesos de control de asistencia.

5.1.1.2. Encuesta con los docentes, secretaria y representantes de la Unidad Educativa Particular Iberoamericano. Obtenida la información por parte del rector de la institución, se comprendió que, en el uso del sistema, también intervendrán personal docente y administrativo, por lo que se procedió a realizar una encuesta a la secretaria, profesores y representantes de los alumnos de la institución. Pregunta #1 ¿Cómo considera sus conocimientos sobre el uso de Internet? Tabla 4. Conocimientos sobre el uso del internet Opción

Frecuencia

Porcentaje

Alto

100

43%

Medio

130

56%

Bajo

Total

233

100%

Nota: Datos obtenidos de la investigación de campo.

PREGUNTA 1 60%

56%

50% 43% 40% 30%

20% 10% 1% 0% PORCENTAJE

Alto 43%

Medio 56%

Bajo 1%

Figura 6. Conocimientos sobre el uso del internet. Adaptado de los datos obtenidos en la investigación de campo.

Análisis: Los resultados que se obtuvieron mediante la tabulación de la primera pregunta fueron los siguientes: al 1% las personas que tienen escaso conocimiento sobre el uso del internet; por otro lado, el 43% tienen un conocimiento alto sobre el uso del internet, y por último el 56%, tiene un conocimiento medio en cuanto al uso del internet. Estos resultados reflejan que se debe tener en cuenta, que no todas las personas dominan los beneficios del uso del internet, razón por la cual se debe capacitar al 1% de las personas encuestadas. Pregunta #2 ¿En qué lugares usted tiene acceso a internet? Tabla 5. Acceso al internet Opción

Frecuencia

Porcentaje

Institución

8,58%

Casa

200

85,84%

Centro de cómputo

5,58%

Total

233

100%

Nota: Datos obtenidos de la investigación de campo.

Pregunta 2 100,00%

85,84%

90,00% 80,00% 70,00% 60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00% PORCENTAJE

8,58%

5,58%

Institucion 8,58%

Casa 85,84%

Centro de cómputo 5,58%

Figura 7. Acceso al internet. Adaptado de los datos obtenidos en la investigación de campo.

Análisis: Los resultados que se obtuvieron mediante la tabulación de la segunda pregunta fueron los siguientes: el 5,58%, acceden a internet mediante algún centro de cómputo de su preferencia; por otro lado, el 8,58%, lo hacen desde la institución y por último se logró evidenciar que el 85,84%, acceden a internet desde su casa, lo que indica que los docentes puedan subir las calificaciones y asistencias desde la comodidad de su hogar, además que los representantes puedan visualizar los reportes de notas desde el domicilio. Pregunta #3 ¿Cree usted que es necesario implementar un sistema online (en internet), que ayude a mejorar la forma del ingreso de notas y control de la asistencia por parte de los docentes y la visualización de calificaciones de los estudiantes por parte de los representantes? Tabla 6. Necesidad de implementar un sistema online Opción Frecuencia

Porcentaje

230

99%

233

100%

Total

Nota: Datos obtenidos de la investigación de campo.

Pregunta 3 100%

99%

90% 80% 70% 60% 50% 40% 30% 20% 10% 0% PORCENTAJE

1% Si 99%

No 1%

Figura 8. Necesidad de implementar un sistema online. Adaptado de los datos obtenidos en la investigación de campo.

Análisis: Los resultados que se obtuvieron mediante la tabulación de la tercera pregunta fueron los siguientes: el 1%, no se sienten con la necesidad de implementar un sistema online para el registro de notas y control de la asistencia; sin embargo, el 99%, consideran la necesidad de implementarlo. En estos resultados se evidencia, la aceptación de las personas encuestadas hacia la implementación del sistema web para el proceso de registro de notas y control de asistencias en la institución. Pregunta #4 ¿Considera usted que la automatización del proceso de registro de calificaciones y control de asistencia beneficiará a la institución? Tabla 7. Beneficio en la institución por la automatización de procesos Opción Frecuencia Si

210

Porcentaje 90%

10%

Total

233

100%

Nota: Datos obtenidos de la investigación de campo.

Pregunta 4 100%

90%

90% 80% 70% 60% 50% 40% 30% 20%

10%

10% 0% PORCENTAJE

Si 90%

No 10%

Figura 9. Beneficio en la institución por la automatización de procesos. Adaptado de los datos obtenidos en la investigación de campo.

Análisis: Los resultados que se obtuvieron mediante la tabulación de la cuarta pregunta fueron los siguientes: el 10% no piensa que haya algún beneficio al automatizar el proceso de calificaciones y asistencia; sin embargo, existe el 90% que si están de acuerdo con la automatización del proceso de calificaciones y asistencia. Estos resultados reflejan el beneficio de automatizar el proceso de registro de calificaciones y control de asistencia en la institución, debido a que ya no se realizarán estos procesos de forma manual. Pregunta 5 ¿Cree usted, que es más seguro llevar la información de calificaciones, asistencias y reportes de notas en un sistema web, que en hojas de papel? Tabla 8. Seguridad en el almacenamiento de las calificaciones y asistencias Opción Frecuencia

Porcentaje

226

97%

Total

233

100%

Nota: Datos obtenidos de la investigación de campo.

Pregunta 5 100%

97%

90% 80% 70% 60% 50% 40% 30% 20% 10% 0% PORCENTAJE

3% Si 97%

No 3%

Figura 10. Seguridad de llevar la información en un sistema web. Adaptado de datos obtenidos de la investigación de campo.

Análisis: Los resultados que se obtuvieron mediante la tabulación de la quinta y última pregunta fueron los siguientes: El 3% cree que no es seguro llevar los datos en un sistema web, sin embargo, el 97% está de acuerdo de llevar la información de manera online. La seguridad de llevar la información en el sistema web es indispensable motivo el cual en el desarrollo del sistema se tomará en cuenta la integración de métodos de seguridad.

5.2. Propuesta de Intervención Para la propuesta de intervención se realizó una investigación de campo en la cual se obtuvieron los requerimientos funcionales y no funcionales, dentro de lo que cabe en la definición del sistema gestor de base de datos en la comparativa realizada, ver tabla 2. Se estableció a PostgreSQL como el SGBD adecuado, para la definición de lenguajes de programación web, así mismo, se realizó una comparativa entre lenguajes de programación, ver tabla 3. Y se constató que, la opción elegida es PHP. Por último, para la metodología de desarrollo, se estableció a Scrum como la opción conveniente en la comparativa, ver tabla 1.

5.2.1. Fase de desarrollo del sistema web utilizando el marco de trabajo SCRUM. El marco de trabajo está bajo un concepto incremental e iterativo, y está propuesto para dar entregas funcionales mediante el proyecto vaya avanzando, llevando consigo los valores y principios de buenas prácticas del manifiesto ágil. 5.2.1.1. Release planning. Dando como oportunidad al inicio de una primera reunión con los interesados e involucrados, misma que ayuda a la definición de los diferentes roles que llevará cada integrante, fijando las reglas de negocio antes de partir con el desarrollo de los artefactos en el marco de trabajo. 5.2.1.1.1 Definición de Roles. Se fijó bajo un acuerdo mutuo, la asignación de rol de cada persona en el proyecto, para de este modo tener conocimiento qué funcionalidades cumplirá cada uno. Tabla 9. Roles de trabajo bajo Scrum Roles de trabajo bajo scrum Product owner Scrum master Equipo de desarrollo Nota: Datos obtenidos de la investigación de campo.

Nombres Lic. José Núñez. Sr. Byron García. Sr. Bryan Agudelo. Sr. Byron García.

5.2.1.2. Product backlog. Tabla 10. Product Backlog Product

Backlog

Nº Historia

Sprint asignado

Historia

Estimación

Priorida d

Riesgo desarrollo

Escenarios de prueba

Estado

100

MEDIA

DADO la selección correcta del rol y el ingreso de usuario y contraseña CUANDO presiono el botón Ingresar ENTONCES accedo al menú principal. DADO la incorrecta elección del rol, el ingreso y contraseña de cualquier usuario CUANDO presiono el botón de Ingresar ENTONCES saltara un cuadro de dialogo que indicara error al ingreso del sistema.

Completo

Ingreso de perfiles de usuarios

100

MEDIA

DADO el ingreso del nuevo perfil de usuario CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Ingreso Exitoso”. DADO la modificación de un perfil creado CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Actualización Exitosa”.

Completo

Ingreso de usuarios

100

MEDIA

DADO el ingreso de la información general de un nuevo usuario CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Ingreso Exitoso”. DADO la modificación de un usuario creado CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Actualización Exitosa”.DADO la modificación de un rol CUANDO presiono el botón Editar con icono de un “lápiz” ENTONCES aparecerá un cuadro de dialogo que diga “Actualización Exitosa”. DADO la búsqueda de un usuario CUANDO presiono el botón con icono de “búsqueda” ENTONCES Mostrara el usuario a buscar de forma sombreada en la lista de usuarios”.

Completo

41 Tabla 10. (continuación) Product Backlog 4 2 Ingreso de periodo académico

MEDIA

DADO la creación del periodo académico CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Ingreso Exitoso”.

Completo

DADO la modificación del periodo académico CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Actualización Exitosa”. DADO la eliminación de un curso CUANDO presiono los botones de color verde con icono de un “visto” ENTONCES se podrá visualizar que esta encendido o apagado de acuerdo a sus respectivos colores. DADO la habilitación del periodo académico CUANDO presiono el botón de color verde con icono de “visto” ENTONCES se visualizará que el periodo se encuentra habilitado. DADO la deshabilitación del periodo académico CUANDO presiono el botón de color verde con icono de visto ENTONCES se visualizará que el periodo se encuentra deshabilitado. 5

Ingreso del Curso

MEDIA

DADO la creación del curso CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Ingreso Exitoso”. DADO la modificación del curso ingresado CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Actualización Exitosa”. DADO la desactivación de un curso CUANDO presiono el botón de color verde con icono de “visto” ENTONCES se desactivará el curso de la lista del módulo de cursos siempre y cuando se encuentre sin alumnos.

Completo

42 Tabla 10. (continuación) Product Backlog 6 2

Ingreso de docentes

MEDIA

DADO la creación del curso CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Ingreso Exitoso” por tanto el nuevo docente estará en el listado de Usuarios del Módulo Docentes.

Completo

DADO la modificación de un docente ya ingresado CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Actualización Exitosa”. DADO la desactivación de un docente CUANDO presiono el botón rojo con el nombre de un “Desactivar” ENTONCES aparece un cuadro de dialogo que diga “Desactivación Exitosa”. DADO la restauración de contraseña del docente CUANDO presiono el botón azul “Restaurar Contraseña” ENTONCES aparecerá un cuadro de dialogo que diga “Restauración Exitosa”. 7

Ingreso de materias

MEDIA

DADO la creación de la materia una vez ingresado el nombre y el área a que pertenece CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Ingreso Exitoso”. DADO la modificación de la materia ingresada CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Actualización Exitosa”. DADO la eliminación de un curso CUANDO presiono el botón “visto” de color verde ENTONCES aparece un cuadro de dialogo de confirmación que diga Estas Seguro de “Si, Eliminarlo” y se eliminara siempre y cuando no esté asignada a un curso o docente.

Completo

43 Tabla 10. (continuación) Product Backlog 8 3

Asociación materia curso

MEDIA

DADO la vinculación de la selección del curso y el listado de materias CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Vinculación Exitosa”.

Completo

DADO la desvinculación de materia y cursos CUANDO presiono el botón de color verde con icono de un “visto” ENTONCES el botón de color rojo cambiara de color y se procederá la desvinculación siempre y cuando el docente no haya hecho el ingreso de ninguna calificación 9

Asociación docente materia

MEDIA

DADO la vinculación de la selección del docente y el listado de materias CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Vinculación Exitosa”.

Completo

DADO la desvinculación de docente con las materias CUANDO presiono el botón de color verde con icono de un “visto” ENTONCES el botón de color verde cambiara de color y se procederá la desvinculación siempre y cuando el docente no haya hecho el ingreso de ninguna calificación. 10

Ingreso de estudiantes y representantes

MEDIA

DADO la creación del estudiante CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Ingreso Exitoso”. DADO la modificación del estudiante CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Actualización Exitosa” . DADO la desactivación o activación de un estudiante CUANDO presiono el botón de “Estado” en la Vista de Alumnos ENTONCES aparece el estudiante con el botón de estado de color verde como activado y color rojo como desactivado”.

Completo

44 Tabla 10. (continuación) Product Backlog 11 3

Ingreso de calificaciones y asistencia

MEDIA

DADO el ingreso de las notas CUANDO presiono el botón check con icono de un “visto” ENTONCES la nota quedara registrada en la lista de calificaciones del Módulo Docentes.

Completo

DADO el ingreso de la inasistencia CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Registro Exitoso”. DADO la visualización de las notas por parte de los representantes y estudiantes CUANDO presiono el botón LOGIN ENTONCES se direccionará al sitio en donde se encuentre las calificaciones y las asistencias del estudiante. 12

Reporte secretaria

MEDIA

DADO la generación del reporte de las calificaciones CUANDO presiono el botón “Reporte PDF” ENTONCES aparecerá un archivo en formato PDF con la lista de todas las calificaciones de cada estudiante.

Completo

Justificación de la inasistencia

MEDIA

DADO la justificación de la inasistencia en el módulo docente CUANDO presiono el “justificar” ENTONCES aparecerá un cuadro de dialogo que diga ¿Estás Seguro? “Si, Justificar” y a su vez se desactiva el botón anteriormente presionado “Justificar”.

Completo

DADO la generación del reporte de inasistencia CUANDO presiono el botón “Reporte PDF” ENTONCES aparecerá un archivo en formato PDF con la lista de los estudiantes que han faltado, así mismo de las justificaciones que se han realizado. 14

Recalificación

Nota: Versión del Product Backlog. Datos obtenidos de la investigación de campo.

MEDIA

DADO la recalificación CUANDO ingreso a la opción Recalificación presiono el botón GUARDAR ENTONCES las notas quedaran modificadas.

Completo

5.2.1.3. Sprint 1. En la reunión con el Product Owner, con el equipo de desarrollo se asignó la estimación de las historias de usuario, ver ANEXO 1, basándose en la complejidad, por lo que se optó por elegir la métrica puntos de historia, guiándose de la técnica Planning Póker, prevista en escala de Fibonacci. Una vez obtenido con el Product Owner el product backlog, se procedió a la asignación de las tareas de ingeniería de cada una de las historias de usuarios, de esta manera se logró comprender de cuántos Sprint Backlog estaría compuesto el proyecto, llegando a un acuerdo con el equipo de desarrollo de una composición de 4 Sprint Backlogs, cada Sprint realizado tendrá una duración de 4 semanas. 5.2.1.3.1 Sprint backlog 1. Tabla 11. Sprint backlog 1 Sprint asignado

Estimación

Tareas de Ingeniería Maquetación de formularios Asignación de hojas de estilo de la institución Creación de formularios para la asignación de perfiles Creación de modelos para login Codificación del frontend del login Encriptación sha256 para passwords Validación de contraseñas con parámetro de numero de cedula Validación de superusuario Creación de rutas mediante los modelos Creación de controladores Supervisión de escenarios de pruebas

Estimación tarea 4

Estado Completo

Completo

Nota: Versión final del Sprint backlog 1. Datos obtenidos de la investigación de campo.

5.2.1.3.2 Burndown chart 1.

2 2

2 1

2 2

1 6

50 50

05/12/2017

04/12/2017

01/12/2017

Supervisión de escenarios de pruebas Restante Ideal

30/11/2017

29/11/2017

Encriptación sha256 para passwords Validación de contraseñas con parámetro de numero de cedula Validación de superusuario Creación de rutas mediante los modelos Creación de controladores

28/11/2017

27/11/2017

24/11/2017

23/11/2017

22/11/2017

21/11/2017

17/11/2017

16/11/2017

15/11/2017

14/11/2017

13/11/2017

10/11/2017

09/11/2017

08/11/2017

07/11/2017

4 6

20/11/2017

06/11/2017

Estimación

Total, horas

Tabla 12. Burndown chart 1.

49 48

47 46

45 44

43 42

39 38

37 36

34 33

Nota: Versión final del Burndown chart 1 del sprint 1. Datos obtenidos de la investigación de campo.

30 29

28 27

24 23

22 21

19 18

17 16

16 15

14 13

12 11

10 9

8 7

6 5

4 3

3 2

1 0

Grรกfico Burndown Chart 1 50

Figura 11. Burndown chart 1. Figura obtenida del sprint 1. Datos obtenidos de la investigaciรณn de campo.

5.2.1.3.3 Desarrollo de sprint 1. Las historias de usuario correspondientes al Sprint 1 son: login, perfiles de usuarios e ingreso de usuarios, las cuales fueron asignadas en la reunión de negocio con el Product Owner y el equipo de desarrollo, para conseguir así un entregable del sistema funcional. Por consiguiente, se demostrará capturas de pantallas correspondientes a cada historia en el Sprint 1, puesto a que, son los resultados de la aplicación en conjunto de tareas de ingeniería. Para la primera historia que conviene recordar que es la autenticación de usuarios, bajo el acuerdo con el Product Owner, planteó la necesidad de tener un login con una interfaz amigable. En otros términos, se propuso el login con los colores de la institución, ver figura 12. Consecuentemente la asignación de la segunda historia pertenece a la oportunidad de seleccionar qué atributos o privilegios de perfil de usuario serán preferente para cada uno, de este modo el Product Owner solicitó el diseño de una interfaz en el que cierto personal solo pueda acceder a ciertas funciones. De la misma manera instó para la creación de un administrador que contenga todos los permisos del sistema, y sea este el que se encargue de elegir los perfiles de usuario. Para la culminación del Sprint backlog 1 se ubica la tercera historia, teniendo como descripción el establecimiento de: nombre de usuario y contraseña para cada secretaria, docente y alumno de la institución, como necesidad funcional el Product Owner solicitó que de manera inicial y predeterminada se pueda asignar la contraseña con el número de cedula de cada usuario, además de tener la opción a cambio si el usuario lo desease. Finalmente, una vez obtenido el primer Sprint de manera completamente funcional, se efectuó la junta con el Product Owner para que de este modo se realice una demostración de uso del Sprint 1 funcional, y en efecto la revisión fue exitosa, se percibió la ausencia de dudas por el usuario antes mencionado en la reunión.

Figura 12. Captura de pantalla del login.

Figura 13. Captura de pantalla de perfiles de usuarios.

Figura 14. Captura de pantalla de ingreso de usuarios.

5.2.1.3.3.1 Retrospectiva de sprint 1. En la primera entrega de Sprint se efectuó una reunión con el Scrum Master, con el documento de revisión, en éste se registra todas las observaciones que hubo por parte del equipo desarrollo, y de este modo pasar al segundo Sprint. A continuación, se presenta las pruebas de aceptaciones por historias de usuario del primer Sprint, esto para observar y probar la funcionalidad del Sprint 1. 5.2.1.3.4 Pruebas de aceptación sprint 1. Tabla 13. Pruebas de aceptación sprint 1 Prueba de aceptación 1 Codigo:001 Nombre caso de prueba: Login Módulo/Sección a evaluar: Ingreso al sistema

Historia de usuario asociada:1

Descripción: Cada usuario de la institución puede ingresar al sistema de acuerdo a los atributos dados Pre-condiciones El usuario inicialmente sujetará la condición de contraseña con numero de cedula Pasos y condiciones de ejecución El usuario accede al sistema dependiendo qué funciones cumple en la institución El usuario debe ingresar al sistema con autenticación nombre de usuario y contraseña Resultado esperado Ingreso al sistema reconociendo los privilegios de acceso en cada uno Estado de prueba Errores asociados: Ninguno Acción final: Los usuarios como secretaria, docentes y alumnos quedan autenticados Nota: Datos obtenidos en la investigación de campo.

Éxito

Fracaso

51 Tabla 14. Prueba de aceptación 2. Prueba de aceptación 2 Codigo:002 Nombre caso de prueba: Ingresar, modificar y buscar usuarios Módulo/Sección a evaluar: Ingreso de usuarios

Historia de usuario asociada: 2 y 3.

Descripción: Para este módulo, el administrador o secretaria tendrán los privilegios para ingresar, modificar o buscar alumnos de la institución, como también los docentes Pre-condiciones  El administrador o secretaria deben estar autenticados al sistema  La secretaria debe tener la lista de los alumnos a ingresar Pasos y condiciones de ejecución El administrador se encarga de ingresar al sistema con su nombre de usuario y contraseña El administrador debe autorizar y asignar a la secretaria los permisos para ingresar, modificar y buscar alumnos en la parte de perfiles de usuario La secretaria se encarga de ingresar al sistema con su nombre de usuario y contraseña La secretaria ingresa la información de los alumnos y docentes Resultado esperado Se ingresa la información de cada alumno de la institución Estado de prueba

Éxito

Fracaso

Errores asociados: Ninguno Acción final: Los usuarios como estudiantes y docentes se almacenaron en la base de datos Nota: Datos obtenidos en la investigación de campo.

5.2.1.4. Sprint 2. 5.2.1.4.1 Sprint planning 2. Se obtuvo una nueva reunión con el Product Owner, el equipo de desarrollo y Scrum Master debido a las historias de usuarios planteadas en el product backlog, que los principales participantes e interesados del producto como el Product Owner ofrecieron, de esta manera se definió el segundo Sprint. En síntesis, se logró asignar qué historias de usuario serán participes para la elaboración y desarrollo de las tareas de ingeniería del Sprint 2.

5.2.1.4.2 Sprint backlog 2. Tabla 15. Sprint backlog 2 Sprint asignado

Estimación

Tareas de Ingeniería Maquetación de formularios Asignación de hojas de estilo de la institución Creación de formularios para la asignación de periodos académicos Creación de modelos para periodos académicos, curso, docentes y materias Codificación del frontend del formulario de control Modelado de la base de datos Validación de contraseñas con parámetro de numero de cedula Validación de superusuario Creación de rutas mediante los modelos Creación de controladores Supervisión de escenarios de pruebas

Estimación tarea 4

Estado Completo

Completo

Nota: Versión final del Sprint backlog 2. Datos obtenidos de la investigación de campo.

5.2.1.4.3 Burndown chart sprint 2.

04/01/2018

03/01/2018

1 2

2 3

1 2

6 3 1 6 6 3 5 0 5 0

02/01/2018

01/01/2018

28/12/2017

27/12/2017

26/12/2017

25/12/2017

22/12/2017

21/12/2017

14/12/2017

2 2

19/11/2017

13/12/2017

18/11/2017

12/12/2017

15/12/2017

11/12/2017

08/12/2017

07/12/2017

29/12/2017

Estimado

4 6 6

20/12/2017

06/12/2017

Estimación

Total horas

Tabla 16 Burndown chart sprint 2

4 7 4 8

4 6 4 5

4 4 4 3

4 2 4 1

Nota: Versión final del Burndown chart sprint 2. Datos obtenidos de la investigación de campo.

3 9 3 9

3 6 3 6

3 3 3 4

3 0 3 2

2 8 3 0

2 4 2 7

2 1 2 5

1 9 2 3

1 8 2 0

1 7 1 8

1 4 1 6

1 3 1 4

1 1 1 1

Grรกfico Burndown Chart 2 60

Figura 15. Burndown Chart 2. Figura obtenida del sprint 2. Datos obtenidos de la investigaciรณn de campo. .

5.2.1.4.4 Desarrollo de sprint 2. Para el segundo Sprint se asignaron las siguientes historias de usuario: ingreso de periodo académico, ingreso del curso, ingreso de docentes e ingreso de materias. Por lo tanto, bajo la negociación y comunicación con el Product Owner quién presentó la propuesta de que, estos procesos deben ser utilizados y manipulados por el usuario secretaria. Por lo que respecta la historia de usuario perteneciente al ingreso de periodo académico, se desarrolló con una interfaz amigable, en el cual pueda tener fácil acceso al ingreso de los mismos, cabe resaltar que, como requerimiento ofrecido por el Product Owner, es la opción de tener la disposición de activar o desactivar los ciclos académicos. Del mismo modo se aplica la interfaz amigable para los demás procesos que son: ingreso del curso, docentes y materias, sin embargo, para el desarrollo de estas historias de usuario anteriormente nombradas, se desarrollaron funcionalidades tales como: ventanas emergentes al momento de ingresar, modificar o eliminar un curso, esto para advertir al usuario secretaria y obtener una confirmación de su parte al momento de intervenir en estos procesos. Finalmente se entregó la funcionalidad del Sprint 2 al Product Owner, se obtuvo éxito con la revisión y no hubo observaciones, de este modo se pasa al Sprint 3, se adjunta las capturas de pantalla reflejando cada proceso de las historias de usuarios, pertenecientes al Sprint 2.

Figura 16. Captura de pantalla del ingreso de periodo académico.

Figura 17. Captura de pantalla del ingreso del curso.

Figura 18. Captura de pantalla del ingreso de docentes e ingreso de materias.

5.2.1.4.4.1 Retrospectiva de sprint 2. De la misma manera se realizรณ una junta con el Scrum Master para registrar del mismo modo todas las observaciones dentro de lo que estuvo el desarrollo del Sprint 2, una vez aprobado su desarrollo se procediรณ al desarrollo de Sprint 3. Por consiguiente, se muestran las pruebas de aceptaciรณn.

5.2.1.4.5 Pruebas de aceptación sprint 2. Tabla 17. Prueba de aceptación 3 Prueba de aceptación 3 Codigo:003 Nombre caso de prueba: Ingreso de información Módulo/Sección a evaluar: Ingresar y modificar información

Historia de usuario asociada: 4,5,6,7

Descripción: La secretaria podrá ingresar información valiosa para la institución, como periodo académico, cursos, docentes y materias Pre-condiciones EL usuario debe ingresar al sistema con su nombre de usuario y contraseña Pasos y condiciones de ejecución El usuario accede al sistema dependiendo qué funciones cumple en la institución El usuario debe ingresar al sistema con autenticación nombre de usuario y contraseña El usuario debe elegir qué información va a almacenar El usuario debe ingresar la información a almacenar según el tipo de dato El usuario puede modificar la información almacenada El usuario puede visualizar la información ya almacenada en la base de datos Resultado esperado Se presenta toda la información ingresada por el usuario Estado de prueba

Éxito

Fracaso

Errores asociados: Ninguno Acción final: Los periodos académicos, cursos, docentes y materias quedan almacenados Nota: Datos obtenidos en la investigación de campo.

5.2.1.5. Sprint 3. 5.2.1.5.1 Sprint planning 3. En la junta efectuada con el Product Owner se obtuvo un product backlog, en el que el equipo de desarrollo, Product Owner y el Scrum Master se encargaron de dividirlo en varias partes nombradas Sprint, en esta parte pertenece al Sprint 3 y en efecto a continuación se muestra el Sprint Backlog 3 y Burndown Chart 3, para de esta manera lograr obtener las tareas de ingeniería que conciernen al grupo de desarrollo.

5.2.1.5.2 Sprint backlog 3. Tabla 18. Sprint backlog 3 Sprint asignado

Estimación

Tareas de Ingeniería Maquetación de formularios Asignación de hojas de estilo de la institución Creación de formularios para la asociación de entidades Creación de relaciones para las tablas Codificación del frontend del formulario de control Modelado de la base de datos Validación de combobox Creación de rutas mediante los modelos Creación de controladores Supervisión de escenarios de pruebas

Estimación tarea 4

Estado Completo

Completo

Nota: Versión final del Sprint backlog 3. Datos obtenidos de la investigación de campo.

5.2.1.5.3 Burndown chart 3.

2 3

04/02/2018

03/02/2018

02/02/2018

01/02/2018

31/01/2018

30/01/2018

29/01/2018

26/01/2018

25/01/2018

24/01/2018

23/01/2018

Validación de combobox

22/01/2018

19/01/2018

Codificación del frontend del formulario de control Modelado de la base de datos

18/01/2018

17/01/2018

Asignación de hojas de estilo de la institución Creación de formularios para la asociación de entidades Creación de relaciones para las tablas

16/01/2018

15/01/2018

12/12/2017

11/01/2018

Maquetación de formularios

10/01/2018

09/01/2018

08/01/2018

Estimación

Total horas

Tabla 19. Burndown chart 3

Tareas de ingeniería

Creación de rutas mediante modelos Creación de controladores

6 3

1 2

los

6 6

Supervisión de escenarios de pruebas

Restante

5 0 5 0

Estimado

4 7 4 8

4 6 4 5

4 4 4 3

4 2 4 1

3 9 3 9

Nota: Versión final del Burndown chart sprint 3. Datos obtenidos de la investigación de campo.

3 6 3 6

3 3 3 4

3 0 3 2

2 8 3 0

2 4 2 7

2 1 2 5

2 0 2 3

1 8 2 0

1 6 1 8

1 3 1 6

1 2 1 4

1 0 1 1

Grรกfico Burndown Chart 3 60

Figura 19. Burndown Chart 3. Figura obtenida del sprint 3. Datos obtenidos de la investigaciรณn de campo.

5.2.1.5.4 Desarrollo de sprint 3. Para las historias de usuario en las que se asocian información, con la notificación del Product Owner, se optó por la implementación de un menú de opciones, para que, al momento de asignar alumnos a sus respectivas aulas, materias y docentes, se pueda visualizar la elección de cada uno. En otros términos, el usuario encargado de ingresar información de los alumnos, podrá seleccionar a qué materia, aula o docente tendrá cada discente. Como resultado al desarrollo de las anteriores historias, se logró implementar los procesos correspondientes al ingreso de información de lo siguiente: alumnos con sus representantes, las calificaciones e inasistencias, ya que, como en las previas historias se implementó las asociaciones, lo que resta para el usuario encargado del ingreso de información es incorporar a cada estudiante. Una vez ingresado cada alumno, el usuario podrá ingresar las calificaciones e inasistencias. De la misma manera se entregó la funcionalidad del Sprint 3 al Product Owner y no se presentaron quejas sobre el tercer entregable, se adjunta las capturas de pantalla demostrando la funcionalidad de cada historia de usuario.

Figura 20. Captura de pantalla del menú para la asociación de estudiantes.

Figura 21. Captura de pantalla del ingreso de la inasistencia.

5.2.1.5.4.1 Retrospectiva sprint 3. Una vez desarrollado todas las tareas de ingeniería del Sprint 3, se procedió con el Scrum Master a llenar las observaciones en el documento de retrospectiva, y con esto dar paso al desarrollo del último Sprint. A continuación, se muestran las pruebas de aceptación. 5.2.1.5.5 Pruebas de aceptación. Tabla 20. Prueba de aceptación 4 Prueba de aceptación 4 Codigo:004 Nombre caso de prueba: Vinculación de información para el estudiante Módulo/Sección a evaluar: Modulo de Control Descripción: La secretaria podrá seleccionar qué materias, curso y docente tendrá cada uno de los alumnos Pre-condiciones EL usuario debe ingresar al sistema con su nombre de usuario y contraseña Pasos y condiciones de ejecución El usuario accede al sistema dependiendo qué funciones cumple en la institución El usuario debe ingresar al sistema con autenticación nombre de usuario y contraseña El usuario debe elegir qué información va a almacenar El usuario debe ingresar la información a almacenar según el tipo de dato El usuario puede modificar la información almacenada El usuario puede seleccionar a que materia pertenece cada alumno El usuario puede visualizar la información ya almacenada en la base de datos

Historia de usuario asociada: 8 y 9

63 Tabla 20. (continuación) Prueba de aceptación 4 Resultado esperado Se presenta toda la información ingresada por el usuario Estado de prueba

Éxito

Fracaso

Errores asociados: Ninguno Acción final: Los alumnos quedan vinculados con materia, curso y docente Nota: Datos obtenidos en la investigación de campo.

Tabla 21. Prueba de Aceptación 5 Prueba de aceptación 5 Codigo:005 Nombre caso de prueba: Ingreso de información Módulo/Sección a evaluar: Ingresar y modificar información

Historia de usuario asociada: 4,5,6,7

Descripción: La secretaria podrá ingresar información valiosa para la institución, como alumnos, representantes, calificaciones e inasistencias Pre-condiciones EL usuario debe ingresar al sistema con su nombre de usuario y contraseña Pasos y condiciones de ejecución El usuario accede al sistema dependiendo qué funciones cumple en la institución El usuario debe ingresar al sistema con autenticación nombre de usuario y contraseña El usuario debe elegir qué información va a almacenar El usuario debe ingresar la información a almacenar según el tipo de dato El usuario puede modificar la información almacenada El usuario puede deshabilitar a cualquier alumno El usuario puede ingresar las calificaciones e inasistencias de cada alumno El usuario puede visualizar la información ya almacenada en la base de datos Resultado esperado Se presenta toda la información ingresada por el usuario Estado de prueba

Éxito

Fracaso

Errores asociados: Ninguno Acción final: Los periodos académicos, cursos, docentes y materias quedan almacenados Nota: Datos obtenidos en la investigación de campo.

5.2.1.6. Sprint 4. 5.2.1.6.1 Sprint planning 4. La finalidad de la reunión de negocio con el Product Owner, Scrum Master y el equipo de desarrollo es para recopilar todas las funcionalidades que debe tener el producto, ya que esto es de mucha ayuda para el grupo de desarrollo, pues con esto, se

puede proceder a dividir el product backlog en pequeñas partes llamadas Sprint, y de este modo dar entregas funcionales al Product Owner. 5.2.1.6.2 Sprint backlog 4. Tabla 22. Sprint backlog 4 Sprint asignado

Estimación

Tareas ingeniería

Estimación tarea

Maquetación formularios

Completo

Asignación de hojas de estilo de la institución

Completo

Creación de formularios para la asociación de entidades

Completo

Creación de relaciones para las tablas

Completo

Codificación frontend formulario control

del del de

Completo

Modelado de la base de datos

Completo

Creación de rutas mediante los modelos

Completo

Creación controladores

Completo

Supervisión escenarios pruebas

de de

Completo

Nota: Versión final del Sprint backlog 4. Datos obtenidos de la investigación de campo.

Estado

5.2.1.6.3 Burndown chart sprint 4.

2 1

07/02/2018

06/02/2018

05/03/2018

02/03/2018

01/03/2018

28/02/2018

Creaciรณn de controladores

27/02/2018

26/02/2018

Creaciรณn de rutas mediante los modelos

23/02/2018

22/02/2018

Codificaciรณn del frontend del formulario de control Modelado de la base de datos

21/02/2018

20/02/2018

Creaciรณn de formularios para la asociaciรณn de entidades Creaciรณn de relaciones para las tablas

19/02/2018

Asignaciรณn de hojas de estilo de la instituciรณn

16/02/2018

15/02/2018

14/02/2018

08/02/2018

13/02/2018

07/02/2018

12/02/2018

06/02/2018

Maquetaciรณn de formularios

09/02/2018

Total horas

Tabla 23. Burndown chart sprint 4

Supervisiรณn de escenarios de pruebas

Restante

Estimado

Tareas de Ingenierรญa 2

1 2

Nota: Versiรณn final del Burndown chart sprint 4. Datos obtenidos de la investigaciรณn de campo.

Grรกfico Burndown Chart 4 60

Figura 22. Burndown chart 4. Figura obtenida del sprint 4. Datos obtenidos de la investigaciรณn de campo.

5.2.1.6.4 Desarrollo de sprint 4. En la historia de usuario de reporte de secretaría, el Product Owner solicitó qué información deseaba sea visualizada a través del navegador, de este modo, se tenga la oportunidad de tener la información más detallada de una reciente búsqueda. En otras palabras, esta historia de usuario radica en la existencia de un botón con el evento de generar reportes en formato PDF. Por lo que sigue en la segunda historia de usuario del Sprint 4, tomado con mucha importancia para los involucrados e interesados del producto, para la justificación de las inasistencias se procedió a la creación de un módulo de inspección en el que se detalla el proceso de inasistencias, con el fin de justificar las inasistencias por parte del alumno durante las horas de clases en cada materia con su respectivo docente. Por consiguiente, para el desarrollo del registro de calificaciones de los alumnos a cargo de los docentes, tendrán acceso al módulo docente en el que constará de la opción de calificaciones, misma que entregará la información para que el docente tenga la oportunidad de ingresar las calificaciones, se tomó en cuenta que para el ingreso de las calificaciones se debe hacer por categorías como: 

Quimestre 1 o Parcial 1 o Parcial 2 o Parcial 3 o Examen Parcial



Quimestre 2 o Parcial 1 o Parcial 2 o Parcial 3 o Examen Parcial



Examen Final

Finalmente, para las recalificaciones a cargo de la secretaría, con la funcionalidad de poder establecer un intervalo de tiempo para que se permita ingresar de nuevo las calificaciones, esto con la necesidad de habilitar o deshabilitar la función de

recalificación. Por consiguiente, se ofreció la funcionalidad al Product Owner, y no se presentaron dudas o quejas acerca del último entregable. A continuación, se presenta las capturas de pantalla de la revisión con el Product Owner, en la reunión del entregable del Sprint 4.

Figura 23. Captura de pantalla de reporte de calificaciones.

Figura 24. Captura de pantalla del ingreso de calificaciones.

Figura 25. Captura de pantalla del listado de estudiantes.

Figura 26. Captura de pantalla del ingreso de estudiantes.

5.2.2. DiseĂąo Relacional de Base de Datos. En consecuencia, tras haber obtenido todas las funcionalidades del Product Owner, se logrĂł obtener un Product Backlog. Por lo que en la versiĂłn final del modelo relacional se muestra en la siguiente figura:

Figura 27. Modelo relacional de la base de datos.

5.2.3. Acta entrega-recepción. Para la constancia de la entrega-recepción del sistema se anexa el documento:

Figura 28. Acta de entrega-recepción.

Nota: con el acta entrega-recepción también se adjuntaron los siguientes archivos: diccionario de datos (ANEXO 4), manual de instalación (ANEXO 5), y manual de usuario (ANEXO 6).

5.3. AnĂĄlisis del Impacto Hay que resaltar que los impactos son necesarios pues, estos ayudan a determinar si el producto o proyecto ha llevado consigo un signo con carĂĄcter positivo o negativo despuĂŠs de su implementaciĂłn. Por lo tanto, se reflejarĂĄ en la siguiente tabla quĂŠ niveles, fĂłrmula e indicadores numĂŠricos se tomaron en cuenta para su respectiva determinaciĂłn de impacto. Tabla 24. Niveles del impacto Nivel -3 -2 -1 0 1 2 3

DescripciĂłn Impacto de alto nivel negativo Impacto de medio nivel negativo Impacto de bajo nivel negativo No existe impacto Impacto de bajo nivel positivo Impacto de medio nivel positivo Impacto de alto nivel positivo

Nota: Adaptado de â&#x20AC;&#x153;MetodologĂas para el trabajo de grado: Tesis y Proyectosâ&#x20AC;? por Posso, M. (2009). Ibarra.

Tabla 25. FĂłrmula para calcular el impacto FĂłrmula đ?&#x2018;ľđ?&#x2018;° =ÎŁ/N.Âş

DescripciĂłn NI = Nivel de Impacto ÎŁ=Sumatoria de niveles N.Âş=NĂşmero de indicadores

Nota: Adaptado de â&#x20AC;&#x153;MetodologĂas para el trabajo de grado: Tesis y Proyectosâ&#x20AC;? por Posso, M. (2009). Ibarra.

En consecuencia, para determinar el valor y nivel de impacto general, se analizaron los siguientes impactos: ď&#x201A;ˇ

Impacto Social

ď&#x201A;ˇ

Impacto TecnolĂłgico

ď&#x201A;ˇ

Impacto Ambiental

ď&#x201A;ˇ

Impacto EconĂłmico Por lo tanto, en las siguientes tablas se demostrarĂĄ los niveles de impacto en cada

ĂĄmbito enlistado anteriormente.

73 5.3.1.

Impacto Social.

Tabla 26. Impacto social Indicadores Accesibilidad en la información Confidencialidad de la información Total Sumatoria Resultado

Nivel de impacto

-3

-2

-1

2 X X

4 4 2

Nota: Datos obtenidos de la investigación de campo.

Análisis: El acceso a la información de la UEI, al tener un diseño responsivo, se logra tener el sistema web para cualquier dispositivo, por lo tanto, no se limita el acceso a la información para un equipo en especial. En la confidencialidad de información se lo enmarca con gran importancia para la UEI, ya que, existen datos de estudiantes y docentes con la información personal, por lo tanto, no debe estar con libre acceso. 5.3.2. Impacto Tecnológico. Tabla 27. Impacto tecnológico Indicadores Reportes con formato acordado Automatización de procesos Total Sumatoria Resultado

Nivel de impacto

-3

-2

-1

2 X X

4 4 2

Nota: Datos obtenidos de la investigación de campo.

Análisis: Los reportes para la UEPI, son importantes, ya que así se puede conocer datos de calificaciones o asistencias de los estudiantes, con esto se logra tener control sobre los mismos y una adecuada toma de decisiones. El traspaso al uso del software automatizado, brinda más versatilidad y rapidez en ingreso de información para los usuarios, pues con esto se logró que los procesos que eran llevados de manera manual, ahora son procesos automatizados.

5.3.3. Impacto Ambiental. Tabla 28. Impacto ambiental Indicadores

Nivel de impacto

-3

-2

-1

Uso de papel y carpetas

Hojas impresas

Total

Sumatoria

Resultado

Nota: Datos obtenidos de la investigación de campo.

Análisis: La UEPI, contrató un servidor con almacenamiento en la nube, por lo tanto, no se necesita imprimir reportes de docentes, estudiantes, materias, cursos, periodos académicos. El sistema permite el ingreso de notas y asistencias a través del sistema web, logrando así un ahorro considerable de papel y carpetas en la institución. 5.3.4. Impacto Económico Tabla 29. Impacto económico Indicadores

Nivel de impacto

-3

-2

-1

Adquisición de dominio y hosting Adquisiciones materiales de oficina

3 X

Total

Sumatoria

Resultado

2.5

Nota: Datos obtenidos de la investigación de campo.

Análisis: La adquisición de dominio y hosting en la nube, logró evitar la compra de servidores físicos, generando un ahorro significativo para la institución. La disminución de adquisición de materiales de oficina, es considerado como un ahorro, debido a que los procesos se automatizaron razón por la cual disminuyó el consumo de materiales de oficina.

5.3.5. Impacto General. Tabla 30. Impacto general Indicadores

Nivel de impacto

-3

-2

-1

Impacto Social

Impacto Tecnolรณgico

Impacto Ambiental

Impacto Econรณmico

Sumatoria

Resultado

Nota: Datos obtenidos de la investigaciรณn de campo.

Anรกlisis: El sistema web para el registro de notas y control de asistencias de la UEI, con los valores obtenidos de los indicadores en los diferentes niveles de impacto, se observa que toma un valor medio nivel positivo, pues se logrรณ automatizar los procesos manuales.

5.3.6. Carta de impacto La instituciรณn entregรณ una carta de impacto del producto desarrollado, la misma que se anexa:

Figura 29. Carta de impacto.

5.4. Discusiones 5.4.1. Discusión de la Entrevista. Obtenida la información por parte del rector de la institución mediante la entrevista (ANEXO 1), se comprendió que el uso del sistema, solo intervendrán los docentes, secretaria, representantes y rector, por lo que se procedió a realizar una encuesta a la secretaria, padres de familia y profesor de la institución. Por otra parte, con la información brindada se pudo evidenciar que el registro de la asistencia se lo lleva de forma manual, así como también el registro de notas se lo hace en hojas de Excel, por lo que se llegó a la conclusión de implementar en la institución un sistema web que automatice dichos procesos. 5.4.2. Discusión de la Encuesta. Al realizar la investigación de campo en la Unidad Educativa Particular Iberoamericano, se procedió a aplicar las respectivas encuestas, para así conocer el grado de aceptación del proyecto, mediante la tabulación de cada pregunta se puede obtener un porcentaje, para así realizar el respectivo análisis. La encuesta fue aplicada a 233 personas, de entre ellos; planta docente, personal administrativo y representantes (ANEXO 2). 5.4.3. Discusión de la Fase de Desarrollo. SCRUM se divide en múltiples fases, la primera es el release planning, en la que, siendo la primera reunión para la definición de roles entre Product Owner, Scrum Master y el equipo de desarrollo, para conocer las reglas de negocio del software. Por consiguiente, se obtiene el product backlog, en el que se establecen todas las funcionalidades planteadas en historias de usuario que el Product Owner ofrece, en este caso se obtuvieron un total de 14 historias de usuario (ANEXO 3). En consecuencia, se da inicio al sprint 1, en el que se estableció la estimación de las historias de usuario basándose en la complejidad, por lo que, se eligió la métrica puntos de historia, guiándose de la técnica Planning Póker, prevista en escala de Fibonacci.

Por lo tanto, bajo la estimación de historias de usuario, se obtiene el sprint backlog, en éste, se detalla una tabla que contiene la estimación, tareas de ingeniería y los días estimados, de este modo, el burndown chart va en conjunto con la elaboración del sprint backlog, logrando una gráfica que sirve para la supervisión por parte del Scrum Master, y que las tareas de ingeniería se estén realizando con lo estimado en el sprint. Una vez desarrolladas las tareas de ingeniería por parte del equipo de desarrollo se procede a la retrospectiva del sprint, realizando una reunión con el Product Owner, Scrum Master y equipo de desarrollo, pues aquí, se realiza la entrega del primer sprint funcional, y de este modo si no existen inconformidades por parte del Product Owner se hace el procedimiento al siguiente sprint. En el caso de que, existieran dudas, aquellas funcionalidades se proceden a realizarlas en el siguiente sprint. De este modo, se lograrán los demás sprint con la misma implementación de artefactos SCRUM, a tal punto de concretar todas las historias de usuario y conseguir un software totalmente funcional.

6. CONCLUSIONES Una correcta recolección de información de los procesos, posibilitó al equipo de desarrollo tener una idea de las reglas de negocio, dado que, con el empleo de las entrevistas, se consiguió determinar qué módulos iban a ser necesarios para el desarrollo del sistema web. Con la tabla comparativa de metodologías de desarrollo de software, el marco de trabajo Scrum, resultó ser oportuno para el desarrollo del software dado que, se ajustó de manera adecuada a las reglas de negocio. Por lo tanto, al ser un marco de trabajo ágil coloca énfasis en las entregas funcionales y las actividades como: product backlog, burndown chart, desarrollo de sprint, scrum diario, retrospectiva de sprint e incrementos, permitiendo así llevar un ritmo controlado. Con la implementación del sistema web, la Unidad Educativa Particular Iberoamericano, automatizó los procesos como el registro de notas y control de asistencias, permitiendo a los docentes el registro de notas directamente en el sistema y descartando el uso de papel.

7. RECOMENDACIONES Para una recolección de información exitosa, es necesario tener buenas prácticas en cuanto a las herramientas de recopilación de datos, por lo tanto, entre los mejores instrumentos en la extracción de datos se recomienda aplicar las entrevistas y las encuestas. Para la selección de una metodología de desarrollo se debe realizar un análisis comparativo inicial entre metodologías de acuerdo a las características del proyecto, pues con esto, se consigue conocer cuál metodología o marco de trabajo se acopla mejor al proyecto. Una vez implementado el software, se recomienda entregar los manuales tanto el técnico como el de usuario, los mismos que servirán de consulta para resolver algún inconveniente presentado o de capacitación para usuarios nuevos.

8. LISTADO DE REFERENCIAS Álvarez, A., De las Heras, R. y Lasa, C. (2012). Métodos Ágiles y Scrum. Madrid, España: Anaya Multimedia. Amar, V. (2008). Tecnologías de la Información y la Comunicación, Sociedad y Educación. Madrid, España: Editorial Tébar. Bootstrap. (2017). About of Bootstrap. USA. Recuperado el 20 de octubre de 2017, de http://getbootstrap.com/ Brito, K., Sosa, D., & Héctor, K. (2015). Selección de Metodologías de Desarrollo para Aplicaciones Web. USA: Editorial Academia Española. Cusik, J. (2013). Durable Ideas in Software Engineering: Concepts, MeTHODS AN Approaches from My Virtual Toolbox. New York: Bentham E-Books Flórez, H. (2012). Programación Orientada a Objetos Usando Java. Bogotá, Colombia: Ecoe Ediciones. García, R., (2016). “Optimización de consultas en Bases de Datos Relacionales” p.

32-35.

Obtenido

https://e-

archivo.uc3m.es/bitstream/handle/10016/24295/TFG_Raquel_Garcia_Frutos.pdf Gardner, B. (2011). Responsive web design: Enriching the user experience. Sigma Journal:

Inside

the

Digital

Ecosystem,

11(1),

13-19.

Obtenido

http://www.noblis.org/media/2dd575c1-2de9-4d92-9bdbf72ad9fb9a19/docs/SigmaDigEco2011_pdf#page=15 Gauchat, J. (2013). El gran libro de HTML5, CSS3 & Javascript (2nd ed.). Madrid: Marcombo. Gómez, J., Villar, E., & Alcayde, A. (2011). Diseño y creación de portales WEB. España: StartBook. Gómez, H. (2000). EDUCACIÓN La Agenda del Siglo XXI. Bogotá, Colombia: TM Editores.

Hernández, R., Fernández, C., & Baptista, M. (2010). Metodología de la Investigación. México: McGraw Hill. Hincapié, J. & Duitama, J. (2012). Model driven web engineering methods: a literature review. Revista Facultad De Ingeniería. Universidad de Antioquia, 63(6), 6981.

Obtenido

http://aprendeenlinea.udea.edu.co/revistas/index.php/ingenieria/article/view/12487/1130 9. Jacobson, I., Ng, P., McMahon, P., Spence, I., & pn, S. (2013). La Esencia de la Ingeniería de Software: El Núcleo de Semat. Revista Latinoamericana De Ingenieria De Software,

1(3),

71-78.

Obtenido

http://sistemas.unla.edu.ar/sistemas/redisla/ReLAIS/relais-v1-n3-p-71-78.pdf López, L. (2013). Metodologia de la Programacion Orientada a Objetos (Segunda ed.). Mexico: Alfaomega. MaríaDB Foundation. (2016). About MariaDB. USA. Recuperado el 15 de Julio de 2016, de https://mariadb.org/ Martínez, J. (2015). PostGIS 2 Análisis Espacial Avanzado. USA: San Berdardino. Ministerio de Educación. (2018). Reglamento General a la Ley Orgánica de Educación Intercultural. Quito. MySQL.

(2017).

Products

MySQL.

Obtenido

https://www.mysql.com/products/workbench/ NotePad++. (2017). About of NotePad++. USA. Recuperado el 03 de Noviembre de 2017, de https://notepad-plus-plus.org/ Peña, O. (2010). Manual Imprescindible de CSS. Madrid, España: Anaya Multimedia. Pérez, M. (2015). Lenguaje de Programación Orientada a Objetos. USA: Createspace Independent Pub.

Posso, M. A. (2009). Metodología para el trabajo de grado: Tesis y Proyectos (Cuarta ed.). Ibarra: NINA Comunicaciones. Purer, K. (2010). “PHP vs. Python vs. Ruby – The web scripting language shootout”, Compilers and Languages Group. Pressman, R. (2010). Ingeniería de Software. México: Mc Graw Hill. Reinosa, E., Maldonado, C., Muñoz, R., Damiano, L., & Abrutsky, M. (2014). Base de Datos. México: Alfaomega. Roldan, D., Valderas, P., & Pastor, O. (2010). Aplicaciones Web un Enfoque Práctico. México: Alfaomega. Rubiales, M. (2013). HTML5, CSS3 y JavaScript. Madrid: Anaya. Secretaría Nacional de Planificación y Desarrollo. (2017). Plan Nacional del Buen Vivir. Quito. Sánchez, J. (2009). Plataformas de enseñanza virtual para entornos. Revista de Medios y Educación, 217-233. Silberschatz, A., Korth, H., & Sudarshan S. (2007). Fundamentos de Diseño de Bases de Datos. Madrid, España: McGraw Hill. Somerville, I. (2011). Ingeniería de Software. México, México: PEARSON EDUCACION. Sublime Text. (2017). About Sublime Text. USA. Recuperado el 03 de Noviembre de 2017, de https://www.sublimetext.com/ Tinoco Gómez, O., & Rosales López, P., & Salas Bacalla, J. (2010). Criterios de selección de metodologías de desarrollo de software. Industrial Data, 13 (2), 70-74. The PostgreSQL Global Development Group. (2017). About PostgreSQL. Obtenido de http://www.postgresql.org/about Zofio, J. (2013). Aplicaciones Web. Madrid: Macmillan Profesional

9. GLOSARIO DE TÉRMINOS Cliente/Servidor: es un modelo que detalla el proceso de relación que existe entre alguna computadora local, que hace referencia al (cliente) y la remota es decir (servidor). CSS: hojas de estilo en cascada utilizadas para describir la presentación de escritos de HTML o XML. Framework: es código ya escrito y probado, compuesto por diferentes bibliotecas que se encuentran definidas en una sola estructura. ICONIX: es una metodología de desarrollo de software que pone énfasis en el ciclo de vida del software del producto a realizar. Paradigma: es un modelo que permite resolver uno o varios problemas claramente delimitados. Release: versiones funcionales del software que se entregan a los usuarios. Scrum: marco de trabajo ágil para el desarrollo de software. SGBD: sistema gestor de base de datos que sirve de interfaz entre el usuario, la base de datos y las aplicaciones que la utilizan. Sprint: intervalo de tiempo predefinido en el que se crea un incremento del producto a realizar. SQL: es un lenguaje de consulta estructurada que permite especificar varias operaciones en una base de datos.

10. ANEXOS ANEXO 1. Entrevista

El propósito del siguiente documento es que permita recolectar la información necesaria para conocer los procesos que llevan en la institución por parte del rector para el desarrollo de un sitio web para el registro de notas y control de asistencia, en la Unidad Educativa Particular Iberoamericano del cantón Santo Domingo, de antemano se agradece su total sinceridad.

¿Cuáles son los procesos que se deben automatizar dentro de la UEI?

¿Cómo se acostumbra a llevar la información anteriormente mencionada?

¿Cuántas y cuáles personas están encomendadas para llevar los procesos anteriormente mencionados?

¿Considera la necesidad de automatizar los procesos de la UEPI?

ANEXO 2. Encuesta

El propósito del siguiente documento es permitir la recolección de información necesaria para conocer el grado de aceptación por parte de los docentes sobre el desarrollo de un sitio web para el registro de notas y control de asistencia, en la Unidad Educativa Particular Iberoamericano del cantón Santo Domingo, de antemano se agradece su total sinceridad. Instrucciones: Marcar con “X” una sola respuesta por pregunta 1. ¿Cómo considera sus conocimientos sobre el uso de Internet? Alto Medio Bajo

2. ¿En qué lugares usted tiene acceso a internet? Institución

Casa

Centro de cómputo

3. ¿Cree usted que es necesario implementar un sistema online (en internet), que ayude a mejorar la forma del ingreso de notas y control de la asistencia por parte de los docentes y la visualización de calificaciones de los estudiantes por parte de los representantes? Si No

4. ¿Considera usted que la automatización del proceso de registro de calificaciones y control de asistencia beneficiará a la institución? Si

5. ¿Cree usted, que es más seguro llevar la información de calificaciones, asistencias y reportes de notas en un sistema web, que en hojas de papel? Si

ANEXO 3. Historias de Usuario Historia de Usuario Número: 1

Usuario: Usuario del Sistema

Nombre historia: Login Prioridad en negocio:

Riesgo en desarrollo:

Puntos estimados:

Sprint Asignado:

Programador responsable: Bryan Agudelo Descripción: COMO usuario del sistema QUIERO elegir el rol en el que este asignado, digitar usuario y contraseña PARA poder ingresar al sistema con las libertades proporcionados. Escenario de prueba: DADO la selección correcta del rol, ingreso y contraseña de cualquier usuario CUANDO presiono el botón ingresar ENTONCES accedo al menú principal. DADO la incorrecta elección del rol, el ingreso y contraseña de cualquier usuario CUANDO presiono el botón de LOGIN ENTONCES saltara un cuadro de dialogo que indicara error al ingreso del sistema.

Historia de Usuario Número: 2

Usuario: Administrador

Nombre historia: Ingreso de Perfiles de Usuarios Prioridad en negocio:

Riesgo en desarrollo:

Puntos estimados:

Sprint Asignado:

Programador responsable: Bryan Agudelo – Byron García Descripción: COMO Administrador QUIERO crear, modificar, eliminar perfiles de usuario siempre y cuando no hayan sido asignados a ningún usuario PARA tener los perfiles de usuario con los que se trabaja en el sistema. Escenario de prueba: DADO la entrada de un nuevo perfil que tenga el usuario CUANDO presiono el botón GUARDAR ENTONCES saltará un mensaje de dialogo que presente “Ingreso Exitoso”. DADO la modificación de un perfil creado CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Actualización Exitosa”. DADO la eliminación de un perfil creado CUANDO presiono el botón “X” de color rojo ENTONCES aparecerá un cuadro de dialogo en el que preguntará si estás seguro de hacerlo, al confirmar “Si, Eliminarlo” se procederá a eliminar actualizándose la tabla de perfiles de usuario.

Historia de Usuario Número: 3

Usuario: Administrador

Nombre historia: Ingreso de Usuarios Prioridad en negocio:

Riesgo en desarrollo:

Puntos estimados:

Sprint Asignado:

Programador responsable: Bryan Agudelo – Byron García Descripción: COMO Administrador QUIERO ingresar, modificar y habilitar o deshabilitar y buscar a los usuario, así como asignar roles, restablecer contraseñas, obtener reportes en formato PDF y actividades de los usuarios en cuanto a inicio de sesión PARA tener los usuarios que puedan dar la funcionalidad al sistema. Escenario de prueba: DADO el ingreso de la información general de un nuevo usuario CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Ingreso Exitoso”. DADO la modificación de un perfil creado CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Actualización Exitosa”. DADO la habilitación o desabilitación de los usuarios CUANDO presiono el botón con icono de “Switch” ENTONCES se visualizará el estado del botón de color verde como habilitado y color rojo como deshabilitado. DADO la modificación de un rol CUANDO presiono el botón check con icono de un “visto” ENTONCES aparecerá un cuadro de dialogo que diga “Actualización Exitosa”.

DADO la búsqueda de un usuario CUANDO presiono el botón con icono de “búsqueda” ENTONCES Mostrara el usuario a buscar de forma sombreada en la lista de usuarios”.

Historia de Usuario Número: 4

Usuario: Administrador

Nombre historia: Ingreso de Periodo Académico Prioridad en negocio:

Riesgo en desarrollo:

Puntos estimados:

Sprint Asignado:

Programador responsable: Bryan Agudelo – Byron García

Descripción: COMO Administrador QUIERO crear, modificar, permitir o cerrar y eliminar los periodos académicos PARA que se pueda trabajar un año lectivo en el sistema. Escenario de prueba: DADO la creación del periodo académico CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Ingreso Exitoso”. DADO la modificación del periodo académico CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Actualización Exitosa”. DADO la eliminación de un curso CUANDO presiono los botones de color rojo y verde con icono de un “Switch” ENTONCES se podrá visualizar que esta encendido o apagado de acuerdo a sus respectivos colores. DADO la habilitación del periodo académico CUANDO presiono el botón de color azul con icono de “Switch” ENTONCES se visualizará que el periodo se encuentra habilitado. DADO la deshabilitación del periodo académico CUANDO presiono el botón de color azul con icono de una mano apuntando hacia abajo ENTONCES se visualizara que el periodo se encuentra deshabilitado.

Historia de Usuario Número: 5

Usuario: Secretaria

Nombre historia: Ingreso del Curso Prioridad en negocio:

Riesgo en desarrollo:

Puntos estimados:

Sprint Asignado:

Programador responsable: Bryan Agudelo – Byron García Descripción: COMO Secretaria QUIERO crear, modificar, deshabilitar curso PARA realizar seguimiento al progreso de las calificaciones, asistencias de los estudiantes y acción docente. Escenario de prueba: DADO la creación del curso CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Ingreso Exitoso”. DADO la modificación del curso ingresado CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Actualización Exitosa”. DADO la desactivación de un curso CUANDO presiono el botón de color rojo con icono de “Switch” ENTONCES se desactivará el curso de la lista del módulo de cursos siempre y cuando se encuentre sin alumnos.

Historia de Usuario Número: 6

Usuario: Secretaria

Nombre historia: Ingreso de Docentes Prioridad en negocio:

Riesgo en desarrollo:

Puntos estimados:

Sprint Asignado:

Programador responsable: Bryan Agudelo – Byron García Descripción: COMO Secretaria QUIERO crear, modificar, desactivar y restaurar contraseña a los docentes PARA tener requerimiento organizado. Escenario de prueba: DADO la creación del curso CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Ingreso Exitoso” por tanto el nuevo docente estará en el listado de Usuarios del Módulo Docentes. DADO la modificación de un docente ya ingresado CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Actualización Exitosa”. DADO la desactivación de un docente CUANDO presiono el botón rojo con el icono de un “Switch” ENTONCES aparece un cuadro de dialogo que diga “Desactivación Exitosa”. DADO la restauración de contraseña del docente CUANDO presiono el botón azul “Restaurar Contraseña” ENTONCES aparecerá un cuadro de dialogo que diga “Restauración Exitosa”.

Historia de Usuario Número: 7

Usuario: Secretaria.

Nombre historia: Ingreso de Materias Prioridad en negocio:

Riesgo en desarrollo:

Puntos estimados:

Sprint Asignado:

Programador responsable: Bryan Agudelo – Byron García Descripción: COMO Secretaria QUIERO crear, modificar, eliminar las materias PARA tener un adecuado control de las materias que incluye en cada curso del periodo académico.

Escenario de prueba: DADO la creación de la materia una vez ingresado el nombre y el área a que pertenece CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Ingreso Exitoso”. DADO la modificación de la materia ingresada CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Actualización Exitosa”. DADO la eliminación de un curso CUANDO presiono el botón “X” de color rojo ENTONCES aparece un cuadro de dialogo de confirmación que diga Estas Seguro de “Si, Eliminarlo” y se eliminara siempre y cuando no este asignada a un curso o docente.

Historia de Usuario Número: 8

Usuario: Secretaria.

Nombre historia: Asociación Materia Curso Prioridad en negocio:

Riesgo en desarrollo:

Puntos estimados:

Sprint Asignado:

Programador responsable: Bryan Agudelo – Byron García Descripción: COMO Secretaria QUIERO vincular y desvincular las materias con los cursos PARA así tener control de cada una de las materias que pertenecen algún curso. Escenario de prueba: DADO la vinculación de la selección del curso y el listado de materias CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Vinculación Exitosa”. DADO la desvinculación de materia y cursos CUANDO presiono el botón de color rojo con icono de un “Switch” ENTONCES el botón de color rojo cambiara de color y se procederá la desvinculación siempre y cuando el docente no haya hecho el ingreso de ninguna calificación.

Historia de Usuario Número: 9

Usuario: Secretaria.

Nombre historia: Asociación Docente Materia Prioridad en negocio:

Riesgo en desarrollo:

Puntos estimados:

Sprint Asignado:

Programador responsable: Bryan Agudelo – Byron García

Descripción: COMO Secretaria QUIERO vincular y desvincular los docentes con las materias PARA así tener un control de los docentes que pertenezcan alguna materia. Escenario de prueba: DADO la vinculación de la selección del docente y el listado de materias CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Vinculación Exitosa”. DADO la desvinculación de docente con las materias CUANDO presiono el botón de color rojo con icono de un “Switch” ENTONCES el botón de color rojo cambiara de color y se procederá la desvinculación siempre y cuando el docente no haya hecho el ingreso de ninguna calificacion.

Historia de Usuario Número: 10

Usuario: Secretaria.

Nombre historia: Ingreso de Estudiantes y Representantes Prioridad en negocio:

Riesgo en desarrollo:

Puntos estimados:

Sprint Asignado:

Programador responsable: Bryan Agudelo – Byron García Descripción: COMO Secretaria QUIERO crear, modificar, y desactivar los estudiantes junto con los representantes PARA tener un control de todos los estudiantes junto con su representante legal. Escenario de prueba: DADO la creación del estudiante CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Ingreso Exitoso”. DADO la modificación del estudiante CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Actualización Exitosa” y se podrá visualizar al estudiante en el botón azul que dice “Vista de Alumnos”. DADO la desactivación o activación de un estudiante CUANDO presiono el botón de “Estado” en la Vista de Alumnos ENTONCES aparece el estudiante con el botón de estado de color verde como activado y color rojo como desactivado”. DADO la creación del representante CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Ingreso Exitoso”. DADO la modificación del representante CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Actualización Exitosa” y se podrá visualizar al representante en el botón azul que dice “Vista de Representantes”.

93 DADO la desactivación o activación de un representante CUANDO presiono el botón de “Estado” en la Vista de Representantes ENTONCES aparece el representante con el botón de estado de color verde como activado y color rojo como desactivado”.

Historia de Usuario Número: 11

Usuario: Docente.

Nombre historia: Ingreso Calificaciones y Asistencia Prioridad en negocio:

Riesgo en desarrollo:

Puntos estimados:

Sprint Asignado:

Programador responsable: Bryan Agudelo – Byron García Descripción: COMO Docente QUIERO ingresar las calificaciones e inasistencias de los estudiantes, de modo que los estudiantes y representantes puedan visualizarlas PARA llevar un control adecuado de las notas y asistencias y a su vez las personas pertinentes puedan visualizarlas. Escenario de prueba: DADO el ingreso de las notas CUANDO presiono el botón check con icono de un “visto” ENTONCES la nota quedara registrada en la lista de calificaciones del Módulo Docentes. DADO el ingreso de la inasistencia CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Registro Exitoso”. DADO la visualización de las notas por parte de los representantes y estudiantes CUANDO presiono el botón LOGIN ENTONCES se direccionará al sitio en donde se encuentre las calificaciones y las asistencias del estudiante.

Historia de Usuario Número: 12

Usuario: Secretaria

Nombre historia: Reporte Secretaria Prioridad en negocio:

Riesgo en desarrollo:

Puntos estimados:

Sprint Asignado:

Programador responsable: Bryan Agudelo – Byron García Descripción: COMO Secretaria QUIERO tener la posibilidad de sacar reportes de los cursos, materias, docentes y las calificaciones de los estudiantes.

Escenario de prueba: DADO la generación del reporte de los cursos CUANDO presiono el botón “Reporte PDF” ENTONCES aparecerá un archivo en formato PDF con la lista de todos los cursos del periodo académico actual. DADO la generación del reporte de las materias CUANDO presiono el botón “Reporte PDF” ENTONCES aparecerá un archivo en formato PDF con la lista de todas las materias pertenecientes a cada curso. DADO la generación del reporte de los docentes CUANDO presiono el botón “Reporte PDF” ENTONCES aparecerá un archivo en formato PDF con la lista de todos los docentes del periodo académico. DADO la generación del reporte de las calificaciones CUANDO presiono el botón “Reporte PDF” ENTONCES aparecerá un archivo en formato PDF con la lista de todas las calificaciones de cada estudiante.

Historia de Usuario Número: 13

Usuario: Docente

Nombre historia: Justificación de la Inasistencia. Prioridad en negocio:

Riesgo en desarrollo:

Puntos estimados:

Sprint Asignado:

Programador responsable: Bryan Agudelo – Byron García. Descripción: COMO docente QUIERO tener la posibilidad de justificar las inasistencias y a su vez generar reportes de las mismas PARA llevar un control adecuado asistencias de los estudiantes. Escenario de prueba: DADO la justificación de la inasistencia en el módulo docente CUANDO presiono el “justificar” ENTONCES aparecerá un cuadro de dialogo que diga ¿Estás Seguro? “Si, Justificar” y a su vez se desactiva el botón anteriormente presionado “Justificar”. DADO la generación del reporte de inasistencia CUANDO presiono el botón “Reporte PDF” ENTONCES aparecerá un archivo en formato PDF con la lista de los estudiantes que han faltado, así mismo de las justificaciones que se han realizado.

Historia de Usuario Número: 14

Usuario: Secretaria.

Nombre historia: Recalificación Prioridad en negocio:

Riesgo en desarrollo:

Puntos estimados:

Sprint Asignado:

Programador responsable: Bryan Agudelo – Byron García Descripción: COMO Secretaria QUIERO modificar las notas ingresadas con anterioridad por los docentes PARA tener un control correcto de las notas de los estudiantes. Escenario de prueba: DADO la recalificación CUANDO ingreso a la opción Recalificación presiono el botón GUARDAR ENTONCES las notas quedaran modificadas. DADO el ingreso de la inasistencia CUANDO presiono el botón GUARDAR ENTONCES aparecerá un cuadro de dialogo que diga “Registro Exitoso”. DADO la visualización de las notas por parte de los representantes y estudiantes CUANDO presiono el botón LOGIN ENTONCES se direccionará al sitio en donde se encuentre las calificaciones y las asistencias del estudiante.

ANEXO 4. Diccionario de la Base de Datos

100

101

102