Evaluación del ciclo de vida del aceite de motor como...

PRESTALUD: PROTOTIPO TELEMÁTICO PARA EL PROCESO DE PRÉSTAMO Y CONTROL DE RECURSOS DE LOS LABORATORIOS DE INDUSTRIAL DE LA FACULTAD TECNOLÓGICA DE LA UNIVERSIDAD

DISTRITAL FRANCISCO JOSÉ DE CALDAS

WILMAR ALEXIS CAICEDO SERRANO MIGUEL ANTONIO CARO OCAMPO

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA

INGENIERÍA EN TELEMÁTICA BOGOTÁ D.C.

2017

PRESTALUD: PROTOTIPO TELEMÁTICO PARA EL PROCESO DE PRÉSTAMO Y CONTROL DE RECURSOS DE LOS LABORATORIOS DE INDUSTRIAL DE LA FACULTAD TECNOLÓGICA DE LA UNIVERSIDAD

DISTRITAL FRANCISCO JOSÉ DE CALDAS


Proyecto de grado para optar al título de Ingeniero en Telemática

INGENIERO, MIGUEL ANGEL LEGUIZAMÓN PÁEZ Asesor Universidad Distrital Francisco José de Caldas

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD TECNOLÓGICA INGENIERÍA EN TELEMÁTICA

BOGOTÁ D.C. 2017

Nota de aceptación

____________________________

____________________________

____________________________

____________________________

____________________________

____________________________

____________________________ Firma del tutor

____________________________ Firma del jurado

Quiero dedicar este trabajo a mi hermosa hija María Paula Caro Murcia, el alma de mi vida, mi motivo de alegría y mis ganas de superación. A mi compañera sentimental Rubiela Murcia, a mi padre, amigo y consejero José Antonio Caro, a mi madre Liliana Ocampo, a mi hermano Cristian Andrés Caro Ocampo, a mi familia y allegados que siempre estuvieron allí presentes en todos los ámbitos de mi vida. Dedico este logro a la Universidad Distrital Francisco José de Caldas y a la Facultad Tecnológica en cuyo campus viví momentos de alegría, angustia, aprendizaje y formación.

Miguel Antonio Caro Ocampo

Dedicado a mis padres y hermanas

Wilmar Alexis Caicedo Serrano

AGRADECIMIENTOS

Quiero agradecer primeramente a mi padre el logro de este esfuerzo por ser la persona que impulso en mí el deseo de superación, paciencia, persistencia y humildad. Agradezco a mi compañera sentimental y mi hija por ser ambas ese motor que me impulsa a salir adelante todos los días. Agradezco a mi familia el esfuerzo, la dedicación y el amor que me brindaron para poder cumplir con este sueño, este objetivo en el trayecto de mi vida profesional. Agradezco a la Universidad Distrital Francisco José de Caldas por haberme dado la oportunidad de formarme en su campus, en su alma máter como persona y profesional.

Miguel Antonio Caro Ocampo

Agradezco a Dios, a mi familia y a la Universidad Distrital Francisco José de Caldas por la oportunidad y consecución de ser un profesional. Mis padres y hermanas gracias por su apoyo, colaboración y acompañamiento durante este camino trazado que me permite lograr tan importante objetivo en mi vida académica.

Wilmar Alexis Caicedo Serrano

TABLA DE CONTENIDO GLOSARIO ............................................................................................................ 10

RESUMEN ............................................................................................................. 12

ABSTRACT ............................................................................................................ 13

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

2. JUSTIFICACIÓN ............................................................................................. 15

3. DEFINICIÓN DEL PROYECTO ....................................................................... 16

3.1 TÍTULO ..................................................................................................... 16

3.2 PROBLEMA .............................................................................................. 16

4. OBJETIVOS .................................................................................................... 17

4.1 OBJETIVO GENERAL .............................................................................. 17

4.2 OBJETIVOS ESPECÍFICOS ..................................................................... 17

5. MARCO DE REFERENCIA ............................................................................. 18

5.1 ANTECEDENTES ..................................................................................... 18

5.2 MARCO TEÓRICO ................................................................................... 19

5.2.1 ¿Qué es el control del uso? ............................................................... 19

5.2.2 ¿Qué es Scrum? ................................................................................ 19

5.2.3 Protocolos de comunicación. ............................................................. 21

5.2.4 Servidor web. ..................................................................................... 24

5.2.5 Gestión de la información. .................................................................. 26

5.2.6 Sistema de control de versiones. ....................................................... 28

5.2.7 Cliente web. ....................................................................................... 31

5.2.8 Cliente rest móvil. ............................................................................... 32

6. METODOLOGÍA SCRUM ............................................................................... 35

6.1 PROCESO DE ANÁLISIS ÁGIL ................................................................ 35

6.1.1 Roles de usuarios. .............................................................................. 35

6.1.2 Identificación de los procesos de negocio. ......................................... 36

6.1.3 Identificación de funcionalidades del software. .................................. 36

6.1.4 Identificación de MVP (producto mínimo viable) y posteriores entregas. 37

6.1.5 Historias de usuario. ........................................................................... 39

6.1.6 Plan de Entregas. ............................................................................... 45

6.1.7 Duración del proyecto. ....................................................................... 49

6.1.8 Costo del proyecto. ............................................................................ 49

7. DISEÑO E IMPLEMENTACIÓN ...................................................................... 51

7.1 REQUERIMIENTOS NO FUNCIONALES ................................................ 51

7.2 DICCIONARIO DE DATOS ....................................................................... 52

7.3 DIAGRAMA DE CLASES .......................................................................... 58

7.4 SERVICIOS DEL API REST ..................................................................... 59

8. PRUEBAS DEL SERVICIO WEB .................................................................... 80

9. CRONOGRAMA DE ACTIVIDADES ............................................................. 105

10. CONCLUSIONES ...................................................................................... 107

11. RECOMENDACIONES .............................................................................. 108

12. REFERENCIAS BIBLIOGRÁFICAS ........................................................... 109

ANEXOS .............................................................................................................. 111

LISTA DE TABLAS Tabla 1. Colección users ....................................................................................... 52 Tabla 2. Colección profiles ..................................................................................... 52 Tabla 3. Colección metrics ..................................................................................... 53 Tabla 4. Colección teachers .................................................................................. 53 Tabla 5. Colección subjects ................................................................................... 53 Tabla 6. Colección providers ................................................................................. 54 Tabla 7. Colección entries ..................................................................................... 55 Tabla 8. Colección stocks ...................................................................................... 55 Tabla 9. Colección maintenances .......................................................................... 56 Tabla 10. Colección controls .................................................................................. 56 Tabla 11. Colección schedules .............................................................................. 57 Tabla 12. Colección requests ................................................................................ 57 Tabla 13. Colección practices ................................................................................ 58 Tabla 14. Prueba para crear solicitud de práctica .................................................. 80 Tabla 15. Prueba para consultar solicitudes de práctica filtrada por semestre y año

........................................................................................................................ 81 Tabla 16. Prueba para consultar solicitud de práctica por día filtrada por fecha y

laboratorio ....................................................................................................... 81 Tabla 17. Prueba para actualizar datos de solicitud de práctica ............................ 82 Tabla 18. Prueba para consultar solicitudes de práctica por fecha y laboratorio ... 82 Tabla 19. Prueba para consultar solicitudes de práctica por usuario y laboratorio 83 Tabla 20. Prueba para consultar solicitud de práctica por consecutivo ................. 83 Tabla 21. Prueba para consultar solicitudes de práctica del año y semestre actual

........................................................................................................................ 84 Tabla 22. Prueba para consultar solicitudes de práctica filtrada por laboratorio .... 84 Tabla 23. Prueba para crear solicitud de material .................................................. 85 Tabla 24. Prueba para consultar equipos o materiales disponibles del inventario . 85 Tabla 25. Prueba para consultar solicitudes de material filtrado por año, semestre

y laboratorio .................................................................................................... 86 Tabla 26. Prueba para consultar solicitudes de material por usuario filtrado por año

y semestre ...................................................................................................... 86 Tabla 27. Prueba para consultar solicitudes de material por sesión de usuario .... 87 Tabla 28. Prueba para consultar solicitudes de práctica y material filtrado por año y

semestre ......................................................................................................... 87 Tabla 29. Prueba para consultar solicitudes de práctica y material por usuario

filtrado por año y semestre ............................................................................. 88 Tabla 30. Prueba para actualizar el campo observaciones de la solicitud de

material ........................................................................................................... 88 Tabla 31. Prueba para actualizar el estado de ejecución de la solicitud de material

........................................................................................................................ 89 Tabla 32. Prueba para consultar las solicitudes de práctica y material por sesión

de usuario y que se encuentran en estado finalizado ..................................... 89

Tabla 33. Prueba para consultar información de todos los usuarios ...................... 90 Tabla 34. Prueba para consultar información de usuarios filtrado por código ....... 90 Tabla 35. Prueba para consultar usuarios agrupados por perfil ............................ 91 Tabla 36. Prueba para crear un usuario ................................................................ 92 Tabla 37. Prueba para iniciar sesión con las credenciales de un usuario .............. 92 Tabla 38. Prueba para modificar el estado de activación de un usuario ................ 93 Tabla 39. Prueba para actualizar los datos de un usuario ..................................... 93 Tabla 40. Prueba para eliminar los datos de un usuario ........................................ 94 Tabla 41. Prueba para obtener una métrica por su identificador ........................... 94 Tabla 42. Prueba para obtener un listado de métricas filtradas por el tipo al que

pertenecen ...................................................................................................... 95 Tabla 43. Prueba para crear una nueva métrica .................................................... 95 Tabla 44. Prueba para actualizar una métrica ....................................................... 96 Tabla 45. Prueba para eliminar una métrica .......................................................... 96 Tabla 46. Prueba para obtener el listado de todas las entradas de almacén ........ 97 Tabla 47. Prueba para obtener una entrada de almacén por su identificador ....... 97 Tabla 48. Prueba para crear una nueva entrada de almacén ................................ 98 Tabla 49. Prueba para actualizar los datos de una entrada de almacén ............... 99 Tabla 50. Prueba para eliminar los datos de una entrada de almacén .................. 99 Tabla 51. Prueba para obtener el listado de todas las fichas técnicas ................ 100 Tabla 52. Prueba para obtener las entradas de almacén que tienen recursos o

herramientas que aún no se han registrado en el inventario ........................ 100 Tabla 53. Prueba para obtener los datos de una ficha técnica por su identificador

...................................................................................................................... 101 Tabla 54. Prueba para retornar los recursos y las cantidades que aún se pueden

registrar en el inventario ............................................................................... 101 Tabla 55. Prueba para crear una nueva ficha técnica .......................................... 102 Tabla 56. Prueba para actualizar los datos de una ficha técnica ......................... 103 Tabla 57. Prueba para actualizar el estado de una ficha técnica ......................... 104 Tabla 58. Prueba para actualizar el estado de una ficha técnica por no disponible

...................................................................................................................... 104

10

GLOSARIO

ANGULARJS: es un framework MVC de JavaScript para el Desarrollo Web Front End que permite crear aplicaciones SPA Single-Page Applications. Entra dentro de la familia de frameworks como BackboneJS o EmberJS.1 AJAX: un método que utiliza JavaScript y XML para modificar páginas Web en forma dinámica, sin mostrar una nueva página, mediante la obtención de pequeñas cantidades de datos del servidor. BASE DE DATOS: un almacén de datos electrónico definido de manera formal y controlado en forma central, para usarse en muchas aplicaciones. BASES DE DATOS NO SQL: son sistemas de almacenamiento de información que no cumplen con el esquema entidad–relación. Tampoco utilizan una estructura de datos en forma de tabla donde se van almacenando los datos sino que para el almacenamiento hacen uso de otros formatos como clave–valor, mapeo de columnas o grafos. CSS: hojas de estilo en cascada, un conjunto de estilos que controlan el formato de una página Web. Los estilos CSS se pueden almacenar en un archivo y usar para dar formato a varias páginas Web, o se pueden definir dentro de una página Web. DICCIONARIO DE DATOS: una obra de consulta con información sobre los datos (metadatos) creados por el analista de sistemas con base en los diagramas de flujo de datos; recopila y coordina términos de datos específicos, confirmando lo que cada término significa para distintas personas en la organización. FTP: protocolo de transferencia de archivos, en la actualidad es la forma más común de mover archivos entre distintos sistemas computarizados. HTML: lenguaje de marcado de hipertexto, el lenguaje detrás de la apariencia de los documentos en Web. En realidad es un conjunto de convenciones que marcan las porciones de un de un documento para indicarle al navegador qué formato distintivo debe aparecer en cada porción de una página. HTTP: protocolo de transferencia de hipertexto, se utiliza para mover páginas Web entre distintas computadoras; por ejemplo, desde un sitio Web en una computadora que esté en otro país, hasta su computadora personal.

1 AZAUSTRE, Carlos. ¿Qué es AngularJS? Primeros pasos para aprenderlo. Formación JS [en línea], 9 de septiembre de 2013 [revisado 10 agosto 2017]. Disponible en Internet: https://carlosazaustre.es/empezando-con-angular-js/

11

JSON: es un formato de intercambio de datos abierto y basado en texto. Igual que XML, es legible e independiente de la plataforma, además de tener a su disposición una amplia gama de implementaciones. Los datos con formato según el estándar JSON son ligeros y las implementaciones de JavaScript pueden analizarlos sintácticamente con increíble facilidad, lo que lo convierte en el formato ideal de intercambio de datos para aplicaciones web de Ajax. Puesto que JSON es ante todo un formato de datos, no está limitado a las aplicaciones web de Ajax y prácticamente se puede usar en cualquier escenario en que las aplicaciones necesiten intercambiar o almacenar información estructurada como texto.2 METODOLOGÍA ÁGIL: una metodología de desarrollo de sistemas que tiene valores, principios y prácticas útiles para los analistas de sistemas que desean una metodología flexible, interactiva y participativa.3 MONGODB: se trata de una base de datos creada por 10gen del tipo orientada a documentos, de esquema libre, es decir, que cada entrada puede tener un esquema de datos diferente que nada tenga que ver con el resto de registros almacenados. Es bastante rápido a la hora de ejecutar sus operaciones ya que está escrito en lenguaje C++.4 NODE.JS: es un entorno de ejecución para JavaScript construido con el motor de JavaScript V8 de Chrome. Node.js usa un modelo de operaciones E/S sin bloqueo y orientado a eventos, que lo hace liviano y eficiente. El ecosistema de paquetes de Node.js, npm, es el ecosistema más grande de librerías de código abierto en el mundo.5 URL: localizador uniforme de recursos, la dirección de un documento o programa en Internet. Las extensiones conocidas son .com para comercios, .edu para instituciones educativas, .gov o .gob para instituciones gubernamentales, .org para organizaciones, etcétera.6

2 ATIF AZIZ, Scott Mitchell. Introducción a JavaScript Object Notation (JSON) en JavaScript y .NET. Microsoft Developer Network [en línea], 26 de junio de 2007 [revisado 10 Agosto 2017]. Disponible en Internet: https://msdn.microsoft.com/es-co/library/bb299886.aspx 3 KENDALL, Kenneth E. KENDALL, Julie E. Análisis y diseño de sistemas. 8 ed. México.: Pearson Educación, 2011. 559 - 561 p. 4 Acens the cloud services company. Bases de datos NoSQL: Qué son y tipos que nos podemos encontrar. Telefónica [en línea], 28 de febrero de 2014 [revisado 10 agosto 2017]. Disponible en Internet: https://www.acens.com/wp-content/images/2014/02/bbdd-nosql-wp-acens.pdf 5 Node.js Foundation. Node.Js. Linux Foundation Collaborative Projects [en línea], [revisado 10 agosto 2017]. Disponible en Internet: https://nodejs.org/es/ 6 KENDALL, Kenneth E. KENDALL, Julie E. Análisis y diseño de sistemas. 8 ed. México.: Pearson Educación, 2011. 349 p.

12

RESUMEN

El prototipo telemático está compuesto por las aplicaciones web y móvil, que permiten la administración de usuarios de la comunidad educativa, controlar el inventario y gestionar el horario de uso libre de los laboratorios de tecnología industrial e ingeniería de producción. La comunicación entre las aplicaciones se realiza por medio de un servicio web y la información es almacenada en una base de datos no relacional. El servicio web está basado en el protocolo HTTP utilizando frecuentemente los métodos de petición get, post, put y delete. La transferencia de información entre el servidor y cliente se realiza mediante el formato JSON, además, se utiliza el estándar JSON web token (JWT) para la autenticación de usuarios y seguridad en la transferencia de datos. Para el desarrollo de este prototipo se utilizaron los lenguajes de programación JavaScript, NodeJS, Angular y Java. El entorno de programación Android Studio. El sistema de control de versiones Git. Base de datos MongoDB y la metodología Scrum. Con base en la metodología scrum se establecen los requerimientos funcionales, sprints y las diferentes actividades que permitieron comprender los procedimientos que ejecutan el grupo de trabajo del laboratorio y construir el prototipo con el cumplimiento de los objetivos planteados en este proyecto. Palabras clave: servicio web, metodología, control de uso, aplicación, scrum.

13

ABSTRACT

Prototype of the telematics is formed by web and mobile applications, which allow the administration of users of the educational community as well as control inventory and manage free schedule for laboratories of industrial technology and production engineering. The communication between applications is done by a web service and the information is accumulated in a non-relational database. The web service is based on the HTTP protocol, using frequently the get, post, put and delete request methods. The transfer of information between the server and the customer is done using the JSON format, in addition, the standard JSON Web Token (JWT) is used for users authentications and data transfer security. For the development of this prototype was used programming languages as JavaScript, NodeJS, Angular and Java. The Android Studio programming environment. The Git version control system. MongoDB database and Scrum methodology. Based on the scrum methodology were set the functional requirements, sprints and the different activities that let understand procedures that execute the work group of the laboratory and tbuild the prototype with the fulfillment of the objectives set in this project. Keywords: web service, methodology, use control, application, scrum.

14

1. INTRODUCCIÓN

El presente proyecto de grado se centra en la realización de un prototipo telemático para el control de uso e inventario de los recursos del laboratorio de industrial de la Universidad Distrital Francisco José de Caldas Facultad Tecnológica. La construcción del prototipo se genera por la falta de información en tiempo real para conocer la disponibilidad de los laboratorios (HAS-200, FMS-200, sala de software especializado, gestión de operaciones GEIO y trabajo en alturas) y sus correspondientes equipos o materiales. Por otra parte, las operaciones manuales que ejecutan el grupo de trabajo del laboratorio no les permite llevar un control y gestión sobre el banco de información o de datos, el cual puede llegar a ser muy útil en la toma de decisiones como: ¿Si la inversión de millones de pesos en sistemas como la HAS-200 o la FMS-200 es coherente con la utilización por parte de la comunidad universitaria sobre la cual fueron planeadas? O si, por el contrario, se requiere inversión en otros recursos que se involucren frecuentemente al método de enseñanza implementado por cada docente e igualmente satisfagan los objetivos académicos del proyecto curricular. La finalidad de este proyecto es mejorar la administración del inventario y gestionar el uso de horarios libres de los laboratorios de tecnología industrial e ingeniería de producción a partir de la disponibilidad, confiabilidad e integridad de la información. Para abordar la problemática actual se hizo necesario abarcar una metodología que permita evidenciar resultados en el menor tiempo posible, es por ello que una de las alternativas seleccionadas para este proyecto es la metodología scrum, la cual consiste en el levantamiento de información por medio de historias de usuario, que a su vez permiten dividir los procesos generales del proyecto y planear todas las actividades que con llevan al cumplimiento de los objetivos de cada uno de estos procesos. Para cumplir con nuestro propósito, el presente documento se compone del marco de referencia, metodología scrum, diseño e implementación y pruebas de software. En el marco de referencia, se describió cada una de las herramientas de software libre utilizadas. En la metodología scrum, se desarrollaron los requerimientos funcionales y los sprints ejecutados. En diseño e implementación, se detallan las colecciones construidas en la base de datos no relacional y los servicios elaborados en la api rest. En las pruebas de software, se definen los test construidos y se exponen los respectivos resultados.

15

2. JUSTIFICACIÓN

Automatizar algunos procesos con relación al préstamo y control de los recursos del laboratorio de industrial, que permita mejorar la calidad de respuesta, organización y almacenamiento de la información. Dado que actualmente se lleva a cabo un ejercicio manual en el proceso de préstamo y control, este presenta inconvenientes para el acceso de los recursos y no permite en muchos casos la escalabilidad de la información, ya que el sitio puede llegar a ser un factor de impedimento para el almacenamiento físico, organización y búsqueda de los mismos. El acceso a la información es muy importante ya que permite informar a una comunidad e involucra a la toma de decisiones sobre hechos relevantes. En la página web de la universidad en el apartado del laboratorio de industrial se puede evidenciar información sobre los recursos y horarios en los cuales pueden estar disponibles para su uso, sin embargo se queda muy corta en el sentido de conocer información actualizada para desarrollar prácticas libres. Este proyecto busca mejorar los procesos de préstamo y control de los recursos haciendo uso de tecnologías web y móviles.

