universidad central del ecuador. facultad …...jorge arturo morales cardoso. quito, 2019 ii...

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

[email protected]

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.

http://www.extremeprogramming.org/rules/bugs.html

http://www.extremeprogramming.org/rules/refactor.html

http://www.extremeprogramming.org/rules/userstories.html

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.


Historia: Roles de usuario.



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.


Fuente: Propia.

La tabla 5, corresponde a la HU asociada a la administración de usuarios.

Tabla 5. Historia - 003. Administración de usuarios.


Nombre historia: Administración de usuarios.



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.


Nombre historia: Administración de docentes.




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.


Fuente: Propia.

25

La tabla 7, muestra la HU asociada a la administración de materias.

Tabla 7. Historia - 005. Administración de materias.


Nombre historia: Administración de materias




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.


Fuente: Propia.

La tabla 8, indica la HU asociada a la administración de laboratorios.

Tabla 8. Historia - 006. Administración de laboratorios.


Historia: Administración de laboratorios.




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.


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.


Nombre historia: Administración de Reservas de laboratorios.




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.


Fuente: Propia.

La tabla 10, corresponde a la HU asociada a la generación de reportes.

Tabla 10. Historia - 008. Generación de Reportes


Nombre historia: Generación de reportes.




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.


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.


Docentes.

3 Semanas.

3


Materias.

006. Administración de

Laboratorios.

3 Semanas.

4


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


Field

Required

Field

Otras

validaciones

Id Identificación

única del

docente


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


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


Field

Required

Field

Otras

validaciones

Docente_Id Identificación

única del

docente


obligatorio para

el registro. Valor

por defecto 0

Materia_id Identificación

única de la

materia


obligatorio para

el registro. Valor

por defecto 0

Fuente: propia.

Tabla 15. Diccionario de datos de la tabla laboratorio.

Tabla Laboratorio.

Nombre

Campo


Field

Required

Field

Otras

validaciones

Id Identificación

única del

laboratorio.


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.


defecto NULL

50

Nombre_laboratorio Nombre por el

que se

identifica el

laboratorio.


defecto NULL

Fuente: propia

Tabla 16. Diccionario de datos de la tabla docente.

Tabla Docente.

Nombre

Campo


Field

Required

Field

Otras

validaciones

Id Identificación

única de la

reserva.


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


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


defecto NULL

Rol_user Password del

usuario.


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


Field

Required

Field

Otras

validaciones

Id Identificación

única del rol de

usuario.


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.


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.



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



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.


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.



docentes.


Datos de entrada: Nombre, apellido y cedula del docente.

Procedimiento:

- Creación de docente.


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.



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.



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.




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.


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.


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.



materias.


Datos de entrada: Código, nombre, carrera y semestre de la materia.

Procedimiento:

- Creación de materia.


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.



3. Cliquear sobre la imagen para editar la materia respectiva.


5. Ejecutar el botón Editar.

- Eliminación de materia.



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.



- 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.



- 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.


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.



laboratorios.


Datos de entrada: Código, nombre y capacidad del laboratorio.

Procedimiento:


60


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.




3. Cliquear sobre la imagen para editar el laboratorio respectivo.


5. Ejecutar el botón Editar.




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.




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.


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.


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.



- 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.



- 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.


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.



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:


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.




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.




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.



- 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.



- 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.



- Cuando se presiona el botón eliminar, la tabla se modifica sin la información de la

reserva eliminada.


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.


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.


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.

http://localhost:4200/login

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).


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


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.


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.



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



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.

universidad central del ecuador. facultad …...jorge arturo morales cardoso. quito, 2019 ii...

Documents