UNIVERSIDAD CENTRAL DEL ECUADOR.
FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS Y
MATEMÁTICA.
CARRERA DE INGENIERÍA INFORMATÍCA.
Sistema de Gestión para la reserva de laboratorios de Informática en la
Facultad de Economía.
Trabajo de titulación modalidad Proyecto Integrador, previo a la
obtención del título de Ingeniero Informático.
AUTOR: Tipantuña Rodríguez Henry Gustavo.
TUTOR: Ing. Jorge Arturo Morales Cardoso.
Quito, 2019
ii
DERECHOS DE AUTOR
Yo Tipantuña Rodríguez Henry Gustavo en calidad de autor y titular de los derechos morales y
patrimoniales del trabajo de titulación SISTEMA DE GESTIÓN PARA LA RESERVA DE
LABORATORIOS DE INFORMÁTICA EN LA FACULTAD DE ECONOMÍA, modalidad
Proyecto integrador, de conformidad con el Art. 114 del CÓDIGO ORGÁNICO DE LA
ECONOMÍA SOCIAL DE LOS CONOCIMIENTOS, CREATIVIDAD E INNOVACIÓN,
concedo a favor de la Universidad Central del Ecuador una licencia gratuita, intransferible y no
exclusiva para el uso no comercial de la obra, con fines estrictamente académicos. Conservo a mi
favor todos los derechos de autor sobre la obra, establecidos en la normativa.
Así mismo, autorizo a la Universidad Central del Ecuador para que realice la digitalización y
publicación de este trabajo de titulación en el repositorio virtual, de conformidad a lo dispuesto
en el Art. 144 de la Ley Orgánica de Educación Superior.
El autor declara que la obra objeto de la presente autorización es original en su forma de
expresión y no infringe el derecho de autor de terceros, asumiendo la responsabilidad por
cualquier reclamación que pudiera presentarse por esta causa y liberando a la Universidad de
toda responsabilidad.
Firma _____________________
Tipantuña Rodríguez Henry Gustavo.
CC: 1721896742
iii
APROBACIÓN DEL TUTOR
En mi calidad de Tutor del Trabajo de Titulación, presentado por TIPANTUÑA RODRÍGUEZ
HENRY GUSTAVO, para optar por el título de Ingeniero Informático cuyo título es: SISTEMA
DE GESTIÓN PARA LA RESERVA DE LABORATORIOS DE INFORMÁTICA EN LA
FACULTAD DE ECONOMÍA, considero que dicho trabajo reúne los requisitos y méritos
suficientes, para ser sometido a la presentación pública y evaluación por parte del tribunal
examinador que se designe.
En la ciudad de Quito, a los 30 días del mes Julio del 2019.
_________________________
Ing. Jorge Arturo Morales Cardoso.
DOCENTE-TUTOR
CC: 1705099784
iv
DEDICATORIA.
A mis padres Vicente y Liliana que con su
amor, esfuerzo y dedicación me impulsan a
ser mejor cada día. Esta tesis y todo lo que
logre será gracias a la fortaleza, valores y
virtudes que ellos me inculcan y en los que
me inspiro para seguir adelante.
A mis hermanos Cristhian y Wendy por su
cariño, su constante apoyo y estar conmigo
en a lo largo de mi vida.
v
AGRADECIMIENTOS.
A mis padres por darme el regalo de la vida, apoyarme en todo, ser la base de mi
desarrollo como persona, sus consejos y creer en mí.
Al Ing. Jorge Morales por su guía como tutor y compartir sus conocimientos a lo
largo de este proceso.
A los docentes de la carrera, que con amabilidad están dispuestos a orientar a los
alumnos con sus valiosos conocimientos y experiencia.
Al personal administrativo de la Unidad de Tecnología de la Facultad de Ciencias
Económicas, que dieron a conocer los requerimientos funcionales del proyecto y
dieron paso al levantamiento de procedimientos dentro de la Unidad.
vi
CONTENIDO
DERECHOS DE AUTOR ............................................................................................................ ii
APROBACIÓN DEL TUTOR .................................................................................................... iii
DEDICATORIA. .......................................................................................................................... iv
AGRADECIMIENTOS. ............................................................................................................... v
LISTA DE TABLAS. ................................................................................................................. viii
LISTA DE FIGURAS. ................................................................................................................. ix
RESUMEN.................................................................................................................................... xi
ABSTRACT ................................................................................................................................. xii
1. Generalidades. ..................................................................................................................... 2
1.1. Planteamiento del Problema. ........................................................................................ 2
1.2. Justificación e Importancia. .......................................................................................... 2
1.3. Objetivos. ........................................................................................................................ 3
1.3.1. Objetivo General. .................................................................................................... 3
1.4. Alcance. ........................................................................................................................... 3
1.5. Limitaciones. ................................................................................................................... 4
2. Marco Teórico. .................................................................................................................... 5
2.1. Aplicación Web. .............................................................................................................. 5
2.1.1. Estructura de aplicaciones Web. ........................................................................... 5
2.2. Herramientas y tecnologías de desarrollo. ................................................................... 6
2.2.1. Tecnologías del lado del servidor Back-End. ....................................................... 6
2.2.2. Tecnologías del lado del cliente Front-End. ....................................................... 10
2.2.3. Motor de Base de Datos. ....................................................................................... 11
3. Metodología. ...................................................................................................................... 13
vii
3.1. Metodología para desarrollo de Software. ................................................................. 13
3.2. Metodologías de desarrollo Ágil de Software. ........................................................... 13
3.2.1. Manifestó Ágil. ...................................................................................................... 13
3.3. Metodología de Programación Extrema(XP). ........................................................... 16
3.3.1. Características. ...................................................................................................... 16
3.3.2. Fases. ...................................................................................................................... 17
4. Desarrollo........................................................................................................................... 22
4.1. Fase de Planeación. ...................................................................................................... 22
4.1.1. Establecimiento de las Historias de Usuario HU. .............................................. 22
4.1.2. Planificación de despliegue de Iteraciones. ......................................................... 28
4.2. Fase de Diseño............................................................................................................... 29
4.2.1. Estructura General del Proyecto. ........................................................................ 29
4.2.2. Diseño de interfaces en las páginas web. ............................................................. 29
4.2.3. Diseño de BD. ........................................................................................................ 46
5.2. Fase de Pruebas. ........................................................................................................... 52
5.2.1. Pruebas de caja negra. .......................................................................................... 52
5.2.2. Pruebas sobre navegadores. ................................................................................. 65
5.2.3. Load Test. .............................................................................................................. 67
5. Conclusiones. ........................................................................................................................... 70
6. Recomendaciones. ................................................................................................................... 71
7. Referencias............................................................................................................................... 72
8. Anexos. ..................................................................................................................................... 75
8.1. Manual de Usuario. ............................................................................................................ 1
8.2. Acta de entrega recepción. ............................................................................................... 47
viii
LISTA DE TABLAS.
Tabla 1. Metodologías preferidas en la red. .................................................................................. 15
Tabla 2. Comparación de M. Scrum y XP. ................................................................................... 15
Tabla 3. Historia - 001. Autenticación. ........................................................................................ 22
Tabla 4. Historia - 002. Roles de Usuario. ................................................................................... 23
Tabla 5. Historia - 003. Administración de Usuarios. ................................................................. 23
Tabla 6. Historia - 004. Administración de Docentes. ................................................................. 24
Tabla 7. Historia - 005. Administración de Materias. .................................................................. 25
Tabla 8. Historia - 006. Administración de Laboratorios. ........................................................... 25
Tabla 9. Historia - 007. Administración de Reservas de Laboratorios. ....................................... 26
Tabla 10. Historia - 008. Generación de Reportes ....................................................................... 27
Tabla 11. División de HU en Iteraciones. ..................................................................................... 28
Tabla 12. Diccionario de datos de la tabla materia. ...................................................................... 47
Tabla 13. Diccionario de datos de la tabla docente. ..................................................................... 48
Tabla 14. Diccionario de datos de la tabla cruzada docente y materia. ........................................ 49
Tabla 15. Diccionario de datos de la tabla laboratorio. ................................................................ 49
Tabla 16. Diccionario de datos de la tabla docente. ..................................................................... 50
Tabla 17. Diccionario de datos de la tabla usuario. ...................................................................... 51
Tabla 18. Diccionario de datos de la tabla UserRol. ..................................................................... 51
Tabla 19. Prueba para la autenticación de usuarios. ..................................................................... 52
Tabla 20. Prueba asociada a la administración de usuarios .......................................................... 53
Tabla 21. Caso de prueba para el módulo de administración de docentes ................................... 55
Tabla 22. Pruebas sobre el módulo de administración de materias .............................................. 57
Tabla 23. Prueba sobre el módulo de administración de laboratorios. ......................................... 59
ix
Tabla 24. Pruebas sobre el módulo de reservas de laboratorios. .................................................. 61
Tabla 25. Pruebas del módulo de reportes de reservas de laboratorios. ....................................... 63
LISTA DE FIGURAS.
Figura 1. Estructura básica de una aplicación Web (Pandey, 2018). .............................................. 6
Figura 2. Top de Popularidad de Lenguajes de Programación. (TIOBE, 2019). ............................ 7
Figura 3. Frameworks Web Populares 2019 (HotFrameworks, 2019) ......................................... 10
Figura 4. Ranking de Motores de BD 2019 (DB-Engines, 2019) ................................................. 12
Figura 5. Valores del Manifiesto ágil (Ruiz, 2018). ..................................................................... 14
Figura 6. Fases dela metodología XP (Hiebaum, 2015). ............................................................. 17
Figura 7. Diagrama del proceso de Iteraciones XP (Wells, 2015)................................................ 19
Figura 8. Estructura General del Proyecto (Tipantuña, 2019) ...................................................... 29
Figura 9. Página de autenticación de la aplicación (Tipantuña, 2019). ........................................ 30
Figura 10. Página de ingreso al sistema rol Master (Tipantuña, 2019). ....................................... 31
Figura 11. Página de ingreso al sistema rol Administrador (Tipantuña, 2019). ........................... 31
Figura 12. Página de ingreso al sistema rol Estándar (Tipantuña, 2019). .................................... 32
Figura 13. Interfaz de visualización de usuarios (Tipantuña, 2019). ............................................ 32
Figura 14. Interfaz para la creación de nuevo usuario (Tipantuña, 2019). ................................... 33
Figura 15. Interfaz de edición de usuario (Tipantuña, 2019). ....................................................... 33
Figura 16. Interfaz de visualización de docente (Tipantuña, 2019). ............................................. 34
Figura 17. Interfaz de creación de docente (Tipantuña, 2019). .................................................... 34
Figura 18. Interfaz de edición de docente (Tipantuña, 2019). ...................................................... 35
Figura 19. Interfaz de visualización de materias (Tipantuña, 2019). ............................................ 35
Figura 20. Interfaz de creación de materia (Tipantuña, 2019). ..................................................... 36
x
Figura 21. Interfaz de edición materia (Tipantuña, 2019). ........................................................... 36
Figura 22. Interfaz de visualización de laboratorios (Tipantuña, 2019). ...................................... 37
Figura 23. Interfaz de creación de laboratorios (Tipantuña, 2019). .............................................. 38
Figura 24. Interfaz de edición de laboratorios (Tipantuña, 2019). ............................................... 38
Figura 25. Interfaz de visualización de reservas de laboratorios (Tipantuña, 2019). ................... 39
Figura 26. Interfaz de Creación de reservas de laboratorios (Tipantuña, 2019). .......................... 40
Figura 27. Interfaz de edición de reservas de laboratorios (Tipantuña, 2019). ............................ 41
Figura 28. Reporte de reservas filtrado por laboratorio (Tipantuña, 2019). ................................. 42
Figura 29. Transformación del reporte a archivo PDF (Tipantuña, 2019). .................................. 43
Figura 30. Reporte de reservas filtrado por docente (Tipantuña, 2019). ...................................... 44
Figura 31. Transformación del reporte a archivo PDF (Tipantuña, 2019). .................................. 45
Figura 32. Diagrama entidad relación de BD (Tipantuña, 2019). ................................................ 46
Figura 33. Interfaz de autenticación en Chrome (Tipantuña, 2019). ............................................ 66
Figura 34. Interfaz de autenticación en Mozilla Firefox (Tipantuña, 2019). ................................ 66
Figura 35. Interfaz de autenticación en Mozilla Firefox (Tipantuña, 2019). ................................ 67
Figura 36. Solicitud de creación de reserva en formato JSON (Tipantuña, 2019). ...................... 68
Figura 37. Prueba de carga para la solicitud con 800 usuarios (Tipantuña, 2019). ...................... 69
Figura 38. Prueba de carga para la solicitud con 900 usuarios (Tipantuña, 2019). ...................... 69
xi
TITULO: Sistema de gestión para la reserva de laboratorios de informática en la Facultad de
economía.
Autor: Tipantuña Rodríguez Henry Gustavo.
Tutor: Ing. Jorge Arturo Morales Cardoso.
RESUMEN
El presente proyecto de titulación, se basa en el desarrollo de un sistema web para sistematizar la
administración de reservas de laboratorios de informática en la Facultad de Economía, de tal
manera que permita automatizar los procesos de gestión de laboratorios, la generación de
reportes y privilegios de acceso a la información que realiza la Unidad de Tecnologías. El
proyecto web se ha desarrollado utilizando tecnologías y herramientas de código abierto que
actualmente se encuentran en auge en el campo profesional del desarrollo de software, además
de la implementación de arquitecturas de comunicación entre sistemas. La implementación del
proyecto con sus componentes interactuando de manera adecuada, le brindará a la Unidad de
Tecnologías de la Facultad de Ciencias Económicas, optimización oportuna en la asignación de
laboratorios, de tal manera que pueda ofrecer un servicio de calidad a la Facultad.
PALABRAS CLAVE: SISTEMA WEB / SISTEMATIZACION / GESTIÓN DE
LABORATORIOS / HERRAMIENTAS DE CÓDIGO ABIERTO / ARQUITECTURAS DE
COMUNICACIÓN.
xii
TITLE: Management system for the reserve of computer labs in the Faculty of Economics.
Author: Tipantuña Rodríguez Henry Gustavo.
Tutor: Ing. Jorge Arturo Morales Cardoso.
ABSTRACT
The present degree project is based on the development of a web system to systematize the
administration of computer lab reserves in the Faculty of Economics, in such a way that it allows
automating laboratory management processes, generating reports and privileges. of access to the
information carried out by the Technology Unit. The web project has been developed using open
source technologies and tools that are currently booming in the professional field of software
development, in addition to the implementation of communication architectures between
systems. The implementation of the project with its components interacting properly, will
provide the Technology Unit of the Faculty of Economic Sciences, timely optimization in the
assignment of laboratories, so that it can offer a quality service to the Faculty.
KEY WORDS: WEB SYSTEM / SYSTEMATIZATION / LABORATORY MANAGEMENT /
OPEN CODE TOOLS / COMMUNICATION ARCHITECTURE.
1
INTRODUCCIÓN.
La Unidad de Tecnologías que se encuentra dentro de la Facultad de Ciencias Económicas de la
Universidad Central del Ecuador, es considerada una entidad de gran importancia, encargada de
gestionar y operar las Tecnologías de la Información que optimizan el potencial en los procesos
estratégicos de la Facultad. Actualmente, entre sus responsabilidades está la administración de
doce laboratorios de informática con aproximadamente doscientas diez reservas asignadas
semanalmente.
En este sentido la Unidad de Tecnologías de esta facultad, requiere gestionar las reservas de
laboratorios, así como la información de cada una, de forma óptima y sencilla, para proveer un
servicio adecuado a la Facultad.
El presente documento de tesis inicia estableciendo el proceso que requiere mejorarse en la
Unidad de Tecnologías, a continuación, se especifica la solución, implementando una
arquitectura de software y herramientas de desarrollo que se apoyan en la metodología ágil XP
para la puesta en marcha del proyecto.
Para la correcta ejecución del proyecto, se realizó un documento de requerimientos, acordado por
ambas partes (cliente y desarrollador), a partir del cual se ha establecido el alcance, objetivos y
limitaciones del proyecto de tesis. Así mismo se han elegido las herramientas y tecnologías de
desarrollo de software en base a las especificaciones del documento. Para concluir el proyecto, se
ha generado un acta de entrega recepción para que quede constancia de que el proyecto, se ha
entregado de acuerdo a lo requerido por el usuario final.
2
1. Generalidades.
1.1. Planteamiento del Problema.
La Unidad de Tecnologías de la Facultad de Ciencias Económicas de la Universidad Central del
Ecuador, entre sus funciones tiene a cargo la administración de reservas de laboratorios de
informática, así como la información correspondiente de cada una, como son docente, materia,
laboratorio, día y horario de una reserva especifica.
Actualmente se gestionan las asignaciones de doce laboratorios sobre los cuales se asignan
doscientas diez reservas de laboratorios semanales. Hasta el momento todo el proceso de
administración de laboratorios se realiza de manera manual, utilizando hojas de cálculo Excel,
que da como resultado una posible pérdida o alteración de los datos y dificulta el seguimiento del
proceso, de manera que en ocasiones se asigna erróneamente profesores a aulas ya reservadas.
Se sabe que los datos correspondientes a las reservas, se deben compartir entre el personal
administrativo de la Unidad de Tecnologías, para la división de tareas sobre las asignaciones, sin
embargo, este proceso solamente se realiza utilizando dispositivos de almacenamiento como
USB, en donde no se protege la información, y no existen privilegios de administración, es decir
no se controla quien puede acceder y alterar los datos. En adición, dicha entidad se ve en la
necesidad de generar reportes de las reservas de los laboratorios, uno que muestre una tabla tipo
horario que señale los días y las horas en que se ha reservado un determinado laboratorio y otro
que muestre la tabla tipo horario señalando los días y las horas en que un determinado docente ha
sido asignado a un laboratorio especifico. Pero no tienen a su disposición un sistema de reportes
automatizado que pueda agilizar el proceso, de esta manera deben acudir a los documentos y
verificar por si mismos los registros.
1.2. Justificación e Importancia.
Hoy por hoy toda institución debe brindar atención de calidad y más cuando se maneja una gran
cantidad de información que necesita, procesarse o compartirse, para esto es necesario hacer uso
de los beneficios que proveen las TIC. En este sentido y dado el planteamiento del problema
enunciado en la sección anterior, es pertinente elaborar un sistema que permita agilizar las
operaciones realizadas por la Unidad de Tecnologías con respecto a la gestión de horarios, tal
que se eviten los errores al asignar docentes a los laboratorios, que la información se pueda
3
acceder a partir de privilegios de usuario y que se puedan generar de forma automatizada los
reportes requeridos por el personal administrativo.
La importancia del sistema es de carácter administrativo, pues la oportuna asignación de
laboratorios, le permite al personal de la Unidad de Tecnologías realizar su trabajo de manera
adecuada y ofrecer un servicio de calidad a la Facultad de Ciencias Económicas.
1.3. Objetivos.
1.3.1. Objetivo General.
Implementar un sistema web para la gestión de reservas de laboratorios de informática, en la
Unidad de Tecnologías de la Facultad de Ciencias Económicas, que permita optimizar los
procesos de gestión, acceso a información y reportes de las asignaciones de laboratorios.
Objetivos Específicos.
Establecer la arquitectura de software que se adapte al sistema requerido.
Aplicar una metodología de desarrollo del software, cumpliendo las etapas y actividades
establecidas.
Realizar pruebas y ajustes, de manera que puedan estar seguros, tanto clientes como
desarrolladores, que el producto entregado cumple con las especificaciones.
1.4. Alcance.
El presente proyecto de tesis, que colabora con la Unidad de Tecnologías de la facultad de
Ciencias Económicas, cuenta con diferentes funcionalidades, tal como es el acceso al sistema a
través de roles de usuario para protección de información, la administración a nivel de creación,
eliminación y actualización de docentes, materias, laboratorios y reservas. Además, cuenta con
verificación de laboratorios reservados, es decir que no permite horarios duplicados. Para
comodidad de los miembros del departamento de la Unidad de Tecnologías de la facultad de
Economía, se ha realizado la generación de reportes por laboratorio/docente. A su vez el usuario
puede realizar búsquedas de reservas por día/laboratorio. Otra funcionalidad del proyecto es la
validación de campos en los formularios, tal que el usuario pueda ingresar los datos correctos en
la aplicación, por último, cabe recalcar que es accesible desde todos los ordenadores
pertenecientes a la Unidad de Tecnologías.
4
1.5. Limitaciones.
A pesar de que el proyecto puede integrarse con otros módulos en el futuro, por el momento es
de carácter independiente. Tomando en cuenta los requerimientos del usuario, el sistema no está
adaptado para visualización en dispositivos móviles. Así mismo no permite la recuperación de
contraseñas de usuario, por sugerencia del usuario final. Las copias de seguridad de la base de
datos no están automatizadas, estas corren por cuenta del personal administrativo de la Unidad
de Tecnologías de la facultad de Economía.
5
2. Marco Teórico.
2.1. Aplicación Web.
Se denomina aplicación web a cualquier programa de computadora que está contenido en un
servidor de Internet y pueden comunicarse a través del protocolo HTTP. Los sistemas web se
pueden utilizar en cualquier navegador de internet, y utilizar las funcionalidades que proveen las
bases de datos para procesar y mostrar información al usuario (Baez, 2012).
Se sabe que las aplicaciones web son muy populares el día de hoy, las ventajas principales de las
mismas se listan a continuación:
Compatibilidad para variedad de sistemas operativos.
Acceso con facilidad a aplicaciones empleando un navegador web.
Facilita el trabajo colaborativo y a distancia.
Mayor seguridad de datos (Peñaherreta, 2017).
2.1.1. Estructura de aplicaciones Web.
Las aplicaciones web constan de 3 capas:
Capa de persistencia: Es donde está generalmente el motor de BD.
Capa de aplicación: Es el programa, que se almacena en el servidor web y se encarga
de establecer la lógica del sistema.
Interfaz de usuario, que se accede con cualquier dispositivo a través de un buscador
de internet (Neosoft, 2018).
6
Figura 1. Estructura básica de una aplicación Web (Pandey, 2018).
2.2. Herramientas y tecnologías de desarrollo.
La puesta en marcha y lanzamiento de un software, requiere de diferentes fases, las cuales hacen
uso de herramientas y tecnologías adecuadas para un óptimo funcionamiento. A continuación, se
describen las herramientas y tecnologías elegidas para el desarrollo del presente proyecto de
tesis.
2.2.1. Tecnologías del lado del servidor Back-End.
Las tecnologías del lado del servidor, permiten implementar el comportamiento de la aplicación
web en el servidor.
2.2.1.1. Java.
Para el desarrollo del presente proyecto se ha elegido el lenguaje de programación Java, debido a
que los beneficios que provee se adaptan a las necesidades que se requieren para la realización
del proyecto, estos se destacan a continuación.
Java cuenta con varios beneficios, que se han tomado en cuenta para que el lenguaje sea
implementado en este proyecto, entre ellos tenemos:
Permite la ejecución en múltiples plataformas.
Orientación a Objetos.
Es de código libre.
Está diseñado para crear software altamente robusto, escalable y fiable.
7
Cuenta con una serie de librerías (nativas y de terceros) que amplían sus
funcionalidades.
Posee gran soporte y documentación.
Existe una importante cantidad de involucrados que colaboran para dar respuesta a
inquietudes en el desarrollo.
(Benites, 2017).
Además de las ventajas que supone la programación con Java, este se encuentra en el top del
índice de TIOBE (ver figura 2), que es una entidad especializada en evaluar y rastrear la
calidad del software. (TIOBE, 2019).
Figura 2. Top de Popularidad de Lenguajes de Programación. (TIOBE, 2019).
2.2.1.2. Spring Framework.
El uso de frameworks en programación web, ofrece grandes beneficios como optimizar tiempo,
agilitar el desarrollo, proveer patrones de diseño, tener librerías y funcionalidades configuradas a
priori (Tébar, 2018). En este sentido es pertinente el uso de uno de ellos para el lado del servidor,
en el presente proyecto. En este contexto se ha optado por utilizar el framework Spring, dadas
sus características y ventajas que se describen a continuación.
8
Spring es un marco de desarrollo para la creación de aplicaciones Java, es decir, puede usar
Spring para compilar todo tipo de programas realizados en Java, a diferencia de muchos otros
frameworks (como Apache Struts, que ejecuta solamente aplicaciones web). Spring es liviano en
el sentido de que se requieren pocos cambios, en el programa para obtener las características que
brinda Spring Core, y en caso de no necesitar utilizar más, Spring se puede dejar de hacerlo con
configuraciones sencillas (Cosmina, et al. 2017).
Entre las ventajas del uso del framework Spring, que se han considerado para implementarse en
el proyecto de tesis, tenemos:
Implementa IoC, para que sus componentes estén bajamente acoplados.
Es de código libre.
Refactorización a través de plantillas como JDBCTemplate.
Posee un IDE (Spring Tool Suite), para desarrollar aplicaciones basadas en Spring.
2.2.1.3. Spring Tool Suite (STS).
El uso de un IDE, facilita en gran medida la programación , pues al fusionar herramientas como,
editor de código, compilador y depurador en una aplicación, simplifican la tarea de seleccionar,
implementar, integrar y administrar todas las herramientas una por una (Rouse, 2016). Así se ha
decidido utilizar el IDE que proporciona Spring, el cual es STS (Spring Tool Suite), pues tiene
alta compatibilidad con el framework y es fácil de usar.
Spring Tool Suite está basado en Eclipse y está adaptado para desarrollar sistemas
Spring. Brinda un entorno para implementar, depurar, ejecutar y desplegar sus programas Java
(Spring, 2019).
2.2.1.4. Servidor web.
Un servidor web es un programa que utiliza el Protocolo de transferencia de hipertexto, para
proveer los archivos que conforman las páginas web a los distintos usuarios, los mismos que
presentan sus solicitudes y las envían desde sus buscadores de internet (Rousse, 2017).
El presente proyecto implementa el servidor Apache Tomcat, pues posee alto nivel desarrollo a
través de los años, se cuenta con experiencia previa y la comunidad alrededor del mismo es
relativamente extensa.
9
2.2.1.5. JPA.
El API de persistencia Java es una especificación, que cuenta con clases y métodos para guardar
información en un banco de datos. JPA permite el establecimiento de un vínculo, entre una base
de datos y un sistema que implementa Programación orientada a objetos POO. A este vínculo se
le conoce como ORM (Object Relational Mapping). JPA fija una interfaz que es implementada
por un proveedor de persistencia de nuestra elección como Eclipse-Link, Hibernate, Top-Link
entre otros (Oracle, 2014). Para el presente proyecto de tesis se implementa el proveedor de
persistencia Hibérnate.
2.2.1.6. REST Services (Transferencia de Estado Representacional).
REST es un estilo de arquitectura que se usa generalmente para comunicar programas por medio
del protocolo HTTP y sirve para extraer y publicar información, en formatos como XML o
JSON. REST utiliza los mismos métodos que HTTP.
SOAP fue por mucho tiempo el protocolo de comunicación que la mayoría de los servicios web
implementaban, pero su especificación se tornaba difícil en términos de codificación, además de
que la comunicación hace que la carga de páginas sea relativamente lenta (Monus, 2019).
A continuación, se describen características de REST que se tomaron en consideración para
implementar este estilo de arquitectura en el presente proyecto de tesis.
Es una arquitectura ligera al implementar protocolos sin estado.
Son relativamente fáciles de integrar y mantener.
REST es muy ligero, sus respuestas son rápidas.
10
2.2.2. Tecnologías del lado del cliente Front-End.
Las tecnologías del lado del cliente, permiten generar interfaces de usuario y establecer
comunicación con el back-end.
2.2.2.1. Angular.
Para las distintas tareas que se tienen que realizar en el lado del cliente, se ha seleccionado la
plataforma Angular version 6, pues se adapta a los requerimietos del proyecto y se encuentra
posicionado entre los frameworks web mas utilizados según el sitio web HotFrameworks (ver
figura 3).
Figura 3. Frameworks Web Populares 2019 (HotFrameworks, 2019)
Angular es una plataforma de aplicaciones web que brinda a los programadores un conjunto de
herramientas y funcionalidades para construir aplicaciones potentes (Freeman, 2018). Angular
nació con el objetivo de crear aplicaciones que funcionen para todas las plataformas, ya sea web
de escritorio o para móviles. A continuación, se muestran algunos beneficios que fueron
cruciales para escoger esta plataforma en el proyecto de tesis:
Genera el proceso de desarrollo en base a estándares como el uso de TypeScript.
Es open Source.
Permite el desarrollo ágil mediante Angular CLI.
Cuenta con una comunidad que proporciona una excelente base, para solventar dudas
de desarrollo.
11
2.2.2.2. TypeScript.
Dado que se utiliza la plataforma Angular, es de carácter obligatorio usar TypeScript, a
continuación, se redacta información, características y ventajas de este lenguaje de
programación.
Según Fenton (2018), TypeScript es un lenguaje creado por Microsoft, que fue publicado bajo
una licencia de código abierto Apache 2.0. El lenguaje es un superset de JavaScript, que
soluciona problemas de la programación del mismo, ofreciendo mejores herramientas en tiempo
de diseño, verificación de errores en tiempo de compilación y tipado estático.
Se cuenta actualmente con un buen soporte para TypeScript dentro de Visual Studio. En adición
sus licencias de código abierto hacen de este lenguaje una gran opción para desarrollar sistemas.
2.2.2.3. Bootstrap.
Bootstrap es un framework basado en CSS y JavaScript para diseño de sitios y aplicaciones web,
ha sido creado por Twitter y muy utilizado actualmente. El marco de estilos permite crear sitios
web, con un diseño personalizable de forma sencilla.
2.2.2.4. Visual Studio Code.
Al igual que se utiliza un IDE para el lado del servidor, también resulta importante el uso de uno
para el lado del cliente, en este sentido Visual Studio Code, resulta ser uno de los mejores para el
desarrollo del proyecto, pues provee soporte tanto para JavaScript, TypeScript, y node.js, que son
lenguajes que se utilizan de forma directa con Angular (VisualStudio, 2019).
Entre los principales beneficios que supone el desarrollo con Visual Studio Code, están:
Disponibilidad para diferentes Sistemas operativos.
Posee un gran ecosistema de complementos para admitir otros idiomas como C, C
++, C #, Python, entre otros.
Alto grado de personalización en la interfaz.
2.2.3. Motor de Base de Datos.
La rapidez de acceso, integridad y seguridad de datos, es de carácter imperativo en el presente
proyecto de tesis, es por esto que se ha utilizado una base de datos. En este contexto se ha
elegido MySQL como gestor de base de datos (Desde este punto cuando se haga referencia a
12
base de datos se utilizarán sus siglas BD o su texto completo) para la aplicación, dadas sus
principales características:
Alto rendimiento, ya que MySQL puede cumplir con las expectativas de rendimiento de
cualquier sistema.
La integridad de datos completa también está asegurada a través de la integridad
referencial obligadas por el servidor.
Fuerte protección de datos, dado que MySQL provee funcionalidades para asegurar sólo
los usuarios autorizados tienen acceso al servidor. También se proporciona soporte SSH
para asegurar conexiones seguras (Neotek, 2016).
Además de estas características, MySQL se ubica hoy por hoy en el segundo lugar de gestores de
bases de datos más utilizados según BD–Engines (ver figura 4), que es una iniciativa para
recopilar y presentar información sobre trecientos cincuenta sistemas de gestión de bases de
datos (DBMS).
Figura 4. Ranking de Motores de BD 2019 (DB-Engines, 2019)
13
3. Metodología.
3.1. Metodología para desarrollo de Software.
Según Enriquez (2017), una metodología para desarrollo de software es un marco de trabajo para
planificar, estructurar y gestionar, todo el ciclo de vida del sistema. En un proyecto asociado a
programación de software, la metodología ayuda a definir:
Responsables.
Tiempo de ejecución de tareas.
Manera de operar las actividades.
En el campo de programación de aplicaciones, existen dos grupos de metodologías, las
denominadas tradicionales y las ágiles. Las primeras son estrictas debido a su carácter de
documentación extensa y se enfocan en finalizar el plan del proyecto definido en la fase inicial
del desarrollo. Por otro lado, las metodologías de carácter ágil enfatizan el esfuerzo en la
capacidad de respuesta a cambios, las habilidades del equipo y sustentar una buena relación con
el usuario.
Dado que el presente proyecto de tesis está sujeto a cambios e interacción continua con el
usuario, se escoge el enfoque de metodología de tipo ágil para gestionar el desarrollo del mismo.
3.2. Metodologías de desarrollo Ágil de Software.
Según Jiménez (2015), las metodologías de tipo ágil surgen en el año 2001, tras una reunión en
Utah, con la intervención de diez y siete expertos en programación, los cuales manifestaron la
importancia de que los desarrolladores respondieran de forma oportuna a las modificaciones que
se puedan generar a lo largo de la ejecución del proyecto. Todo se basa en el manifiesto ágil, que
es un documento en el que se especifica lo que compete a la filosofía “ágil”.
3.2.1. Manifestó Ágil.
El manifiesto ágil contiene principios que hacen diferente un proyecto de carácter ágil de uno en
su forma tradicional. El manifiesto ágil les da valor a cuatro aspectos específicos (ver figura 5).
14
Figura 5. Valores del Manifiesto ágil (Tipantuña, 2019).
Este manifiesto se rige además por doce principios que ayudan a que el proceso de trabajo sea
más sencillo y de solución a los cambios que surgen a lo largo del mismo.
Jiménez (2015), en su investigacion “Metodologías ágiles para desarrollo de programas aplicadas
a la administración de proyectos empresariales” afirma que las principales metodologías a ser
utilizadas son:
Scrum.
Extreme Programming (XP).
Crystal Clear.
En el análisis realizado por las plataformas de internet Google, Yahoo! y Live, se concluye que
los usuarios toman como preferencia de desarrollo, las metodologías SCRUM, XP, TDD y CM.
La tabla 1, ilustra la cantidad de usuarios que se inclinan por cada una de ellas respectivamente.
15
Tabla 1. Metodologías preferidas en la red.
Número de
Usuarios
SCRUM
Número de
Usuarios
XP
Número de
Usuarios TDD
Número de
Usuarios
CM
Google 3420000 1190000 492000 244000
Yahoo 5120000 4470000 2800000 2330000
Live 1970000 1470000 1040000 7249000
TOTAL
USUARIOS
10510000 7130000 4332000 3298000
Fuente: (Jiménez, 2015).
En este sentido, se puede considerar que las metodologías de carácter ágil SCRUM y XP tienen
un gran nivel de prestigio y alta aceptación entre los usuarios de internet, sin embargo, son
diferentes en ciertos puntos. La tabla 2, define las principales diferencias entre ambas.
Tabla 2. Comparación de M. Scrum y XP.
Metodología XP
Metodología SCRUM.
Ciclos de desarrollo
XP trabaja generalmente en
iteraciones que llevan un tiempo de
una o dos semanas
Se trabaja comúnmente en
iteraciones (Sprints) que
duran de dos semanas o un
mes.
Gestión de cambios
XP puede gestionar cambios, durante
la iteración.
SCRUM no provee
cambios mientras el
sprint este activo.
16
Prácticas de
Ingeniería.
XP recomienda hacer practica de
pruebas para mejorar la calidad del
producto.
Scrum enfoca su trabajo en
la productividad y
establece en si prácticas de
ingeniería.
Dueño del Producto.
En XP, el cliente se denomina el
propietario del producto, y está a
disposición para revisar e incorporar
nuevos requisitos.
En Scrum, la directiva se
comunica con el
propietario del producto y
así configurar las historias
del sprint
Fuente: (Malaviya, 2018)
El tipo de metodología que se implementa en el presente proyecto de tesis, es la metodología XP
pues se adapta al ciclo de trabajo que se requiere en el proyecto, en adición el proyecto necesita
que cambios se realicen entre iteraciones y que se realicen pruebas estrictas sobre el mismo. A
continuación, se describen la definición, características y fases específicas de la metodología XP.
3.3. Metodología de Programación Extrema(XP).
La metodología de programación extrema es una metodología de desarrollo ágil, para llevar a
cabo la gestión de proyectos de manera óptima, flexible y controlada. XP fue echo para realizar
programas que necesiten un numero de programadores no muy extenso, en el cual la
comunicación sea bidireccional de parte de desarrollador y usuario final (Castillo, Figueroa, &
Sevilla, 2018).
3.3.1. Características.
Según Castillo, Figueroa & Sevilla (2018), la metodologia XP posee estas caracteristicas.
Comunicación: El grupo de programadores y directivos, se relaciona con el usuario
final para satisfacer las necesidades del proyecto y realizar modificaciones si es
necesario.
Simplicidad: Se recomienda realizar diseños sencillos, los cuales se enfoquen en
funcionalidad que requiera el usuario.
17
Realimentación: Permite guiar, de tal manera que el equipo de trabajo comunique al
cliente los avances del programa y que el usuario, opine para la conformación en
conjunto del sistema.
Valor: El grupo de trabajo debe enfrentar los desafíos que se presenten a lo largo del
proyecto y dar solución a los mismos.
3.3.2. Fases.
La metodología XP, está compuesta de 4 fases. La figura 6 indica estas fases y los temas que se
toman en cuenta dentro de cada una.
Figura 6. Fases dela metodología XP (Hiebaum, 2015).
A continuación, se redactan los componentes de las fases de la metodología XP.
3.3.2.1. Planeación del proyecto.
El primer componente a tener en cuenta en la implementación de la metodología XP, es la
planeación, la cual conlleva subprocesos, como son las historias de usuario, planeación de
despliegue, lanzamientos, entre otros, los cuales se enfocan en mantener un control del proyecto
mientras se esté ejecutando el desarrollo.
Incremento del software
18
Historias de Usuario HU.
Joskowicz (2008), en su estudio “Reglas y Prácticas en eXtreme Programming”, afirma que
las Historias se realizan como alternativa a las fases de casos de uso. Estas son redactadas por
el usuario final, con resúmenes de lo que el programa debe hacer por ellos. Las historias no
deben mostrar un gran detalle en ellas, solo lo necesario para que el equipo de trabajo realice
una estimación del tiempo que llevará la puesta en marcha.
Planeación de despliegue.
El plan de despliegue genera planes de iteración. El fin de la de planificación de despliegue
es que el equipo de trabajo realice una estimación de cada historia (Wells, 2015).
Planificación de la iteración.
Se realiza al principio de cada iteración para establecer las tareas respectivas.
Pequeños lanzamientos.
Para mantener controlado el proyecto el equipo de trabajo realiza versiones del programa
constantemente. Es recomendable poner en producción una versión cada dos semanas. Al
final de la iteración, se entrega el demo de la versión a los clientes.
Iteraciones.
Las iteraciones proveen agilidad al flujo de trabajo. Generalmente se programa el desarrollo,
en aproximadamente doce iteraciones que constan de un tiempo de 2 semanas (Wells, 2015).
La Figura 7 indica el proceso que cumplen las iteraciones realizadas sobre el flujo de trabajo
del sistema.
19
Figura 7. Diagrama del proceso de Iteraciones XP (Tipantuña, 2015).
Las iteraciones se llevan a cabo comenzando por el plan de lanzamiento de iteración que se
genera tomando en cuenta las historias de usuario, posteriormente se da paso a la planeación
de la iteración en donde se establecen responsabilidades y tareas respectivas. Una vez
concluida la planeación se da paso al desarrollo en donde se mantiene la comunicación con el
usuario final, para verificar si existe algún cambio o situación que haga que la iteración de
replantee. En caso de que se ha
3.3.2.2. Diseño.
El segundo componente de la implementación de la metodología XP es el diseño. A
continuación, se presentan recomendaciones y aspectos importantes que son de utilidad al
momento de realizar la aplicación.
Simplicidad.
Wells (2015), recomienda los diseños sencillos debido a que aportan mucho más que los
complejos, además de utilizar menos tiempo. Siempre se tiene que enfocar en lo más simple
que pueda funcionar. Sin embargo, no se puede medir la simplicidad, por lo que se
recomienda las siguientes características para establecerla:
Comprobable: Quiere decir que es proclive de realizar pruebas para comprobar si
hay problemas. Se recomienda subdividir el programa en unidades comprobables.
20
Navegable: Es decir que se puede encontrar lo que se busca cuando se requiera. Los
nombres de archivos pueden ayudar en esto, siendo representativos.
Comprensible: Que pueda entenderse. Sin embargo, es relativo, por ejemplo, un
equipo que ha estado trabajando con un sistema de mucho tiempo lo entenderá a pesar
de que a alguien nuevo puede estar completamente desconcertado.
Metáfora de Sistema.
La metáfora de sistema es la manera de indicar la arquitectura del programa, explicándolo en
función de algo con lo que los programadores y usuarios finales están familiarizados. Una
metáfora del sistema ayuda a discutir ideas de un proyecto en un lenguaje que sea
comprensible para clientes y desarrolladores. Proporciona a su vez un glosario para explicar
problemas del sistema (Wells, 2015).
Soluciones Spike.
XP, recomienda el uso de soluciones Spike para encontrar respuestas a problemas técnicos
específicos. La solución en cuestión es un procedimiento simple para explorar soluciones a
problemas aislados.
Refactorización.
La refactorización, consiste en eliminar la redundancia, funcionalidad no utilizada y
rediseñar código obsoleto. La refactorización implementada a un proyecto ahorra tiempo y
aumenta la calidad. Se realiza refactorización con el objetivo de mantener un diseño sencillo
del proyecto y evitar tanto desorden y complejidad innecesarios.
21
3.3.2.3. Codificación.
El tercer componente para la correcta implementación de la metodología es la codificación. En
esta sección, se observan sugerencias respecto a la codificación del proyecto, para evitar
problemas comunes que pudiesen desencadenarse.
Cliente disponible.
La presencia continua del cliente, no solo ayuda al equipo de trabajo, sino también al usuario
final. Todas las fases del proyecto requieren interacción con el cliente. Es recomendable que
el cliente tenga subordinados que provean comunicación continua.
El Código debe estar escrito de acuerdo a estándares.
Es sustancial que el código tenga un formato general. Los formatos de codificación
mantienen el código fácil de interpretar para todo el equipo.
Integrar a menudo
Es recomendable subir el código en un repositorio, lo más rápido posible. La integración
continua evita sobre esfuerzos de trabajo que pueden desembocar en desviación de los
objetivos del proyecto.
Usar la propiedad colectiva.
Esta propiedad promueve la colaboración de todos, sobre todo con ideas en todos los
módulos del proyecto. Todos pueden opinar sobre algún cambio en el código para agregar
funcionalidades, solventar errores , optimizar diseños o refactorizar. (Wells, 2015).
3.3.2.4. Pruebas.
Según Wells (2015), las pruebas de aceptación del software se generan en función de las ya
mencionadas historias de usuarios. El usuario final detalla entornos de prueba para
comprobar si las historias se han interpretado de manera correcta. Una historia puede tener
varias pruebas de aceptación, para garantizar que un módulo esté completamente funcional.
Las pruebas de aceptación son en general pruebas de caja negra. Cada prueba representa un
resultado que se espera del programa.
22
4. Desarrollo.
Esta sección consiste en mostrar la implementación de la metodología XP, al presente
proyecto de tesis.
4.1. Fase de Planeación.
4.1.1. Establecimiento de las Historias de Usuario HU.
La fase de planeación, inicia con la creación de las historias de usuario (desde este punto se hace
referencia a las historias de usuario, con las siglas HU o su nombre completo), que se detallan en
las siguientes tablas.
La tabla 3, indica los detalles de la HU referente a la autenticación.
Tabla 3. Historia - 001. Autenticación.
Código Historia: 001
Historia: Autenticación.
Usuario Final: Ing. Verónica Verdezoto.
Iteración asignada: 1
Desarrollador: Henry Tipantuña.
Contenido:
- Se debe generar un inicio de sesión, de tal manera que se ingrese un usuario y contraseña, para
acceder al sistema.
- El sistema verifica si el usuario existe en la BD.
- En caso de que el nombre de usuario o clave son incorrectos, se genera un mensaje de error.
- Al ingresar al sistema se da la opción de cerrar la sesión del usuario
Observaciones: Ninguna
Fuente: Propia.
23
La tabla 4, indica los detalles de la HU de los roles de acceso.
Tabla 4. Historia - 002. Roles de usuario.
Código Historia: 002
Historia: Roles de usuario.
Usuario Final: Ing. Verónica Verdezoto.
Iteración asignada: 1
Desarrollador: Henry Tipantuña.
Contenido:
- El sistema debe contar con tres roles de usuario: Master, Administrador y Estándar.
- El usuario Master accede a las funcionalidades de administración de usuarios, docentes,
materias, laboratorios, reservas y generación de reportes.
- El usuario Administrador está autorizado para configurar las funcionalidades de administración
reservas de laboratorios y generación de reportes.
- El usuario Estándar solamente puede ingresar a la funcionalidad de reportes.
Observaciones: Ninguna
Fuente: Propia.
La tabla 5, corresponde a la HU asociada a la administración de usuarios.
Tabla 5. Historia - 003. Administración de usuarios.
Código Historia: 003
Nombre historia: Administración de usuarios.
Usuario Final: Ing. Verónica Verdezoto.
Iteración asignada: 2
Programador responsable: Henry Tipantuña.
Descripción:
- El usuario Master, que acceda a la administración de usuarios, podrá visualizar a través de una
tabla los nombres, contraseñas y roles de los distintos usuarios que se han creado.
24
- El registro de los datos para la creación de un nuevo usuario, se debe generar a través de un
formulario, que permite la escritura en los campos correspondientes a nombre y contraseña,
ademas de la elección de un rol de usuario en un campo de selección.
- El software permitirá actualizar los datos ingresados, correspondientes a un usuario específico
(nombre, contraseña y tipo de usuario).
- El sistema debe dar la opción de eliminar un usuario.
Fuente: Propia.
La tabla 6, corresponde a la HU asociada a la administración de docentes.
Tabla 6. Historia - 004. Administración de docentes.
Código Historia: 004
Nombre historia: Administración de docentes.
Usuario Final: Ing. Verónica Verdezoto.
Iteración asignada: 2
Programador responsable: Henry Tipantuña.
Descripción:
- El usuario Master, que acceda a la administración de docentes, podrá visualizar a través de una
tabla los nombres, apellidos y cédula de los distintos docentes que se han registrado.
- El registro de los datos para la creación de un nuevo docente, se debe generar a través de un
formulario, que permite la escritura en los campos correspondientes a nombre apellido y
cédula.
- El software permitirá modificar los datos, correspondientes a un docente específico (nombre,
apellido y cédula).
- El sistema debe dar la opción de eliminar un docente.
Observaciones: Ninguna
Fuente: Propia.
25
La tabla 7, muestra la HU asociada a la administración de materias.
Tabla 7. Historia - 005. Administración de materias.
Código Historia: 005
Nombre historia: Administración de materias
Usuario Final: Ing. Verónica Verdezoto.
Iteración asignada: 3
Programador responsable: Henry Tipantuña.
Descripción:
- EL usuario Master, que acceda a la administración de materias, podrá visualizar a través de una
tabla los códigos, nombres, carrera y semestre de las distintas materias que se han registrado.
- El registro de los datos para la creación de una materia, se debe generar a través de un
formulario, que permite la escritura en los campos correspondientes a código, nombre, carrera
y semestre.
- El software permitirá actualizar los datos, correspondientes a una materia específica
- El sistema debe dar la opción de eliminar una materia.
Observaciones: Ninguna
Fuente: Propia.
La tabla 8, indica la HU asociada a la administración de laboratorios.
Tabla 8. Historia - 006. Administración de laboratorios.
Código Historia: 006
Historia: Administración de laboratorios.
Usuario Final: Ing. Verónica Verdezoto.
Iteración asignada: 3
Programador responsable: Henry Tipantuña.
26
Descripción:
- El usuario Master, que acceda a la administración de laboratorios, podrá visualizar a través de
una tabla los códigos, nombres y capacidad de los laboratorios que se han registrado.
- El registro de los datos para la creación de un nuevo laboratorio, se debe generar a través de un
formulario, que permite la escritura en los campos correspondientes a código, nombre y
capacidad.
- El software permitirá modificar los datos, correspondientes a un laboratorio específico.
- El sistema debe dar la opción de eliminar un laboratorio.
Observaciones: Ninguna
Fuente: Propia.
La tabla 9, corresponde a la HU de administración de reserva de l21aboratorios.
Tabla 9. Historia - 007. Administración de reservas de laboratorios.
Código Historia: 007
Nombre historia: Administración de Reservas de laboratorios.
Usuario Final: Ing. Verónica Verdezoto.
Iteración asignada: 4
Programador responsable: Henry Tipantuña.
Descripción:
- Los usuarios Master o Administrador, que accedan a la administración de reserva de
laboratorios, podrán visualizar a través de una tabla los días, horas, docentes, materias y
laboratorios de las diferentes reservas que se han creado.
- El registro de los datos para la creación de una reserva, se debe generar a través de un
formulario, que permite escoger el día, hora, docente, materia, y laboratorio en un campo de
selección.
- El software permitirá modificar los datos, correspondientes a una reserva específica.
- El sistema debe dar la opción de eliminar una reserva.
- El usuario será capaz de borrar todas las reservas de los laboratorios haciendo clic en un botón.
- El usuario podrá realizar la búsqueda de una reserva, a través del día y o nombre de laboratorio
27
de la reserva.
Observaciones: Ninguna
Fuente: Propia.
La tabla 10, corresponde a la HU asociada a la generación de reportes.
Tabla 10. Historia - 008. Generación de Reportes
Código Historia: 008
Nombre historia: Generación de reportes.
Usuario Final: Ing. Verónica Verdezoto.
Iteración asignada: 5
Programador responsable: Henry Tipantuña.
Descripción:
- Los usuarios Master, Administrador o Estándar, que accedan a la funcionalidad de generación
de reportes, podrán escoger entre dos tipos de reportes, el primero se basa en una tabla de doble
entrada tipo horario, que según el laboratorio que se indique en un campo de selección, muestre
el docente, materia y carrera de cada una de las reservas realizadas en ese laboratorio. El
segundo reporte es una tabla de doble entrada tipo horario, que según el nombre de docente que
sea ingrese en un campo de selección, muestre el laboratorio docente y materia de cada reserva
asociada a ese docente.
- Debajo de los dos tipos de reportes generados, el sistema debe dar la opción de transformar el
reporte a un archivo PDF, para su posterior impresión.
Observaciones: Ninguna
Fuente: Propia.
28
4.1.2. Planificación de despliegue de Iteraciones.
A continuación, se muestra como se gestionan las iteraciones, a lo largo del desarrollo del
sistema y el tiempo aproximado de cada una.
Tabla 11. División de HU en iteraciones.
ITERACIÓN.
Historia de Usuario
Duración.
1
001. Autenticación.
002. Roles de Usuarios.
2 Semanas.
2
003.Administracion de
Usuarios.
004.Administracion de
Docentes.
3 Semanas.
3
005.Administracion de
Materias.
006. Administración de
Laboratorios.
3 Semanas.
4
007.Administracion de
Reservas de Laboratorios.
2 Semanas.
5
008. Generación de Reportes. 4 Semanas.
Fuente: Propia.
29
4.2. Fase de Diseño.
4.2.1. Estructura General del Proyecto.
La figura 8 muestra la arquitectura específica para el presente proyecto de tesis.
4.2.2. Diseño de interfaces en las páginas web.
A continuación, se muestran las interfaces de usuario del presente proyecto de tesis, las cuales
fueron creadas a partir de la colaboración del cliente dando a conocer sus requerimientos y
consecuentemente la intervención del autor del proyecto para desarrollarlas.
La aplicación implementa en las interfaces de usuario los estilos del framework Bootstarp 4 y
CSS 3, además de Angular Material 8.0.1 en los cuadros de diálogo, y los iconos de la fuente
Web Font Awesome 5.9.
Figura 8. Estructura general del proyecto (Tipantuña, 2019)
30
Inicio de Sesión.
La figura 9, representa la interfaz de usuario asociada a la autenticación de la aplicación.
Figura 9. Página de autenticación de la aplicación (Tipantuña, 2019).
Ingreso al sistema – Usuario Master.
La figura 10 corresponde a la interfaz de usuario para los usuarios de tipo Master.
31
Figura 10. Página de ingreso al sistema rol Master (Tipantuña, 2019).
Ingreso al sistema – Usuario Administrador.
En caso de que el usuario que se a autenticado es de tipo administrador, la pantalla de ingreso a
la aplicación es tal y como muestra la figura 11.
Figura 11. Página de ingreso al sistema rol Administrador (Tipantuña, 2019).
32
Ingreso al sistema – Usuario Estándar.
La figura 12, muestra la interfaz de usuario para los usuarios de tipo Estándar.
Figura 12. Página de ingreso al sistema rol Estándar (Tipantuña, 2019).
Administración de Usuarios
Administración de Usuarios - Visualización.
La figura 13 muestra la interfaz de visualización de la administración de usuarios.
Figura 13. Interfaz de visualización de usuarios (Tipantuña, 2019).
33
Administración de Usuarios - Creación.
La figura 14 corresponde a la interfaz de creación para la administración de usuarios.
Figura 14. Interfaz para la creación de nuevo usuario (Tipantuña, 2019).
Administración de Usuarios - Edición.
La figura 15 hace referencia a la interfaz de edición para la administración de usuarios.
Figura 15. Interfaz de edición de usuario (Tipantuña, 2019).
34
Administración de Docentes.
Administración de Docentes - Visualización.
La figura 16 ilustra la interfaz de visualización de la administración de usuarios.
Figura 16. Interfaz de visualización de docente (Tipantuña, 2019).
Administración de Docentes - Creación.
La figura 17 corresponde a la interfaz de creación para la administración de docentes.
Figura 17. Interfaz de creación de docente (Tipantuña, 2019).
35
Administración de Docentes - Edición.
La figura 18 muestra la interfaz de edición para la administración de docentes.
Figura 18. Interfaz de edición de docente (Tipantuña, 2019).
Administración de Materias.
Administración de Materias - Visualización.
En la figura 19 se muestra la pantalla de visualización para la administración de Materias.
Figura 19. Interfaz de visualización de materias (Tipantuña, 2019).
36
Administración de Materias - Creación.
La figura 20 corresponde a la pantalla de creación para la administración de Materias.
Figura 20. Interfaz de creación de materia (Tipantuña, 2019).
Administración de Materias - Edición.
La figura 21 corresponde a la pantalla de edición para la administración de Materias.
Figura 21. Interfaz de edición materia (Tipantuña, 2019).
37
Administración de Laboratorios.
Administración de Laboratorios - Visualización.
La figura 22 muestra la interfaz de visualización de la administración de laboratorios.
Figura 22. Interfaz de visualización de laboratorios (Tipantuña, 2019).
Administración de Laboratorios - Creación.
La figura 23 corresponde a la interfaz de creación para la administración de laboratorios.
38
Figura 23. Interfaz de creación de laboratorios (Tipantuña, 2019).
Administración de Laboratorios - Edición.
La figura 24 hace referencia a la interfaz de edición para la edición de laboratorios.
Figura 24. Interfaz de edición de laboratorios (Tipantuña, 2019).
39
Administración de Reservas
Administración de Reservas - Visualización.
La figura 25 indica la página donde se visualizan las reservas de los laboratorios.
Figura 25. Interfaz de visualización de reservas de laboratorios (Tipantuña, 2019).
40
Administración de Reservas - Creación.
La figura 26 corresponde a la interfaz de creación para la administración de reservas.
Figura 26. Interfaz de Creación de reservas de laboratorios (Tipantuña, 2019).
Administración de Reservas - Edición.
La figura 27 hace referencia a la interfaz de edición para la administración de reservas.
41
Figura 27. Interfaz de edición de reservas de laboratorios (Tipantuña, 2019).
Reporte de Reservas filtrado por Laboratorio.
La figura 28 indica como se ve la interfaz de generación de reportes de reservas de laboratorios
filtrado por laboratorio.
42
Figura 28. Reporte de reservas filtrado por laboratorio (Tipantuña, 2019).
43
La transformación del reporte a PDF se muestra en la figura 29.
Figura 29. Transformación del reporte a archivo PDF (Tipantuña, 2019).
44
Reporte de Reservas filtrado por Docente.
En la figura 30 se indica como se ve la interfaz de generación de reportes de reservas de
laboratorios filtrado por docente.
Figura 30. Reporte de reservas filtrado por docente (Tipantuña, 2019).
45
La transformación del reporte a PDF se muestra en la figura 31.
Figura 31. Transformación del reporte a archivo PDF (Tipantuña, 2019).
46
4.2.3. Diseño de BD.
Como se especificó en el apartado de Herramientas y tecnologías, se utiliza la BD MySQL, para
la persistencia de datos del sistema. El diagrama entidad relación, se generó a través del uso de la
herramienta MySQL Workbench 6.3 (ver figura 32).
Figura 32. Diagrama entidad relación de BD (Tipantuña, 2019).
47
4.2.3.1. Diccionario de datos.
A continuación, se muestran el diccionario de datos asociado al banco de datos del presente
proyecto de tesis.
La tabla indica el diccionario de datos de la tabla materia.
Tabla 12. Diccionario de datos de la tabla materia.
Tabla Materia.
Nombre
Campo
Descripción Tipo dato. Longitud Mandatory
Field
Required
Field
Otras
validaciones
Id Identificación
única de la
materia
INT 11 X X El campo es
obligatorio para
el registro.
Valor por
defecto 0
Carrera Nombre de la
carrera a la que
pertenece la
materia.
VARCHAR 50 Se ingresan las
carreras:
Economía,
Finanzas y
Estadística.
Valor por
defecto NULL
Cod_materia Código
identificador
de la materia
en la carrera
VARCHAR 50 El código es
establecido por
la carrera.
Valor por
defecto NULL.
Name_materia Nombre por el
que se
identifica la
materia.
VARCHAR 50 El nombre de la
materia es
asignado por la
carrera. Valor
por defecto
NULL
48
Semestre Semestre al
cual pertenece
la materia
VARCHAR 50 Se ingresan los
semestres de
primero a
noveno. Valor
por defecto
NULL.
Fuente: propia.
A continuación, se indica la tabla que ilustra el diccionario de datos de la tabla docente.
Tabla 13. Diccionario de datos de la tabla docente.
Tabla Docente.
Nombre
Campo
Descripción Tipo dato. Longitud Mandatory
Field
Required
Field
Otras
validaciones
Id Identificación
única del
docente
INT 11 X X El campo es
obligatorio
para el
registro. Valor
por defecto
Cédula Número de
identificación
de ciudadanía
del docente
VARCHAR 50 Consta de 10
caracteres
numéricos.
Valor por
defecto NULL
Nombre Nombre del
docente
VARCHAR 50 Valor por
defecto NULL
Apellido Apellido del
docente
VARCHAR 50 Valor por
defecto NULL
Fuente: propia.
49
A continuación, se indica la tabla que ilustra el diccionario de datos de la tabla docente_materia.
Tabla 14. Diccionario de datos de la tabla cruzada docente y materia.
Tabla Docente_materia.
Nombre
Campo
Descripción Tipo dato. Longitud Mandatory
Field
Required
Field
Otras
validaciones
Docente_Id Identificación
única del
docente
INT 11 X X El campo es
obligatorio para
el registro. Valor
por defecto 0
Materia_id Identificación
única de la
materia
INT 11 X X El campo es
obligatorio para
el registro. Valor
por defecto 0
Fuente: propia.
Tabla 15. Diccionario de datos de la tabla laboratorio.
Tabla Laboratorio.
Nombre
Campo
Descripción Tipo dato. Longitud Mandatory
Field
Required
Field
Otras
validaciones
Id Identificación
única del
laboratorio.
INT 11 X X El campo es
obligatorio
para el
registro. Valor
por defecto 0
Capacidad Cantidad de
ordenadores
disponibles
INT 11 X Valor por
defecto
Cod_laboratorio Código
identificador
del
laboratorio.
VARCHAR 50 Valor por
defecto NULL
50
Nombre_laboratorio Nombre por el
que se
identifica el
laboratorio.
VARCHAR 50 Valor por
defecto NULL
Fuente: propia
Tabla 16. Diccionario de datos de la tabla docente.
Tabla Docente.
Nombre
Campo
Descripción Tipo dato. Longitud Mandatory
Field
Required
Field
Otras
validaciones
Id Identificación
única de la
reserva.
INT 11 X X El campo es
obligatorio
para el
registro.
Valor por
defecto 0
Día Día de la
semana en que
se ha realizado
la reserva.
VARCHAR 50 Los días son
de lunes a
viernes. Valor
por defecto
NULL
Hora Hora de inicio
y fin de la
reserva.
VARCHAR 50 El tiempo
entre horas es
de dos horas.
Valor por
defecto NULL
Docente_id Identificación
única del
docente.
INT 11 Valor por
defecto 0
Laboratorio_id Identificación
única del
laboratorio.
INT 11 Valor por
defecto 0
51
Materia_id Identificación
única materia
INT 11 Valor por
defecto 0
Fuente: propia.
Tabla 17. Diccionario de datos de la tabla usuario.
Tabla Usuario.
Nombre
Campo
Descripción Tipo dato. Longitud Mandatory
Field
Required
Field
Otras
validaciones
Id Identificación
única del
usuario.
INT 11 X X Valor por
defecto 0. El
campo es
obligatorio
para el registro
Name_user Nombre de
usuario
VARCHAR 50 Valor por
defecto NULL
Rol_user Password del
usuario.
VARCHAR 50 Valor por
defecto NULL
User_rol Id del rol de
usuario.
INT 11 Valor por
defecto NULL
Fuente: propia.
Tabla 18. Diccionario de datos de la tabla UserRol.
Tabla UserRol.
Nombre
Campo
Descripción Tipo dato. Longitud Mandatory
Field
Required
Field
Otras
validaciones
Id Identificación
única del rol de
usuario.
INT 11 X X El campo es
obligatorio para
el registro.
Valor por
defecto 0.
User_rol Nombre del rol
de usuario.
VARCHAR 50 Los nombres
pueden ser
52
MASTER,
ADMIN y
ESTANDAR.
Valor por
defecto NULL.
5 Fuente: propia.
5.2. Fase de Pruebas.
Las pruebas realizadas sobre los sistemas tienen gran importancia para la obtención de
aplicaciones, que se caracterizan por la calidad. En este contexto esta sección se centra en
realizar pruebas de caja negra, pruebas en navegadores y pruebas de carga en la aplicación con el
fin de detectar fallas de funcionamiento y realizar las respectivas acciones correctivas según sea
el caso.
5.2.1. Pruebas de caja negra.
Es una categoría de pruebas de software en donde funcionalidad se evalúa dejando de lado la
estructura interna de código o detalles de implementación. Estas pruebas se enfocan en las
entradas y salidas de información en el programa (Terrera, 2017). A continuación, se muestran
las pruebas de caja negra correspondientes al presente proyecto de tesis.
La tabla 19 hace referencia a la prueba de inicio de sesión o autenticación de usuarios.
Tabla 19. Prueba para la autenticación de usuarios.
Caso de Prueba: Autenticación de usuarios
Responsable: Henry Tipantuña.
Propósito: Comprobar el funcionamiento de inicio de sesión de los distintos tipos de usuarios.
Prerrequisitos: El usuario debe haber iniciado la aplicación y estar en la dirección de inicio
de la página web.
Datos de entrada: Credenciales de usuario (usuario y contraseña)
Procedimiento:
1. Ingresar el usuario en el campo de texto UserName.
2. Ingresar la contraseña en el campo de password.
3. Presionar el botón Ingresar.
53
Resultado esperado:
- El usuario ingresará al sistema solamente cuando sus credenciales están registradas en
la BD.
- Cada tipo de usuario (Master, Administrador o Estándar) ingresará a su
correspondiente interfaz.
- Si las credenciales de usuario ingresadas, no están correctamente ingresadas el sistema
le mostrará un mensaje de error cuando presione el botón Ingresar.
Resultado Obtenido:
- El sistema da el paso solamente a usuarios registrados en la base.
- Cada tipo de usuario accede correctamente a su respectiva interfaz.
- El sistema no permite el ingreso al sistema si las credenciales de usuario son
incorrectas e indica con un mensaje cuando esto ocurra.
Estado del caso de prueba: Correcto.
Fuente: Propia.
La tabla 20 corresponde a la prueba de administración de usuarios.
Tabla 20. Prueba asociada a la administración de usuarios
Caso de Prueba: Administración de usuarios.
Responsable: Henry Tipantuña.
Propósito: Comprobar el funcionamiento y comportamiento del módulo de administración de
usuarios.
Prerrequisitos: El usuario ya ha ingresado al sistema como Master.
Datos de entrada: Nombre, contraseña y rol del usuario.
Procedimiento:
- Creación de usuario.
1. Elegir la opción Administración de la barra de navegación en la página.
2. Escoger la opción Usuarios.
3. Hacer clic sobre el botón crear usuario.
4. Ingresar el nombre, contraseña y rol de usuario en los campos de texto
correspondientes.
54
5. Clicar en el botón Crear.
- Edición de usuario.
1. Elegir la opción Administración de la barra de navegación en la página.
2. Escoger la opción Usuarios.
3. Cliquear sobre la imagen para editar el usuario correspondiente.
4. Escribir los datos que se han de modificar sobre los campos de texto y el campo de
selección.
5. Presionar el botón Editar.
- Eliminación de usuario
1. Elegir la opción Administración de la barra de navegación en la página.
2. Escoger la opción Usuarios.
3. Cliquear sobre la imagen para eliminar el usuario correspondiente.
Resultado esperado:
- El botón crear solamente se habilitará si se llenan los tres campos de nombre,
contraseña y rol de usuario.
- En caso de que no se llene uno o más campos del formulario se generará un mensaje
que indica que los campos son requeridos.
- Si se han registrado los campos del formulario correctamente, al presionar el botón
crear, el sistema actualizará la tabla de usuarios con la información del nuevo usuario
creado.
- El botón de edición de usuario solamente se habilitará si los campos están llenos.
- Si un campo del formulario no tiene contenido, se generará un mensaje para informarle
al usuario que el campo es requerido.
- Dado que se han ingresado los campos correctamente, al clicar en el botón editar el
sistema actualizará la tabla con la información del usuario modificado.
- Al cliquear en la imagen de eliminación de usuario, la tabla se actualizará sin el
usuario que se ha decidido eliminar.
Resultado Obtenido:
- El sistema no habilita la creación de usuarios cuando uno o más de los campos del
formulario están vacíos.
55
- Los campos que no están llenos generan un mensaje que le informa al usuario que
estos son requeridos.
- Dado que los campos se han ingresado correctamente, al hacer un clic sobre el botón
crear, el sistema actualiza la tabla con la información del nuevo usuario.
- El sistema no habilita el botón editar, cuando uno o más de los campos del formulario
están vacíos.
- Los campos que estén vacíos generan un mensaje que le permite al usuario conocer que
estos son requeridos.
- Si los campos del formulario se han ingresado correctamente, al cliquear en el botón
editar, el sistema actualiza la tabla con la información del usuario modificado.
- Cuando se presiona el botón eliminar, la tabla se modifica sin los datos del usuario
eliminado.
Estado del caso de prueba: Correcto.
Fuente: Propia.
La tabla 21 corresponde a la prueba de administración de docentes.
Tabla 21. Caso de prueba para el módulo de administración de docentes
Caso de Prueba: Administración de docentes.
Responsable: Henry Tipantuña.
Propósito: Comprobar el funcionamiento y comportamiento del módulo de administración de
docentes.
Prerrequisitos: El usuario ya ha ingresado al sistema como Master.
Datos de entrada: Nombre, apellido y cedula del docente.
Procedimiento:
- Creación de docente.
1. Elegir la opción Administración de la barra de navegación en la página.
2. Escoger la opción Docentes.
3. Clicar sobre el botón crear docente.
4. Ingresar el nombre, apellido y cédula en los campos de texto correspondientes.
5. Cliquear en el botón Crear.
56
- Edición de docente.
1. Elegir la opción Administración de la barra de navegación en la página.
2. Escoger la opción Docentes.
3. Hacer clic sobre la imagen para editar el docente correspondiente.
4. Escribir la información que se ha de modificar sobre los campos de texto.
5. Clicar sobre el botón Editar.
- Eliminación de docente.
1. Elegir la opción Administración de la barra de navegación en la página.
2. Escoger la opción Docentes.
3. Clicar sobre la imagen para eliminar el docente correspondiente.
Resultado esperado:
- El botón crear solamente se habilitará si se llenan los tres campos de nombre, apellido
y cédula de docente correctamente.
- En caso de que no se llene uno o más campos del formulario se generará un mensaje
que indica que los campos son requeridos.
- Si se han registrado los campos del formulario correctamente, al presionar el botón
crear, el sistema actualizará la tabla de docentes con la información del nuevo docente
creado.
- El botón de edición de docente solamente se habilitará si los campos están llenos y el
campo de cédula se llena con caracteres numéricos cuya longitud sea de diez
caracteres.
- Si un campo del formulario no tiene contenido, se generará un mensaje para informarle
al usuario que el campo es requerido, en adición si el campo cédula se llena con
caracteres no numéricos y de longitud diferente de diez también se muestra un mensaje
al usuario indicando la invalidez de la información ingresada.
- Dado que se han ingresado los campos correctamente, al presionar el botón editar el
sistema actualizará la tabla con los datos del docente modificado.
- Al cliquear en la imagen de eliminación de docente, la tabla se actualizará sin el
docente que se ha decidido eliminar.
57
Resultado Obtenido:
- El sistema no habilita el botón crear, cuando uno o más de los campos del formulario
están vacíos.
- Los campos del formulario de creación que no tengan contenido le indican al usuario
mediante un mensaje que estos son requeridos.
- Dado que los campos se han ingresado correctamente, al hacer un clic en el botón
crear, el sistema actualiza la tabla con los datos del nuevo docente.
- El sistema no habilita el botón editar cuando uno o más de los campos del formulario
están vacíos.
- Los campos del formulario de edición que estén vacíos generan un mensaje que le
permite al usuario conocer que estos son requeridos.
- Si los campos del formulario se han ingresado correctamente, al presionar el botón
editar, el sistema actualiza la tabla con la información del docente modificado.
- Cuando se presiona el botón eliminar, la tabla se modifica sin la información del
docente eliminado.
Estado del caso de prueba: Correcto.
Fuente: Propia.
A continuación, se indica las pruebas realizadas sobre el módulo de administración de materias
(ver tabla 22).
Tabla 22. Pruebas sobre el módulo de administración de materias
Caso de Prueba: Administración de materias.
Responsable: Henry Tipantuña.
Propósito: Comprobar el funcionamiento y comportamiento del módulo de administración de
materias.
Prerrequisitos: El usuario ya ha ingresado al sistema como Master.
Datos de entrada: Código, nombre, carrera y semestre de la materia.
Procedimiento:
- Creación de materia.
1. Elegir la opción Administración de la barra de navegación en la página.
58
2. Escoger la opción Materias.
3. Ejecutar el botón crear materia.
4. Ingresar el código, nombre, carrera y semestre en los campos de texto
correspondientes.
5. Clicar en el botón Crear.
- Edición de materia.
1. Elegir la opción Administración de la barra de navegación en la página.
2. Escoger la opción Materias.
3. Cliquear sobre la imagen para editar la materia respectiva.
4. Escribir la información que se ha de modificar sobre los campos de texto.
5. Ejecutar el botón Editar.
- Eliminación de materia.
1. Elegir la opción Administración de la barra de navegación en la página.
2. Escoger la opción Materias.
3. Cliquear sobre la imagen para eliminar la materia correspondiente.
Resultado esperado:
- El botón crear solamente se habilitará si se llenan los campos de código, nombre,
carrera y semestre de la materia.
- En caso de que no se llene uno o más campos del formulario se generará un mensaje
que indica que los campos son requeridos.
- Si se han registrado los campos del formulario correctamente, al ejecutar el botón
crear, el sistema actualizará la tabla de materias con la información de la nueva materia
creada.
- El botón de edición de materia solamente se habilitará si todos los campos están llenos.
- Si un campo del formulario no tiene contenido, se generará un mensaje para informarle
al usuario que el campo es requerido.
- Dado que se han ingresado los campos correctamente, al ejecutar el botón editar, el
sistema actualizará la tabla con la información de la materia modificada.
- Al clicar en la imagen de eliminación de materia, la tabla se actualizará sin la materia
que se ha decidido eliminar.
59
Resultado Obtenido:
- El sistema no permite creación de materias cuando uno o más de los campos del
formulario están vacíos.
- Si es que no se llena uno o más campos del formulario de creación se genera un
mensaje que alerta al usuario de que estos requeridos.
- Dado que los campos se han ingresado correctamente, al ejecutar el botón crear, el
sistema actualiza la tabla con los datos del nuevo usuario.
- El sistema no permite editar usuarios cuando uno o más de los campos del formulario
de edición están vacíos.
- En el escenario de no llenarse uno o más campos del formulario se genera un mensaje
que le indica al usuario de que estos requeridos.
- Si los campos del formulario se han ingresado correctamente, al ejecutar en el botón
editar, el sistema actualiza la tabla con la información de la materia modificada.
- Cuando se presiona el botón eliminar, la tabla se modifica sin la información de la
materia eliminada.
Estado del caso de prueba: Correcto.
Fuente: Propia.
A continuación, la tabla 23 muestra las pruebas realizadas sobre el módulo de administración de
laboratorios.
Tabla 23. Prueba sobre el módulo de administración de laboratorios.
Caso de Prueba: Administración de laboratorios.
Responsable: Henry Tipantuña.
Propósito: Comprobar el funcionamiento y comportamiento del módulo de administración de
laboratorios.
Prerrequisitos: El usuario ya ha ingresado al sistema como Master.
Datos de entrada: Código, nombre y capacidad del laboratorio.
Procedimiento:
- Creación de materia.
60
1. Elegir la opción Administración de la barra de navegación en la página.
2. Escoger la opción Laboratorios.
3. Cliquear sobre el botón crear laboratorio.
4. Ingresar el código, nombre y capacidad en los campos de texto correspondientes.
5. Hacer un clic en el botón Crear.
- Edición de materia.
1. Elegir la opción Administración de la barra de navegación en la página.
2. Escoger la opción Laboratorios.
3. Cliquear sobre la imagen para editar el laboratorio respectivo.
4. Escribir la información que se ha de modificar sobre los campos de texto.
5. Ejecutar el botón Editar.
- Eliminación de materia.
1. Elegir la opción Administración de la barra de navegación en la página.
2. Escoger la opción Laboratorios.
3. Clicar sobre la imagen para eliminar el laboratorio correspondiente.
Resultado esperado:
- El botón crear solamente se habilitará si se llenan los campos de código, nombre y
capacidad del laboratorio correctamente.
- Si es que no se llena uno o más campos del formulario de creación se genera un
mensaje que alerta al usuario de que estos requeridos.
- En caso de que no se llene uno o más campos del formulario se generará un mensaje
que indica que los campos son requeridos, en adición si el campo capacidad se llena
con campos no numéricos el sistema indicará con un mensaje al usuario, que solamente
ingrese caracteres numéricos.
- Si se han registrado los campos del formulario correctamente, al presionar el botón
crear, el sistema actualizará la tabla de laboratorios con la información del nuevo
laboratorio creado.
- El botón de edición de laboratorio solamente se habilitará si todos los campos están
llenos.
- Si un campo del formulario no tiene contenido, se generará un mensaje para informarle
61
al usuario que el campo es requerido, así mismo si el campo de capacidad se llena con
caracteres no numéricos el sistema le presenta al usuario un mensaje de error indicando
la invalidez de la información ingresada.
- Dado que se han ingresado los campos correctamente, al ejecutar el botón editar, el
sistema actualizará la tabla con la información del laboratorio modificado.
- Al cliquear en la imagen de eliminación de laboratorio, la tabla se actualizará sin el
laboratorio que se ha decidido eliminar.
Resultado Obtenido:
- El sistema no permite creación de laboratorios cuando uno o más de los campos del
formulario están vacíos o cuando el campo de capacidad no sea numérico.
- Si es que no se llena uno o más campos del formulario de creación se genera un
mensaje que alerta al usuario de que estos requeridos.
- Dado que los campos se han ingresado correctamente, al presionar el botón crear, el
sistema actualiza la tabla con la información del nuevo laboratorio.
- El sistema no permite editar laboratorios cuando uno o más de los campos del
formulario están vacíos o cuando el campo de capacidad no sea numérico.
- Los campos del formulario de edición que estén vacíos generan un mensaje que le
permite al usuario conocer que estos son requeridos.
- Si los campos del formulario se han ingresado correctamente, al presionar en el botón
editar, el sistema actualiza la tabla con la información del laboratorio modificado.
- Cuando se presiona el botón eliminar, la tabla se modifica sin la información del
laboratorio eliminado.
Estado del caso de prueba: Correcto.
Fuente: Propia.
La tabla 24 hace referencia a las pruebas realizadas en el módulo de administración de reservas
de laboratorios.
Tabla 24. Pruebas sobre el módulo de reservas de laboratorios.
Caso de Prueba: Administración de reservas de laboratorios.
Responsable: Henry Tipantuña.
Propósito: Comprobar el funcionamiento y comportamiento del módulo de administración de
62
reservas laboratorios.
Prerrequisitos: El usuario ya ha ingresado al sistema como Master o Administrador.
Datos de entrada: Día, hora, docente, materia y laboratorio de la reserva del laboratorio.
Procedimiento:
- Creación de materia.
1. Elegir la opción Horarios de la barra de navegación en la página.
2. Escoger la opción Reservar Laboratorio.
3. Presionar un clic sobre el botón crear reserva.
4. Escoger el día, hora, docente, materia y laboratorio en los respectivos campos de
selección del formulario.
5. Cliquear en el botón Crear.
- Edición de materia.
1. Elegir la opción Horarios de la barra de navegación en la página.
2. Escoger la opción Reservar Laboratorio.
3. Hacer clic sobre la imagen para editar la reserva correspondiente.
4. Elegir los datos que se han de modificar sobre los campos de selección en el
formulario.
5. Cliquear sobre el botón Editar.
- Eliminación de materia.
1. Elegir la opción Horarios de la barra de navegación en la página.
2. Escoger la opción Reservar Laboratorio.
3. Cliquear sobre la imagen para eliminar la reserva correspondiente.
Resultado esperado:
- El botón crear, solamente se habilitará si se seleccionan todos los campos del
formulario.
- En caso de que no se registre uno o más campos del formulario, se generará un
mensaje que indica que los campos son requeridos.
- Si se han registrado los campos del formulario correctamente, al ejecutar el botón
crear, el sistema actualizará la tabla de reservas de laboratorios con la información de
la nueva reserva creada.
63
- El botón de edición de reserva de laboratorio solamente se habilitará si todos los
campos están llenos.
- Si un campo del formulario no tiene contenido, se generará un mensaje para informarle
al usuario que el campo es requerido.
- Dado que se han ingresado los campos, al presionar el botón editar, el sistema
actualizará la tabla con la información de la reserva modificada.
- Al cliquear en la imagen de eliminación de reserva, la tabla se actualizará sin la
reserva que se ha decidido eliminar.
Resultado Obtenido:
- El sistema no habilita el botón de creación de reservas de laboratorios cuando uno o
más de los campos del formulario están vacíos.
- Si es que no se llena uno o más campos del formulario de creación se genera un
mensaje que alerta al usuario de que estos requeridos.
- Dado que los campos se han ingresado correctamente, al presionar el botón crear, el
sistema actualiza la tabla con la información de la nueva reserva.
- El sistema no habilita el botón editar de las reservas de laboratorios cuando uno o más
de los campos del formulario están vacíos.
- Si los campos del formulario se han ingresado, al ejecutar el botón editar, el sistema
actualiza la tabla con la información de la reserva modificada.
- Los campos del formulario de edición que estén vacíos generan un mensaje que le
permite al usuario conocer que estos son requeridos.
- Cuando se presiona el botón eliminar, la tabla se modifica sin la información de la
reserva eliminada.
Estado del caso de prueba: Correcto.
La tabla 25 corresponde a las pruebas realizadas en el módulo de reportes de reservas de
laboratorios.
Tabla 25. Pruebas del módulo de reportes de reservas de laboratorios.
Caso de Prueba: Reportes de reservas de laboratorios.
Responsable: Henry Tipantuña.
64
Propósito: Comprobar el funcionamiento del módulo de reportes de reservas de laboratorios.
Prerrequisitos: El usuario ya ha ingresado al sistema como Master, Administrador o
Estándar.
Datos de entrada: Nombre de laboratorio y nombre de docente.
Procedimiento:
- Reporte por Laboratorio.
1. Seleccionar la opción Reportes de la barra de navegación en la página.
2. Escoger la opción Reporte por laboratorio.
3. Elegir el laboratorio del cual quiere generar el reporte de reserva en el campo de
selección correspondiente.
4. Clicar en el botón buscar.
5. Ejecutar el botón generar reporte.
- Reporte por Docente.
1. Seleccionar la opción Horarios de la barra de navegación en la página.
2. Escoger la opción Reporte por docente.
3. Elegir el docente del cual quiere generar el reporte de reserva en el campo de
selección correspondiente.
4. Cliquear el botón buscar.
5. Hacer un clic en el botón generar reporte.
Resultado esperado:
- Después de elegir un laboratorio el sistema generará una tabla tipo horario en la que se
especifique el día, hora, docente, materia y carrera de las respectivas reservas
realizadas en ese laboratorio.
- Al presionar el botón generar reporte se descargará un archivo PDF, que contiene la
tabla tipo horario de las reservas realizadas en ese laboratorio.
- Después de elegir un docente el sistema generará una tabla tipo horario en la que se
especifique el laboratorio, nombre de docente y materia de las respectivas reservas
realizadas para ese docente.
- Al ejecutar el botón generar reporte se descargará un archivo PDF, que contiene la
65
tabla tipo horario de las reservas asociadas al docente.
Resultado Obtenido:
- El sistema permite visualizar una tabla tipo horario en donde se encuentra los datos
respecto a día, hora, docente, materia y carrera de las reservas asociadas a un
laboratorio especifico.
- Al clicar en el botón generar reporte se descarga en efecto un archivo PDF en el que se
encuentra la tabla con la información de las reservas en el correspondiente laboratorio.
- El sistema permite visualizar una tabla tipo horario en donde se encuentra la
información de laboratorio, nombre de docente y materia de las reservas asociadas a un
docente especifico.
- Al ejecutar el botón generar reporte se descarga un archivo PDF en el que se encuentra
la tabla con la información de las reservas correspondientes a un determinado docente.
Estado del caso de prueba: Correcto.
5.2.2. Pruebas sobre navegadores.
Es muy común en la realización de programas web, que antes del lanzamiento de la aplicación a
producción se evalué como responde la aplicación en diferentes buscadores. En este sentido se
verifica que los componentes web se rendericen de forma correcta en el buscador de internet
(DiligentTeam, 2019).
Para el presente proyecto de tesis se especifican pruebas realizadas en los navegadores Chrome
versión 75.0.3770.100, Firefox versión 67.0.4, Microsoft Edge versión 42.17134.1.0, dado que
son los navegadores que utiliza la Unidad de Tecnologías en sus respectivos ordenadores. A
continuación, se resume el resultado de las pruebas.
Google Chrome.
Las pruebas del sistema realizadas en Google Chrome, no dieron inconvenientes en las interfaces
o funcionamiento, la figura 33 muestra la interfaz de autentificación en el navegador Chrome.
66
Figura 33. Interfaz de autenticación en Chrome (Tipantuña, 2019).
Mozilla Firefox.
Las pruebas del sistema realizadas en Mozilla Firefox, presentaron un problema de funcionalidad
en la creación de usuarios, debido a que la versión del navegador tiene protección en los campos
de tipo password. En este sentido se optó por instalar una versión nueva del navegador lo que
resolvió el problema. A continuación, se muestra el inicio de sesión en la versión actualizada de
Firefox.
Figura 34. Interfaz de autenticación en Mozilla Firefox (Tipantuña, 2019).
67
Microsoft Edge.
Las pruebas del sistema realizadas en Microsoft Edge, no presentaron inconvenientes en las
interfaces o funcionamiento. En la figura 35 se observa la interfaz de login del sistema.
Figura 35. Interfaz de autenticación en Mozilla Firefox (Tipantuña, 2019).
5.2.3. Load Test.
Para realizar las pruebas de carga en el sistema se utilizó el programa SoapUI 5.5.0, que realizara
el test sobre los servicios web REST, que publica el servidor. Según Sudeesh (2012), el informe
de la prueba de carga, brinda información de tiempos de solicitud en milisegundos además de
otros detalles de la simulación como:
min: el tiempo más corto que ha tomado una solicitud.
máx: el tiempo más largo que una solicitud ha tomado.
avg: el tiempo promedio entre solicitudes.
last: tiempo de la última solicitud.
tps: el número de transacciones por segundo en las solicitudes.
bytes: el número de bytes procesados en las solicitudes.
bps: los bytes por segundo procesados en las solicitudes.
err: el número de errores de confirmación en las solicitudes.
68
Debido al extenso número de servicios REST que se implementan en la aplicación, solamente se
hace énfasis en el servicio de creación de reservas de laboratorios, porque es el que genera más
carga de datos al momento de realizar la solicitud POST.
El formato JSON implementado, para enviar solicitudes de creación de reservas se ilustra en la
imagen.
Figura 36. Solicitud de creación de reserva en formato JSON (Tipantuña, 2019).
Resultado de las Pruebas de Carga.
El sistema respondió sin errores para el caso de prueba que comprende 800 usuarios solicitando
el recurso por el lapso de tiempo de un minuto, ver figura 37.
69
Figura 37. Prueba de carga para la solicitud con 800 usuarios (Tipantuña, 2019).
Por otro lado, el sistema empieza a fallar a partir de 900 usuarios realizando solicitudes al
recurso, tal como se puede ver en la figura 38, donde se registran 4 errores de confirmación para
el paso de prueba.
Figura 38. Prueba de carga para la solicitud con 900 usuarios (Tipantuña, 2019).
70
5. Conclusiones.
La arquitectura elegida para satisfacer los requerimientos de la Unidad de
Tecnologías de la facultad de Economía, resultó conveniente tanto para el usuario
final como para el desarrollador, pues por un lado la velocidad de respuesta, el diseño
y la correcta funcionalidad de la aplicación terminaron agradando al cliente. Por otro
lado, la arquitectura implementada, ha sido favorable para el desarrollador en el
sentido de que los marcos y tecnologías utilizadas, han provisto de potentes
funcionalidades para desarrollar de manera adecuada la aplicación.
La implementación de la metodología XP al presente proyecto de tesis, ha sido de
gran utilidad al momento de definir los intervalos de tiempo para entrega de avances,
realizar buenas prácticas de diseño y codificación. Sin embargo, esta metodología
puede resultar ser muy formal cuando se realiza por un equipo pequeño de desarrollo.
Las últimas versiones (versión 8.0.16) de MySQL, puede causar problemas de
incompatibilidad con el JDK 8. Para solventar este tipo de problemas es de gran
utilidad, revisar la documentación de la página oficial de MySQL y verificar que
versiones del JDBC de MySQL interactúan de manera correcta con una respectiva
versión de JDK.
La flexible adaptación a cambios que permite la metodología XP, resulto ser de gran
ayuda, pues el personal de la Unidad de Gestión, tenía problemas al definir ciertos
alcances del proyecto que desembocaban en cambios en el sistema.
En la fase de pruebas se manifestaron errores de funcionamiento del sistema,
específicamente en la carga de datos y en la vista de las interfaces de usuario, que en
colaboración con el personal administrativo fueron detectados y solucionados, para
proveer un sistema de calidad.
La implementación del sistema para la gestión de horarios en los laboratorios de
informática en la facultad de economía, finalizó exitosamente con un acuerdo firmado
por parte del desarrollador y el representante del personal administrativo de la Unidad
de Tecnologías de la facultad de Economía.
71
6. Recomendaciones.
En vista de que el sistema no genera copias de seguridad automáticas, y que se tiene
alrededor de doscientas diez reservas de laboratorios, sería de utilidad realizar una
copia de seguridad de la base de datos, cada mes. De esta manera se mitiga el riesgo
de pérdida de información de la Unidad de Titulación respecto a las reservas de
horarios generadas.
Se recomienda agregar un módulo de gestión de inventario de laboratorios de
informática, que contenga las características del equipo como memoria RAM,
frecuencia de procesador, tarjeta de video, programas instalados, entre otras, pues el
proceso de inventario se realiza sin un sistema especializado, que colabore a facilitar
el trabajo asociado.
El sistema en sí, es de carácter intuitivo, sin embargo, se recomienda el uso del
manual de usuario, que se encuentra en la sección de anexos de este documento de
tesis, para solventar cualquier dificultad respecto al manejo del sistema.
En caso de ejecutar la aplicación con Mozilla Firefox verificar que la versión
instalada sea 67.0.4 o mayor. Además, evitar el uso del sistema con el navegador
Opera, pues algunos iconos no son reconocidos en la última versión
51.2.2461.137690.
72
7. Referencias.
Baez, S. (20 de Octubre de 2012). KnowDO. Obtenido de
http://www.knowdo.org/knowledge/39-sistemas-web
Benites, A. G. (2017). Obtenido de https://devcode.la/blog/que-es-java/
Castillo, Figueroa, & Sevilla. (Julio de 2018). Programacionextrema. Obtenido de
http://programacionextrema.tripod.com/index.htm
Cosmina, L., Harrop, R., Schaefer, C., & Ho, C. (2017). Pro Spring 5. New York: Apress.
DB-Engines. (2019). DB-Engines. Obtenido de https://db-engines.com/en/ranking
DiligentTeam. (Julio de 2019). Diligent. Obtenido de https://www.diligent.es/como-probar-una-
web-en-diferentes-navegadores/
Enriquez, J. (2017). METODOLOGÍA DE DESARROLLO. Universidad Catolica de los
Angeles, Chimbote Perú.
Fenton, S. (2018). Pro TypeScript. New York: Apress.
Freeman, A. (2018). Pro Angular 6. New York: Apress.
Globe. (Julio de 2019). Globe. Obtenido de https://www.globetesting.com/2012/08/pruebas-de-
caja-negra/
Hiebaum, F. (21 de Mayo de 2015). Obtenido de
http://manualdelgamedesigner.blogspot.com/2015/05/programacion-extrema-xp.html
HotFrameworks. (Julio de 2019). Obtenido de https://hotframeworks.com/
Jiménez, R. E. (2015). Metodologías Ágiles de Desarrollo de Software Aplicadas a la Gestión de
Proyectos Empresariales. ITCA-FEPADE R, 6.
Joskowicz., J. (2008). Reglas y Prácticas en Extreme Programming. Universidad de Vigo ,
España.
Malaviya, H. (23 de Mayo de 2018). Obtenido de https://blog.usejournal.com/scrum-vs-xp-
75cf216d324
73
Monus, A. (2 de Agosto de 2019). Raygun. Obtenido de https://raygun.com/blog/soap-vs-rest-vs-
json/
Neosoft. (8 de Enero de 2018). Neosoft. Obtenido de https://www.neosoft.es/blog/que-es-una-
aplicacion-web/
Neotek, B. (22 de Junio de 2016). NEotek. Obtenido de https://blog.neothek.com/10-razones-
porque-elegir-mysql/
Oracle, J. (2 de Noviembre de 2014). Oracle Juniors. Obtenido de
http://oraclejuniors.blogspot.com/2014/11/que-es-jpa-java-persistence-api.html
Pandey, S. (11 de Febrero de 2018). Medium. Obtenido de
https://medium.com/coffeetechandme/three-tier-architecture-the-beginning-2d2f6063fa1e
Peñaherreta, E. P. (2017). Sistema web para la administración y control de acceso en los
laboratorios de cómputo en la Universidad Regional Uniandes-Babahoyo. Universidad
Regional Autónoma de los Andes, Quevedo.
Rouse, M. (3 de Junio de 2016). TechTarget. Obtenido de
https://searchsoftwarequality.techtarget.com/definition/integrated-development-
environment
Rousse, M. (16 de Febrero de 2017). WhatIs. Obtenido de
https://whatis.techtarget.com/definition/Web-server
Ruiz, J. (4 de Agosto de 2018). JorgeLuis.Agile. Obtenido de
https://jorgeruizagile.com/2018/08/04/los-4-valores-de-la-agilidad-el-manifiesto-agil/
Spring. (Julio de 2019). Spring. Obtenido de https://spring.io/tools3/sts
Sudeesh. (21 de Septiembre de 2012). webservice-testing. Obtenido de http://webservice-
testing.blogspot.com/2011/10/web-services-performance-load-test-soap.html
Tébar, E. (27 de Septiembre de 2018). Wam. Obtenido de
https://www.wearemarketing.com/es/blog/frameworks-en-el-desarrollo-web-las-mejores-
practicas-para-tu-negocio-online.html
74
TIOBE. (2019). TIOBE the software Quality company. Obtenido de
https://www.tiobe.com/company/about/
VisualStudio. (Julio de 2019). Microsoft VS. Obtenido de https://code.visualstudio.com/docs
Wells, D. (Julio de 2015). Extreme Programming. Obtenido de
http://www.extremeprogramming.org/map/iteration.html
75
8. Anexos.
1
8.1. Manual de Usuario.
Contenido
Introducción. ................................................................................................................................. 3
1. Ingreso al sistema................................................................................................................... 3
2. Página de bienvenida al sistema ........................................................................................... 4
2.1. Interfaz correspondiente a usuarios tipo Master. ....................................................... 5
2.2. Interfaz correspondiente a usuarios tipo Administrador. .......................................... 5
2.3. Interfaz correspondiente a usuarios tipo Estándar. .................................................... 6
3. Módulo de Administración. .................................................................................................. 6
3.1. Funcionalidad Usuarios. ................................................................................................ 7
3.1.1. Creación de usuario. ............................................................................................... 7
3.1.2. Edición de Usuario. ............................................................................................... 10
3.1.3. Eliminación de usuario. ........................................................................................ 12
3.2. Funcionalidad Docentes. .............................................................................................. 13
3.2.1. Creación de docente. ............................................................................................. 13
3.2.2. Edición de docente. ............................................................................................... 16
3.2.3. Eliminación de docente. ........................................................................................ 18
3.3. Funcionalidad Materias. .............................................................................................. 19
3.3.1. Creación de materia. ............................................................................................. 19
3.3.2. Edición de materia. ............................................................................................... 21
3.3.3. Eliminación de materia......................................................................................... 24
3.4. Funcionalidad Laboratorios. ....................................................................................... 24
3.4.1. Creación de laboratorio. ....................................................................................... 25
2
3.4.2. Edición de laboratorio. ......................................................................................... 27
3.4.3. Eliminación de laboratorio................................................................................... 30
4. Módulo de Horarios............................................................................................................. 30
4.1. Funcionalidad de reserva de laboratorios. ................................................................. 30
4.1.1. Creación de reserva. ............................................................................................. 31
4.1.2. Edición de reserva. ................................................................................................ 35
4.1.3. Eliminación de reserva. ........................................................................................ 37
4.1.4. Reseteo de reservas. .............................................................................................. 37
4.1.5. Búsqueda de reservas ........................................................................................... 38
5. Modulo Reportes.................................................................................................................. 40
5.1. Funcionalidad de Reportes por laboratorio............................................................... 41
5.1.1. Transformación a PDF. ........................................................................................ 43
5.2. Funcionalidad de Reportes por docente. .................................................................... 44
5.2.1. Transformación a PDF. ........................................................................................ 46
3
Introducción.
El presente documento tiene la finalidad de dar a conocer a los usuarios finales como interactuar
con el sistema de gestión de reservas de laboratorios, de tal manera que puedan ingresar al
sistema, hacer uso de las funcionalidades y aclarar dudas sobre las mismas. El software en sí es
de carácter intuitivo, sin embargo, este documento es de mucha utilidad para la total
comprensión del sistema.
1. Ingreso al sistema.
Para iniciar la interacción con el software, el usuario debe abrir su navegador de internet y en la
barra de búsqueda digitar la siguiente URL:
http://localhost:4200/login
Esta URL le muestra en primera instancia la página web del inicio de sesión del sistema (ver
figura 1).
Figura 39. Página de inicio de sesión del sistema.
4
En caso de que las credenciales sean incorrectas se genera un mensaje de error, tal como muestra
la figura 2.
Figura 40. Mensaje de error generado debido a credenciales incorrectas.
2. Página de bienvenida al sistema
El sistema cuenta con tres roles de usuario:
Usuario Master.
Usuario Administrador.
Usuario Estándar.
Al superar el inicio de sesión, el sistema muestra la página de bienvenida correspondiente según
el tipo de usuario. A continuación, se indican las interfaces asociadas a cada tipo de usuario
después de haber ingresado sus credenciales.
5
2.1. Interfaz correspondiente a usuarios tipo Master.
Figura 41. Página de bienvenida para usuarios de tipo Master.
2.2. Interfaz correspondiente a usuarios tipo Administrador.
Figura 42. Página de bienvenida para usuarios de tipo Administrador.
6
2.3. Interfaz correspondiente a usuarios tipo Estándar.
Figura 43. Página de bienvenida para usuarios de tipo Estándar.
La principal diferencia entre las paginas, es la barra de navegación con los módulos que permite
gestionar el sistema (Administración, Horarios y Reportes). A continuación, se detalla la
funcionalidad de los mismos.
3. Módulo de Administración.
Es accesible solo para usuarios de tipo Master. Para acceder a sus funcionalidades, debe cliquear
en la opción de Administración tal como indica la figura 6.
Figura 44 Funcionalidades del módulo administración.
El modulo cuenta con cuatro funcionalidades (Usuarios, Docentes, Materias y Laboratorios), las
mismas que se detallan a continuación.
7
3.1. Funcionalidad Usuarios.
Una vez que se ha escogido la opción Usuarios, el sistema le muestra una página web, referente a
la administración de usuarios del sistema (ver figura 7).
Figura 45 Pagina de administración de usuarios.
El sistema le permite visualizar mediante una tabla el nombre, contraseña y rol de los usuarios
que se han registrado hasta el momento. En adición la tabla contiene los botones de creación,
edición y eliminación de los mismos.
3.1.1. Creación de usuario.
Para añadir un usuario al sistema, es necesario clicar sobre el botón “Crear Usuario” que se
encuentra en la parte inferior de la tabla y el sistema redirige a la página que contiene el
formulario para la creación de un nuevo usuario (ver figura 8).
Figura 46. Formulario de registro para creación de usuarios.
8
El formulario cuenta con tres campos, los referentes a “Nombre de Usuario” y “Contraseña” son
de tipo texto, es decir que deben ingresarse a través de teclado. El campo “Rol” es de tipo
selección, es decir que se llena al clicar sobre un elemento de la lista que despliega (ver figura 9).
Figura 47. Lista de opciones para el campo Rol.
En caso de que los campos del usuario no se han ingresado, el botón de creación de usuario, no
se habilita y en adición el sistema genera un mensaje de error sobre los campos que no se han
ingresado (ver figura 10).
Figura 48. Mensajes de error ante campos requeridos.
9
En el caso de que los campos se han ingresado, el sistema activa el botón de creación, ver figura
11.
Figura 49. Formulario de creación de usuario con campos registrados.
Debe presionar el botón “crear” y el sistema redirige a la página de administración de usuarios y
actualiza la tabla con los datos del nuevo usuario (ver figura 12).
Figura 50. Nuevo usuario creado en la tabla.
10
3.1.2. Edición de Usuario.
A fin de modificar los datos de un usuario del sistema, se procede a presionar el botón de edición
correspondiente que se encuentra habilitado para cada usuario al lado derecho de la columna Rol.
la figura 13 muestra como se ve dicho botón.
Figura 51. Botón de edición de usuarios.
El sistema redirige, a una página web con el formulario para editar la información del usuario, tal
como ilustra la figura 14.
Figura 52. Formulario de edición de usuario.
Para ingresar los nuevos datos en los capos de “Nombre de Usuario” y “Contraseña”, se debe
borrar la que está por defecto en el formulario e ingresar la nueva. Para modificar el rol basta con
escoger otro al clicar en campo correspondiente. La figura 15 muestra los datos a modificar en
formulario.
11
Figura 53. Formulario con campos modificados.
En caso de que el nombre de usuario o contraseña queden vacíos, el sistema no habilita el botón
“Editar” y genera los mensajes de error asociados (ver figura 16).
Figura 54. Mensajes de error ante campos requeridos.
En caso de que se han ingresado correctamente los datos del usuario a modificar, se habilita el
botón de “Editar”, de tal forma que, al cliquear sobre el mismo, el sistema redirecciona a la
página web de administración de usuarios, en donde se encuentra la información editada (ver
figura 17).
12
Figura 55. Información modificada del usuario en la tabla.
3.1.3. Eliminación de usuario.
En el escenario de que por cualquier circunstancia se desea eliminar un usuario del sistema basta
con presionar el botón de eliminación correspondiente al usuario. La figura 18 muestra el botón
de eliminación.
Figura 56. Botón de eliminación de usuarios.
Una vez que hace clic sobre el botón de eliminación, la página de administración de usuarios se
recarga, sin el usuario que se ha decidido eliminar.
13
3.2. Funcionalidad Docentes.
Dado que se ha escogido la opción “Docentes”, en la barra de navegación, el sistema muestra la
interfaz asociada a la administración de docentes del sistema (ver figura 19).
Figura 57. Página de administración de docentes.
La página le permite observar a través de una tabla los nombres, apellidos y cedula de los
docentes que se han registrado en el sistema. En adición la tabla contiene los botones de
creación, edición y eliminación de los mismos.
3.2.1. Creación de docente.
Para agregar un docente, se debe ejecutar el botón “Crear Docente” ubicado abajo de la tabla de
docentes. El sistema redirige a la página que contiene el formulario para la creación de un nuevo
docente (ver figura 20).
14
Figura 58. Formulario para creación de docentes.
El formulario contiene tres campos de tipo texto referentes a nombre, apellido y cedula, es decir
que deben ingresarse a través de teclado. En el campo cedula deben ingresarse solamente
caracteres numéricos y de longitud igual a 10. En caso de que no se ingresen los datos en los
campos o que la información en el campo de cedula no sea correcta, el sistema no habilita el
botón crear y envía los mensajes de error correspondientes (ver figura 21).
Figura 59. Mensajes de error ante campos vacíos.
En caso de que los campos estén correctamente ingresados, el sistema activa el botón de
creación, ver figura 22.
15
Figura 60. Campos correctamente ingresados.
Una vez se habilite el botón “Crear” el usuario debe clicar en el mismo y el sistema redirige a la
página de administración de docentes con la información que se registró (ver figura 23).
Figura 61. Nuevo docente registrado en la tabla.
16
3.2.2. Edición de docente.
A fin de cambiar los datos de un docente especifico, se procede a ejecutar el botón de edición
correspondiente que se encuentra habilitado para cada usuario al lado derecho de la columna
cedula, la figura 24 muestra como se ve dicho botón.
Figura 62. Botón de edición de docente.
El sistema redirige, a una página web con el formulario para editar la información del docente,
tal como indica la figura 25.
Figura 63. Formulario de edición de docente.
Para ingresar los nuevos datos en los capos de nombre, apellido y cedula del docente, se debe
borrar la que está por defecto en el formulario e ingresar la nueva. Hay que tener en cuenta que
en el campo cedula deben ingresarse solamente caracteres numéricos y de longitud igual a 10. A
fin de ejemplificar la edición, se procede a cambiar los datos de la docente que se creó en la
sección anterior (ver figura 26).
17
Figura 64. Modificación de datos del docente.
En caso de que uno o más campos del formulario no se registren, el sistema no habilita el botón
“Editar” y genera los mensajes de error asociados (ver figura 27).
Figura 65. Mensajes de error sobre campos requeridos.
En el caso de que se ha ingresado correctamente los datos del docente a modificar, se habilita el
botón de “Editar”, de tal forma que, al clicar sobre el mismo, el sistema redirecciona a la página
web de administración de docentes, en donde se encuentra la información editada (ver figura 28).
18
Figura 66. Información modificada del docente en la tabla.
3.2.3. Eliminación de docente.
En el escenario de que por alguna razón desee eliminar un docente del sistema basta con cliquear
el botón de eliminación correspondiente al usuario. La figura 29 muestra el botón de eliminación.
Figura 67. Botón de eliminación de docentes.
Una vez que hace clic sobre el botón de eliminación, la página de administración de docentes se
recarga, sin el docente que se ha decidido eliminar.
19
3.3. Funcionalidad Materias.
Una vez que se ha escogido la opción Materias, el sistema le muestra una página web, referente a
la administración de materias del sistema (ver figura 30).
Figura 68. Página de administración de materias.
La página le permite visualizar mediante una tabla el código, nombre, carrera y semestre de las
materias que se han registrado en el sistema. En adición la tabla contiene los botones de creación,
edición y eliminación de las mismas.
3.3.1. Creación de materia.
Para agregar una materia, se debe ejecutar el botón “Crear Materia” ubicado abajo de la tabla. El
sistema redirige a la página que contiene el formulario para la creación de una nueva materia (ver
figura 31).
20
Figura 69. Formulario de creación de materias.
El formulario cuenta con cuatro campos de tipo texto referentes a código, nombre, carrera y
semestre de la materia. En caso de que uno o más campos queden vacíos, el sistema no habilita el
botón “Crear” y se generan los mensajes de error respectivos debajo de los campos, ver figura
32.
Figura 70. Mensajes de error ante campos requeridos.
21
Dado que los campos estén correctamente ingresados, el sistema activa el botón de creación, ver
figura 33.
Figura 71. Formulario de creación con campos correctamente ingresados.
Una vez se habilite el botón “Crear” el usuario debe cliquear en el mismo y el sistema redirige a
la página de administración de materias con los datos que se registraron (ver figura 34).
Figura 72. Información de la materia creada en la tabla.
3.3.2. Edición de materia.
A fin de modificar los datos de una materia, se procede a presionar el botón de edición
correspondiente que se encuentra habilitado para cada materia al lado derecho de la columna
semestre, la figura 35 muestra como se ve dicho botón.
22
Figura 73. Botón de edición de materias.
El sistema redirige, a una página web con el formulario para editar la información de la materia,
tal como ilustra la figura 36.
Figura 74. Formulario de edición de materias.
Para ingresar los nuevos datos en los capos, se debe borrar la que está por defecto en el
formulario e ingresar la nueva. A fin de ejemplificar la edición, se procede a cambiar los datos de
la materia que se creó en la sección anterior (ver figura 37).
23
Figura 75. Modificación de datos de la materia.
En caso de que uno o más campos del formulario no se registren, el sistema no habilita el botón
“Editar” y genera los mensajes de error asociados (ver figura 38).
Figura 76. Masajes de error frente a campos requeridos.
24
Si, por el contrario, se ha ingresado correctamente los datos de la materia a modificar, se habilita
el botón de “Editar”, de tal forma que, al hacer clic sobre el mismo, el sistema redirecciona a la
página web de administración de materias, en donde se encuentra la información editada (ver
figura 39).
Figura 77. Información modificada de la materia en la tabla.
3.3.3. Eliminación de materia.
En caso de que por alguna razón desea eliminar una materia del sistema, basta con presionar el
botón de eliminación correspondiente a la materia. La figura 40 muestra el botón de eliminación.
Figura 78. Botón de eliminación de materia.
Una vez que hace clic sobre el botón de eliminación, la página de administración de materias se
recarga, sin la materia que se ha decidido eliminar.
3.4. Funcionalidad Laboratorios.
Dado que se ha escogido la opción “Docentes”, en la barra de navegación, el sistema muestra la
interfaz asociada a la administración de docentes del sistema, ver figura 41.
25
Figura 79. Página de administración de laboratorios.
La página le permite observar a través de una tabla los códigos, nombres y capacidad de los
distintos laboratorios que se han registrado en el sistema. En adición la tabla contiene los botones
de creación, edición y eliminación de los mismos.
3.4.1. Creación de laboratorio.
Para agregar un laboratorio, se debe ejecutar el botón “Crear Laboratorio” ubicado abajo de la
tabla. El sistema redirige a la página que contiene el formulario para la creación de un nuevo
laboratorio (ver figura 42).
26
Figura 80. Formulario de creación de laboratorio.
El formulario contiene tres campos de tipo texto referentes a código, nombre y capacidad, es
decir que deben ingresarse a través de teclado. En el campo capacidad deben ingresarse
solamente caracteres numéricos. En caso de que no se ingresen datos en los campos o que la
información en el campo de capacidad no sea correcta, el sistema no habilita el botón crear y
envía los mensajes de error en los campos (ver figura 43).
Figura 81. Mensajes de error frente a campos requeridos.
27
En caso de que los campos estén correctamente ingresados, el sistema activa el botón de
creación, ver figura 44.
Figura 82. Campos ingresados correctamente.
Una vez se habilite el botón “Crear” el usuario debe hacer clic en el mismo y el sistema redirige
a la página de administración de docentes con la información que se registró (ver figura 45).
Figura 83. Información del laboratorio creado en la tabla.
3.4.2. Edición de laboratorio.
A fin de modificar los datos de un laboratorio especifico, se procede a ejecutar el botón de
edición correspondiente que se encuentra habilitado para cada usuario al lado derecho de la
columna capacidad, la siguiente figura 46 muestra como se ve dicho botón.
28
Figura 84. Botón de edición de laboratorios.
El sistema redirige, a una página web con el formulario para editar la información del
laboratorio, tal como indica la figura 47.
Figura 85. Formulario de edición de laboratorios.
Para ingresar los nuevos datos en los capos de código, nombre y capacidad, se debe borrar la que
está por defecto en el formulario e ingresar la nueva. A fin de ejemplificar la edición, se procede
a cambiar los datos del laboratorio que se creó en la sección anterior (ver figura 48).
Figura 86. Información modificada del laboratorio.
29
En caso de que uno o más campos del formulario no se registren, el sistema no habilita el botón
“Editar” y genera los mensajes de error asociados (ver figura 49).
Figura 87. Mensajes de error frente a campos requeridos.
En el caso de que se ha ingresado correctamente los datos del laboratorio a modificar, se habilita
el botón de “Editar”, de tal forma que, al hacer clic sobre el mismo, el sistema redirecciona a la
página web de administración de docentes, en donde se encuentra la información editada (ver
figura 50).
Figura 88. Información editada del laboratorio en la tabla.
30
3.4.3. Eliminación de laboratorio.
En el escenario de que por alguna razón se desee eliminar un laboratorio del sistema basta con
clicar sobre el botón de eliminación correspondiente al usuario. La figura 51 muestra el botón de
eliminación.
Figura 89. Botón de eliminación de laboratorios.
Una vez que hace clic sobre el botón de eliminación, la página de administración de laboratorios
se recarga, sin el laboratorio que se ha decidido eliminar.
4. Módulo de Horarios.
Es accesible solo para usuarios de tipo Master y Administrador. Para acceder a su funcionalidad,
debe cliquear sobre la opción “Horarios” tal como indica la figura 52.
Figura 90. Funcionalidad de reserva del módulo horarios.
El modulo cuenta con la funcionalidad de reserva de laboratorios, esta se detalla a continuación.
4.1. Funcionalidad de reserva de laboratorios.
Dado que ha escogido la opción “Reservar Laboratorio”, en la barra de navegación, el sistema
muestra la interfaz asociada a la administración de reserva de laboratorios del sistema, ver figura
53.
31
Figura 91. Página de administración de reservas de laboratorios.
La página le permite observar a través de una tabla los días, horas, docentes, materias y
laboratorios de las distintas reservas que se han registrado en el sistema. En adición la tabla
contiene los botones de creación, edición, eliminación, búsqueda y reseteo de las mismas.
4.1.1. Creación de reserva.
Para añadir una reserva, se debe hacer clic en el botón “Crear Reserva” ubicado abajo de la tabla.
El sistema redirige a la página que contiene el formulario para la creación de una nueva reserva
(ver figura 54).
32
Figura 92. Formulario de creación de reserva. De laboratorio
El formulario contiene cinco campos de tipo selección referentes a día, hora, docente, materia y
laboratorio. El campo “Día” lista los cinco días laborables de la semana (ver figura 55).
Figura 93. Lista de opciones para el campo día.
El campo “Hora” lista la hora de inicio y fin en que se puede asignar una reserva (ver figura 56).
Figura 94. Lista de opciones del campo hora.
33
Al cliquear en el campo docente se listan los docentes que se han registrado en el sistema, ver
figura 57.
Figura 95. Lista de opciones del capo docente.
El campo “Materia” lista las materias que se han registrado en el sistema (ver figura 58).
Figura 96. Lista de opciones del campo materia
34
Al clicar en el campo laboratorio se listan los laboratorios que se han registrado en el sistema ver
figura 59.
Figura 97. Lista de opciones del campo laboratorio.
Dado de que los campos estén ingresados, el sistema activa el botón de creación, ver figura 60.
Figura 98.
Una vez se habilite el botón “Crear” el usuario clicar en el mismo y el sistema valida si es que
existe una reserva ya asignada en el día, hora y laboratorio especificados. En caso de que se
35
encuentre una coincidencia el sistema le informa al usuario, que no se puede generar la reserva
(ver figura 61).
Figura 99. Ventana de dialogo para alerta de error en creación de reserva.
En caso de que no se encuentren coincidencias el sistema redirige a la página de administración
de reservas con los datos que se registraron (ver figura 62).
Figura 100. Información de la reserva creada en la tabla.
4.1.2. Edición de reserva.
Para cambiar los datos de una reserva específica, se procede a ejecutar el botón de edición
correspondiente que se encuentra habilitado para cada reserva al lado derecho de la columna
laboratorio, la figura 63 muestra como se ve dicho botón.
Figura 101. Botón de edición de reserva de laboratorio.
El sistema redirige, a una página web con el formulario para editar la información de la reserva,
tal como indica la figura 64.
36
Figura 102. Formulario de edición de reservas de laboratorios.
Para modificar los datos en los capos de día, hora, docente, materia y laboratorio se debe borrar
la que está por defecto en el formulario e ingresar la nueva. A fin de ejemplificar la edición, se
procede a cambiar los datos de la reserva que se creó en la sección anterior (ver figura 65).
Figura 103. Datos de la reserva modificados.
37
Una vez ingresados los datos a modificar, se debe presionar el botón modificar y el sistema
redirecciona a la página web de administración de reservas, en donde se encuentra la
información editada (ver figura 66).
Figura 104. Información de reserva modificada en la tabla.
4.1.3. Eliminación de reserva.
En caso de que se desee eliminar una reserva del sistema basta con ejecutar el botón de
eliminación correspondiente a la reserva. La figura 67 muestra el botón de eliminación.
Figura 105. Botón de eliminación de las reservas de laboratorios.
Una vez que hace clic sobre el botón de eliminación, la página de administración de reserva se
recarga, sin el laboratorio que se ha decidido eliminar.
4.1.4. Reseteo de reservas.
Para borrar todas las reservas que se encuentran registradas, tiene que presionar el botón “Reset”,
que se encuentra en la parte superior de la tabla de reservas. Al presionarlo se genera una ventana
de dialogo que le pide confirmación del reseteo (ver figura 68).
Figura 106. Ventana de dialogo para confirmación de reseteo de reservas.
38
El botón “NO” del cuadro de dialogo hace que se cierre la venta, y el botón “SI” da paso a la
eliminación de todas las reservas, dejando la tabla de reservas vacia.
4.1.5. Búsqueda de reservas
La opción de búsqueda, se encuentra en la parte de debajo de la tabla de reservas de laboratorio.
Para realizar la búsqueda de reservas por día, elija uno en el campo de selección (ver figura 69).
A fin de ejemplificar, se ha tomado el día martes.
Figura 107. Lista de opciones del campo día.
Una vez que ha escogido el día se debe presionar el botón buscar y el sistema genera una tabla
con todas las reservas registradas el día que se ha escogido (ver figura 70).
Figura 108. Tabla de reservas generada en función del día seleccionado.
39
Para realizar la búsqueda por laboratorio, hay que escoger el laboratorio, en el campo de
selección laboratorio. La figura 71 muestra la lista que se despliega.
A fin de ejemplificar se ha escogido el laboratorio siete. A continuación, se debe presionar el
botón buscar y el sistema genera una tabla con todas las reservas registradas en el laboratorio
(ver figura 72).
Figura 110. Tabla de reservas generada en función del laboratorio elegido.
Por otro lado, para realizar la búsqueda por día y al mismo tiempo por laboratorio. Se debe
escoger ambos en los campos de selección respectivos. A fin de ejemplificar el caso, se ha
escogido el día lunes y el laboratorio tres para realizar la búsqueda. Los campos de selección
lucen tal como ilustra la figura 73.
Figura 109. Lista de opciones del campo
laboratorio
40
Figura 111. Selección de día y laboratorio para realizar la búsqueda de reservas.
Una vez escogidos ambos parámetros, hay que presionar el botón buscar, y se genera una tabla
con los datos de las reservas realizadas en el día y laboratorio seleccionados (ver figura 74).
Figura 112. Tabla de reservas generada en función del día y laboratorio elegidos.
5. Modulo Reportes.
Es accesible para todos los usuarios Master, Administrador y Estándar. Para acceder a sus
funcionalidades, debe cliquear sobre la opción “Reportes” tal como indica la figura 75.
41
Figura 113. Funcionalidades del módulo reportes.
El modulo cuenta con la funcionalidad de reportes por laboratorio y reportes por docente.
5.1. Funcionalidad de Reportes por laboratorio.
En caso de haber escogido la opción “Reporte por Laboratorio”, en la barra de navegación, el
sistema muestra la página web para generar el reporte (ver figura 76).
Figura 114. Página de reportes por laboratorio.
La página tiene un campo de selección llamado “Laboratorios”, debe hacer clic en él para que se
listen los laboratorios, que están registrados en el sistema. La figura muestra como se ve la lista.
A fin de muestra de la funcionalidad se ha escogido el laboratorio uno.
Figura 115. Lista de opciones del campo laboratorios.
42
Una vez que ha elegido un laboratorio, debe cliquear el botón buscar y el sistema genera una
tabla de doble entrada tipo horario, que indica el día y la hora en que se ha reservado el
laboratorio. En adición la tabla muestra el apellido del docente, la materia y semestre asociados a
la reserva. La figura 78 muestra la tabla tipo horario para el laboratorio seleccionado.
Figura 116. Tabla horaria en función del laboratorio.
43
5.1.1. Transformación a PDF.
El botón generar reporte que se encuentra debajo de la tabla tipo horario, da paso a la descarga
de un archivo PDF, que contiene la tabla (ver figura 79).
Figura 117. Contenido del archivo PDF descargado.
44
5.2. Funcionalidad de Reportes por docente.
En caso de haber escogido la opción “Reporte por Docente”, en la barra de navegación, el
sistema muestra la página web para generar el reporte (ver figura 80).
Figura 118. Página de reportes por docente.
La página tiene un campo de selección llamado “Docentes”, cliquear en él para que se listen los
docentes, que están registrados en el sistema. La figura 81 muestra como se ve la lista.
Figura 119. Lista de opciones del campo docentes.
Una vez que ha elegido un docente, debe ejecutar botón buscar y el sistema genera una tabla de
doble entrada tipo horario, que indica el día y la hora en que el docente está asignado a una
reserva de laboratorio. En adición la tabla muestra el laboratorio y la materia asociados a la
reserva. A fin de ejemplificar esta funcionalidad, se ha elegido el docente “Cajas Cadena José
Alejandro “. La figura 82 muestra la tabla tipo horario para el docente seleccionado.
45
Figura 120. Tabla tipo horario en función del docente.
46
5.2.1. Transformación a PDF.
El botón generar reporte que se encuentra debajo de la tabla tipo horario, da paso a la descarga
de un archivo PDF, que contiene la tabla (ver figura).
Figura 121. Contenido del archivo PDF descargado.
47
8.2. Acta de entrega recepción.
Top Related