16

3. DEFINICIÓN DEL PROYECTO

3.1 TÍTULO

PRESTALUD: PROTOTIPO TELEMÁTICO PARA EL PROCESO DE PRÉSTAMO Y CONTROL DE RECURSOS DE LOS LABORATORIOS DE INDUSTRIAL DE LA FACULTAD TECNOLÓGICA DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

3.2 PROBLEMA

La gestión de prácticas libres del laboratorio de industrial de la Facultad Tecnológica inicia con la exposición del horario de uso libre de los laboratorios en su página web. El préstamo de las salas, máquinas y entrega de instrumentos se lleva a cabo mediante el diligenciamiento de formatos físicos y requerimiento del carnet para los estudiantes y profesores de la universidad. El administrador del laboratorio tiene que verificar la disponibilidad de las salas, equipos e instrumentos para permitir el acceso o entrega a quien realiza la solicitud. El control del inventario del laboratorio se desarrolla de forma manual a partir de los soportes que brinda el almacén general de la universidad que realiza la entrega de los equipos o instrumentos. El grupo de trabajo realiza una revisión de los equipos registrando los resultados del proceso en informes que describen los daños, necesidades de mantenimiento y organización dentro de la infraestructura del laboratorio. Los estudiantes para realizar las prácticas libres deben ceder el carnet en la administración del laboratorio durante el tiempo que desarrollen la práctica para garantizar la identidad de la persona responsable en la manipulación de los equipos, máquinas, instrumentos, salas, entre otros. Este procedimiento de ceder el carnet durante un tiempo a un recurso de la universidad como laboratorios, biblioteca, salones de talleres o auditorio restringe al estudiante de poder acceder en paralelo a varios recursos. El grupo de trabajo del laboratorio de industrial como se describe anteriormente desarrolla procesos manuales para brindar el acceso a integrantes de la universidad; el control e inventario de las salas, máquinas, equipos e instrumentos es poco eficiente porque les dificulta el análisis de la información recaudada en los formatos físicos para tomar decisiones que promuevan actividades o procesos académicos en pro de toda la comunidad educativa. ¿De qué manera se pueden mejorar, agilizar o facilitar los procesos de préstamo y control del laboratorio de industrial?

17

4. OBJETIVOS

4.1 OBJETIVO GENERAL

Desarrollar un prototipo telemático para el control del uso e inventario de los recursos (HAS 200, FMS 200, sala de software, trabajo en alturas e instrumentos) del laboratorio de industrial de la Universidad Distrital Francisco José de Caldas Facultad Tecnológica.

4.2 OBJETIVOS ESPECÍFICOS

Desarrollar un módulo para la administración de los usuarios del sistema.

Implementar un módulo para la gestión del préstamo de los recursos del laboratorio de industrial.

Realizar un módulo para la visualización de los recursos del laboratorio de industrial disponibles para su uso.

Diseñar API REST y base de datos para la comunicación entre las aplicaciones web y móvil.

Construir un módulo para llevar el inventario y hoja de vida de los recursos del laboratorio de industrial.

18

5. MARCO DE REFERENCIA

5.1 ANTECEDENTES

Documentación de procesos de los laboratorios de Tecnología Industrial e Ingeniería de Producción de la Facultad Tecnológica de la Universidad Distrital Francisco José de Caldas. Tomando como base la calidad se realiza un proceso de documentación en los laboratorios del proyecto curricular de tecnología industrial e ingeniería de producción, partiendo de cada uno de los 5 laboratorios independientemente, para lograr una buena documentación de cada uno ellos y generando la propuesta de los documentos que se deben utilizar, basando el análisis en las normas de calidad como: la ISO 9001:2008, la NTC-ISO-IEC 17025:2000 y la NTCGP 1000:2009; contemplando estas normas porque la primera es la norma que actualmente se maneja para los procesos de certificación de calidad, la segunda es la norma que se utiliza para laboratorios de ensayo y calibración, y la tercera la norma que rige para la calidad de la gestión pública. Partiendo de las necesidades de tener una mejor calidad de laboratorios y servicios que se prestan en ellos se crea el proyecto de iniciar el proceso y la primera fase de la certificación de calidad de cada uno de estos laboratorios ya que como entidad pública estamos en el derecho y la obligación de ser cada vez mejores y se sabe que para lograrlo tenemos que enfocar nuestros espacios y conocimiento hacia la calidad y la mejora continua de los mismos; generando el incentivo de acoger el ciclo PHVA en nuestra universidad y la conciencia de utilizar todas las herramientas que nos ofrece la misma para tener una educación de la mejor calidad posible, se desea documentar los procesos de los laboratorios porque son elementos fundamentales dentro de la formación académica ya que otorgan información y el conocimiento necesario para cada uno de los estudiantes dependiendo la práctica o investigación que se desarrollen en los mismos.7

7 HERRERA, Sonia y SARMIENTO, Camilo. Documentación de Procesos de los Laboratorios de Tecnología Industrial e Ingeniería de Producción de la Facultad Tecnológica de la Universidad Distrital Francisco José de Caldas con miras hacia la certificación de Calidad. Bogotá D.C.: Universidad Distrital Francisco José de Caldas. Facultad Tecnológica. 2016. 8 p.

19

5.2 MARCO TEÓRICO

5.2.1 ¿Qué es el control del uso? El Control del Uso se refiere a la administración del acceso de los estudiantes, al cumplimiento de horario de uso de laboratorios, a la entrega y recepción del equipamiento móvil, así como también, velar por la adecuada utilización del equipamiento y la prevención de fallas en su funcionamiento. ¿Qué beneficios tiene realizar un adecuado Control del Uso? Un adecuado control del uso facilita la utilización de los recursos digitales, asegurando el acceso de los estudiantes, mediante el cumplimiento de los horarios establecidos y las reservas de equipamiento móvil realizadas. Además, al promover normas y buenas prácticas, el control del uso facilita el funcionamiento continuo de los recursos (PCs, portátiles, proyectores, software, etc.). Un adecuado control del uso previene descoordinaciones que ocasionen pérdida de horas de clases, pérdida de equipos, deterioros, fallas u otras situaciones que pueden afectar el equipamiento. Además, en caso de ocurrencia, permite detectarlas en forma temprana. El cumplimiento de los horarios del laboratorio y de la reserva del equipamiento móvil (entrega y recepción), beneficia al establecimiento facilitando un acceso equitativo a la tecnología de todos los estudiantes.8 5.2.2 ¿Qué es Scrum? Scrum es un marco de trabajo que nos permite encontrar prácticas emergentes en dominios complejos, como la gestión de proyectos de innovación. No es un proceso completo, y mucho menos, una metodología. En lugar de proporcionar una descripción completa y detallada de cómo deben realizarse las tareas de un proyecto, genera un contexto relacional e iterativo, de inspección y adaptación constante para que los involucrados vayan creando su propio proceso. Esto ocurre debido a que no existen ni mejores ni buenas prácticas en un contexto complejo. Es el equipo de involucrados quien encontrará la mejor manera de resolver sus problemáticas. Este tipo de soluciones serán emergentes. El equipo de desarrollo se encuentra apoyado en dos roles: el ScrumMaster y el Product Owner. El ScrumMaster es quien vela por la utilización de Scrum, la remoción de impedimentos y asiste al equipo a que logre su mayor nivel de performance posible. Puede ser considerado un coach o facilitador encargado de acompañar al equipo de desarrollo. El Product Owner es quien representa al

8 MINISTERIO DE EDUCACIÓN GOBIERNO DE CHILE. Guía para Control del Uso [en línea], [revisado 11 julio 2017]. Disponible en Internet: http://www.enlaces.cl/wp-content/uploads/Control_del_Uso.pdf

http://www.enlaces.cl/wp-content/uploads/Control_del_Uso.pdf

20

negocio, stakeholders, cliente y usuarios finales. Tiene la responsabilidad de conducir al equipo de desarrollo hacia el producto adecuado. El progreso de los proyectos que utilizan Scrum se realiza y verifica en una serie de iteraciones llamadas Sprints. Estos Sprints tienen una duración fija, pre-establecida de no más de un mes. Al comienzo de cada Sprint el equipo de desarrollo realiza un compromiso de entrega de una serie de funcionalidades o características del producto en cuestión. Al finalizar el Sprint se espera que estas características comprometidas estén terminadas, lo que implica su análisis, diseño, desarrollo, prueba e integración al producto. En este momento es cuando se realiza una reunión de revisión del producto construido durante el Sprint, donde el equipo de desarrollo muestra lo construido al Product Owner y a cualquier stakeholder interesado en participar. El feedback obtenido en esta reunión puede ser incluido entre las funcionalidades a construir en futuros Sprints.9 Scrum estructura el desarrollo del producto en ciclos o iteraciones que denomina Sprints. La idea central es que un Sprint se fije objetivos (funcionalidades que desarrollará) al comienzo del mismo, y que el trabajo acordado esté finalizado al terminar. Antes de comenzar un Sprint, el Product Owner discute y define con el resto del equipo qué requisitos o ítems del Product Backlog habrá que desarrollar en el Sprint, construyendo con ellos el Sprint Backlog. Se parte de requisitos para generar tareas. El Sprint Backlog, por lo tanto, no es un subconjunto del Product Backlog, ya que sus ítems son tareas, mientras que los de éste son requisitos. En cuanto a la organización de los Sprints, también existen algunas reglas. Durante un Sprint, no se pueden cambiar los integrantes de un grupo de trabajo ni el Sprint Backlog. Lo único que se puede hacer es cancelar un Sprint por razones de fuerza mayor. Durante el Sprint, se realizan diariamente las Scrum Daily Meetings, en las que participa todo el equipo, y en las que se analiza el avance y el trabajo del día. Estas reuniones son las que dieron nombre al método. El Scrum Master hace de moderador de estas reuniones. Al finalizar el Sprint, se realiza una reunión denominada Sprint Review Meeting, de la que se obtienen las lecciones aprendidas, que se dejan registradas en un artefacto denominado Sprint Retrospective.

9 ALAIMO, Diego Martín. Proyectos ágiles con Scrum: flexibilidad, aprendizaje, innovación y colaboración en contextos

complejos. 1 ed. Ciudad Autónoma de Buenos Aires: Kleer, 2013. 22 p. EBook.

21

En cuanto a las métricas, se pueden usar las que desee el equipo. No obstante, hay un reporte típico de Scrum, denominado Burndown Chart. El objetivo de este gráfico es hacer un seguimiento sobre la base del trabajo que falta por hacer. Se puede realizar durante el Sprint, en cuyo caso se llama Sprint Burndown Chart, y muestra día a día cuánto trabajo falta realizar dentro del Sprint, y su relación con el que se esperaba realizar. También se puede proceder Sprint a Sprint el Product Burndown Chart, en el nivel del proyecto. Visto en forma más global, un proyecto Scrum tiene tres fases:

Inicio: incluye la planificación de una versión, con una primera estimación en tiempo y costo, y un diseño de alto nivel.

Fase iterativa, con varios Sprints.

Cierre: preparación para la versión desplegable, documentación final y entornos necesarios.10

5.2.3 Protocolos de comunicación. 5.2.3.1 La web y el protocolo HTTP Dentro del mundo de Internet destaca una aplicación que es, con mucho, la más utilizada: la Word Wide Web (WWW), a la que nos referiremos coloquialmente como la web. Su gran éxito se debe a la facilidad de uso, dado que simplifica el acceso a todo tipo de información, y a que está información es presentada de forma atractiva. Básicamente, la web nos ofrece un servicio de acceso a información distribuida en miles de servidores en todo Internet, que nos permite ir navegando por todo tipo de documentos multimedia gracias a un sencillo sistema de hipervínculos. Para la comunicación entre los clientes y los servidores de esta aplicación, se emplea el protocolo HTTP (Hypertext Transfer Protocol), que será el objeto de estudio de este apartado. El protocolo HTTP HTTP es un sencillo protocolo cliente-servidor que articula los intercambios de información entre los navegadores web y los servidores web. Fue propuesto por Tim Berners-Lee, atendiendo a las necesidades de un sistema global de distribución de información como la World Wide Web. En la web los servidores han de escuchar en el puerto 80, esperando la conexión de algún cliente web. Versión 1.0 del protocolo HTTP Con la popularización de la aplicación WWW, pronto se vio la necesidad de ampliar este sencillo protocolo para permitir nuevas funcionalidades. Se definió la versión

10 FONTELA, Carlos. UML: modelado de software para profesionales. Buenos Aires.: Alfaomega Grupo Editor Argentino, 2011. 23-24 p.

22

1.0 del protocolo, que añadía nuevos métodos (PUT, POST) además de permitir el intercambio de cabeceras entre cliente y servidor. Aunque el método GET es el más utilizado, en la versión 1.0 se añaden nuevos métodos. A continuación se incluye una descripción: GET: Petición de lectura de un recurso. POST: Envió de información asociada a un recurso del servidor. PUT: Creación de un nuevo recurso en el servidor. DELETE: Eliminación de un recurso. HEAD: El servidor solo transmitirá las cabeceras, no la página.11 De manera esquemática, el funcionamiento de HTTP es el siguiente: el cliente establece una conexión TCP hacia el servidor, hacia el puerto HTTP (o el indicado en la dirección de conexión), envía un comando HTTP de petición de un recurso (junto con algunas cabeceras informativas) y por la misma conexión el servidor responde con los datos solicitados y con algunas cabeceras informativas. El protocolo define además cómo codificar el paso de parámetros entre páginas, el tunelizar las conexiones (para sistemas de firewall), define la existencia de servidores intermedios de cache, etc. Las directivas de petición de información que define HTTP 1.1 (la versión considerada estable y al uso) son: GET: Petición de recurso. POST: Petición de recurso pasando parámetros. HEAD: Petición de datos sobre recurso. PUT: Creación o envío de recurso. DELETE: Eliminación de recurso. TRACE: Devuelve al origen la petición tal como se ha recibido en el receptor, para depurar errores. OPTIONS: Sirve para comprobar las capacidades del servidor. CONNECT: Reservado para uso en servidores intermedios capaces de funcionar como túneles. Respuestas en HTTP Las respuestas en HTTP son muy similares a las peticiones. Una respuesta estándar a una petición de una página sería similar a lo siguiente: HTTP/1.1 200 OK Date: Mon, 04 Aug 2003 15:19:10 GMT Server: Apache/2.0.40 (Red Hat Linux) Last-Modified: Tue, 25 Mar 2003 08:52:53 GMT Accept-Ranges: bytes Content-Length: 428 Connection: close

11 TOMÁS, Jesús. El gran libro de Android. 5 ed. México.: Alfaomega, 2016. 477 p.

23

<HTML> ... En ella podemos observar que la primera línea nos responde con la versión del protocolo empleada para enviarnos la página, seguida de un código de retorno y una frase de retorno. El código de retorno puede adoptar uno de los siguientes valores:

- 1xx Petición recibida, continúa en proceso. - 2xx Correcta. Petición procesada correctamente. - 3xx Redirección. La petición debe repetirse o redirigirse. - 4xx Error de cliente. No se puede procesar la petición porque ésta es

incorrecta, no existe, etc. - 5xx Error de servidor. El servidor ha fallado intentando procesar la petición,

que a priori es correcta. La frase de retorno dependerá de la implementación, pero sólo sirve como aclaratorio del código de retorno. Después del estatus aparece una serie de campos de control, con el mismo formato que en las cabeceras de la petición que nos informan del contenido (fecha de creación, longitud, versión del servidor, etc.).12 5.2.3.2 Servicios web basados en REST En primer lugar conviene destacar que el término REST se refiere a una arquitectura en lugar de a un protocolo en concreto, como es el caso de SOAP. A diferencia de SOAP, no vamos a añadir una capa adicional a la pila de protocolos, sino que utilizaremos directamente el protocolo HTTP. Siendo estrictos, la arquitectura REST no impone el uso de HTTP; no obstante, en la práctica se entiende que un servicio web basado en REST es aquel que se implementa directamente sobre la web. Este planteamiento supone seguir los principios de la aplicación WWW, pero en lugar de solicitar páginas web solicitaremos servicios web. Los principios básicos de la aplicación WWW y, por tanto, los de REST son:

Transporte de datos mediante HTTP, utilizando las operaciones de este protocolo, que son GET, POST, PUT y DELETE.

Los diferentes servicios son invocados mediante el espacio de URI unificado. Como ya se ha tratado, una URI identifica un recurso en internet. Este sistema ha demostrado ser flexible, sencillo y potente al mismo tiempo. Se cree que fue uno de los principales factores que motivó el éxito de WWW.

12 MATEU, Carles. Desarrollo de aplicaciones web. Barcelona.: Fundació per a la Universitat Oberta de Catalunya, 2004. 14-18 p.

24

La codificación de datos es identificada mediante tipos MIME (text/html, image/gif, etc.), aunque el tipo de codificación preferido es XML (text/xml).

Las ventajas de REST derivan de su simplicidad, Entre estas podemos destacar: mejores tiempos de respuesta y disminución de sobrecarga tanto en cliente como en servidor, mayor estabilidad frente a futuros cambios y, también, una gran sencillez en el desarrollo de clientes, que solo han de ser capaces de realizar interacciones HTTP y codificar información en XML. Como inconveniente podemos indicar que, al igual que ocurre con el protocolo HTTP, no se mantiene el estado. Es decir, cada solicitud es tratada por el servidor de forma independiente sin recordar solicitudes anteriores.13 5.2.4 Servidor web. 5.2.4.1 Node.js La meta número uno declarada de Node es "proporcionar una manera fácil para construir programas de red escalables". ¿Cuál es el problema con los programas de servidor actuales? Hagamos cuentas. En lenguajes como Java™ y PHP, cada conexión genera un nuevo hilo que potencialmente viene acompañado de 2 MB de memoria. En un sistema que tiene 8 GB de RAM, esto da un número máximo teórico de conexiones concurrentes de cerca de 4.000 usuarios. A medida que crece su base de clientes, si usted desea que su aplicación soporte más usuarios, necesitará agregar más y más servidores. Desde luego, esto suma en cuanto a los costos de servidor del negocio, a los costos de tráfico, los costos laborales, y más. Además de estos costos están los costos por los problemas técnicos potenciales — un usuario puede estar usando diferentes servidores para cada solicitud, así que cualquier recurso compartido debe almacenarse en todos los servidores. Por todas estas razones, el cuello de botella en toda la arquitectura de aplicación Web (incluyendo el rendimiento del tráfico, la velocidad de procesador y la velocidad de memoria) era el número máximo de conexiones concurrentes que podía manejar un servidor. Node resuelve este problema cambiando la forma en que se realiza una conexión con el servidor. En lugar de generar un nuevo hilo de OS para cada conexión (y de asignarle la memoria acompañante), cada conexión dispara una ejecución de evento dentro del proceso del motor de Node. Node también afirma que nunca se quedará en punto muerto, porque no se permiten bloqueos y porque no se bloquea directamente para llamados E/S. Node afirma que un servidor que lo ejecute puede soportar decenas de miles de conexiones concurrentes.

13 TOMÁS, Jesús. El gran libro de Android. 5 ed. México.: Alfaomega, 2016. 489-490 p.

25

Entonces, ahora que usted tiene un programa que puede manejar cientos de miles de conexiones concurrentes, ¿qué puede usted construir en realidad con Node? Sería extraordinario si usted tuviera una aplicación Web que necesitara de toda esta cantidad de conexiones. Ese es uno de esos problemas del tipo "si usted tiene este problema, no es un problema". Antes de pasar a ello, observemos cómo funciona Node y cómo está diseñado que se ejecute. Cómo funciona Node Node ejecuta V8 JavaScript. Espere... ¿qué? ¿JavaScript en el servidor? Sí, leyó correctamente. El JavaScript del lado del servidor puede ser un concepto nuevo para cualquiera que haya trabajado exclusivamente con JavaScript del lado del cliente, pero la idea en sí no es tan inverosímil — ¿por qué no utilizar el mismo lenguaje de programación que usted usa en el cliente del lado del servidor? ¿Qué es el V8? El motor V8 JavaScript es el motor JavaScript subyacente que Google usa con su navegador Chrome. Pocas personas piensan en lo que en realidad sucede con JavaScript en el cliente. Bien, un motor JavaScript en realidad interpreta el código y lo ejecuta. Con el V8, Google creó un intérprete ultra-rápido escrito en C++, con otro aspecto único: usted puede descargar el motor e incorporarlo a cualquier aplicación que desee. No está restringido a ejecutarse en un navegador. Así, Node en realidad usa el motor V8 JavaScript escrito por Google y le da otro propósito para usarlo en el servidor. ¡Perfecto! Para qué crear un nuevo lenguaje cuando ya hay una buena solución disponible.14 5.2.4.2 Express Es un módulo de NodeJS implementado por terceras partes. Es el módulo por excelencia para el desarrollo web, proporcionando una API muy completa, con múltiples funcionalidades necesarias en cualquier aplicación web. Los objetos application, request y response Objeto application: Es una instancia o referencia asociada al módulo Express. Con frecuencia se utiliza para configurar la aplicación Express u obtener información de las características de la misma. Objeto request: Es un objeto, que encapsula a su vez a otro objeto utilizado en el módulo http de NodeJS, llamado request. Almacena información de la última petición HTTP realizada al servidor, como por ejemplo parámetros de la petición o cabeceras HTTP.

14 ABERNETHY, Michael. ¿Simplemente qué es Node.js? IBM developerWorks [en línea], 14 de junio de 2011 [revisado 20 julio 2017]. Disponible en Internet: https://www.ibm.com/developerworks/ssa/opensource/library/os-nodejs/index.html

26

Objeto response: Es un objeto, que encapsula a su vez a otro objeto utilizado en el módulo http de NodeJS, llamado response. Almacena la información a proporcionar, como respuesta ante la última petición HTTP realizada al servidor. La abreviatura común para trabajar con el objeto es res.15 5.2.4.3 Json web token JSON Web Token (JWT) es un estándar abierto (RFC-7519) basado en JSON para crear un token que sirva para enviar datos entre aplicaciones o servicios y garantizar que sean válidos y seguros. El caso más común de uso de los JWT es para manejar la autenticación en aplicaciones móviles o web. Para esto cuando el usuario se quiere autenticar manda sus datos de inicio del sesión al servidor, este genera el JWT y se lo manda a la aplicación cliente, luego en cada petición el cliente envía este token que el servidor usa para verificar que el usuario este correctamente autenticado y saber quién es. Este igual no es el único caso de uso para JWT, es posible usarlo para transferir cualquier dato entre servicios de nuestra aplicación y asegurarnos de que sean siempre válido. Por ejemplo si tenemos un servicio de envío de email otro servicio podría enviar una petición con un JWT junto al contenido del mail o cualquier otro dato necesario y que estemos seguros que esos datos no fueron alterados de ninguna forma.16 5.2.5 Gestión de la información. 5.2.5.1 Bases de datos no relacionales Durante la evolución del modelo relacional de almacenamiento de datos, otros diferentes modelos de almacenamiento también han surgido. Uno de los más conocidos es el modelo de almacenamiento de datos orientado a documentos. Este tipo de modelo de almacenamiento de datos no utiliza tablas. Almacena la información en unas estructuras jerárquicas, llamadas colecciones. Cada uno de los elementos de una colección es un documento. El formato más utilizado para representar la información de un documento en XML o JSON. Ambos, son dos formatos de representación de la información de forma jerarquizada, con diferentes niveles de jerarquía, normalmente en función de la importancia del dato. JSON representa la información en una cadena de caracteres y XML lo hace utilizando un lenguaje de etiquetas para establecer las jerarquías.

15 LÓPEZ JURADO, Francisco Carlos. Api rest con mean para contenidos multimedia. Madrid.: Universidad Politécnica de Madrid. Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. 2015. 37 p. 16 XALAMBRÍ, Sergio Daniel. Introducción a JSON Web Tokens (JWT). Blog Platzi [en línea], [revisado 20 Agosto 2017]. Disponible en Internet: https://platzi.com/blog/introduccion-json-web-tokens/

27

Esta representación de la información, permite almacenar una gran cantidad de datos, que tienen cierta relación entre sí. Al almacenar diferentes tipos de datos en una misma estructura, pero formando parte de una misma colección, las operaciones típicas de manipulación de la información (acceso, inclusión, modificación o borrado), se aceleran en gran medida. Las BBDDs no relacionales, tienen que trabajar con menos contenedores de información (colecciones) que las BBDDs relacionales, que necesitaría manipular una mayor cantidad de tablas. Las colecciones pueden ser más heterogéneas que una tabla, albergando datos de distinta tipología dentro de un mismo entorno de manipulación. Otra de las ventajas de las BBDDs no relacionales, es la flexibilidad para modificar modelos. En una BBDD relacional, es necesario modificar la estructura de una tabla y los registros existentes, para añadir un nuevo campo. En cambio, en las BBDDs no relacionales, se puede añadir un nuevo atributo a una colección, sin necesidad de modificar los datos de la colección. A partir del cambio, lo nuevos documentos que se almacenen en la colección disponen de este nuevo campo. Los anteriores documentos carecen de esta propiedad. No existen problemas de incompatibilidad de documentos en una misma colección, al ser permitida la heterogeneidad en este tipo de bases de datos. En las BBDDs relacionales es algo impensable. Al disponer de documentos dentro de una misma colección y que algunos de ellos dispongan de atributos diferentes, permite asignar la responsabilidad de la estructura de cada colección a la aplicación web, en lugar de ser responsabilidad de la propia BBDD. Esta ventaja acelera notablemente el proceso de desarrollo.17 5.2.5.2 MongoDB MongoDB (que proviene de «humongous») es la base de datos NoSQL líder y permite a las empresas ser más ágiles y escalables. Organizaciones de todos los tamaños están usando MongoDB para crear nuevos tipos de aplicaciones, mejorar la experiencia del cliente, acelerar el tiempo de comercialización y reducir costes. Es una base de datos ágil que permite a los esquemas cambiar rápidamente cuando las aplicaciones evolucionan, proporcionando siempre la funcionalidad que los desarrolladores esperan de las bases de datos tradicionales, tales como índices secundarios, un lenguaje completo de búsquedas y consistencia estricta.

17 LÓPEZ JURADO, Francisco Carlos. Api rest con mean para contenidos multimedia. Madrid.: Universidad Politécnica de Madrid. Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. 2015. 62-63 p.

28

MongoDB ha sido creado para brindar escalabilidad, rendimiento y gran disponibilidad, escalando de una implantación de servidor único a grandes arquitecturas complejas de centros multidatos. MongoDB brinda un elevado rendimiento, tanto para lectura como para escritura, potenciando la computación en memoria (in-memory). La replicación nativa de MongoDB y la tolerancia a fallos automática ofrece fiabilidad a nivel empresarial y flexibilidad operativa.18 5.2.5.3 Mongoose Mongoose es un módulo NodeJS implementado por terceras partes. Puede ser empleado en una aplicación Express, para el manejo de BBDDs MongoDB. Emplea esquemas, para la definición de las colecciones de la BBDD. Estos esquemas son estructuras JSON, en las que se definen los atributos de la colección y las características de cada uno. El modelado se realiza con estos esquemas y a partir del mismo, los documentos de una colección pueden ser manipulados como objetos, en una aplicación Express. Gracias a la definición de estos esquemas, Mongoose aporta estructuración en BBDDs no relacionales, que no tienen una estructura fija para sus colecciones. Como cualquier otro módulo de NodeJS implementado por terceras partes, su instalación es sencilla, incluyendo la dependencia correspondiente al módulo, en el fichero package.json, Posteriormente a la inclusión de la dependencia, se hace uso de NPM para la instalación del código fuente asociado al módulo. Para definir los esquemas de cada colección, Mongoose ofrece un objeto llamado Schema para la definición de las estructuras. Tras la definición de las estructuras asociadas a cada colección, es posible crear instancias del objeto esquema, para gestionar los documentos de la colección como objetos. Mediante la manipulación de estos objetos, es posible realizar las operaciones de creación, consulta, actualización y borrado de la información.19 5.2.6 Sistema de control de versiones. ¿Qué es el control de versiones, y por qué debería importarte? El control de versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones específicas más adelante. Los ejemplos de este libro utilizan el control de versiones

18 MONGODB. Reinventando la gestión de datos. [en línea], [revisado 20 julio 2017]. Disponible en Internet: https://www.mongodb.com/es 19 LÓPEZ JURADO, Francisco Carlos. Api rest con mean para contenidos multimedia. Madrid.: Universidad Politécnica de Madrid. Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. 2015. 76 p.

29

para el código fuente, pero puedes emplearlo para casi cualquier tipo de archivo que encuentres en un ordenador. Si eres diseñador gráfico o web, y quieres mantener cada versión de una imagen o diseño (algo que sin duda quieres), un sistema de control de versiones (Version Control System o VCS en inglés) es una elección muy sabia. Te permite revertir archivos a un estado anterior, revertir el proyecto entero a un estado anterior, comparar cambios a lo largo del tiempo, ver quién modificó por última vez algo que puede estar causando un problema, quién introdujo un error y cuándo, y mucho más. Usar un VCS también significa que si fastidias o pierdes archivos, puedes recuperarlos fácilmente. Además, obtienes todos estos beneficios a un coste muy bajo. 5.2.6.1 Sistemas de control de versiones distribuidos Es aquí donde entran los sistemas de control de versiones distribuidos (Distributed Version Control Systems o DVCSs en inglés). En un DVCS (como Git, Mercurial, Bazaar o Darcs), los clientes no sólo descargan la última instantánea de los archivos: replican completamente el repositorio. Así, si un servidor muere, y estos sistemas estaban colaborando a través de él, cualquiera de los repositorios de los clientes puede copiarse en el servidor para restaurarlo. Cada vez que se descarga una instantánea, en realidad se hace una copia de seguridad completa de todos los datos. Es más, muchos de estos sistemas se las arreglan bastante bien teniendo varios repositorios con los que trabajar, por lo que puedes colaborar con distintos grupos de gente de maneras distintas simultáneamente dentro del mismo proyecto. Esto te permite establecer varios tipos de flujos de trabajo que no son posibles en sistemas centralizados, como pueden ser los modelos jerárquicos.20 5.2.6.2 Git Es uno de los SCV distribuidos más populares, inicialmente desarrollado para Linux. Git permite a varios programadores trabajar paralelamente con sus propias copias de trabajo obtenidas de un repositorio, como lo efectúan todos los SCV distribuidos. Git está compuesto de una estructura de tres secciones, las cuales son:

Directorio de Git. Es donde se guardan los objetos que mantienen el historial con los cambios que se han producido en el proyecto.

Directorio de trabajo. Contiene los archivos de la versión actual del proyecto sobre los que se realizan los cambios.

20 CHACON, Scott. Pro Git, el libro oficial de Git. LIBROSWEB [en línea], [revisado 20 julio 2017]. Disponible en Internet: http://librosweb.es/libro/pro_git/capitulo_1/acerca_del_control_de_versiones.html

30

Área de preparación o índice. Es un archivo que incluye la información de los cambios que se van a enviar en la próxima confirmación.

Git utiliza ramas favoreciendo el trabajo paralelo sobre un mismo proyecto. En el momento de iniciar un repositorio se genera una rama maestra, de donde se extienden nuevas ramas que incluirán todo el historial del proyecto. Cuando se han realizado los cambios en una rama, permite que ésta se combine con otras ramas, uniéndose a la rama maestra (merge), integrando historiales y archivos de las ramas participantes; es entonces cuando se genera una nueva versión. El proceso de actualización de los archivos contenidos en un repositorio y la posterior generación de una nueva versión utilizando Git es el siguiente: cada desarrollador debe generar una copia del repositorio original en su computadora, creando un repositorio local. Este repositorio local contiene toda la información del historial de cambios y los archivos del directorio de trabajo. En esta etapa el desarrollador puede empezar a trabajar en el repositorio Git local, creando y modificando los archivos de acuerdo a sus requerimientos. Para crear y almacenar una nueva versión el procedimiento es el siguiente: primeramente se debe consultar el estado del repositorio, con lo cual se obtiene un listado de los archivos que han sido modificados. Enseguida, se seleccionan los que se almacenarán en la nueva versión, esto es, los archivos que contienen cambios y se quieren incluir en la nueva versión. Posteriormente, se detallan los cambios que se han realizado en los archivos, esto servirá a los desarrolladores para identificar las versiones. Al finalizar estos pasos, Git almacenará en la sección "área de preparación" una nueva copia en el historial del proyecto con todos los cambios incluidos. Posteriormente, el desarrollador debe confirmar los cambios, con lo cual Git almacenará una nueva versión del proyecto en la sección "directorio de git" conteniendo los archivos que sufrieron cambios y, de los archivos que no fueron modificados solo guarda el enlace al archivo anterior, que ya se encontraba en el repositorio del proyecto. En esta parte del proceso del funcionamiento de Git, los cambios y actualización de versión solo se han realizado en el repositorio local del desarrollador. Enseguida se debe realizar un proceso de fusión (merge), el cual consiste en combinar una o varias ramas de un proyecto en un repositorio local al repositorio origen o al repositorio de otros desarrolladores. La acción de merge realiza una combinación de los historiales y archivos de las dos ramas implicadas. Git detecta los cambios que existen en las dos ramas, combinándolas y generando una única versión con los cambios realizados en ambas ramas. Al efectuar el merge se cambian todos los archivos en la rama del proyecto destino, generándose una nueva versión.21

21 Tello, Edgar; Sosa, Claudia; Tello, Diego. Revisión de los sistemas de control de versiones utilizados en el desarrollo de software. En: Revista de Ingenierías USBMED. Junio, 2012. vol. 3, no. 1, p. 78.

31

5.2.7 Cliente web. 5.2.7.1 JavaScript JavaScript es un lenguaje de programación que se utiliza principalmente para crear páginas web dinámicas. Una página web dinámica es aquella que incorpora efectos como texto que aparece y desaparece, animaciones, acciones que se activan al pulsar botones y ventanas con mensajes de aviso al usuario. Técnicamente, JavaScript es un lenguaje de programación interpretado, por lo que no es necesario compilar los programas para ejecutarlos. En otras palabras, los programas escritos con JavaScript se pueden probar directamente en cualquier navegador sin necesidad de procesos intermedios. A pesar de su nombre, JavaScript no guarda ninguna relación directa con el lenguaje de programación Java. Legalmente, JavaScript es una marca registrada de la empresa Sun Microsystems, como se puede ver en http://www.sun.com/suntrademarks/.22 5.2.7.2 AngularJS Es un framework diseñado para construir aplicaciones web, que sean servidas bajo el concepto de una única página o documento HTML, que va alterando su contenido en función de las operaciones que un usuario realiza. Esto se consigue, modificando una única vista dinámicamente tras cada operación del usuario. Uno de los objetivos que persigue y logra, es la potenciación de las características del lenguaje HTML, utilizado para la estructuración de una vista. AngularJS lo consigue al añadir nuevas etiquetas a este lenguaje, junto a nuevos atributos para etiquetas ya existentes. Por otro lado, es un framework de fácil utilización en proyectos con menor enjundia. A medida que el proyecto es más grande y existe una mayor complejidad en los algoritmos, las implementaciones con AngularJS pueden aumentar en dificultad exponencialmente. No obstante, si el desarrollador o equipo de desarrollo tiene claro los conceptos clave del framework, se reduce esta dificultad considerablemente.23

22 Eguiluz, Javier. Introducción a JavaScript. LIBROSWEB. [en línea], [revisado 20 julio 2017]. Disponible en Internet: http://librosweb.es/libro/javascript/capitulo_1.html 23 LÓPEZ JURADO, Francisco Carlos. Api rest con mean para contenidos multimedia. Madrid.: Universidad Politécnica de Madrid. Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. 2015. 79 p.

http://www.sun.com/suntrademarks/

32

5.2.8 Cliente rest móvil. 5.2.8.1 Android y arquitectura Android constituye un sistema operativo para dispositivos móviles. Las aplicaciones para Android se programan en el lenguaje Java y C++, y son ejecutadas en una máquina virtual llamada Dalvik, el núcleo de la cual está basado este sistema operativo es Linux. Maneja la licencia de distribución apache 2.0, lo que es denominado software de libre distribución. Android es patrocinado principalmente por la compañía Google y por un conjunto de empresas que conforman el Open Handset Alliance (OHA). Actualmente Android ha conseguido reunir los elementos necesarios para desarrollar y controlar las funcionalidades ofrecidas por los dispositivos móviles (GPS, NFC, Videojuegos, Etc.), estandarizando así el desarrollo de aplicaciones para una gran cuota del mercado actual. Además de todo ello, otro aspecto básico para entender la visión de Android es que proyecta facilitar la integración de estos dispositivos con las contingencias cada vez mayores ofrecidas por la Web. Por ejemplo, aplicaciones desarrolladas en Android que indican la posición en coordenadas a través del servicio Google Maps, introducir medios de pago electrónico por medio del chip NFC de un teléfono con Android, entre otras aplicaciones. La arquitectura empleada de Android se caracteriza porque cada una de las capas se apoya en los servicios ofrecidos en las capas inferiores. La capa 1 corresponde al núcleo de Android, que utiliza a su vez el núcleo Linux como una capa de integración para el hardware disponible en los dispositivos móviles. Esta capa contiene los drives necesarios para que los componentes de hardware puedan comunicarse. La capa intermedia proporciona las librerías que son escritas en C/C++, que proporcionan la mayor parte de sus características. Los últimos niveles corresponden al framework de aplicaciones que está escrito directamente en lenguaje Java y que representa fundamentalmente la herramienta para el desarrollo de aplicaciones en Android.24 ¿Qué hace que Android sea especial?

Plataforma realmente abierta. Es una plataforma de desarrollo libre basada en Linux y de código abierto. Una de sus grandes ventajas es que se puede usar y customizar el sistema sin pagar royalties.

Adaptable a cualquier tipo de hardware. Android no ha sido diseñado exclusivamente para su uso en teléfonos y tabletas. Hoy en día podemos

24 ACOSTA LÓPEZ, Alberto; MANZANO GONZÁLEZ, Dago José; MARTÍNEZ MORALES, Carlos A. Diseño e implementación de un prototipo para el registro y verificación de activos fijos utilizando plataforma android y tecnología NFC. Bogotá D.C.: Universidad Distrital Francisco José de Caldas. Facultad de ingeniería. 2014.

33

encontrar relojes, gafas, cámaras, TV, sistemas para automóviles, electrodomésticos y una gran variedad de sistemas empotrados que se basan en este sistema operativo, lo cual tiene sus evidentes ventajas, pero también va a suponer un esfuerzo adicional para el programador. La aplicación ha de funcionar correctamente en dispositivos con una gran variedad de tipos de entrada, pantalla, memoria, etc. Esta característica contrasta con la estrategia de Apple: en IOS tenemos que desarrollar una aplicación para iPhone y otra diferente para iPad.

Portabilidad asegurada. Las aplicaciones finales son desarrolladas en Java, lo que nos asegura que podrán ser ejecutadas en cualquier tipo de CPU, tanto presente como futuro. Esto se consigue gracias al concepto de máquina virtual.

Arquitectura basada en componentes inspirados en Internet. Por ejemplo, el diseño de la interfaz de usuario se hace en XML, lo que permite que una misma aplicación se ejecute en un reloj de pantalla reducida o en un televisor.

Filosofía de dispositivo siempre conectado a Internet. Muchas aplicaciones solo funcionan si disponemos de una conexión permanente a Internet. Por ejemplo, comunicaciones interpersonales o navegación con mapas.

Gran cantidad de servicios incorporados. Por ejemplo, localización basada tanto en GPS como en redes, bases de datos con SQL, reconocimiento y síntesis de voz, navegador, multimedia, etc.

Aceptable nivel de seguridad. Los programas se encuentran aislados unos de otros gracias al concepto de ejecución dentro de una caja, que hereda de Linux. Además, cada aplicación dispone de una serie de permisos que limitan su rango de actuación (servicios de localización, acceso a Internet, etc.). Desde la versión 6.0 el usuario puede conceder o retirar permisos a las aplicaciones en cualquier momento.

Optimizado para baja potencia y poca memoria. En el diseño de Android se ha tenido en cuenta el hardware específico de los dispositivos móviles. Por ejemplo, Android utiliza la máquina virtual ART (o Dalvik en versiones antiguas). Se trata de una implementación de Google de la máquina virtual Java optimizada para dispositivos móviles.

Alta calidad de gráficos y sonido. Gráficos vectoriales suavizados, animaciones, gráficos en 3D basados en OpenGL. Incorpora los codecs estándares más comunes de audio y video, incluyendo H.264 (AVC), MP3, AAC, etc.25

5.2.8.2 Retrofit Retrofit es un cliente REST para Android y Java creado por Square. Hace relativamente fácil el proceso de obtener un JSON (u otra estructura de datos) desde un WebService REST. Retrofit usa la librería OkHttp para realizar las peticiones HTTP. Suele configurarse con algún convertidor para la serialización de

25 TOMÁS, Jesús. El gran libro de Android. 5 ed. México: Alfaomega, 2016. 24 p.

34

datos. Generalmente cuando se obtienen JSON's se suele usar como convertidor la librería GSon, pero se pueden utilizar otros convertidores por ejemplo para XML.26

5.2.8.3 Gson Gson es una biblioteca de Java que se puede usar para convertir objetos de Java en su representación JSON. También puede ser usado para convertir una cadena JSON a su objeto Java equivalente. Gson puede funcionar con objetos Java arbitrarios, incluyendo objetos pre-existentes de los cuales no se tiene el código fuente. Existen unos pocos proyectos de código abierto que puedan convertir objetos Java a JSON. La mayoría no soportan el uso de las colecciones genéricas de Java. Gson considera esto como un objetivo esencial en su diseño.27

26 LAZA, Javier. Desarrollo de una aplicación Android para la localización proactiva de establecimientos. Madrid.: Universidad Politécnica de Madrid. Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. 2016. 13 p. 27 Chillarón, Diego Castaño. Desarrollo de una plataforma social para compartir imágenes en dispositivos Android. Madrid.: Universidad Politécnica de Madrid. Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. 2016. 26 p.

35

6. METODOLOGÍA SCRUM

La implementación de la metodología ágil se basa en las historias de usuario y los objetivos prioritarios del proyecto por esta razón se recurre a la técnica de análisis ágil Mapeo Visual de Historias. “La teoría del Visual Story Mapping comienza en un nivel “humano” identificando los Objetivos que toda persona persigue y dividiéndolos en Actividades para las cuales deben utilizarse Herramientas, resultando entonces en una jerarquía de Objetivos → Actividades → Herramientas.”28

6.1 PROCESO DE ANÁLISIS ÁGIL

6.1.1 Roles de usuarios.

Coordinador: uso intensivo del sistema con gran conocimiento de las actividades que realizan en los laboratorios. Su responsabilidad es de supervisar el correcto desarrollo de las actividades, definir el equipo de laboratoristas y delegar sus correspondientes funciones, y establecer la metodología de trabajo para la operación de los laboratorios.

Laboratorista: uso intensivo del sistema con gran conocimiento de las actividades que realizan en los laboratorios. Su responsabilidad es recibir y aprobar las solicitudes de préstamo, mantener en óptimas condiciones los laboratorios para su adecuado uso y verificar que la devolución de los recursos y equipos de los laboratorios se realice en buen estado.

Docente: uso periódico del sistema con nivel medio de conocimiento por las actividades que se realizan en los laboratorios. Su objetivo es la planeación de prácticas, solicitar a los laboratoristas los equipos necesarios para desarrollar las prácticas y ejecutarlas en los horarios programados.

Estudiante: uso infrecuente del sistema sin conocimiento por las actividades que realizan en los laboratorios. Está interesado en realizar la solicitud de préstamo para desarrollar las prácticas libres.

Entidad externa a la universidad: uso infrecuente del sistema sin conocimiento por las actividades que realizan en los laboratorios. Su interés es desarrollar prácticas realizando la solicitud por medio de una carta a la coordinación de la carrera.

28 ALAIMO, Diego Martín. Proyectos ágiles con Scrum: flexibilidad, aprendizaje, innovación y colaboración en contextos complejos. Ciudad Autónoma de Buenos Aires.: Kleer, 2013. 57 p. EBook.

36

6.1.2 Identificación de los procesos de negocio. A continuación se identifican los procesos de los laboratorios que el sistema debe ejecutar:

Administración de usuarios

Inventario y hoja de vida de los elementos materiales y equipos

Programación de prácticas

Control de uso de los equipos y elementos materiales

Gestión de solicitud de práctica y materiales

6.1.3 Identificación de funcionalidades del software.

Administración de usuarios o Gestionar proyecto curricular

Registrar proyecto curricular Inscribir las asignaturas por proyecto curricular

o Gestionar usuarios Elaborar perfiles de usuario Registrar usuarios autorizados Actualizar contraseña del usuario Modificar el estado de acceso del usuario Actualizar el perfil del usuario activo

o Notificar credenciales de acceso Enviar por correo al docente o estudiante las credenciales

Inventario y hoja de vida de los elementos materiales y equipos o Gestionar laboratorios

Establecer los laboratorios del proyecto curricular o Administrar entrada de almacén

Desarrollar listado maestro de proveedores Establecer ubicación de almacenamiento Crear entrada de almacén

o Gestionar inventario Elaborar ficha técnica del equipo

o Mantenimiento preventivo Programar horarios para control de calibraciones o

verificaciones Modificar estado de proceso del mantenimiento Notificar mantenimiento al coordinador y laboratorista

o Mantenimiento correctivo Registrar programación del mantenimiento Notificar mantenimiento al coordinador y laboratorista

Programación de prácticas o Construir horario de laboratorio

Elaborar programación de prácticas

37

o Visualizar horarios de laboratorios Ver listado de programación agrupado por semestre y

laboratorio

Control de uso de los equipos y elementos materiales o Visualizar prácticas de uso

Ver listado de las prácticas de uso por equipo o Actualizar estado de disponibilidad

Modificar estado de disponibilidad del equipo

Gestión de solicitud de práctica y materiales o Realizar solicitud de práctica

Elaborar ingreso de tipos de práctica Registrar prácticas guiadas Crear solicitud de práctica Notificar nueva solicitud de práctica a coordinador o

laboratorista Modificar estado de proceso de la práctica Notificar respuesta por solicitud de práctica a docente o

estudiante Ver listado de solicitudes de prácticas

o Realizar solicitud de materiales Obtener listado de solicitudes de prácticas aprobadas Crear solicitud de materiales Notificar nueva solicitud de materiales a coordinador o

laboratorista Modificar estado de proceso de la solicitud de materiales Ver listado de solicitudes de materiales

6.1.4 Identificación de MVP (producto mínimo viable) y posteriores entregas. Se plantea los objetivos y entregas priorizadas de acuerdo a las funcionalidades o actividades definidas anteriormente: Entrega 1 – Objetivo: Establecer parámetros generales del laboratorio

Administración de usuarios o Gestionar proyecto curricular

Registrar proyecto curricular Inscribir las asignaturas por proyecto curricular

Inventario y hoja de vida de los elementos materiales y equipos o Gestionar laboratorios

Establecer los laboratorios del proyecto curricular o Administrar entrada de almacén

Establecer ubicación de almacenamiento


Elaborar ingreso de tipos de práctica

38

Registrar prácticas guiadas

Entrega 2 – Objetivo: Administrar usuarios

Administración de usuarios o Gestionar usuarios

Elaborar perfiles de usuario Registrar usuarios autorizados Actualizar contraseña del usuario Modificar el estado de acceso del usuario Actualizar el perfil del usuario activo

o Notificar credenciales de acceso Enviar por correo al docente o estudiante las credenciales

Entrega 3 – Objetivo: Gestionar inventario

Inventario y hoja de vida de los elementos materiales y equipos o Administrar entrada de almacén

Desarrollar listado maestro de proveedores Crear entrada de almacén

o Hoja de vida de equipos Elaborar ficha técnica del equipo

o Mantenimiento preventivo Programar horarios para control de calibraciones o

verificaciones Modificar estado de proceso del mantenimiento preventivo Recordatorio de mantenimiento preventivo programado al

coordinador y laboratorista o Mantenimiento correctivo

Registrar programación de mantenimiento correctivo Recordatorio de mantenimiento correctivo al coordinador y

laboratorista

Entrega 4 – Objetivo: Controlar disponibilidad de equipos

Control de uso de los equipos y elementos materiales o Visualizar prácticas de uso

Ver listado de las prácticas de uso por equipo o Actualizar estado de disponibilidad

Modificar estado de disponibilidad del equipo

Entrega 5 – Objetivo: Gestionar solicitudes de préstamo

Programación de prácticas o Construir horario de laboratorio

Elaborar programación de prácticas o Visualizar horarios de laboratorios

39

Ver listado de programación agrupado por semestre y laboratorio


Crear solicitud de práctica Notificar nueva solicitud de práctica a coordinador o

laboratorista Modificar estado de proceso de la práctica Notificar respuesta por solicitud de práctica a docente o

estudiante Ver listado de solicitudes de prácticas

o Realizar solicitud de materiales Obtener listado de solicitudes de prácticas aprobadas Crear solicitud de materiales Notificar nueva solicitud de materiales a coordinador o

laboratorista Modificar estado de proceso de la solicitud de materiales Ver listado de solicitudes de materiales

6.1.5 Historias de usuario. “Hay métodos de desarrollo que no utilizan casos de uso, destacándose los user stories de XP y la mayor parte de los métodos ágiles. En realidad, una user story es un requisito expresado de manera simple y en términos del usuario, por esta razón podría ser muy similar a un caso de uso de poco detalle. Lo único que las diferencia de éstos es que no hay tanta formalidad en su descripción. Habitualmente, una user story se expresa con una oración en los siguientes términos: Como <rol> Quiero que el sistema haga <funcionalidad> Para obtener <beneficio esperado>”29

Entrega 1 - Establecer parámetros generales del laboratorio

Prio. Como… Necesito… Para… Criterios de Aceptación

1 Laboratorista Registrar los proyectos curriculares

Establecer la carrera a la que pertenecen los docentes y estudiantes.

-Realizar la creación y modificación de los proyectos curriculares. -Aceptar datos como: código,

29 FONTELA, Carlos. UML: modelado de software para profesionales. Buenos Aires.: Alfaomega Grupo Editor Argentino, 2011. 31 p.

40

nombre y descripción.

2 Laboratorista Inscribir las asignaturas por proyecto curricular

Asociar e identificar las materias que dicta un docente

-Permitir crear y modificar las asignaturas. -Debe contener código, nombre, descripción y proyectos curriculares donde se dicte la materia.

3 Laboratorista Establecer los laboratorios del proyecto curricular

Construir el horario de cada laboratorio y registrar los equipos y elementos de materiales que le corresponden.

-Se debe poder crear y modificar los laboratorios. -Debe contener nombre, descripción y asociar con un proyecto curricular.

4 Laboratorista Establecer ubicación de almacenamiento

Brindar la ubicación donde se almacenan los equipos o elementos materiales

-Crear, modificar y consultar las ubicaciones. -Los campos que debe tener son: nombre y descripción.

5 Laboratorista Elaborar ingreso de tipos de práctica

Exponer a docente o estudiante el tipo de práctica que puede desarrollar

-Crear, modificar y consultar los tipos de práctica. -Debe tener nombre y descripción.

6 Laboratorista Registrar prácticas guiadas

Exponer a docente o estudiante las prácticas documentadas por el proyecto curricular

-Crear, modificar y consultar las prácticas guiadas. -Debe tener nombre, descripción, tipo de práctica y carrera a la que pertenece.

Entrega 2 – Administrar usuarios

Prio.

Como… Necesito… Para… Criterios de Aceptación

41

7 Laboratorista

Elaborar perfiles de usuario

Restringir el acceso a los usuarios en algunas funciones del sistema

-Permitir crear, modificar y consultar los perfiles de usuario. -Debe contener nombre y descripción.

8 Laboratorista/Coordinador

Registrar usuarios autorizados

Brindar acceso al sistema a las personas autorizadas

-Crear, modificar y consultar usuarios. -Debe tener nombre completo, código, contraseña teléfono, celular, correo, perfil y proyecto curricular.

9 Laboratorista

Actualizar contraseña del usuario

Los usuarios que no recuerdan o pierden la información de sus credenciales

-Notificar al usuario por correo la actualización de su contraseña.

10 Laboratorista

Modificar el estado de acceso del usuario

Permitir o restringir acceso al sistema

-Los estados de acceso son: activo o inactivo. -Cuando un usuario se actualiza a inactivo se restringe el ingreso al sistema.

11 Laboratorista

Actualizar el perfil del usuario activo

Corregir cualquier error

-Al modificar el perfil cambia automáticamente los permisos dentro del sistema.

12 Laboratorista

Enviar por correo al docente o estudiante las credenciales

Que puedan ingresar al sistema.

-Se notifica al usuario por correo tan pronto se guarda la información.

Entrega 3 – Gestionar inventario


13 Laboratorista

Desarrollar listado maestro de proveedores

Consultar y guardarlos en la entrada de almacén que corresponda.

-Poder crear, modificar y consultar proveedores. - Debe tener nombre, servicio suministrado, importancia, dirección, teléfono, e-mail y estado actual.

42

-Ingresar criterios por los que fue seleccionado: fecha, resultado valor, resultado criterio y observaciones.

14 Laboratorista

Crear entrada de almacén

Documentar el proceso de recibir equipos nuevos al laboratorio

-Cuando llega un equipo nuevo al laboratorio de debe registrar el ingreso e indicar dónde queda almacenado. -En este proceso el equipo no está disponible para ser utilizado.

15 Laboratorista

Elaborar ficha técnica del equipo

Iniciar la hoja de vida del equipo

-A partir de los equipos registrados en las entradas de almacén se desarrolla la ficha técnica a cada uno. -Cuando se finaliza la creación de la ficha técnica el equipo queda disponible para ser utilizado.

16 Laboratorista

Programar horarios para control de calibraciones o verificaciones

Realizar mantenimiento preventivo a los equipos

-Crear, modificar y consultar mantenimiento preventivo. -Se debe tener fecha, equipo y control. -Compone la hoja de vida del equipo. -Cuando un equipo está en mantenimiento no puede estar disponible para su eso.

17 Laboratorista

Modificar estado de proceso del mantenimiento preventivo

Asegurar que se ha cumplido con el proceso.

-El estado del mantenimiento puede ser activo o finalizado.

18 Laboratorista

Recordar mantenimiento preventivo programado

Comunicar a los encargados de ejecutarlo

-Si se realiza el mantenimiento se debe guardar en la hoja de vida los siguientes

43

datos: fecha, nombre del equipo, falla, solución y repuestos.

19 Laboratorista

Registrar programación de mantenimiento correctivo

Equipos que presentan fallas o daños

-Permitir crear, modificar y consultar la programación del mantenimiento correctivo. -Se debe tener fecha, equipo y descripción.

20 Laboratorista

Recordar mantenimiento correctivo al coordinador y laboratorista


-Si se realiza el mantenimiento se debe guardar en la hoja de vida los siguientes datos: fecha, nombre del equipo, falla, solución y repuestos.

Entrega 4 – Controlar disponibilidad de equipos


21 Laboratorista

Visualizar prácticas de uso

Tener un reporte con la información de las veces que ha sido utilizado un equipo

-La consulta se realiza por equipo. -Recoger información de la solicitud de materiales.

22 Laboratorista

Actualizar estado de disponibilidad

Que el equipo pueda utilizarlo o no un docente o estudiante

-El estado puede ser disponible o no disponible. -El coordinador o laboratorista tienen la autoridad para brindar disponibilidad de un equipo.

Entrega 5 – Gestionar solicitudes de préstamo


23 Laboratorista

Elaborar programación de prácticas

Establecer cuáles son los horarios disponibles para realizar prácticas libres

-Crear, modificar y consultar la programación de prácticas. -Debe tener semestre, año, día, hora,

44

laboratorio, docente, asignatura y estado.

24 Laboratorista/Estudiante


Analizar los horarios disponibles para realizar prácticas libres

-Consulta automática del semestre y laboratorio con fechas actuales. -Revisar histórico de horarios programados de prácticas.

25 Estudiante/ Docente

Crear solicitud de práctica

Cumplir con trabajos asignados o trabajo autónomo

-Crear y consultar solicitud de práctica. -Debe tener consecutivo, usuario, tipo de práctica, práctica guiada, nombre de práctica, laboratorio, fecha de solicitud y observaciones.


Notificar nueva solicitud de práctica a coordinador o laboratorista

Que el laboratorista confirme la autorización o no para realizar la práctica

-Exponer notificación en el panel de control. -Cuando el estudiante realiza la solicitud de práctica se debe notificar de inmediato al laboratorista.

27 Laboratorista

Modificar estado de proceso de la práctica

Confirmar al estudiante que puede desarrollar o no la práctica

-El estado de la solicitud de práctica puede ser: aprobado o no aprobado.

28 Laboratorista

Notificar respuesta por solicitud de práctica a docente o estudiante

Si la solicitud de práctica es aprobada el estudiante o docente puede iniciar a realizar la solicitud de materiales

-Notificar al estudiante o docente en la aplicación web y móvil la decisión del laboratorista.

29 Laboratorista/Estudiante/Docente

Ver listado de solicitudes de prácticas

Revisar histórico y estado de las solicitudes

-El estudiante solo puede revisar el histórico de sus solicitudes. -El laboratorista puede observar el histórico de solicitudes de práctica

45

ya sea de estudiantes o docentes.


Obtener listado de solicitudes de prácticas aprobadas

Realizar solicitud de materiales

-Si la solicitud de práctica está aprobada se general enlace para realizar solicitud de materiales.


Crear solicitud de materiales

Desarrollar la práctica en el horario establecido

-Crear y consultar la solicitud de materiales. -Debe tener universidad, asignatura, usuarios, equipo y observaciones.


Notificar nueva solicitud de materiales a coordinador o laboratorista

Que verifique el estado de los equipos

-La notificación se expone en el panel de control de la aplicación web.

33 Laboratorista

Modificar estado de proceso de la solicitud de materiales

Finalizar la solicitud cuando se ha terminado la práctica

-Para finalizar una práctica el estudiante o docente debe devolver en buen estado los equipos prestados.

34 Laboratorista/Estudiante/Docente

Ver listado de solicitudes de materiales

Revisar el histórico de solicitudes y su respectivo estado

-El estudiante o docente solo puede revisar el histórico de sus solicitudes. -El laboratorista puede observar el histórico de solicitudes de práctica ya sea de estudiantes o docentes.

6.1.6 Plan de Entregas. A continuación se organizan las entregas por sprint y se brinda un valor estimado que es de 15 puntos máximo, cada sprint tiene una duración de 2 semanas:


Prio.

Como… Necesito… Para… Estim.

Sprint 1 – Velocidad: 15 puntos

1 Laboratorista Registrar los proyectos curriculares

Establecer la carrera a la que pertenecen los

2

46

docentes y estudiantes.

2 Laboratorista Inscribir las asignaturas por proyecto curricular

Asociar e identificar las materias que dicta un docente

3

3 Laboratorista Establecer los laboratorios del proyecto curricular

Construir el horario de cada laboratorio y registrar los equipos y elementos de materiales que le corresponden.

3

4 Laboratorista Establecer ubicación de almacenamiento

Brindar la ubicación donde se almacenan los equipos o elementos materiales

3

5 Laboratorista Elaborar ingreso de tipos de práctica

Exponer a docente o estudiante el tipo de práctica que puede desarrollar

2

6 Laboratorista Registrar prácticas guiadas

Exponer a docente o estudiante las prácticas documentadas por el proyecto curricular

2


Prio.



7 Laboratorista Elaborar perfiles de usuario

Restringir el acceso a los usuarios en algunas funciones del sistema

2

8 Laboratorista/Coordinador

Registrar usuarios autorizados

Brindar acceso al sistema a las personas autorizadas

4

9 Laboratorista Actualizar contraseña del usuario

Los usuarios que no recuerdan o pierden la información de sus credenciales

2

10 Laboratorista Modificar el estado de acceso del usuario

Permitir o restringir acceso al sistema

2

11 Laboratorista Actualizar el perfil del usuario activo

Corregir cualquier error

2

47

12 Laboratorista Enviar por correo al docente o estudiante las credenciales

Que puedan ingresar al sistema.

3


Prio.



13 Laboratorista Desarrollar listado maestro de proveedores

Consultar y guardarlos en la entrada de almacén que corresponda.

6

14 Laboratorista Crear entrada de almacén Documentar el proceso de recibir equipos nuevos al laboratorio

9


15 Laboratorista Elaborar ficha técnica del equipo

Iniciar la hoja de vida del equipo

8

16 Laboratorista Programar horarios para control de calibraciones o verificaciones

Realizar mantenimiento preventivo a los equipos

7


17 Laboratorista Modificar estado de proceso del mantenimiento preventivo

Asegurar que se ha cumplido con el proceso.

5

18 Laboratorista Recordar mantenimiento preventivo programado


3

19 Laboratorista Registrar programación de mantenimiento correctivo

Equipos que presentan fallas o daños

5

20 Laboratorista Recordar mantenimiento correctivo al coordinador y laboratorista


2


Prio. Como… Necesito… Para… Estim.


21 Laboratorista Visualizar prácticas de uso

Tener un reporte con la información de las veces que ha sido utilizado un equipo

8

48

22 Laboratorista Actualizar estado de disponibilidad

Que el equipo pueda utilizarlo o no un docente o estudiante

7


Prio. Como… Necesito… Para… Estim.


23 Laboratorista Elaborar programación de prácticas

Establecer cuáles son los horarios disponibles para realizar prácticas libres

10

24 Laboratorista/Estudiante


Analizar los horarios disponibles para realizar prácticas libres

5



Crear solicitud de práctica Cumplir con trabajos asignados o trabajo autónomo

8


Notificar nueva solicitud de práctica a coordinador o laboratorista

Que el laboratorista confirme la autorización o no para realizar la práctica

4

27 Laboratorista Modificar estado de proceso de la práctica

Confirmar al estudiante que puede desarrollar o no la práctica

3


28 Laboratorista Notificar respuesta por solicitud de práctica a docente o estudiante

Si la solicitud de práctica es aprobada el estudiante o docente puede iniciar a realizar la solicitud de materiales

8

29 Laboratorista/Estudiante/ Docente

Ver listado de solicitudes de prácticas

Revisar histórico y estado de las solicitudes

4


Obtener listado de solicitudes de prácticas aprobadas

Realizar solicitud de materiales

3



Crear solicitud de materiales

Desarrollar la práctica en el horario establecido

8

49


Notificar nueva solicitud de materiales a coordinador o laboratorista

Que verifique el estado de los equipos

4

33 Laboratorista Modificar estado de proceso de la solicitud de materiales

Finalizar la solicitud cuando se ha terminado la práctica

2

34 Laboratorista/Estudiante/ Docente

Ver listado de solicitudes de materiales

Revisar el histórico de solicitudes y su respectivo estado

1

6.1.7 Duración del proyecto. A partir del tiempo establecido en el plan de entregas se calcula que la duración total es: 10 Sprints = 20 semanas = 4 meses aproximadamente.

Etapa Duración Desde Hasta

Incepción 2 semanas 14-Mar-2017 26-Mar-2017


Sprint 1 2 semanas 27-Mar-2017 08-Abr-2017


Sprint 2 2 semanas 10-Abr-2017 23-Abr-2017


Sprint 3 2 semanas 25-Abr-2016 06-May-2017

Sprint 4 2 semanas 08-May-2017 20-May-2017

Sprint 5 2 semanas 23-May-2017 04-Jun-2017


Sprint 6 2 semanas 06-Jun-2017 17-Jun-2017


Sprint 7 2 semanas 20-Jun-2017 01-Jul-2017

Sprint 8 2 semanas 03-Jul-2017 15-Jul-2017

Sprint 9 2 semanas 18-Jul-2017 30-Jul-2017

Sprint 10 2 semanas 01-Ago-2017 11-Ago-2017

6.1.8 Costo del proyecto.

Recursos Concepto Costo

Hardware 1 Computador HP, disco duro 700 GB, procesador Intel core i7-

$2.700.000

50

3630QM de 2.40GHz y RAM 6 GB

1 Computador marca ASUS, disco duro 1 TB, procesador Intel core i7-4710HQ de 2.50GHz y RAM 8 GB

$2.500.000

Software

Android $ 0

NodeJS $ 0

MongoDB $ 0

MySql $ 0

Firebase $ 0

JavaScript $ 0

Humano Desarrolladores (2) $ 0

Otros

Fotocopias, impresiones, papelería, bibliografía, medios de transporte

$300.000

Fondo de Contingencia (10 %) $550.000

Total del Proyecto $6.050.000

51

7. DISEÑO E IMPLEMENTACIÓN

7.1 REQUERIMIENTOS NO FUNCIONALES

Clase de requerimiento Nombre Descripción

Portabilidad Ejecución del software

La aplicación web se debe ejecutar en cualquier navegador, mientras la aplicación móvil se debe instalar en aparatos con sistema operativo Android versión igual o mayor a 5.1

Rendimiento Optimización del tiempo de respuesta

Después de la ejecución de una acción o actividad el tiempo de respuesta debe ser aceptable, se pone un límite máximo de 5s por respuesta.

Seguridad Autenticación de usuario

Los usuarios se deben agrupar por perfiles, estos deben limitar el acceso en algunas funciones del sistema.

Usabilidad Diseño de interfaz gráfica

Se debe diseñar una interfaz gráfica en las aplicaciones web y móvil que sea de fácil intuición para el usuario, cada proceso debe tener una identificación clara y resaltar las respuestas de validación.

Fiabilidad Garantizar integridad de la información

El sistema debe garantizar que la información ingresada esta validada y permite la correcta ejecución de los procesos como la salida confiable de resultados.

52

7.2 DICCIONARIO DE DATOS

Se utiliza la base de datos no relacional MongoDB por esta razón se describe las colecciones y la estructura de los documentos que componen a cada una:

Nombre colección: users

Descripción: Almacena los datos de los usuarios (coordinador, laboratoristas, docentes y estudiantes)

Campo Tipo de dato Descripción

username String Código del usuario

password String Contraseña del usuario

name String Nombres del usuario

lastname String Apellidos del usuario

full_names String Nombre completo del usuario

phone String Número de teléfono fijo del usuario

mobile String Número de teléfono móvil del usuario

email String Correo electrónico del usuario

creator: ObjectId

Identificador del usuario que crea o modifica el registro

status: ObjectId Identificador del estado del usuario

profile: ObjectId Identificador del perfil del usuario

career: ObjectId

Identificador del proyecto curricular a que pertenece el usuario

created: Date Fecha de creación del usuario

updated: Date

Fecha de última actualización del usuario

Tabla 1. Colección users

Nombre colección: profiles

Descripción: Almacena los datos de perfiles, un usuario debe tener un perfil


name String Nombre del perfil

description String Descripción del perfil

routes [{route: ObjectId, _id: boolean}]

Arreglo que contiene la identificación de las rutas a las que tiene acceso el perfil

creator ObjectId Identificador del usuario que crea o modifica el perfil

status ObjectId Identificador del estado del perfil

created Date Fecha de creación del perfil

updated Date Fecha de última actualización del perfil Tabla 2. Colección profiles

53

Nombre colección: metrics

Descripción: Almacena la información de proyectos curriculares, laboratorios, tipos de práctica, prácticas guiadas y ubicaciones de almacenamiento


name String Nombre de la métrica

type String Nombre del tipo de métrica

code Number Código asignado a la métrica

description String Descripción de la métrica

metric_rel

{career: ObjectId, practical_type: ObjectId}

Arreglo que contiene el identificador del proyecto curricular y el identificador del tipo de práctica.

Tabla 3. Colección metrics

Nombre colección: teachers

Descripción: Almacena información adicional para los usuarios que tienen el perfil de profesores


user_id ObjectId Identificador del docente

career_id ObjectId Identificador del proyecto curricular

subject_id ObjectId Identificador de las asignaturas

date_admission Date Fecha de admisión

semester_admission ObjectId Identificador del semestre de admisión

status ObjectId Identificador del estado de los docentes

update Date Fecha de la última actualización de los datos

Tabla 4. Colección teachers

Nombre colección: subjects

Descripción: Almacena los datos de las materias y asocia con los proyectos curriculares


code Number Código de la materia

name String Nombre de la materia

description String Descripción de la materia

career_id [{ ObjectId }] Arreglo que contiene los identificadores de los proyectos curriculares

status ObjectId Identificador de estado

updated Date Fecha de última actualización de los datos

Tabla 5. Colección subjects

54

Nombre colección: providers

Descripción: Guarda la información correspondiente a los proveedores


name String Nombre del proveedor

supply String Bien o servicio suministrado por el proveedor

importance String Importancia (crítico o no crítico del proveedor)

city String Ciudad que está ubicado el proveedor

address String Dirección del proveedor

phone { mobile: String, fixed: String }

Número de teléfonos fijo y móvil del proveedor

email String Correo electrónico del proveedor

status String Estado actual del proveedor

selection

{ date: Date, value_r: String, criterion_r: String, observation: String}

Resultados de selección del proveedor

Tabla 6. Colección providers

Nombre colección: entries

Descripción: Guarda la información referente a las entradas de almacén


invoice String Número de la factura que entrega el proveedor

date Date Fecha de entrada al almacén

date_registry Date Fecha y hora actual que se realiza el presente formulario

Username ObjectId Identificador del usuario coordinador o laboratorista que recibe

per_delivery String Nombre de quien entrega el material

entry String Entrada

contract String Tipo de contrato con el proveedor

provider_id ObjectId Identificador del proveedor

description

[{ group: String, unity: Number, quantity: Number, description:

Arreglo que contiene la descripción de la entrada de almacén (grupo, unidad, cantidad, descripción del equipo y ubicaci)

55

String, location: ObjectId }]

Tabla 7. Colección entries

Nombre colección: stocks

Descripción: Almacena los datos de la ficha técnica de los equipos


entry_id ObjectId Identificador de la entrada de almacén

entry_val ObjectId Identificador de la descripción de equipos en la entrada de almacén

code String Código del equipo

succession String Serie del equipo

trademark String Marca del equipo

equipment String Nombre del equipo

model String Modelo del equipo

state String Estado de adquisición del equipo

laboratory_id ObjectId Identificador del laboratorio donde se utilizara el equipo

location_id ObjectId Identificador de la ubicación donde se almacena el equipo

characteristics

{ power: String, voltaje: String, kw: String, amperaje: String }

Características detalladas del equipo

description String Descripción del equipo

photo String Foto del equipo

handbook String Manual del equipo

observations String Observaciones del equipo

status ObjectId Estado de disponibilidad del equipo Tabla 8. Colección stocks

Nombre colección: maintenances

Descripción: Almacena información referente a los mantenimientos preventivos y correctivos


stocks_id ObjectId Identificador del equipo o material que está en el inventario

type ObjectId Tipo de mantenimiento

controls_id ObjectId Identificador del mantenimiento preventivo programado

date Date Fecha de ejecución del mantenimiento

fault String Avería que presenta el equipo

56

solution String Solución ejecutada en el mantenimiento

spare_parts String Repuestos utilizados en el mantenimiento

user_id ObjectId Identificador del laboratorista que realizo el mantenimiento

status ObjectId Estado de ejecución del mantenimiento

Tabla 9. Colección maintenances

Nombre colección: controls

Descripción: Guarda los datos sobre la programación de horarios de los mantenimientos preventivos


stocks_id ObjectId Identificador del equipo que está en el inventario

check_id ObjectId Identificador del control

date_schedules Date Fecha programada del mantenimiento preventivo

user_id ObjectId Identificador del laboratorista que realiza la programación

status ObjectId Estado de ejecución del mantenimiento preventivo

update Date Fecha de última actualización Tabla 10. Colección controls

Nombre colección: schedules

Descripción: Almacena los datos de los horarios de los laboratorios


semester ObjectId Identificador del semestre del horario de laboratorio

year String Año del horario de laboratorio

date Date Fecha que se realiza el horario de laboratorio

day ObjectId Identificador del día que se utiliza algún laboratorio

hour ObjectId Hora que se utiliza algún laboratorio

laboratory_id ObjectId Identificador del laboratorio

career ObjectId Identificador del proyecto curricular

teacher ObjectId Identificador del docente

subject ObjectId Identificador de la materia

creator ObjectId Identificador del usuario que registra la programación

comment String Comentarios de la clase programada

57

status ObjectId Estado del horario de laboratorio

created Date Fecha de creación del registro

updated Date Fecha de última actualización Tabla 11. Colección schedules

Nombre colección: requests

Descripción: Guarda información referente a las solicitudes de práctica


consecutive Number Consecutivo de la solicitud de práctica

user_id ObjectId Identificador del usuario o docente que realiza la solicitud de práctica

date_created Date Fecha de creación del registro

year String Año de creación del registro

semester ObjectId Identificador del semestre

day ObjectId Identificador del día que se programa la solicitud de práctica

hour ObjectId Identificador del bloque de hora que se programa la solicitud de práctica

practice_type ObjectId Identificador del tipo de práctica

practice_guided ObjectId Identificador de la práctica guiada

practice_name String Nombre de la práctica

laboratory_id ObjectId Identificar del laboratorio donde se va realizar la práctica

date_request Date Fecha de creación de la solicitud de práctica

observations String Observaciones de la solicitud de práctica

user_receives ObjectId Identificador del laboratorista que recibe la solicitud de práctica

state ObjectId Estado de ejecución de la solicitud Tabla 12. Colección requests

Nombre colección: practices

Descripción: Almacena los datos referentes a las solicitudes de materiales


requests_id ObjectId Identificador de la solicitud de práctica asociada

university String Nombre de la universidad

subject_id ObjectId Identificador de la materia

users ObjectId Identificador de los usuarios para la solicitud de material

58

equipment

[{ stocks_id: ObjectId, delivery: ObjectId, receives: ObjectId }]

Materiales, equipos e insumos. (Identificador del equipo que está en el inventario, identificador del usuario que recibe los materiales e identificador del laboratorista que entrega los materiales)

observation String Observaciones de la solicitud de material

status ObjectId Estado de ejecución de la solicitud de material

update Date Fecha de última actualización Tabla 13. Colección practices

7.3 DIAGRAMA DE CLASES

59

7.4 SERVICIOS DEL API REST

A continuación, se describe la función de cada uno de los métodos que componen el servicio web desarrollado para el prototipo. Se establece, el método de petición, la url con los parámetros para ejecutar correctamente el método del servicio y se describe la operación para la cual fue creada.

URL API http://18.221.4.46:3131/api

TOKEN JWT - RFC 7519

RESPONSE JSON format

USUARIOS

GET users/

Servicio que obtiene un listado de usuarios del sistema.

GET users/:username

Servicio para obtener un usuario especificado por el parámetro username.

username string Identifica un usuario dentro del sistema.

GET users/profile/:profile_id

Servicio para obtener un listado de usuarios por perfil.

profile_id string Identifica un perfil dentro del sistema.

POST users/

Servicio para obtener un listado de usuarios por perfil.

{

"username": string,

"password": string,

"name": string,

"lastname": string,

"phone": string,

"mobile": string,

"email": string,

"profile": string,

"status": string,

"creator": string,

"career": string

60

}

POST users/signin

Servicio para autenticarse dentro del sistema.

{

"Username": string,

"password": string

}

POST users/forgot

Servicio para recuperar la contraseña mediante el envío de un e-mail.

{

"username": string

}

PUT users/:username

Servicio para actualizar los datos de un usuario.


{

"username": string,

"password": string,

"name": string,

"lastname": string,

"phone": string,

"mobile": string,

"email": string,

"profile": string,

"status": string,

"creator": string,

"career": string

}

DELETE users/:username

Servicio para eliminar un usuario del sistema.


PERFILES

61

GET profiles/

Servicio para obtener un listado de perfiles.

GET profiles/profiles

Servicio para obtener un listado de perfiles en tipo lista para usarse en componentes select HTML5.

GET profiles/:name

Servicio para obtener el perfil mediante parámetro name.

name string Campo único para identificar un perfil dentro del sistema.

POST profiles/

Servicio para obtener el perfil mediante parámetro name.

{

"creator" : string,

"description" : string,

"name" : string,

"status" : string,

"routes" : [

string,

string,

]

}

PUT profiles/:name

Servicio para actualizar los datos de un perfil.


{

"creator" : string,

"description" : string,

"name" : string,

"status" : string,

"routes" : [

string,

string,

]

}

62

DELETE profiles/:name

Servicio para eliminar un perfil del sistema.


RUTAS/ROLES

GET routes/

Servicio para obtener una lista de rutas.

GET routes/:route_id

Servicio para obtener una ruta por identificador.

route_id string Campo único para identificar una ruta dentro del sistema.

POST routes/

Servicio para crear una nueva ruta.

{

"url": string,

"description": string,

"creator": string

}

PUT routes/:route_id

Servicio para actualizar una ruta por identificador.


{

"url": string,


"creator": string

}

DELETE routes/:route_id

Servicio para eliminar una ruta por identificador.


CONSTANTES

63

GET constants/

Servicio para obtener una lista de constantes.

GET constants/children/:father

Servicio para obtener una lista de constantes hijas mediante la constante padre.

father string Campo único para identificar una constante padre dentro del sistema.

GET constants/fathers

Servicio para obtener una lista de las constantes padres activas.

GET constants/father/blocks

Servicio para obtener un listado de los bloques de horas.

GET constants/:name

Servicio para obtener una constante por su nombre.

name string Campo único para identificar una constante por su nombre dentro del sistema.

POST constants/

Servicio para crear una nueva constante.

{

"name": string,

"value": string,

"label": string,

"father": string,

"status": string,

"creator": string

}

PUT constants/:name

Servicio para actualizar los datos de una constante.


{

"name": string,

"value": string,

64

"label": string,

"father": string,

"status": string,

"creator": string

}

DELETE constants/:name

Servicio para eliminar una constante.


MÉTRICAS

GET metrics/id/:id

Servicio para obtener una métrica por su identificador.

id string Campo único para identificar una métrica dentro del sistema.

GET metrics/:type

Servicio para obtener un listado de métricas filtradas por el tipo al que pertenecen.

type string Campo para identificar el tipo de métrica dentro del sistema.

POST metrics/

Servicio para crear una nueva métrica.

{

"name": string,

"code": number,

"type": string,


"career": string,

"practical_type": string

}

PUT metrics/id/:id

Servicio para actualizar una métrica.

{

"name": string,

65

"code": number,

"type": string,


"career": string,

"practical_type": string

}

DELETE metrics/id/:id

Servicio para eliminar una métrica.

id string Campo único para identificar una métrica dentro del sistema.

PROVEEDORES

GET providers/

Servicio para obtener un listado de proveedores.

GET providers/id/:id

Servicio para obtener un proveedor por su identificador.

id string Campo único para identificar un proveedor dentro del sistema.

POST providers/

Servicio para crear un nuevo proveedor.

{

"name": string,

"supply": string,

"importance": string,

"city": string,

"address": string,

"mobile": string,

"fixed": string,

"email": string,

"status": string,

"date": string,

"value_r": string,

"criterion_r": string,

"observation": string

66

}

PUT providers/id/:id

Servicio para actualizar los datos de un proveedor.


{

"name": string,

"supply": string,

"importance": string,

"city": string,

"address": string,

"mobile": string,

"fixed": string,

"email": string,

"status": string,

"date": string,

"value_r": string,

"criterion_r": string,

"observation": string

}

DELETE providers/id/:id

Servicio para eliminar un proveedor del sistema.


HORARIOS

GET schedules/

Servicio para obtener una lista de horarios con programación física.

GET schedules/:schedule_id

Servicio para obtener un horario por identificador.

schedule_id

string Campo único para identificar la programación de un horario dentro del sistema.

POST schedules/

67

Servicio para crear un nuevo horario.

{

"semester": string,

"year": string,

"fixed": number,

"date": date,

"day": string,

"hour": string,

"location": string,

"career": string,

"subject": string,

"creator": string,

"comment": string

}

PUT schedules/:schedule_id

Servicio para actualizar un horario por identificador.

schedule_id


{

"semester": string,

"year": string,

"fixed": number,

"date": date,

"day": string,

"hour": string,

"location": string,

"career": string,

"subject": string,

"creator": string,

"comment": string

}

DELETE schedules/:schedule_id

Servicio para eliminar un horario por identificador.

schedule_id


MATERIAS

68

GET subjects/

Servicio para obtener un listado de materias.

GET subjects/id/:id

Servicio para obtener una materia por su identificador.

id string Campo único para identificar una materia dentro del sistema.

POST subjects/

Servicio para crear una nueva materia.

{

"code": number,

"name": string,


"career": []

}

PUT subjects/id/:id

Servicio para actualizar los datos de una materia.


{

"code": number,

"name": string,


"career_id": []

}

DELETE subjects/id/:id

Servicio para eliminar una materia.


MANTENIMIENTOS PREVENTIVOS

GET /controls

Servicio para obtener todos los mantenimientos preventivos programados.

69

GET /controls/status

Servicio para obtener el listado de mantenimientos preventivos que se encuentran con estado activo.

POST /controls

Servicio para crear un nuevo mantenimiento preventivo sobre los recursos registrados en el inventario.

{ "stocks_id": string, "check_id": string, "date_schedules": string, "user_id": string }

PUT /controls/id/:id

Servicio para actualizar los datos de un mantenimiento preventivo.

id string Campo único para identificar un mantenimiento preventivo dentro del sistema.

{ "stocks_id": string, "check_id": string, "date_schedules": string, "user_id": string }

PUT /controls/status/id/:id

Servicio para actualizar el estado de un mantenimiento preventivo programado. Los estados pueden ser los siguientes: activo, inactivo o ejecutado.

id string Campo único para identificar un mantenimiento preventivo dentro del sistema.

{ "status": string }

ENTRADAS DE ALMACÉN

GET /entries

Servicio para obtener el listado de todas las entradas de almacén.

70

GET /entries/id/:id

Servicio para obtener una entrada de almacén por su identificador.

id string Campo único para identificar una entrada de almacén dentro del sistema.

POST /entries

Servicio para crear una nueva entrada de almacén.

{ "invoice": string, "date": string, "username": string, "per_delivery": string, "entry": string, "contract": string, "provider_id": string, "description": [ { "group": number, "unity": number, "quantity": number, "description": string, "location_id": string } ] }

PUT /entries/id/:id

Servicio para actualizar los datos de una entrada de almacén.


{ "invoice": string, "date": string, "username": string, "per_delivery": string, "entry": string, "contract": string, "provider_id": string, "description": [ { "group": number, "unity": number,

71

"quantity": number, "description": string, "location_id": string } ] }

DELETE /entries/id/:id

Servicio para eliminar los datos de una entrada de almacén.


MANTENIMIENTOS

GET /maintenances

Servicio para obtener el listado de todos los mantenimientos ejecutados.

GET /maintenances/type/:type

Servicio para obtener un listado de mantenimientos filtrados por el tipo a que pertenecen. Los tipos pueden ser correctivos o preventivos.

type string Campo para identificar el tipo de mantenimiento dentro del sistema.

GET /maintenances/status/all

Servicio para obtener el listado de mantenimientos filtrados por el estado activo.

POST /maintenances

Servicio para crear un nuevo mantenimiento.

{ "stocks_id": string, "controls_id": string, "type": string, "date": string, "fault": string, "solution": string, "spare_parts": string, "user_id": string }

PUT /maintenances/id/:id

72

Servicio para actualizar los datos de un mantenimiento.

id string Campo único para identificar un mantenimiento dentro del sistema.


PUT /maintenances/status/id/:id

Servicio para actualizar el estado de un mantenimiento.

id string Campo único para identificar un mantenimiento dentro del sistema.


SOLICITUDES DE MATERIAL

GET /practices/users

Servicio para obtener el listado de usuarios con perfiles de estudiantes y profesores que pertenecen a la misma carrera del usuario que tiene abierta la sesión.

GET /practices/reqprac/all

Servicio para obtener el listado de solicitudes de práctica en estado finalizado con su correspondiente solicitud de material filtrado por identificador del usuario.

GET /practices/stock/:requestId

73

Servicio para obtener un listado de recursos del inventario filtrado por laboratorio y el estado sea disponible.

requestId string Campo único para identificar una solicitud de préstamo dentro del sistema.

GET practices/request/admin/:year/:semesterId/:laboratoryId

Servicio para obtener el listado de solicitudes de práctica aprobadas filtrado por año, semestre, laboratorio y estado.

year number Campo para identificar un año dentro del sistema.

semesterId string Campo único para identificar un semestre dentro del sistema.

laboratoryId

string Campo único para identificar un laboratorio dentro del sistema.

GET /practices/request/user/:year/:semesterId

Servicio para obtener el listado de solicitudes de práctica aprobadas que no tienen relación con una solicitud de material filtrado por identificador del usuario, año y semestre.


semesterId string Campo único para identificar un semestre dentro del sistema.

GET /practices/reqprac/:year/:semester

Servicio para obtener el listado de solicitudes de práctica en estado finalizado con su correspondiente solicitud de material filtrado por año, semestre y estado.


semester string Campo único para identificar un semestre dentro del sistema.

GET practices/reqpracuser/:year/:semester

Servicio para obtener el listado de solicitudes de práctica en estado finalizado con su correspondiente solicitud de material filtrado por identificador del usuario, año, semestre y estado.



POST practices/:requestId

Servicio para crear una nueva entrada de almacén.

74


{ "university": string, "subject_id": string, "users": [ string ], "equipment": [ string, string ], "observation": string, "status": string }

PUT /practices/id/:id/:status

Servicio para actualizar los datos de una solicitud de material filtrado por su identificador. Condiciones: 1. Cuando la solicitud está en el estado "en espera" se puede actualizar los siguientes campos: "university", "subject_id", "observation", "users". 2. Cuando la solicitud esta en el estado "en proceso" se puede actualizar el siguiente campo: "observation".

id string Campo único para identificar una práctica dentro del sistema.

status string Campo único para identificar un estado del registro dentro del sistema.


75

PUT /practices/status/id/:id

Servicio para actualizar el estado de una solicitud de material.

id string Campo único para identificar una práctica dentro del sistema.


SOLICITUDES DE PRÁCTICA

GET /requests/all/present

Servicio para obtener el listado de solicitudes de práctica filtrado por la fecha actual y el estado: en espera.

GET /requests/semester/:semester/:year

Servicio para obtener el listado de solicitudes de práctica filtrados por año y semestre.



GET /requests/days/:date/:laboratory_id

Servicio para obtener el listado de bloques de hora disponibles que pueden relacionarse en una solcitud de práctica filtrado por fecha y laboratorio.

date number Campo para identificar un bloque de hora dentro del sistema.

laboratory_id


GET requests/date/:date/:laboratoryId

76

Servicio para obtener un listado de solicitudes de práctica filtrados por fecha y laboratorio.

date number Campo para identificar una fecha dentro del sistema.

laboratory_id


GET /requests/user/:laboratoryId

Servicio para obtener un listado de solicitudes de práctica filtrado por laboratorio, fecha actual, identificador del usuario y estado aprobado.

laboratoryId


GET requests/consecutive/:consecutiveCod

Servicio para obtener los datos de una solicitud de práctica por su consecutivo.

consecutiveCod

number Campo para identificar un consecutivo de solicitud dentro del sistema.

GET /requests/user/all/:laboratoryId

Servicio para obtener el listado de todas las solicitudes de práctica filtrado por identificador de usuario y los estados: "en espera" o "no aprobado".

laboratoryId


POST /requests

Servicio para crear una nueva solicitud de práctica.

{ "practice_type": string, "practice_guided": string, "practice_name": string, "laboratory_id": string, "date_request": string, "hour": string, "observations": string, "user_receives": string }

PUT /requests/requestId/:requestId

Servicio para actualizar el estado de una solicitud de práctica.


77

{ "practice_type": string, "practice_guided": string, "practice_name": string, "laboratory_id": string, "date_request": string, "hour": string, "observations": string, "user_receives": string }

INVENTARIO

GET /stocks

Servicio para obtener el listado de todas las fichas técnicas.

GET /stocks/entries/available

Servicio para obtener las entradas de almacén que tienen recursos, productos o herramientas que aún no se han registrado en el inventario. Cuando una entrada de almacén tiene todos sus recursos registrados en el inventario no se puede retornar para evitar relaciones incorrectas.

GET stocks/id/:id

Servicio para obtener los datos de una ficha técnica por su identificador.

id number Campo para identificar un inventario dentro del sistema.

GET /stocks/entries/stock/:id

A partir del listado de entradas que aún tienen recursos que hacen falta por registrar en el inventario, se debe permitir al usuario elegir una de esas entradas, de esta manera el presente servicio retorna los recursos y las cantidades que aún se pueden registrar en el inventario. La cantidad que retorna es la que hace falta por registrar, es decir es el número de intentos que todavía puede registrar. Si el valor es cero quiere decir que la cantidad del recurso que se encuentra en la entrada coincide con el número de registros del inventario por lo tanto ya no se debe permitir realizar más registros al inventario.


POST /stocks

Servicio para crear una nueva ficha técnica.

78

{ "entry_id": string, "code": string, "succession": string, "trademark": string, "equipment": string, "model": string, "state": string, "laboratory_id": string, "location_id": string, "power": string, "voltage": string, "kw": string, "amperage": string, "description": string, "photo": string, "handbook": string, "observations": string, "status": string }

PUT /stocks/id/:id

Servicio para actualizar los datos de una ficha técnica.


{ "entry_id": string, "code": string, "succession": string, "trademark": string, "equipment": string, "model": string, "state": string, "laboratory_id": string, "location_id": string, "power": string, "voltage": string, "kw": string, "amperage": string, "description": string, "photo": string, "handbook": string, "observations": string,

79

"status": string }

PUT /stocks/status/:id

Servicio para actualizar el estado de una ficha técnica.

id string Campo para identificar un inventario dentro del sistema.

{ "entry_id": string, "code": string, "succession": string, "trademark": string, "equipment": string, "model": string, "state": string, "laboratory_id": string, "location_id": string, "power": string, "voltage": string, "kw": string, "amperage": string, "description": string, "photo": string, "handbook": string, "observations": string, "status": string }

DELETE /stocks/id/:id

Servicio para actualizar el estado de una ficha técnica por no disponible.

id string Campo para identificar un inventario dentro del sistema.

80

8. PRUEBAS DEL SERVICIO WEB

Para el desarrollo de las pruebas del servicio web se hizo uso de la herramienta postman, este software es una extensión de google chrome, que sirve para validar el comportamiento de los métodos del api mediante la elaboración de pruebas. Las siguientes pruebas están estructuradas como se describe a continuación: - Servicio: este campo describe la url que apunta a un método. Los métodos del presente prototipo se encuentran descritos en la sección servicios del api rest. - La parte de test se divide en tres partes. La primera expone el método del protocolo http. La segunda describe la url con datos reales que se encuentran persistidos en la base de datos. Por último, se programa la prueba unitaria que valida la respuesta del método requerido. - Los resultados muestran si las pruebas unitarias programadas fueron exitosas o no con respecto a la respuesta que retorna el servicio. Es importante, tener en cuenta el código de estado, el cual es un valor que indica si la respuesta es correcta, si es informativa o presenta errores en el lado del cliente o del servidor.

Servicio http://18.221.4.46:3131/api/requests

Tests Método de petición POST

http://18.221.4.46:3131/api/requests

tests["Tiempo de respuesta es menor o igual a 1000ms"] = responseTime < 1000; tests["Código de estado 200"] = responseCode.code === 200; var jsonData = JSON.parse(responseBody); tests["Respuesta satisfactoria"] = jsonData.success === true; tests["data contiene registros"] = Object.keys(jsonData.data).length > 0;

Resultados

PASS Tiempo de respuesta es menor o igual a 1000ms PASS Código de estado 200 PASS Respuesta satisfactoria PASS data contiene registros

Tabla 14. Prueba para crear solicitud de práctica

Servicio http://18.221.4.46:3131/api/requests/semester/:semester/:year

Tests Método de petición GET




81

http://18.221.4.46:3131/api/requests/semester/594584c31fad253a347a9de1/2017

tests["Tiempo de respuesta es menor o igual a 1000ms"] = responseTime < 1000; tests["Código de estado 200"] = responseCode.code === 200; var jsonData = JSON.parse(responseBody); tests["Respuesta satisfactoria"] = jsonData.success === true; tests["data es un arreglo"] = Array.isArray(jsonData.data); tests["data contiene registros"] = jsonData.data.length > 0;

Resultados

PASS Tiempo de respuesta es menor o igual a 1000ms PASS Código de estado 200 PASS Respuesta satisfactoria PASS data es un arreglo PASS data contiene registros

Tabla 15. Prueba para consultar solicitudes de práctica filtrada por semestre y año

Servicio http://18.221.4.46:3131/api/requests/days/:date/:laboratory_id


http://18.221.4.46:3131/api/requests/days/2017-07-11/5932cf5642fbb621ecc35ee2


Resultados


Tabla 16. Prueba para consultar solicitud de práctica por día filtrada por fecha y laboratorio

Servicio http://18.221.4.46:3131/api/requests/requestId/:requestId

Tests Método de petición PUT





82

http://18.221.4.46:3131/api/requests/requestid/5957c7423780bd1a601a1cd2


Resultados


Tabla 17. Prueba para actualizar datos de solicitud de práctica

Servicio http://18.221.4.46:3131/api/requests/date/:date/:laboratoryId


http://18.221.4.46:3131/api/requests/date/2017-07-09/5932cf5642fbb621ecc35ee2


Resultados


Tabla 18. Prueba para consultar solicitudes de práctica por fecha y laboratorio

Servicio http://18.221.4.46:3131/api/requests/user/:laboratoryId


http://18.221.4.46:3131/api/requests/user/5932cf5642fbb621ecc35ee2



83


Resultados


Tabla 19. Prueba para consultar solicitudes de práctica por usuario y laboratorio

Servicio http://18.221.4.46:3131/api/requests/consecutive/:consecutiveCod


http://18.221.4.46:3131/api/requests/consecutive/1


Resultados


Tabla 20. Prueba para consultar solicitud de práctica por consecutivo

Servicio http://18.221.4.46:3131/api/requests/all/present


http://18.221.4.46:3131/api/requests/all/present




84


Resultados


Tabla 21. Prueba para consultar solicitudes de práctica del año y semestre actual

Servicio http://18.221.4.46:3131/api/requests/user/all/:laboratoryId


http://18.221.4.46:3131/api/requests/user/all/5932cf5642fbb621ecc35ee2


Resultados


Tabla 22. Prueba para consultar solicitudes de práctica filtrada por laboratorio

Servicio http://18.221.4.46:3131/api/practices/:requestId


http://18.221.4.46:3131/api/practices/595a70d0b211dd1b840a9ab0

85


Resultados


Tabla 23. Prueba para crear solicitud de material

Servicio http://18.221.4.46:3131/api/practices/stock/:requestId


http://18.221.4.46:3131/api/practices/stock/5959114679f4ab5450111002


Resultados


Tabla 24. Prueba para consultar equipos o materiales disponibles del inventario

Servicio http://18.221.4.46:3131/api/practices/request/admin/:year/:semesterId/:laboratoryId


http://18.221.4.46:3131/api/practices/request/admin/2017/594584c31fad253a347a9de1/5932cf5642fbb621ecc35ee2

86


Resultados


Tabla 25. Prueba para consultar solicitudes de material filtrado por año, semestre y laboratorio

Servicio http://18.221.4.46:3131/api/practices/request/user/:year/:semesterId


http://18.221.4.46:3131/api/practices/request/user/2017/594584c31fad253a347a9de1


Resultados


Tabla 26. Prueba para consultar solicitudes de material por usuario filtrado por año y semestre

Servicio http://18.221.4.46:3131/api/practices/users


http://18.221.4.46:3131/api/practices/users

87


Resultados


Tabla 27. Prueba para consultar solicitudes de material por sesión de usuario

Servicio http://18.221.4.46:3131/api/practices/reqprac/:year/:semester


http://18.221.4.46:3131/api/practices/reqprac/2017/594584c31fad253a347a9de1


Resultados


Tabla 28. Prueba para consultar solicitudes de práctica y material filtrado por año y semestre

Servicio http://18.221.4.46:3131/api/practices/reqpracuser/:year/:semester


http://18.221.4.46:3131/api/practices/reqpracuser/2017/594584c31fad253a347a9de1

88


Resultados


Tabla 29. Prueba para consultar solicitudes de práctica y material por usuario filtrado por año y semestre

Servicio http://18.221.4.46:3131/api/practices/id/:id/:status


http://18.221.4.46:3131/api/practices/id/59abf2a9636c050180e015a0


Resultados


Tabla 30. Prueba para actualizar el campo observaciones de la solicitud de material

Servicio http://18.221.4.46:3131/api/practices/status/id/:id


http://18.221.4.46:3131/api/practices/status/id/59abf2a9636c050180e015a0

89


Resultados


Tabla 31. Prueba para actualizar el estado de ejecución de la solicitud de material

Servicio http://18.221.4.46:3131/api/practices/reqprac/all


http://18.221.4.46:3131/api/practices/reqprac/all


Resultados


Tabla 32. Prueba para consultar las solicitudes de práctica y material por sesión de usuario y que se encuentran en estado finalizado

Servicio http://18.221.4.46:3131/api/users


http://18.221.4.46:3131/api /users

90


Resultados


Tabla 33. Prueba para consultar información de todos los usuarios

Servicio http://18.221.4.46:3131/api/users/:username


http://18.221.4.46:3131/api /users/20151678009

tests["Tiempo de respuesta es menor o igual a 300ms"] = responseTime < 300; tests["Código de estado 200"] = responseCode.code === 200; var jsonData = JSON.parse(responseBody); tests["Respuesta satisfactoria"] = jsonData.success === true; tests["data es un objeto"] = typeof jsonData.data === 'object'; tests["data contiene registros"] = jsonData.data !== null && jsonData.data !== undefined && jsonData.data !== '';

Resultados

PASS Tiempo de respuesta es menor o igual a 300ms PASS Código de estado 200 PASS Respuesta satisfactoria PASS data es un objeto PASS data contiene registros

Tabla 34. Prueba para consultar información de usuarios filtrado por código

Servicio http://18.221.4.46:3131/api/users/profile/:profile_id


http://18.221.4.46:3131/api /users/profile/590fddb8b605751ba40ffd9b

91


Resultados


Tabla 35. Prueba para consultar usuarios agrupados por perfil

Servicio http://18.221.4.46:3131/api/users


http://18.221.4.46:3131/api /users

{ "username": "20151678010", "password": "123456789", "name": "Nayvir Vanessa", "lastname": "Casas Ruíz", "phone": "7542356", "mobile": "3131234455", "email": "[email protected]", "profile": "590fdd99b605751ba40ffd99", "status": "590fbd757f874e15187408bc", "creator": "590fb40e11f1711164efba78", "career": "5932ccd922ba202574c018ff" }


92

Resultados


Tabla 36. Prueba para crear un usuario

Servicio http://18.221.4.46:3131/api/users/signin


http://18.221.4.46:3131/api /users/signin

{ "username": "20151678010", "password": "123456789" }


Resultados


Tabla 37. Prueba para iniciar sesión con las credenciales de un usuario

Servicio http://18.221.4.46:3131/api/users/forgot


http://18.221.4.46:3131/api /users/forgot

{ "username": "20151678010", }

93


Resultados


Tabla 38. Prueba para modificar el estado de activación de un usuario



http://18.221.4.46:3131/api /users/20151678010

{ "email": “[email protected]” }


Resultados


Tabla 39. Prueba para actualizar los datos de un usuario


Tests Método de petición DELETE

http://18.221.4.46:3131/api /users/20151678010

mailto:[email protected]

94

tests["Tiempo de respuesta es menor o igual a 200ms"] = responseTime < 200; tests["Código de estado 200"] = responseCode.code === 200; var jsonData = JSON.parse(responseBody); tests["Respuesta satisfactoria"] = jsonData.success === true;

Resultados


Tabla 40. Prueba para eliminar los datos de un usuario

Servicio http://18.221.4.46:3131/api/metrics/id/:id


http://18.221.4.46:3131/api /metrics/id/5932d61ed8ff6829981c8367

tests["Tiempo de respuesta es menor o igual a 300ms"] = responseTime < 300; tests["Código de estado 200"] = responseCode.code === 200; var jsonData = JSON.parse(responseBody); tests["Respuesta satisfactoria"] = jsonData.success === true; tests["data es un objeto"] = typeof jsonData.data === 'object'; tests["data contiene registros"] = jsonData.data !== null && jsonData.data !== undefined && jsonData.data !== '';

Resultados


Tabla 41. Prueba para obtener una métrica por su identificador

Servicio http://18.221.4.46:3131/api/metrics/:type


http://18.221.4.46:3131/api /metrics/career

95

tests["Tiempo de respuesta es menor o igual a 300ms"] = responseTime < 300; tests["Código de estado 200"] = responseCode.code === 200; var jsonData = JSON.parse(responseBody); tests["Respuesta satisfactoria"] = jsonData.success === true; tests["data es un objeto"] = typeof jsonData.data === 'object'; tests["data contiene registros"] = Object.keys(jsonData.data).length > 0;

Resultados


Tabla 42. Prueba para obtener un listado de métricas filtradas por el tipo al que pertenecen

Servicio http://18.221.4.46:3131/api/metrics


http://18.221.4.46:3131/api /metrics

{ "name": "test career", "code": 1000, "type": "career", "description": "test career" }


Resultados


Tabla 43. Prueba para crear una nueva métrica

96



http://18.221.4.46:3131/api /metrics/id/59b68ae8b566652be50d76aa

{ "description": "test career updated" }


Resultados


Tabla 44. Prueba para actualizar una métrica



http://18.221.4.46:3131/api /metrics/id/59b68ae8b566652be50d76aa


Resultados PASS Tiempo de respuesta es menor o igual a 200ms PASS Código de estado 200 PASS Respuesta satisfactoria

Tabla 45. Prueba para eliminar una métrica

Servicio http://18.221.4.46:3131/api/entries

97


http://18.221.4.46:3131/api /entries


Resultados


Tabla 46. Prueba para obtener el listado de todas las entradas de almacén

Servicio http://18.221.4.46:3131/api/entries/id/:id


http://18.221.4.46:3131/api/entries/id/593f511d8323fe1c703333f3


Resultados


Tabla 47. Prueba para obtener una entrada de almacén por su identificador

Servicio http://18.221.4.46:3131/api/entries/


http://18.221.4.46:3131/api/entries/

98

{ "invoice": "1", "username": "59178271cfce1707247c1045", "entry": "AAA", "contract": "PS", "provider_id": "593f3edc0857e82bfc4a72c0", "per_delivery": "Juliana Gutiérrez", "description": [ { "location_id": "5932dab8d8ff6829981c837e", "description": "Computadores de escritorio Lenovo", "quantity": 5, "unity": 1, "group": "1" } ], "date_registry": "2017-09-08T00:07:57.766Z" }


Resultados


Tabla 48. Prueba para crear una nueva entrada de almacén




99

{ "invoice": "2", "entry": "AA", "contract": "PS", "per_delivery": "Ana Gutiérrez", }


Resultados


Tabla 49. Prueba para actualizar los datos de una entrada de almacén





Resultados PASS Tiempo de respuesta es menor o igual a 400ms PASS Código de estado 200 PASS Respuesta satisfactoria

Tabla 50. Prueba para eliminar los datos de una entrada de almacén

Servicio http://18.221.4.46:3131/api/stocks


http://18.221.4.46:3131/api/stocks

100


Resultados


Tabla 51. Prueba para obtener el listado de todas las fichas técnicas

Servicio http://18.221.4.46:3131/api/stocks/entries/available


http://18.221.4.46:3131/api/stocks/entries/available


Resultados


Tabla 52. Prueba para obtener las entradas de almacén que tienen recursos o herramientas que aún no se han registrado en el inventario

Servicio http://18.221.4.46:3131/api/stocks/id/:id


http://18.221.4.46:3131/api/stocks/id/5920c7ffe6d184316e74e969

101


Resultados


Tabla 53. Prueba para obtener los datos de una ficha técnica por su identificador

Servicio http://18.221.4.46:3131/stocks/entries/stock/:id


http://18.221.4.46:3131/api/stocks/entries/stock/593f511d8323fe1c703333f3


Resultados


Tabla 54. Prueba para retornar los recursos y las cantidades que aún se pueden registrar en el inventario

Servicio http://18.221.4.46:3131/stocks


http://18.221.4.46:3131/api/stocks

102

{ "entry_id": "593f53a78323fe1c703333f5", "code": "1", "succession": "987654", "trademark": "RSA", "equipment": "Estación de llenado granza azul", "model": "2017", "state": "", "laboratory_id": "5932cf5642fbb621ecc35ee2", "location_id": null, "description": "laboratorio HAS 200 - ubicación HAS 200", "photo": "", "handbook": "", "observations": "Equipo nuevo", "status": "59458e138656f53f36bfc472", }


Resultados


Tabla 55. Prueba para crear una nueva ficha técnica

Servicio http://18.221.4.46:3131/stocks/id/:id



103

{ "code": "10", "trademark": "RSA", "equipment": "Estación de llenado granza azul", "model": "2017", "description": "laboratorio HAS 200 - ubicación HAS 200", "photo": "/granza_azul_1", "observations": "Equipo nuevo con funda de protección", "status": "59458e138656f53f36bfc472", }


Resultados


Tabla 56. Prueba para actualizar los datos de una ficha técnica

Servicio http://18.221.4.46:3131/stocks/status/:id


http://18.221.4.46:3131/api/stocks/status/5920c7ffe6d184316e74e969

{ "code": "10", "trademark": "RSA", "equipment": "Estación de llenado granza azul", "model": "2017", "description": "laboratorio HAS 200 - ubicación HAS 200", "photo": "/granza_azul_1", "observations": "Equipo nuevo con funda de protección", "status": "59458e138656f53f36bfc472", }

104


Resultados


Tabla 57. Prueba para actualizar el estado de una ficha técnica

Servicio http://18.221.4.46:3131/stocks/id/:id




Resultados


Tabla 58. Prueba para actualizar el estado de una ficha técnica por no disponible

105

9. CRONOGRAMA DE ACTIVIDADES

107

10. CONCLUSIONES

Se desarrolló un prototipo telemático que permite controlar y gestionar los horarios libres del laboratorio mediante el registro de los horarios fijos entregados por la coordinación al inicio del semestre y las solicitudes de práctica y material que solicitan docentes o estudiantes durante el transcurso del periodo académico. Así mismo, se controla los recursos del laboratorio por medio de la elaboración del inventario que contiene el registro de cada equipo o material, su correspondiente ubicación y si están disponibles para el uso por parte de la comunidad educativa. Se desarrolló el módulo de administración de usuarios con el fin de identificar los docentes o estudiantes que tienen permiso a los servicios del laboratorio de tecnología industrial e ingeniería de producción. El grupo de trabajo del laboratorio puede limitar los permisos de acceso a los procesos que ejecuta el sistema, está restricción puede ser parcial o completa cuando se inactiva la cuenta de un usuario. Para mantener la integridad de la información no se permite eliminar la cuenta de un usuario. Se implementó un módulo de préstamos que permite a los docentes y estudiantes la posibilidad de realizar solicitudes por medio de un aparato móvil, tener información actualizada sobre la disponibilidad de los laboratorios para realizar prácticas libres, por último, revisar el historial de solicitudes de práctica ejecutadas, aprobadas, en espera y no aprobadas. El grupo de trabajo del laboratorio por medio de la aplicación web puede mejorar la operatividad de acceso a los laboratorios y sus respectivos elementos o materiales, así mismo, tienen la autoridad para aprobar o no las solicitudes de práctica. Se realizó un módulo para la visualización de los recursos del laboratorio que permite conocer el estado de disponibilidad y las características de los equipos o materiales que previamente se ingresaron al inventario. Se diseñó un api rest para facilitar la adaptación a cualquier lenguaje de programación por esta razón los componentes de desarrollo web o móvil pueden evolucionar de forma independiente. Junto con la base de datos no relacional aumenta la escalabilidad del sistema sin generar excesivos inconvenientes. Se construyó un módulo de inventario que proporciona a los administradores del laboratorio tener una hoja de vida y organización de los equipos o materiales en un inventario que cumple con los formatos de ingreso al almacén establecidos por la coordinación del laboratorio, también permite habilitar o no la disponibilidad de los recursos para que puedan ser utilizados por la comunidad educativa durante el ejercicio de las prácticas.

108

11. RECOMENDACIONES

Se recomienda complementar el componente web del prototipo realizando una interfaz para las solicitudes de práctica y materiales que permitan a los docentes o estudiantes crear por este medio las solicitudes. También que los usuarios mencionados puedan revisar la información completa de la solicitud y el estado en que se encuentra. Se recomienda antes de hacer uso del prototipo realizar la lectura del manual de usuario anexo en el presente documento, debido a la necesidad de conocer las funcionalidades y características además de evitar la pérdida de información. Se invita a los laboratorios de los demás proyectos curriculares a analizar el servicio web creado en este proyecto para que lo puedan adaptar a sus procesos y de esta manera promulgar la ejecución de prácticas libres de forma ágil y eficiente.

109

12. REFERENCIAS BIBLIOGRÁFICAS

ALAIMO, Diego Martín. Proyectos ágiles con Scrum: flexibilidad, aprendizaje, innovación y colaboración en contextos complejos. 1 ed. Ciudad Autónoma de Buenos Aires.: Kleer, 2013. EBook. ISBN 978-987-45158-1-0 MINISTERIO DE EDUCACIÓN GOBIERNO DE CHILE. Guía para Control del Uso [en línea], [revisado 11 julio 2017]. Disponible en Internet: http://www.enlaces.cl/wp-content/uploads/Control_del_Uso.pdf HERRERA, Sonia y SARMIENTO, Camilo. Documentación de Procesos de los Laboratorios de Tecnología Industrial e Ingeniería de Producción de la Facultad Tecnológica de la Universidad Distrital Francisco José de Caldas con miras hacia la certificación de Calidad. Bogotá D.C.: Universidad Distrital Francisco José de Caldas. Facultad Tecnológica. 2016. ACOSTA LÓPEZ, Alberto; MANZANO GONZÁLEZ, Dago José y MARTÍNEZ MORALES, Carlos A. Diseño e implementación de un prototipo para el registro y verificación de activos fijos utilizando plataforma android y tecnología NFC. Bogotá D.C.: Universidad Distrital Francisco José de Caldas. Facultad de ingeniería. 2014. ABERNETHY, Michael. ¿Simplemente qué es Node.js? IBM developerWorks [en línea], 14 de junio de 2011 [revisado 20 julio 2017]. Disponible en Internet: https://www.ibm.com/developerworks/ssa/opensource/library/os-nodejs/index.html TOMÁS, Jesús. El gran libro de Android. 5 ed. México.: Alfaomega, 2016. ISBN 978-607-622-692-6 KENDALL, Kenneth E. KENDALL, Julie E. Análisis y diseño de sistemas. 8 ed. México.: Pearson Educación, 2011. ISBN 978-607-32-0577-1 REINOSA, Enrique José; MALDONADO, Calixto Alejandro; MUÑOZ, Roberto y DAMIANO, Luis Esteban. ABRUTSKY, Maximiliano Adrián. Bases de Datos. Buenos Aires.: Alfaomega. 2012. CHACON, Scott. Pro Git, el libro oficial de Git. LIBROSWEB [en línea], [revisado 20 julio 2017]. Disponible en Internet: http://librosweb.es/libro/pro_git/capitulo_1/acerca_del_control_de_versiones.html Tello, Edgar; Sosa, Claudia y Tello, Diego. Revisión de los sistemas de control de versiones utilizados en el desarrollo de software. En: Revista de Ingenierías USBMED. Junio, 2012. vol. 3, no. 1, p. 78.



https://www.ibm.com/developerworks/ssa/opensource/library/os-nodejs/index.html

http://librosweb.es/libro/pro_git/capitulo_1/acerca_del_control_de_versiones.html

110

GÓMEZ LÓPEZ, Julio. Administración de sistemas GNU/LINUX. Bogotá D.C.: Ediciones de la U. 2011. GUTIERREZ, Emmanuel. JavaScript Conceptos básicos y avanzados. Barcelona.: Ediciones Eni, 2009. Eguiluz, Javier. Introducción a JavaScript. LIBROSWEB [en línea], [revisado 20 julio 2017]. Disponible en Internet: http://librosweb.es/libro/javascript/capitulo_1.html CERNUDA MENÉNDEZ, José Higinio. Creación de juegos y aplicaciones para Android: desarrollo práctico de proyectos. Bogotá D.C.: Ediciones de la U, 2016. (Serie Informática). ISBN 978-958-762-520-2. AMARO SORIANO, José Enrique. Android: Programación de dispositivos móviles a través de ejemplos. México.: Alfaomega, 2012. SÁNCHEZ, Salvador; SICILIA, Miguel y RODRÍGUEZ, Daniel. Ingeniería del Software. Un enfoque desde la guía SWEBOK. México.: Alfaomega, 2012. LÓPEZ JURADO, Francisco Carlos. Api rest con mean para contenidos multimedia. Madrid.: Universidad Politécnica de Madrid. Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. 2015. FONTELA, Carlos. UML: modelado de software para profesionales. Buenos Aires.: Alfaomega Grupo Editor Argentino, 2011. ISBN 978-987-1609-22-2 Chillarón, Diego Castaño. Desarrollo de una plataforma social para compartir imágenes en dispositivos Android. Madrid.: Universidad Politécnica de Madrid. Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. 2016.

http://librosweb.es/libro/javascript/capitulo_1.html

111

ANEXOS

112

MANUAL DE USUARIO



INGENIERÍA EN TELEMÁTICA BOGOTÁ D.C., 2017

113

TABLA DE CONTENIDO

1. MANUAL DE USUARIO ................................................................................ 116

1.1 INTRODUCCIÓN .................................................................................... 116

1.2 OBJETIVOS ............................................................................................ 116

1.3 ADMINISTRADOR WEB ......................................................................... 116

1.3.1 Ingreso a la plataforma ..................................................................... 116

1.3.2 Ingreso con credenciales inválidas................................................... 117

1.3.3 Bienvenida a la plataforma ............................................................... 117

1.3.4 Sección de configuración ................................................................. 119

1.3.5 Constantes ....................................................................................... 120

1.3.6 Usuarios ........................................................................................... 122

1.3.7 Rutas ................................................................................................ 123

1.3.8 Perfiles ............................................................................................. 123

1.3.9 Proveedores ..................................................................................... 125

1.3.10 Métricas ........................................................................................ 125

1.3.11 Carreras ........................................................................................ 126

1.3.12 Docentes ....................................................................................... 126

1.3.13 Laboratorios .................................................................................. 127

1.3.14 Tipos de prácticas ......................................................................... 127

1.3.15 Prácticas dirigidas ......................................................................... 127

1.3.16 Ubicaciones .................................................................................. 128

1.3.17 Materias ........................................................................................ 128

1.3.18 Horarios ........................................................................................ 129

1.3.19 Sección de Almacén ..................................................................... 129

1.3.20 Entradas ........................................................................................ 130

1.3.21 Inventario ...................................................................................... 130

1.3.22 Sección de solicitudes .................................................................. 131

1.3.23 Préstamos ..................................................................................... 131

1.3.24 Materiales ..................................................................................... 132

1.4 GESTIÓN DE PRÉSTAMOS .................................................................. 133

114

LISTA DE FIGURAS

Administrador Fig. 1. Iniciar sesión. ..................................................................... 117 Administrador Fig. 2. Mensaje error. Administrador Fig. 1. Iniciar sesión. ........... 117 Administrador Fig. 2. Mensaje error. .................................................................... 117 Administrador Fig. 3. Mensaje de bienvenida. Administrador Fig. 2. Mensaje error.

...................................................................................................................... 117 Administrador Fig. 3. Mensaje de bienvenida. ..................................................... 118 Administrador Fig. 4. Sección de estadísticas. Administrador Fig. 3. Mensaje de

bienvenida. ................................................................................................... 118 Administrador Fig. 4. Sección de estadísticas. .................................................... 118 Administrador Fig. 5. Sección de solicitudes entrantes. Administrador Fig. 4.

Sección de estadísticas. ............................................................................... 118 Administrador Fig. 5. Sección de solicitudes entrantes. ....................................... 119 Administrador Fig. 6. Horario día sábado. Administrador Fig. 5. Sección de

solicitudes entrantes. .................................................................................... 119 Administrador Fig. 6. Horario día sábado. ........................................................... 119 Administrador Fig. 7. Menú de configuraciones. Administrador Fig. 6. Horario día

sábado. ......................................................................................................... 119 Administrador Fig. 7. Menú de configuraciones. .................................................. 120 Administrador Fig. 8. Módulo de gestión de constantes. Administrador Fig. 7. Menú

de configuraciones. ....................................................................................... 120 Administrador Fig. 8. Módulo de gestión de constantes. ..................................... 120 Administrador Fig. 9. Acción agregar constante. ................................................. 121 Administrador Fig. 10. Acción editar constante. ................................................... 121 Administrador Fig. 11. Acción eliminar constante. ............................................... 122 Administrador Fig. 12. Módulo de gestión de usuarios. ....................................... 122 Administrador Fig. 13. Módulo de gestión de rutas. ............................................. 123 Administrador Fig. 14. Módulo de gestión de perfiles. ......................................... 124 Administrador Fig. 15. Agregar perfil. .................................................................. 124 Administrador Fig. 16. Editar perfil. ...................................................................... 125 Administrador Fig. 17. Eliminar perfil. .................................................................. 125 Administrador Fig. 18. Módulo de gestión de proveedores. ................................. 125 Administrador Fig. 19. Sección métrica. .............................................................. 126 Administrador Fig. 20. Módulo de gestión de carreras. ........................................ 126 Administrador Fig. 21. Módulo de gestión de profesores. .................................... 126 Administrador Fig. 22. Módulo de gestión de laboratorios. .................................. 127 Administrador Fig. 23. Módulo de gestión de tipos de prácticas. ......................... 127 Administrador Fig. 24. Módulo de gestión de prácticas dirigidas. ........................ 128 Administrador Fig. 25. Módulo de gestión de ubicaciones. .................................. 128 Administrador Fig. 26. Módulo de gestión de materias. ....................................... 129 Administrador Fig. 27. Módulo de gestión de horarios. ........................................ 129 Administrador Fig. 28. Sección de almacén. ........................................................ 129

115

Administrador Fig. 29. Módulo de gestión de entradas. ....................................... 130 Administrador Fig. 30. Módulo de gestión de inventarios. ................................... 130 Administrador Fig. 31. Sección de solicitudes...................................................... 131 Administrador Fig. 32. Formato para la solicitud de préstamos arrojado por el

sistema. ........................................................................................................ 131 Administrador Fig. 33. Módulo de gestión de préstamos. .................................... 132 Administrador Fig. 34. Formato para la solicitud de materiales. .......................... 132 Administrador Fig. 35. Módulo de gestión de materiales. .................................... 132 Móvil Fig. 1. Inicio de sesión. ............................................................................... 133 Móvil Fig. 2. Lista de solicitudes de práctica aprobadas. ..................................... 133 Móvil Fig. 3. Formulario de solicitud de material. ................................................. 134 Móvil Fig. 4. Menú. ............................................................................................... 135 Móvil Fig. 5. Formulario solicitud de práctica. ...................................................... 135 Móvil Fig. 6. Lista de solicitudes de material. ....................................................... 136 Móvil Fig. 7. Lista de solicitudes de práctica en espera y no aprobadas. ............ 136

116

1. MANUAL DE USUARIO

1.1 INTRODUCCIÓN

El presente manual se construyó con el fin de instruir al usuario en las funcionalidades del prototipo mencionando cada uno de los módulos que lo componen y la forma en la cual se debe operar sobre los mismos. Los módulos están distribuidos en secciones que permiten realizar una acción o visualización con respecto a la información que irá alimentando al prototipo.

1.2 OBJETIVOS

Describir las funcionalidades de cada uno de los módulos que componen el prototipo de administración web. Proporcionar una guía de consulta en caso de dudas e inquietudes sobre la operatividad del prototipo.

1.3 ADMINISTRADOR WEB

1.3.1 Ingreso a la plataforma Para poder ingresar, se debe contar con las credenciales para acreditarse dentro del sistema. Para ello, el administrador debe gestionar los usuarios, roles y perfiles que va a tomar cada uno dentro del mismo.

117

1.3.2 Ingreso con credenciales inválidas El sistema mediante conexión con la API REST valida las credenciales del usuario y si éstas son satisfactorias le permite el ingreso a la plataforma, en caso contrario mostrará el siguiente mensaje: “Las credenciales son inválidas”.

1.3.3 Bienvenida a la plataforma

Administrador Fig. 1. Iniciar sesión.

Administrador Fig. 2. Mensaje error. Administrador Fig. 3. Iniciar sesión.

Administrador Fig. 4. Mensaje error.

Administrador Fig. 5. Mensaje de bienvenida. Administrador Fig. 6. Mensaje

error.

118

Si el usuario ingresa las credenciales correctas, el sistema le mostrará la página de bienvenida, la cual contiene un menú y una pantalla principal denominado “TABLERO PRINCIPAL”. Como se puede observar en la imagen en la primera opción del menú “TABLERO PRINCIPAL” se puede observar la siguiente información: a. Sección de estadísticas: Aquí es posible visualizar el número de solicitudes en los estados de “en espera”, “aprobados”, “cancelados” y “finalizados”. b. Sección de solicitudes entrantes: Al dar clic sobre el ícono de alertas se despliega un listado con todas las solicitudes de préstamo entrantes.

Administrador Fig. 7. Mensaje de bienvenida.

Administrador Fig. 8. Sección de estadísticas. Administrador Fig. 9. Mensaje de

bienvenida.

Administrador Fig. 10. Sección de estadísticas.

Administrador Fig. 11. Sección de solicitudes entrantes. Administrador Fig. 12.

Sección de estadísticas.

119

c. Sección de horarios: Esta sección brinda al usuario información sobre la programación fija de los laboratorios, en ella se puede observar: Día (sábado en este caso), laboratorios (fila 1), bloques de hora (columna 1.1), nombre de la materia (columna 1.2 fila 3.1), nombre del docente (columna 1.2 fila 3.2) y el proyecto curricular (columna 1.2 fila 3.3).

1.3.4 Sección de configuración El usuario puede en esta sección realizar la parametrización del sistema, de forma que pueda gestionar usuarios, perfiles, roles, proveedores, laboratorios, y demás que se irán explicando en las siguientes secciones.

Administrador Fig. 13. Sección de solicitudes entrantes.

Administrador Fig. 14. Horario día sábado. Administrador Fig. 15.

Sección de solicitudes entrantes.

Administrador Fig. 16. Horario día sábado.

Administrador Fig. 17. Menú de configuraciones. Administrador Fig. 18.

Horario día sábado.

120

1.3.5 Constantes Las constantes permiten modificar un comportamiento en el sistema debido a que su valor no cambia con el transcurso de la ejecución de la aplicación. Este módulo está compuesto de dos tipos de constantes: Una constante padre y una constante hijo (apunta a un padre). Constante padre: Permite agrupar constantes por ejemplo la constante de nombre blocks, agrupará los bloques de horas como block_1 que tiene el valor de 6-8 o block₇ que tiene el valor de 18-20. Constante hijo: Contiene un valor y es quien modifica el comportamiento dentro del sistema por ejemplo la constante de nombre block_1.

Administrador Fig. 19. Menú de configuraciones.

Administrador Fig. 20. Módulo de gestión de constantes. Administrador Fig.

21. Menú de configuraciones.

Administrador Fig. 22. Módulo de gestión de constantes.

121

La grilla se divide en: filtros, acciones, columnas y filas. Filtros: Como su nombre lo indica, nos permite ir filtrando en este caso la información que hay sobre la columna. Por ejemplo, si en el filtro “Padre” se digita “blocks”, se mostrarán en la grilla únicamente las filas que tengan relación con el filtro. Acciones: Existen 3 acciones estandarizadas en todas las grillas del sistema: Agregar, editar y eliminar. Sin embargo, hay dos tipos de estilo para estas acciones: El primero es el estilo en línea, da la sensación de estar editando un registro como en una hoja de cálculo mediante la pulsación de los íconos. El segundo es el estilo con ventanas emergentes, sirve para evitar distracciones al usuario en el momento de agregar o editar un registro. A continuación, se describen las acciones del primer estilo nombrado: a. Agregar: Al dar clic sobre esta opción, se desplegará hacia abajo una fila nueva que permitirá agregar un campo nuevo, en este caso una constante. Para crear una constante padre en la columna “Padre” no se debe seleccionar nada. Y para relacionar una constante hijo a un padre en la columna “Padre” se debe seleccionar una opción de la lista.

Administrador Fig. 23. Acción agregar constante.

b. Editar: Cuando el usuario da clic sobre el ícono del lápiz, éste cambia al ícono de paloma. Significa que el registro se puede editar y una vez terminada su edición se procede a dar clic sobre la paloma para confirmar los cambios.

Administrador Fig. 24. Acción editar constante.

c. Eliminar: El usuario debe dar clic en el ícono de eliminar (cesta), al pulsar se muestra una ventana emergente de confirmación, al confirmar el registro se elimina.

122

Administrador Fig. 25. Acción eliminar constante.

1.3.6 Usuarios Este módulo le permite al perfil administrador gestionar los usuarios del sistema. En él se permite realizar las 3 acciones con estilo en línea: Agregar, editar y eliminar. Al guardar la contraseña quedará encriptado con un hash conocido sólo por el sistema.

Administrador Fig. 26. Módulo de gestión de usuarios.

Username: Es el nombre del usuario, es su identificación única en el sistema. Ésta puede ser cualquier cadena de caracteres. Sin embargo, se sugiere sea el número del código con el cual se reconoce a una persona como perteneciente al campus universitario. Password: Es un campo alfanumérico que brinda un nivel de seguridad para el ingreso a la plataforma. Perfil: En este campo se muestra al usuario una lista desplegable con los perfiles parametrizados en el sistema, con el fin de tener un grado de privilegios dentro del sistema. Carrera: Es un campo de tipo lista, el cual despliega información con respecto al proyecto curricular al cual está asociada la persona perteneciente al campus universitario.

123

Estado: Este campo permite validar si un usuario está activo o inactivo en el sistema, es importante que se cree en estado activo para que el usuario pueda desarrollar sus actividades dentro del mismo, en caso contrario se restringirá su acceso al sistema hasta que su estado sea reactivado por un usuario con privilegios para otorgar el permiso. 1.3.7 Rutas Este módulo se desarrolló para brindar seguridad a los enlaces y módulos dentro de la aplicación. Por ende, una ruta especificará posteriormente un rol para un perfil definido por el usuario con privilegios para crearlo y asignarlo.

Administrador Fig. 27. Módulo de gestión de rutas.

URL: Como su nombre lo indica es el enlace o vínculo, el cual está apuntando hacia un módulo en específico. Éste es un módulo técnico, por lo cual se recomienda no editarlo a menos que se tenga el personal adecuado y capacitado en función de la necesidad de crear un nuevo módulo. 1.3.8 Perfiles Los perfiles permiten definir los privilegios y funciones para determinar el comportamiento de un usuario dentro del sistema.

124

Administrador Fig. 28. Módulo de gestión de perfiles.

El estilo de las acciones para este módulo cambia pues se optó por el estilo de ventanas emergentes como se describe a continuación: a. Agregar perfil: A diferencia del estilo en línea, el estilo por ventanas emergentes permite una mayor cobertura de componentes web. En esta ventana el usuario puede seleccionar los módulos a los cuales el nuevo perfil tendrá acceso, además en la parte inferior izquierda aparece un interruptor que permitirá cambiar el estado del perfil, de activo (en uso) a inactivo (no está disponible su uso dentro del sistema).

Administrador Fig. 29. Agregar perfil.

b. Editar perfil: Al accionar el ícono de editar aparecerá una ventana emergente con los datos correspondientes al registro seleccionado. Permitirá al usuario identificar y modificar según las necesidades de operación sobre el sistema.

125

Administrador Fig. 30. Editar perfil.

c. Eliminar perfil. Al accionar este botón el usuario verá una ventana emergente de confirmación la cuál pregunta: “¿Desea eliminar el registro?”. Al aceptar el sistema eliminará el registro, de lo contrario se anulará la operación.

Administrador Fig. 31. Eliminar perfil.

1.3.9 Proveedores Este módulo permite al usuario gestionar los proveedores con los cuales tiene acceso directo el laboratorio, con el fin de registrar, hacer uso de ellos para informes y demás.

Administrador Fig. 32. Módulo de gestión de proveedores.

1.3.10 Métricas Esta sección contiene 6 módulos, que permitirán al sistema interactuar de una forma más amigable con el usuario.

126

Administrador Fig. 33. Sección métrica.

1.3.11 Carreras El módulo de carreras permitirá al usuario parametrizar los proyectos curriculares existentes en la universidad.

Administrador Fig. 34. Módulo de gestión de carreras.

1.3.12 Docentes Este módulo le permite al usuario gestionar los docentes del campus universitario, la carrera a la cual pertenecen y las materias que dictan, con el fin de tener una trazabilidad en el sistema.

Administrador Fig. 35. Módulo de gestión de profesores.

127

1.3.13 Laboratorios El módulo de laboratorios tiene la finalidad de identificar los lugares en los cuales se imparten las prácticas y lleva consigo una relación hacia el proyecto curricular al cual pertence.

Administrador Fig. 36. Módulo de gestión de laboratorios.

1.3.14 Tipos de prácticas Este módulo permite parametrizar los diferentes tipos de prácticas que se pueden llevar a cabo en los laboratorios del proyecto curricular al cual pertenecen.

Administrador Fig. 37. Módulo de gestión de tipos de prácticas.

1.3.15 Prácticas dirigidas Este módulo al igual que los otros permite la parametrización de aquellas prácticas que son dirigidas.

128

Administrador Fig. 38. Módulo de gestión de prácticas dirigidas.

1.3.16 Ubicaciones Permite al usuario parametrizar aquellas ubicaciones o localizaciones en donde se encuentran los laboratorios de la universidad.

Administrador Fig. 39. Módulo de gestión de ubicaciones.

1.3.17 Materias Este módulo permite al usuario gestionar las materias y relacionarlas a un proyecto curricular.

129

Administrador Fig. 40. Módulo de gestión de materias.

1.3.18 Horarios Este módulo contiene la lógica del sistema para organizar y validar la disponibilidad de los espacios, con el fin de establecer un bloque de hora para realizar una práctica determinada.

Administrador Fig. 41. Módulo de gestión de horarios.

1.3.19 Sección de Almacén Esta sección está pensada en los formatos de entradas e inventario de los laboratorios, con el fin de llevar una contabilidad sobre la existencia de recursos con los cuales cuentan y pueden servir a la comunidad universitario en función del desarrollo académico-práctico.

Administrador Fig. 42. Sección de almacén.

130

1.3.20 Entradas Este módulo del sistema permite al usuario de acuerdo con una solicitud aprobada registrar los elementos recibidos y ubicarlos en el almacén del laboratorio. Esto debido a que todos los elementos que ingresen al almacén deben tener un registro de ingreso al almacén.

Administrador Fig. 43. Módulo de gestión de entradas.

1.3.21 Inventario El módulo de inventarios permite al usuario con privilegios para éste, registrar en el inventario de almacén los elementos recibidos, unidad por unidad. Con el fin de posteriormente poder permitir el préstamo y uso en función del cumplimiento con el nivel de educación de la universidad.

Administrador Fig. 44. Módulo de gestión de inventarios.

131

1.3.22 Sección de solicitudes En esta sección se lleva a cabo el procedimiento mediante el cual se realiza la formalización de los documentos requeridos para el préstamo de un laboratorio y los materiales correspondientes a la práctica.

Administrador Fig. 45. Sección de solicitudes.

1.3.23 Préstamos El objetivo de este módulo es poder llevar a la práctica los lineamientos definidos para la atención y respuesta a solicitudes de práctica en los laboratorios de la Universidad por parte de docentes, estudiantes y otras partes interesadas.

Administrador Fig. 46. Formato para la solicitud de préstamos arrojado por el sistema.

Como se puede observar en la figura de arriba, el sistema permite como resultado obtener un archivo en formato PDF para realizar el registro de la práctica que se desea llevar a cabo.

132

Administrador Fig. 47. Módulo de gestión de préstamos.

1.3.24 Materiales Una vez aprobada la ejecución de práctica, el responsable de la solicitud debe hacer saber a los participantes, la fecha, hora y lugar programados para el desarrollo de la misma. Debe también identificar los materiales y elementos de protección necesarios para el desarrollo de la práctica, y es por ello que este módulo le permite al usuario hacer gestión de esos materiales y elementos que se van a utilizar.

Administrador Fig. 48. Formato para la solicitud de materiales.

En la figura de arriba se puede observar como el sistema arroja como resultado un archivo en formato PDF para realizar el registro de los materiales y elementos de protección para llevar a cabo el desarrollo de la práctica.

Administrador Fig. 49. Módulo de gestión de materiales.

133

1.4 GESTIÓN DE PRÉSTAMOS

A continuación se menciona el proceso genérico para realizar las solicitudes de práctica, solicitudes de material y consultar el estado de los préstamos. Ingreso al módulo de préstamos

Móvil Fig. 1. Inicio de sesión.

El usuario digita las credenciales que fueron brindadas previamente por el administrador del sistema, una vez que tiene acceso se expone la siguiente pantalla:

Móvil Fig. 2. Lista de solicitudes de práctica aprobadas.

134

En la parte superior se tiene el título del proceso donde se encuentra ubicado el usuario, el icono de la izquierda despliega el menú con los enlaces que dirigen a los otros procesos del módulo, finalmente el icono de la derecha permite cerrar la sesión. En la pantalla de inicio se muestran las solicitudes de práctica que fueron aprobadas por el administrador del laboratorio. De esta manera, el usuario tiene la posibilidad de acceder al formulario para realizar la solicitud de materiales haciendo clic en la solicitud de práctica aprobada, luego se expone el siguiente formulario:

Móvil Fig. 3. Formulario de solicitud de material.

El icono ubicado en el extremo izquierdo de la parte superior de la pantalla retorna al usuario a la pantalla de inicio donde se muestra el listado de solicitudes de práctica aprobadas. El usuario despliega el menú y encuentra los siguientes servicios:

135

Móvil Fig. 4. Menú.

El enlace crear solicitud de práctica dirige al usuario al siguiente formulario para registrar una nueva solicitud:

Móvil Fig. 5. Formulario solicitud de práctica.

Se recomienda al usuario elegir primeramente y en orden la fecha que desea realizar la práctica, luego seleccionar el laboratorio y finalmente el bloque de hora disponible. El enlace solicitudes de materiales dirige al usuario a una lista de solicitudes que están en estado de espera o finalizado.

136

Móvil Fig. 6. Lista de solicitudes de material.

Si la solicitud de práctica y de materiales se encuentra en estado finalizado representa que el estudiante o docente ejecutaron la práctica y retornaron el laboratorio y sus materiales sin inconvenientes. El enlace préstamos en espera expone una lista de las solicitudes de práctica que fueron realizadas por el usuario y están esperando ser aprobadas por los administradores del laboratorio, también expone las solicitudes que no fueron aprobadas.

Móvil Fig. 7. Lista de solicitudes de práctica en espera y no aprobadas.

137

MANUAL DEL SISTEMA



INGENIERÍA EN TELEMÁTICA BOGOTÁ D.C., 2017

138

TABLA DE CONTENIDO

1. MANUAL DEL SISTEMA ............................................................................... 140

1.1 INTRODUCCIÓN .................................................................................... 140

1.2 OBJETIVOS ............................................................................................ 140

1.3 REQUISITOS DE HARDWARE .............................................................. 140

1.4 REQUERIMIENTOS DE SOFTWARE .................................................... 140

1.5 INSTALACIÓN SERVIDOR EN LA NUBE AWS FREE TIER ................. 141

1.5.1 Creación de una instancia EC2 ........................................................ 141

1.5.2 Seleccionar el sistema operativo del servidor .................................. 141

1.5.3 Configuración del grupo de seguridad .............................................. 142

1.5.4 Generación de una llave privada para obtener acceso al servidor ... 142

1.6 INGRESO AL SERVIDOR AWS MEDIANTE PROTOCOLO SSH ......... 142

1.7 INSTALACIÓN MONGODB COMMUNITY EDITION ............................. 143

1.8 IMPORTACIÓN DE LA BASE DE DATOS ............................................. 144

1.9 INSTALACIÓN DEL API REST ............................................................... 144

1.10 INSTALAR ADMINISTRADOR WEB ...................................................... 145

1.11 INSTALAR APLICACIÓN MÓVIL ........................................................... 145

1.12 RECOMENDACIONES ........................................................................... 147

139

TABLA DE FIGURAS Manual Sistema Fig. 1. Servidor AWS Free Tier. ................................................ 141 Manual Sistema Fig. 2. Creación EC2. ................................................................ 141 Manual Sistema Fig. 3. Servidor Ubuntu 16.04 LTS. ........................................... 141 Manual Sistema Fig. 4. Grupos de seguridad. ..................................................... 142 Manual Sistema Fig. 5. Generación de llave privada. .......................................... 142

140

1. MANUAL DEL SISTEMA

1.1 INTRODUCCIÓN

El presente manual tiene como fin dar a conocer al usuario técnico o profesional una guía en cuanto a los requisitos de hardware y software para la instalación y despliegue de las aplicaciones que componen el sistema del prototipo telemático para el préstamo y control de uso de laboratorios.

1.2 OBJETIVOS

Describir la importación de la base de datos. Conocer las herramientas de software utilizadas en el prototipo. Exponer el paso a paso para el despliegue de las aplicaciones.

1.3 REQUISITOS DE HARDWARE

Para una ejecución óptima del sistema se recomiendan los siguientes requerimientos mínimos de hardware con los cuales debe contar el servidor.

Hardware Característica

Procesador Core Dúo 1,6 GHz.

Espacio en disco 1 Tb.

Memoria RAM 2 GHz.

Tarjeta Red 10/100/1000 Mbps.

Ancho de banda 2 Mbps.

1.4 REQUERIMIENTOS DE SOFTWARE

Software Versión

Ubuntu 16.04 LTS

MongoDB Community Edition 3.4

NodeJS 6.10.0

141

NPM 3.10.0

ExpressJS 4.14.1

Angular 4

1.5 INSTALACIÓN SERVIDOR EN LA NUBE AWS FREE TIER

Para la realización del prototipo se decidió subir el backend (API REST) a un servidor en la nube que pudiera simular el comportamiento del sistema en el mundo real.

Manual Sistema Fig. 1. Servidor AWS Free Tier.

1.5.1 Creación de una instancia EC2

Manual Sistema Fig. 2. Creación EC2.

1.5.2 Seleccionar el sistema operativo del servidor Se recomienda utilizar un servidor Linux con distribución Ubuntu 16.04 LTS que viene con arquitectura de 64 bits.

Manual Sistema Fig. 3. Servidor Ubuntu 16.04 LTS.

142

1.5.3 Configuración del grupo de seguridad En este apartado se debe configurar los puertos por los cuales el servidor va a escuchar peticiones y dar respuesta a las mismas.

Manual Sistema Fig. 4. Grupos de seguridad.

1.5.4 Generación de una llave privada para obtener acceso al servidor Generar esta llave es importante porque nos proveerá de acceso remoto vía SSH al servidor.

Manual Sistema Fig. 5. Generación de llave privada.

1.6 INGRESO AL SERVIDOR AWS MEDIANTE PROTOCOLO SSH

Ubicar el archivo de extensión “.pem” descargado en el paso de generación de llave privada y modificar los permisos del fichero mediante la siguiente instrucción:

143

chmod 400 prestalud-1.pem

Seguidamente, para conectarse al servidor deberá ejecutar el siguiente comando: ssh -i "prestalud-1.pem" [email protected]

1.7 INSTALACIÓN MONGODB COMMUNITY EDITION

Para la instalación de la base de datos NO-SQL se deben seguir los siguientes pasos: Importación de la llave pública sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 –recv 0C49F3730359A14518585931BC711F9BA15703C6

Crear una lista de archivos para MongoDB echo "deb [ arch=amd64,arm64 ] http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list

Recargar los paquetes locales sudo apt-get update

Instalar los paquetes de MongoDB sudo apt-get install -y mongodb-org

Correr el servicio de MongoDB sudo service mongod start

Parar el servicio de MongoDB sudo service mongod stop

Reiniciar el servicio de MongoDB sudo service mongod restart

144

1.8 IMPORTACIÓN DE LA BASE DE DATOS

Para la importación de la base de datos se debe tener acceso al repositorio GITLAB (https://gitlab.com/prestalud_team/database.git). Extraer la Base de datos del repositorio cd /mnt/prestalud git clone https://gitlab.com/prestalud_team/database.git

Importar la base de datos “prestalud” mongorestore -d prestalud -o /mnt/prestalud/database/prestalud

1.9 INSTALACIÓN DEL API REST

Para la instalación del API REST se debe tener acceso al repositorio GITLAB (https://gitlab.com/prestalud_team/backend.git) Extraer código fuente de la aplicación cd /mnt/prestalud git clone https://gitlab.com/prestalud_team/backend.git

Instalar dependencias cd /mnt/prestalud/backend npm install npm install -g forever

Establecer la variable del ambiente y correr aplicación Esto se hace con el propósito de poder configurar varios ambientes (desarrollo, pruebas y producción). cd /mnt/prestalud/backend NODE_ENV=server forever start app.js

Mediante el comando forever, le decimos al servidor que queremos tener trabajando un servicio en segundo plano, con el fin de que cuando cerremos la sesión en el servidor el servicio del API REST siga recibiendo y respondiendo peticiones den los usuarios.

https://gitlab.com/prestalud_team/database.git

https://gitlab.com/prestalud_team/backend.git

145

1.10 INSTALAR ADMINISTRADOR WEB

El administrador web es fundamental para la parametrización del sistema y la ejecución del ciclo de vida del mismo. Para instalar el administrador web se debe tener acceso al repositorio GITLAB (https://gitlab.com/prestalud_team/adminer.git) Extraer código fuente de la aplicación cd /mnt/prestalud git clone https://gitlab.com/prestalud_team/adminer.git

Instalar dependencias cd /mnt/prestalud/adminer npm install npm install http-server -g

Establecer la variable del ambiente y correr aplicación cd /mnt/prestalud/adminer ng build --env=prod --output-hashing http-server ./dist -o -s &

1.11 INSTALAR APLICACIÓN MÓVIL

La aplicación móvil permite a los docentes, estudiantes o personas externas de la universidad realizar la solicitud de préstamo para desarrollar prácticas libres o guiadas. Primero se debe instalar el entorno de programación Android Studio, la descarga se puede realizar desde la página oficial para desarrolladores (https://developer.android.com/studio/index.html?hl=es-419). Luego, el proyecto Prestalud que está almacenado en el cd junto con el presente documento debe ubicarse en la carpeta AndroidStudioProjects, este directorio es posiblemente creado por el IDE en la siguiente ruta: C:\Users\nombre_usuario\AndroidStudioProjects

https://gitlab.com/prestalud_team/adminer.git

https://developer.android.com/studio/index.html?hl=es-419

146

El siguiente paso es abrir Android Studio y abrir el proyecto desde esta aplicación dirigiéndose al menú file -> Open como se muestra a continuación:

Manual Sistema Fig. 6. Abrir ventana

Después de realizar clic en Open aparece una ventana para seleccionar el proyecto, de este modo debe buscar la carpeta AndroidStudioProjects y elegir el proyecto Prestalud de la siguiente manera:

Manual Sistema Fig. 7. Seleccionar proyecto android

147

Después de realizar clic en el botón OK de la ventana anterior, el IDE abre el proyecto con las respectivas carpetas que componen la aplicación como se expone a continuación:

Manual Sistema Fig. 8. Estructura del proyecto

1.12 RECOMENDACIONES

Se recomienda que la instalación de la aplicación móvil se realice en dispositivos con sistema operativo android con una versión igual o mayor a 5.1. Se recomienda que la transferencia de datos se mantenga con el formato json para garantizar el correcto funcionamiento del servicio web; también para mantener las operaciones de la aplicación móvil porque se utiliza la librería gson como base para deserializar los datos recibidos en notación json. El prototipo está desarrollado sobre un componente backend y otro frontend, de este modo se puede realizar la instalación de cada componente en diferentes servidores sin afectar su normal operación.

Evaluación del ciclo de vida del aceite de motor como...

Documents

Transcript of Evaluación del ciclo de vida del aceite de motor como...