DESARROLLO DE MÓDULOS DE SOFTWARE PARA EL PROYECTO …

DESARROLLO DE MÓDULOS DE SOFTWARE PARA EL PROYECTO “SMART INDUSTRY 4.0”

JUAN PABLO DUQUE CRUZ

UNIVERSIDAD CATÓLICA DE PEREIRA

FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES

PEREIRA

2021

DESARROLLO DE MÓDULOS DE SOFTWARE PARA EL PROYECTO “SMART INDUSTRY 4.0”

JUAN PABLO DUQUE CRUZ

ESTUDIANTE DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES

Trabajo de grado bajo modalidad “Residencia en línea de investigación” para optar por el título de Ingeniero de Sistemas y Telecomunicaciones

M,Sc. ALONSO TORO LAZO DIRECTOR

UNIVERSIDAD CATÓLICA DE PEREIRA

FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES

PEREIRA

2021

3

ÍNDICE

PROYECTO 1

RESUMEN ............................................................................................................. 10

INTRODUCCIÓN ................................................................................................... 11

1. DESCRIPCIÓN DEL PROYECTO .................................................................. 13

2. FORMULACIÓN DEL PROBLEMA ................................................................. 13

3. OBJETIVOS .................................................................................................... 15

3.1. Objetivo General ....................................................................................... 15

3.2. Objetivos específicos ................................................................................ 15

4. JUSTIFICACIÓN DEL PROYECTO ................................................................ 15

5. CRONOGRAMA DE ACTIVIDADES ............................................................... 16

6. ENTREGABLES DEL PROYECTO ................................................................. 16

7. MARCO CONCEPTUAL ................................................................................. 17

7.1. Framework ................................................................................................ 17

7.2. Lenguajes de programación utilizados ..................................................... 18

7.3. Herramientas usadas ................................................................................ 19

7.4. Arquitectura del proyecto .......................................................................... 20

7.5. Metodología de desarrollo ........................................................................ 20

8. RESULTADOS OBTENIDOS .......................................................................... 23

8.1. Requisitos funcionales .............................................................................. 24

8.1.1 Definición de términos ........................................................................ 24

8.1.2 Funciones para la configuración del sistema ..................................... 24

8.1.3 Funciones relacionadas con el rol Planner......................................... 26

8.1.4 Funciones relacionadas con el rol de Maintainer ............................... 29

8.2. Requisitos no funcionales ......................................................................... 32

8.3. Diagrama Relacional ................................................................................ 32

8.4. Desarrollo del módulo de Administrador ................................................... 33

8.5. Desarrollo del módulo del Planner ............................................................ 37

8.6. Desarrollo del módulo del Maintainer ....................................................... 38

8.7 . Desarrollo de los triggers y funciones relacionadas con la base datos MySQL ............................................................................................................... 40

9. CONCLUSIONES ............................................................................................ 40

4

PROYECTO 2

1. DESCRIPCIÓN DEL PROYECTO .................................................................. 42

2. FORMULACIÓN DEL PROBLEMA ................................................................. 42

3. OBJETIVOS .................................................................................................... 43

3.1 Objetivo General ....................................................................................... 43

4.1 Objetivos específicos ................................................................................ 43

4. JUSTIFICACIÓN DEL PROBLEMA ................................................................ 43

5. CRONOGRAMA DE ACTIVIDADES ............................................................... 44

6. ENTREGABLES .............................................................................................. 44

7. MARCO CONCEPTUAL ................................................................................. 44

7.1 Metodología de desarrollo ........................................................................ 44

7.2 Herramienta de gestión del proyecto Trello .............................................. 54

7.3 Generador de información de prueba (EMS Data Generator for MySQL) 54

7.4 Librerías para graficar datos ..................................................................... 58

7.4.1 Librería Morris.js ................................................................................ 58

7.4.2 Librería Chart.js .................................................................................. 60

7.4.3 Librería HighChart .............................................................................. 63

7.5 AJAX y el manejo de JSON entre diferentes servidores ........................... 64

7.6 Jupyter Notebook ...................................................................................... 65

7.7 Arquitectura del proyecto .......................................................................... 65

7.8 Framework ................................................................................................ 65

7.9 Lenguajes usados ..................................................................................... 66

7.10 Herramientas usadas ................................................................................ 66

8. RESULTADOS OBTENIDOS .......................................................................... 66

8.1 Requerimientos funcionales ..................................................................... 66

8.2 Requerimientos no funcionales................................................................. 67

8.3 Análisis de datos (fuentes de datos: CNC Log, Sensor de vibraciones MONTRONIX) .................................................................................................... 68

8.4 Diagrama relacional .................................................................................. 69

8.5 Diseño de interfaces (Prototipos).............................................................. 70

8.5.1 Interfaz de home ................................................................................ 70

5

8.5.2 Interfaz de los sensores ..................................................................... 71

8.6 Algoritmo de inteligencia artificial para la predicción (Gaussian Mixtures)72

8.7 Aplicación PDMS ...................................................................................... 74

8.7.1 Login .................................................................................................. 74

8.7.2 Interfaz del home ............................................................................... 75

8.7.3 Interfaz de los sensores ..................................................................... 78

8.8 Testing ...................................................................................................... 80

9. CONCLUSIONES ............................................................................................ 85

10. REFERENCIAS ........................................................................................... 87

6

TABLA DE ILUSTRACIONES Ilustración 1. Clasificación de mantenimiento ........................................................ 14 Ilustración 2. Conexión entre el mantenimiento y la rentabilidad ........................... 15 Ilustración 3. Diagrama de flujo que ilustra la interacción de todas las entidades . 20 Ilustración 4. Diagrama del funcionamiento de Scrum ........................................... 21 Ilustración 5. Plantilla de seguimiento de los sprints utilizada en el proyecto ........ 22 Ilustración 6. Gráfico de horas de trabajo por día a lo largo del sprint ................... 23 Ilustración 7. Flujo de actividades relacionadas con el Planner ............................. 26 Ilustración 8. Pantalla inicial del Maintainer ........................................................... 29 Ilustración 9. Diagrama relacional de la base de datos ......................................... 33 Ilustración 10. Menú principal del módulo de administrador .................................. 34 Ilustración 11. Módulo de administrador, sección de lectura ................................. 34 Ilustración 12. Botón para acceder a la creación de la sección de lectura............. 35 Ilustración 13. Módulo de administrador, sección de creación ............................... 35 Ilustración 14. Índices para acceder a la sección de modificación y eliminación del registro ................................................................................................................... 36 Ilustración 15. Módulo de administrador, sección de actualización y eliminación .. 36 Ilustración 16. Asignación de actividades planificadas y de llamada ..................... 37 Ilustración 17. Asignación de competencias al momento de crear un registro EWO ............................................................................................................................... 38 Ilustración 18. Interfaz de control del Maintainer en una actividad planificada y de llamada .................................................................................................................. 38 Ilustración 19. Cierre de EWO, tipo de causa raíz ................................................. 39 Ilustración 20. Entorno de desarrollo MySQL Workbench ..................................... 40 Ilustración 21. Fases del modelo de prototipos evolutivos ..................................... 53 Ilustración 22. Fases del modelo de prototipos evolutivos ..................................... 54 Ilustración 23. Interfaz del generador de EMS ....................................................... 55 Ilustración 24. Sección de preferencias al inicio de la aplicación ........................... 55 Ilustración 25. Interfaz del generador de EMS, sección de configuración del servidor .................................................................................................................. 56 Ilustración 26. Interfaz del generador de EMS, selección de la base de datos y la tabla ....................................................................................................................... 57 Ilustración 27. Interfaz del generador de EMS, sección de configuración del servidor .................................................................................................................. 57 Ilustración 28. Tipos de gráficos desarrollados con Morris.js ................................. 58 Ilustración 29. CDN-hosted assets ........................................................................ 59 Ilustración 30. Paquete de la librería Morris.js ....................................................... 59 Ilustración 31. Script del gráfico ............................................................................. 60 Ilustración 32. Llamada del gráfico ........................................................................ 60 Ilustración 33. CDN’s disponibles de la librería Chart.js ........................................ 61 Ilustración 34. Paquete de la librería Chart.js ........................................................ 61 Ilustración 35. Llamada y creación del gráfico ....................................................... 62 Ilustración 36. Configuración del conjunto de datos .............................................. 62 Ilustración 37. Configuración del tipo de gráfico .................................................... 63 Ilustración 38. Librería tipo CDN ............................................................................ 63

7

Ilustración 39. Llamada del gráfico ........................................................................ 63 Ilustración 40. Código de la gráfica ........................................................................ 64 Ilustración 41. Configuración del httpd.config del Apache en local ........................ 64 Ilustración 42. Diagrama de relación de Jupyter .................................................... 65 Ilustración 43. Diagrama fuente de datos .............................................................. 69 Ilustración 44. Diagrama relacional de la base de datos........................................ 70 Ilustración 45. Prototipo de interfaz del home ........................................................ 71 Ilustración 46. Prototipo de interfaz de los sensores ............................................. 71 Ilustración 47. Librerías del algoritmo .................................................................... 72 Ilustración 48. Importación de los datos................................................................. 72 Ilustración 49. Creando el dataframe ..................................................................... 72 Ilustración 50. Función base del algoritmo ............................................................. 73 Ilustración 51. Gráfica de los clusters .................................................................... 73 Ilustración 52. Conjunto de datos a modelar .......................................................... 73 Ilustración 53. Llamado de función ........................................................................ 74 Ilustración 54. Login ............................................................................................... 74 Ilustración 55. Interfaz del Home ........................................................................... 75 Ilustración 56. Navbar ............................................................................................ 75 Ilustración 57. Sección de sensores y LogOut ....................................................... 76 Ilustración 58. Alertas del sistema ......................................................................... 76 Ilustración 59. Información importante de la gráfica .............................................. 76 Ilustración 60. Gráfico ............................................................................................ 77 Ilustración 61. Herramientas de la gráfica .............................................................. 77 Ilustración 62. Barra histórica de tamaño variable ................................................. 78 Ilustración 63. Interfaz sensor corriente ................................................................. 79 Ilustración 64. Límites de visualización de datos ................................................... 79 Ilustración 65. Gráfico de corriente ........................................................................ 80

8

TABLA DE TABLAS

Tabla 1. Cronograma de actividades ..................................................................... 16 Tabla 2. Requisitos funcionales ............................................................................. 24 Tabla 3. Requisitos funcionales relacionados con el módulo del Planner ............. 26 Tabla 4. Requisitos funcionales relacionados con el módulo del Maintainer ......... 29 Tabla 5. Requisitos no funcionales ........................................................................ 32 Tabla 6. Cronograma de actividades ..................................................................... 44 Tabla 7. Cuadro comparativo de metodologías de desarrollo aplicables al proyecto ............................................................................................................................... 46 Tabla 8. Requerimientos funcionales ..................................................................... 66 Tabla 9. Requerimientos no funcionales ................................................................ 68 Tabla 10. Caso de prueba del navbar de las interfaces ......................................... 81 Tabla 11. Caso de prueba de las alertas en la interfaz del home .......................... 82 Tabla 12. Caso de prueba de los cuatros con información relevante .................... 83 Tabla 13. Caso de prueba de los gráficos ............................................................. 84

9

AGRADECIMIENTOS

A Dios

Por guiar e iluminar mi camino

A mis padres

Por su amor, comprensión y apoyo incondicional

A mi hermana

Por su amor y apoyo incondicional para alcanzar mis metas

A mis amigos y compañeros

Por su compañía, aliento en cada momento

A mi director de tesis M.Sc. Alonso Toro Lazo

Por su orientación, conocimiento y apoyo durante esta labor

10

RESUMEN

En la actualidad, la producción en masa es fundamental para competir en la industria de manufactura, razón por la cual se empezaron a automatizar gran parte de sus procesos productivos gracias a la aparición de las tecnologías de la industria 4.0. Aunque esta estrategia resolvió muchas de las necesidades de estas grandes empresas, dio paso a que surgieran nuevas problemáticas que impactan directamente el núcleo de producción, tales como la degradación o desgaste de las máquinas y la aparición de fallas relacionadas con las mismas.

Con la intención de aportar a la solución de estos problemas, se presenta en este documento el análisis y desarrollo de dos herramientas de software que contribuyen al mejoramiento continuo del proceso productivo de cara a la industrialización inteligente, puesto que con ellos se soporte a las actividades de mantenimiento de maquinaria industrial como actividad clave para evitar la degradación de los activos industriales. La primera se relaciona con la planificación y ejecución de actividades de mantenimiento planificado y no planificado; mientras que la segunda aporta a la visualización de datos para un sistema de mantenimiento predictivo. Palabras clave: Aprendizaje de máquina, Desarrollo evolutivo prototipado, Industria 4.0, Internet de las cosas, Mantenimiento profesional.

ABSTRACT

Nowadays, mass production is essential to compete in the manufacturing industry, which is why they began to automate a large part of their production processes thanks to the emergence of Industry 4.0 technologies. Although this strategy solved many needs of these large companies, it gave way to the emergence of new problems that directly impact the production core, such as the degradation or wear of the machines and the appearance of failures related to them.

With the intention of contributing to the solution of these problems, this paper presents the analysis and development of two software tools that contribute to the continuous improvement of the production process in the face of intelligent industrialization, since they support the maintenance activities of industrial machinery as a key activity to prevent the degradation of industrial assets. The first one is related to the planning and execution of planned and unplanned maintenance activities; while the second one contributes to the visualization of data for a predictive maintenance system. Key words: Evolutionary development prototyping, Internet of things, Industry 4.0, Machine learning, Professional Maintenance, SCRUM.

11

INTRODUCCIÓN

Las máquinas y equipos industriales son productos cuyo rendimiento operativo inevitablemente se deteriora con el tiempo [1] ya que funcionan a largo plazo bajo ciertas condiciones de estrés o carga extrema en el entorno de fabricación. Este deterioro, también llamado degradación, a menudo se lleva a cabo a fallos en los componentes de la máquina, máquinas enteras o incluso líneas de producción. Al alcanzar un grado crítico de degradación, los componentes o subsistemas de bajo rendimiento pueden fallar y poner en riesgo la seguridad del sistema [2].

Aunque sólo ciertas fallas causarán graves riesgos en productividad y seguridad, la mayoría de las fallas conducen a averías disruptivas, inconvenientes y costosas y pérdida de calidad [3]. El impacto de la falla en una máquina crítica es un enorme riesgo para los costos de tiempo de inactividad y, a su vez, se convierte en un cuello de botella en las operaciones logísticas de producción [4].

Según Chan et al.[3], en la mayoría de los casos, hay un proceso medible de degradación antes de que una máquina falle. Según ha explicado el autor, a lo largo de su vida útil, la máquina puede degradarse continuamente hasta alcanzar una condición en la que es posible observar una caída en su nivel de rendimiento, momento desde el que pueden producirse defectos incipientes o fallos iniciales debido al progreso de la degradación. La proliferación continua de estos defectos aumenta gradualmente la gravedad, haciendo que la máquina no realice su función correctamente y falla.

Los errores, por su parte, se pueden definir como cualquier cambio o anomalía en el sistema que cause un nivel de rendimiento insatisfactorio [3]. Por lo tanto, el mantenimiento se ha introducido como una manera eficiente de asegurar un nivel satisfactorio de fiabilidad durante la vida útil de un activo físico [5], así como su disponibilidad [6].

En la industria manufacturera, el mantenimiento consiste en llevar a cabo todas las acciones necesarias para restaurar el equipo duradero o mantenerlo en condiciones de funcionamiento específicas [7], ya que el equipo está destinado a durar mucho tiempo y, por lo tanto, debe mantenerse. En este sentido, el propósito del mantenimiento es maximizar la eficacia de las máquinas.

Con la introducción de tecnologías de la Industria 4.0 como internet de las cosas (IoT), Big Data y sistemas ciber-físicos (CPS), surgen nuevas oportunidades de mantenimiento en fábricas en red con la disponibilidad de datos masivos de procesos, máquinas y sistemas. Esto permite a los operadores (o incluso a los sistemas de programación inteligentes) supervisar las condiciones de la maquinaria en lugar de sus fallos, anticipando así posibles fallos y optimizando la utilización de los activos [8].

Como parte del proyecto Smart Industry 4.0 y obedeciendo al pilar técnico de la metodología World Class Manufacturing (WCM) denominado “Mantenimiento

https://www.zotero.org/google-docs/?5p7EN5

https://www.zotero.org/google-docs/?DYTrXL

https://www.zotero.org/google-docs/?DYTrXL

12

Profesional”, se establece la necesidad de llevar a cabo actividades encaminadas a reducir las fallas y micro-paradas de máquinas industriales en las plantas de manufactura del sector automotriz italiano, de manera que se pueda mejorar la productividad y extender el ciclo de vida de las máquinas mediante el uso de prácticas de mantenimiento preventivas, correctivas y predictivas, que contribuyan a obtener ahorros económicos.

Para lograr lo anterior, se plantea el desarrollo de diferentes aplicativos software que soporten la planificación, ejecución y control de diversas actividades relacionadas con las labores de mantenimiento de diferentes activos, principalmente de maquinaria y equipos de manufactura. Como parte de esta iniciativa, se presenta a continuación dos proyectos de desarrollo de software: el primero, denominado Professional Maintenance App está relacionado con la planificación y control de la ejecución de actividades de mantenimiento planificado y no planificado; el segundo, denominado Predictive Maintenace App consiste en una interfaz de visualización de datos en la cual se puedan presentar los resultados de un algoritmo de análisis de datos ejecutado mediante técnicas de Inteligencia Artificial o Machine Learning, para conocer el estado de salud de las máquinas y predecir posibles anomalías o fallas.

13

PROYECTO 1: Professional Maintenance App

1. DESCRIPCIÓN DEL PROYECTO

El proyecto consiste en el desarrollo de una aplicación web responsive que permita la gestión, planificación y registro de ejecución de las actividades de mantenimiento preventivo y correctivo a través de una herramienta portátil de entrada de datos. Las actividades a gestionar son las siguientes:

1. Actividad programada (mantenimiento planificado) 2. Actividad no programada (mantenimiento no planificado)

a. Atención de Daños (Emergency Work Order - EWO) b. Actividades Extra

3. Cierre de orden de trabajo de emergencia (EWO)

Para ello, la aplicación debe hacer uso de una base de datos en la que se puedan registrar las actividades relacionadas con el mantenimiento, exponiendo una interfaz intuitiva y fácil de usar que admita los diferentes roles involucrados en el proceso (Planificador, Mantenedor, Administrador) y de soporte al ciclo de gestión de un proceso de mantenimiento de maquinaria. Los módulos que hacen parte de la aplicación se listan a continuación:

a. Módulo de administración (Rol Administrador) b. Módulo de asignación de actividades planificadas (Rol Planificador) c. Módulo de registro de ejecución de actividades planificadas (Rol

Mantenedor) d. Módulo de gestión de actividades no planificadas (Planificador)

i. Módulo de ejecución de EWO (Mantenedor) ii. Módulo de cierre de EWO (Mantenedor)

2. FORMULACIÓN DEL PROBLEMA

En un mundo impulsado por el capitalismo, en donde la producción de elementos a gran escala es fundamental para el sostenimiento de la economía global, se hace evidente el uso de herramientas tecnologías que apoyan y aumentan la productividad. Por lo anterior, muchas empresas de manufactura alrededor del globo optaron por la automatización de líneas de producción grandes y complejas como lo son las productoras de automóviles a gran escala. Aunque la producción automatizada resuelve algunas necesidades de las grandes empresas, surgen nuevos elementos importantes que impactan directamente la fabricación y tiene que ver específicamente con las máquinas. Siguiendo la premisa anterior, es necesario mencionar el mantenimiento como elemento fundamental, no solo para mantener el equipo en condiciones funcionales sino para evitar problemas a corto, mediano y largo plazo que amenazan la

14

productividad y que esto se traduce principalmente en pérdidas económicas para la empresa.

Una vez resaltado el mantenimiento como elemento principal, es necesario entrar a definir este concepto y su impacto en la rentabilidad de la producción, con el fin de dejar claro el objeto de estudio. Según Blanchard [9], el mantenimiento se define como todos los requerimientos y acciones esenciales que son necesarias para mantener un sistema dentro de su ciclo de vida en una condición funcional y completamente operativa, o restaurar su estado para que pueda realizar la función para la que fue creada. Además, Blanchard [9], clasifica el mantenimiento en dos grandes áreas, el mantenimiento preventivo, que se refiere a todas las acciones planeadas, como por ejemplo las inspecciones periódicas, la condición de monitorización, etc. Y el mantenimiento correctivo que incluye todas las acciones no planeadas para restaurar una falla; como se muestra a continuación en la (Ilustración 1) [10].

Ilustración 1. Clasificación de mantenimiento

Fuente: [10]

Ahora bien, Alsyouf [11], relaciona la rentabilidad como producto de la

productividad y la estrategia de recuperar los gastos de la producción con los precios. Entonces, la productividad se podría decir que es el resultado de la eficiencia y eficacia del proceso de producción como lo determina Enofe [12]; Por lo tanto, como las mejoras de mantenimiento tiene como objetivo tanto reducir los costos de operación como mejorar la calidad de producto, Alsyouf [11], indica que la rentabilidad de cada acción de mejora puede analizarse mediante la evaluación de la restricción de costos relevantes antes y después de las mejoras; con el fin de mostrar la conexión entre el mantenimiento y la rentabilidad se expone la (Ilustración 2) [13].

15

Ilustración 2. Conexión entre el mantenimiento y la rentabilidad

Fuente: [13]

3. OBJETIVOS

3.1. Objetivo General

Desarrollar los módulos de administrador y mantenimiento no planificado de la aplicación denominada “Smart Maintenance”, aplicando buenas prácticas de programación e ingeniería software.

3.2. Objetivos específicos

● Codificar la funcionalidad de los módulos de acuerdo con los requisitos establecidos.

● Realizar el proceso de testing para asegurar la calidad del software desarrollado.

● Documentar el proceso de desarrollo del software de acuerdo con la metodología seleccionada.

4. JUSTIFICACIÓN DEL PROYECTO

Partiendo de la estrategia del mantenimiento como elemento fundamental en las empresas para ahorrar capital y aumentar la producción a escala, es necesario hacer un estudio profundo con el fin de mejorar la forma en la que se realiza, más aún, con la forma en la se implementa la tecnología de cara a la automatización de procesos, en ese orden de ideas, es fundamental aplicar elementos que guíen el

16

proceso de detección, asignación, corrección y puntuación de errores a corto y largo plazo de un sector productivo de una empresa; pues son estas las ayudas que apoyan el desarrollo ágil de producción de cualquier compañía y abren paso a la evolución de los sectores productivos del mercado actual. Por lo tanto, tener formalizado el dónde, cuándo y quién va a resolver una falla o realizar un mantenimiento se hace realmente importante para aumentar la productividad y eficacia de cualquier sector productivo, específicamente en el área de la manufactura; en este sentido, se plantea un software que permita el control, asignación y verificación de cualquier actividad relacionada con el mantenimiento planeado y no planeado.

5. CRONOGRAMA DE ACTIVIDADES

El desarrollo del proyecto se llevó a cabo de acuerdo con la siguiente planeación de actividades, establecidas en concordancia con la metodología de desarrollo indicada.

Tabla 1. Cronograma de actividades

DESCRIPCIÓN S1

S2

S3

S4

S5

S6

S7

S8

S9

S10

S11

S12

Introducción al proyecto a desarrollar

Reconocimiento de la estrategia pedagógica y herramientas

Desarrollo del aplicativo

Estudio de los requisitos

Diseño de los módulos

Programación de los módulos

Pruebas y ajustes

Documentación del software

Documentación del proyecto de grado

6. ENTREGABLES DEL PROYECTO

● Módulo de administrador de acuerdo a los requisitos funcionales establecidos.

● Módulo de mantenimiento no planificado de acuerdo a los requisitos funcionales.

● Manual de usuario de la aplicación ● Documentación relacionada (manual de instalación y configuración del

framework, implementación de la metodología ágil seleccionada para el proyecto)

17

7. MARCO CONCEPTUAL

Con el objetivo de cumplir con el desarrollo de los módulos propuestos en la sección de objetivos y entregables del proyecto, se realizó un ejercicio de investigación exhaustiva para centralizar todas las posibles tecnologías y herramientas necesarias para el desarrollo del proyecto en cuestión; Siguiendo la idea anterior, se nombrarán y explicarán breve y concisamente aquellas tecnologías, herramientas, arquitecturas y metodologías de desarrollo usadas.

7.1. Framework

Este framework está desarrollado por el ingeniero Rosario Carvello, un desarrollador de software italiano el cual publicó el paquete con formato de código abierto en la plataforma de GitHub; La función más significativa que ofrece el framework es el desarrollo basado en componentes, esto facilita aplicar otro nivel tanto de descomposición como de reutilización de software y ofrece herramientas puntuales que agregan valor a aspectos relacionados a MySQL, como son: “beans” que contribuyen al manejo de datos entre el framework y la base de datos, lista de datos, orden de los datos, filtros, paginación, manejo de registros, y las operaciones comunes de CRUD (Create, Read, Update, Delete). [14]

Según Carvello [14], Webmvcframework, es un potente framework

PHP orientado a objetos, ideal para diseñar y desarrollar aplicaciones web. Este framework es realmente eficaz en proyectos web pequeños y medianos en referencia a aplicaciones web intensivas de datos, sitios, aplicaciones web y API’s web.

Carvello [14], define los siguientes conceptos de su framework

WebMVC: ● Conjunto de modelos, supuestos y prácticas que juntas constituyen

una manera de construir y constituir un software. ● Un sistema de software que se pretende instanciar para:

○ Definir la arquitectura para sus subsistemas y proporcionar la base de construcción para su creación.

○ Definir donde se realiza y ejecuta las adaptaciones para una funcionalidad en específico.

En este ejercicio de definición del framework, Carvello [14] también

menciona las siguientes características principales de WebMVC: ● Proporciona un conjunto de funcionalidades para organizar la

aplicación basadas en la arquitectura Modelo-Vista-Controlador (MVC) con el fin de separar las responsabilidades en cuanto a negocio, interfaz y procesamiento.

● Separar una aplicación en subsistemas con el objetivo de solucionar problemas complejos de proyectos grandes.

18

● Evita la mezcla de lenguajes de programación del lado del cliente, como HTML, CSS y JavaScript necesarios para la construcción de una aplicación web, y lenguajes de programación del lado del servidor como MySQL. Este proceso mejora el proceso de colaboración entre personas con diferentes conocimientos.

● Proporciona la generación automática de código ORM mediante el uso de ingeniería inversa de un esquema de base de datos Mysql proporcionado.

● Componentes de software listos para ser usados en la solución de problemas recurrentes en el desarrollo web.

● Soluciones preconstruidas y personalizables para el desarrollo rápido y eficaz de funcionalidades frecuentes en una aplicación web como es la autenticación, gestión de usuarios y control de acceso con roles.

7.2. Lenguajes de programación utilizados

Aclarando que la aplicación desarrollada está enfocada en desarrollo web, se hace indispensable el uso de herramientas FRONTEND como HTML5, CSS y JAVASCRIPT junto con AJAX, pues sin estas, el desarrollo de las interfaces presentadas en este informe no sería posible; En cuanto al BACKEND se utilizaron herramientas como PHP y MySQL, como fundamento que permitió la correcta realización de cada uno de los requerimientos del proyecto con alto enfoque en la gestión de la información referente a la aplicación; A continuación se definirán amenamente los lenguajes, con el fin de centralizar los conceptos abordados en este ejercicio de desarrollo.

● HTML: Es un lenguaje de hipertexto, que hace referencia a los enlaces que conectan páginas web entre sí. Se conoce como el componente base del desarrollo web, y maneja la estructura del contenido en web. En acción, este elemento se distingue de los demás por la forma de etiquetar el texto en forma de árbol. [15]

● CSS: Según W3C [15], Cascading Style Sheets(CSS), es un mecanismo simple para dar diseño a documentos web HTML y XML (e.g., fuentes, colores, espaciado, etc).

● JAVASCRIPT: Según W3C [16], un script es una sección de código del programa que no necesita ser preprocesador antes de ser ejecutado. Hablando más en web, este script es un programa escrito vía JavaScript que el navegador ejecuta cuando se descarga una página o en el momento en que reciba respuesta de un evento que provoque el usuario; estos scripts pueden hacer que en tiempo real la página modifique contenido de la misma (Dynamic HTML), añada o envíe contenido de ella (JavaScript and XML-AJAX).

● PHP: Según PHP [17], es un lenguaje de programación de código abierto especializado para el desarrollo web y con alta escalabilidad en lenguajes de hipertexto como HTML. Una diferencia respecto al

19

lado del cliente como puede ser JavaScript es que todo se ejecuta en el servidor y se envía al cliente, el cliente recibe el resultado de este código al ejecutar un script vía JavaScript, sin embargo, no sabrá el código subyacente que era.

7.3. Herramientas usadas

El entorno de desarrollo utilizado por el estudiante fue Visual Studio Code, pues su simpleza y orden de los elementos que conforman el proyecto facilitan el acceso, comprensión y desarrollo del mismo. Para la administración de la base de datos MySQL sobre el aplicativo, se usó los servicios de Apache y MySQL simulados con XAMPP; Finalmente, se utilizó el sistema de gestión de versiones Git como parte de la gestión de configuración que permitió el desarrollo colectivo y otorgó un historial de cambios y pruebas que se iban realizando a lo largo del proceso de desarrollo del proyecto. Para aterrizar conceptos, se presentarán los conceptos nombrados anteriormente:

● VISUAL STUDIO CODE: Según VSC [18], es un editor de código

bastante ligero y potente que se ejecuta en escritorio, está disponible para Linux, Windows y macOS. Tiene soporte incorporado para JavaScript, TypeScript y Node.js, además, hay un extenso ecosistema de lenguajes (e.g., C++, C#, Java, Python, PHP, Go) y en tiempo de ejecución (.NET y Unity).

● MYSQL: Según MySQL [19], es un sistema de manejo de base de datos de código abierto, distribuida y con soporte de Oracle Corporation. Con el fin de añadir, acceder y procesar datos almacenados en una base de datos informática, se necesita un sistema de gestión de base de datos como MySQL Server; finalmente estas bases de datos MySQL son relacionales y se conocen por ser rápidas, escalables y fácil de usar.

● APACHE: Según Apache [20], es un servidor HTTP desarrollado con el fin de crear una implementación de código fuente de un servidor HTTP (web), de calidad, comercial, con muchas características y disponibilidad gratuita.

● XAMPP: Según Apache Friends [21], XAMPP es una distribución fácil de instalar que simula un servidor web de Apache que además combina elementos como MariaDB, PHP y Perl.

● GIT: Según Git [22], es un sistema de control de versiones distribuido, de código abierto, diseñado para manejar cualquier clase de proyectos y gratuito. Esta herramienta resalta por tener características como ramificación local, barata, cómoda y con múltiples flujos de trabajo.

20

7.4. Arquitectura del proyecto

El estilo de arquitectura de software ligada al proyecto es el Modelo Vista-Controlador (MVC), este patrón se encarga de separar la interfaz y el controlador en varios componentes, por lo tanto, se tiene que cada módulo cuenta con vista, modelo, controlador y una sección adicional del framework que permite mejorar la interacción con la vista llamada templates (todo el contenido HTML5 y JAVASCRIPT). [14]

Ilustración 3. Diagrama de flujo que ilustra la interacción de todas las entidades

Fuente: [14]

7.5. Metodología de desarrollo

La metodología de desarrollo ágil Scrum se enfoca principalmente en el control de procesos empírico. En este enfoque el empirismo es el encargado de asegurar que el conocimiento se de a partir de la experiencia y toma de decisiones

21

desde lo que se conoce. Entonces, Scrum aplica un enfoque iterativo e incremental que optimiza la predictibilidad y el control de los riesgos en acción. A continuación, se presenta el diagrama del funcionamiento en el que se visualizan todas las partes de la metodología y su secuencia de ejecución. [23]

Ilustración 4. Diagrama del funcionamiento de Scrum

Fuente: [23]

Con el fin de llevar a cabo una correcta implementación del control de

procesos empírico, Scrum usa tres pilares fundamentales, los cuales son:

● Transparencia: Este elemento hace referencia que todos los procesos desarrollados con esta metodología deban ser definidos por un estándar común que permita que todos los observadores compartan el entendimiento de lo que se está realizando. [23]

● Inspección: Todos aquellos usuarios de Scrum deben frecuentemente realizar una revisión de los artefactos de la metodología y asegurarse que el objetivo no lleve variaciones indeseadas; Entonces, el trabajo de inspección, aunque debe ser riguroso no debe ser tan frecuente como para interferir en el trabajo que se realiza y debe ser realizada de forma diligente por inspectores expertos. [23]

● Adaptación: De acuerdo al proceso de inspección, el inspector puede determinar si el proceso que se está desarrollando se está desviando de sus límites y esto afectará negativamente el producto final, en este caso debe realizarse un ajuste inmediato para minimizar desviaciones mayores del proceso. [23]

22

Scrum [23], abarca cuatro eventos dentro del Sprint (Bloque de tiempo en el que se crea un producto utilizable y potencialmente desplegable) que llevan correctamente estos pilares mencionados:

● Planificación del Sprint (Sprint Planning) ● Scrum diario (Daily Scrum) ● Revisión del Sprint (Sprint Review) ● Retrospectiva del Sprint (Sprint Retrospective)

Con la finalidad de centralizar los roles abarcados en el desarrollo de este

proyecto, se mencionan los actores que son necesarios para el despliegue de la metodología Scrum [23], los cuales son conocidos como “El Equipo Scrum (Scrum team)”; estos actores son:

● El dueño del producto (Product Owner): Es el responsable de maximizar el valor del producto y el trabajo del equipo de desarrollo.

● El equipo de desarrollo (Development Team): Son los profesionales encargados de realizar el trabajo de entregar un incremento de producto “Terminado” que se pueda poner en producción al final de cada Sprint.

● El Scrum Master: Responsable de asegurarse que el entienda y se adopte la metodología al proceso del desarrollo del producto.

Ilustración 5. Plantilla de seguimiento de los sprints utilizada en el proyecto

23

Ilustración 6. Gráfico de horas de trabajo por día a lo largo del sprint

Siguiendo lo anterior, la metodología empleada para el desarrollo de

este proyecto fue SCRUM, el scrum master a cargo de M.sc. Alonso Toro Lazo y responsable de organizar reuniones constantes y ligeras que tenían como objetivo realizar la asignación, seguimiento y pruebas de las actividades que se debían cumplir, con el propósito de alcanzar cada requisito funcional propuesto. Este proyecto se desarrolló en alrededor de dos a tres sprints, cada sprint constaba de diez días, estos espacios estaban dirigidos completamente en el área de desarrollo de software, pues este fue el foco desde el planteamiento del proyecto desde el inicio (Ver Ilustración 5 y 6).

8. RESULTADOS OBTENIDOS

Antes de mostrar todos los resultados obtenidos de la etapa de desarrollo, cabe destacar que, respecto a las etapas del ciclo de vida del proyecto, esta intervención se enfocó en su mayoría en el área de la implementación, pues el proyecto ya había sido planteado con anterioridad y contaba con las etapas de requisitos, diseño e integración del software. Siguiendo la idea anterior, se abordaron los requisitos funcionales, mockups y el diagrama de la base de datos del sistema seguido de una revisión exhaustiva de los módulos entregados respecto al proyecto 1.

24

8.1. Requisitos funcionales

Antes de listar los requisitos funcionales del sistema, es importante aclarar que estos fueron suministrados como parte del análisis previo del proyecto, sin embargo, hacen parte fundamental del desarrollo.

8.1.1 Definición de términos

En esta sección, se encuentran los términos y palabras en inglés nombradas a continuación:

● Call(Call activity): Hace referencia a las actividades de llamada [24]. ● EWO: Orden de trabajo de emergencia, se genera cuando se produce

una avería no programada, y un activo necesita ser reparado de inmediato. Se utiliza para registrar y hacer un seguimiento de cualquier trabajo reactivo realizado que no haya sido planificado de antemano. Una vez finalizado el trabajo, el técnico de mantenimiento puede proporcionar información en la orden de trabajo sobre lo que ha ocurrido, por qué se ha producido la avería, que se ha hecho al respecto y qué se puede hacer para evitar que vuelva a ocurrir [24].

● Maintainer: Referente al mantenedor [24]. ● Planner: Referente al planificador [24].

8.1.2 Funciones para la configuración del sistema

Los requisitos de configuración de la aplicación hacen referencia a las capacidades que tiene el rol del Sistema de Administrador, de acuerdo con los requisitos FRSA, para el manejo de los usuarios que van a tener el acceso al sistema, también la información inicial que debe ser cargada en la base de datos del sistema. Las funciones cargadas principalmente en la base de datos se describen en los requisitos FRDB1 - FRDB6 [24].

Tabla 2. Requisitos funcionales

REQ-ID DESCRIPCIÓN

FRSA1 El Sistema de Administrador debe ser capaz de crear, ver, modificar o eliminar usuarios del sistema, asignarles nombre de usuario, contraseña, y especificarlos un rol; el rol puede ser: - Planner (maintenance manager) - Maintainer

FRDB1 El sistema debe permitir a un administrador del sistema manejar (crear, ver, modificar o eliminar) competencias relacionadas a una tarea en específico.

25

FRSA2 Para cada rol de Maintainer, el sistema debe permitir asignarle competencias específicas.

FRDB2 El sistema debe permitir administrar (crear, ver, modificar o eliminar) áreas, estas áreas están compuestas por sitios de la fábrica (sucursales) y área o departamento (interiores de fábrica).

FRDB3 El sistema debe permitir administrar (crear, ver, modificar o eliminar) materiales, que son usados durante la actividad de mantenimiento.

FRDB4 El sistema debe permitir administrar (crear, ver, modificar o eliminar) procedimientos de mantenimiento, para así indicarle al Maintainer el procedimiento que debe realizar de acuerdo a cada actividad de mantenimiento. Cada procedimiento de mantenimiento debe ser asociado a un Standard Maintenance Procedure (SMP) archivo en formato PDF.

FRDB5 Para cada procedimiento de mantenimiento, el sistema debe permitir asignarle la competencia específica requerida para realizar la actividad de mantenimiento.

FRDB6 El sistema debe permitir administrar (crear, ver, modificar o eliminar) una tipología de mantenimiento como por ejemplo: Eléctrica, electrónica, hidráulica o mecánica.

FRSA3 El sistema debe permitir administrar (crear, ver, modificar o eliminar) notas de espacio de trabajo (Opcional). Estas notas pueden ser asociadas a un área en específico o a todas las áreas.

FRA Todo el acceso a la aplicación debe ser registrada.

Fuente: [24]

26

8.1.3 Funciones relacionadas con el rol Planner

Ilustración 7. Flujo de actividades relacionadas con el Planner

Fuente: [24]

Un Planner puede realizar las siguientes acciones a través del sistema:

Tabla 3. Requisitos funcionales relacionados con el módulo del Planner

REQ-ID DESCRIPCIÓN

FRP1 El Planner debe ser capaz de gestionar (crear, ver, modificar o eliminar) Actividades de mantenimiento. Una actividad de mantenimiento puede realizarse en una línea o en una máquina fuera de servicio y puede ser:

- Planned activity - Un-planned activity (EWO) - Extra activity (an unplanned activity type)

27

FRP2 El sistema debe permitir ver la lista de las actividades de mantenimiento programadas ordenadas por semana.

Cada actividad debe ser seleccionable.

FRP3 Cuando el rol de Planner selecciona una actividad específica, el sistema debe permitir verificar la siguiente información: número de semana, actividad a asignar (ID de la actividad, aérea, tipología, tiempo estimado de intervención), notas del espacio de trabajo, descripción de la intervención (descripción de la actividad), SMP (Standard Maintenance Procedure) archivo en formato PDF relacionado a la intervención en específico, competencias (estas requeridas para realizar la intervención).

FRP4 Una vez la actividad en específico ha sido verificada, el sistema debe permitir asignar la actividad programada a un Maintainer en concreto.

El sistema debe permitir seleccionar entre los días de la semana que el Maintainer tenga disponibilidad.

En este punto, el sistema debe permitir seleccionar el espacio de tiempo disponible (asignación de horario en minutos) en donde la actividad de mantenimiento va a ser asignada y programada la actividad.

Cada Maintainer va a ser asignado con una o más actividades de mantenimiento.

FRP5 Cuando la actividad de mantenimiento es asignada de acuerdo con FRP5, el sistema debe enviar una notificación al perfil del Maintainer seleccionado con una copia al email del Production manager

28

FRP6 Cuando se selecciona un EWO en específico, el sistema debe permitir verificar la siguiente información: número de semana, fecha, actividad a asignar (ID EWO, área, tipología), notas de espacio de trabajo, interrupción de la actividad (Si, No).

El rol de Planner debe poder agregar la siguiente información: descripción de la intervención (descripción de la actividad), tiempo estimado de la intervención (en minutos), competencias (aquellas requeridas para realizar la intervención, este campo debe ser seleccionado de una lista de competencias predefinidas), materiales (aquellos usados durante el mantenimiento de la actividad, este campo debe ser opcional).

FRP7 Una vez que un EWO específico ha sido verificado y diligenciado (ver FRP6), el sistema debe permitir asignar la actividad no programada a un Maintainer en específico, de acuerdo a su disponibilidad.

El procedimiento es el mismo presentado anteriormente en el requisito RFP4 y RFP5 para actividades programadas, con la única diferencia que la información corresponde a la actividad EWO seleccionada.

Además de la información mostrada en el RFP4, para la EWO seleccionada la siguiente información debe ser mostrada en la pantalla: notas de espacio de trabajo y tiempo estimado de la intervención.

FRP8 Cuando una actividad EWO es asignada a un Maintainer en específico, la actividad que está realizando en ese momento debe ser interrumpida, siempre y cuando la actividad no sea interrumpible.

FRP9 Un Planner debe ser capaz de gestionar (crear, ver, modificar o eliminar) materiales necesarios para realizar la actividad de mantenimiento, al igual que FRSA5. (opcional)

FRP10 El sistema debe permitir al rol de Planner ver la lista de tickets asignados (EWO).

El estado del ticket puede ser:

29

● Para el área: recibido, enviado o no enviado. ● Para el Maintainer: enviado, recibido, leído. ● Estado general: no iniciado, en progreso, cerrado.

Fuente: [24]

8.1.4 Funciones relacionadas con el rol de Maintainer

Ilustración 8. Pantalla inicial del Maintainer

Fuente: [24]

Un Maintainer puede realizar las siguientes acciones a través del sistema:

Tabla 4. Requisitos funcionales relacionados con el módulo del Maintainer

REQ-ID DESCRIPCIÓN

FRM1 El sistema debe permitir al Maintainer ver la lista de las actividades de mantenimiento planificadas (FRP1).

FRM2 El sistema debe permitir seleccionar la actividad planificada sobre la que se realizarán las operaciones de mantenimiento, de la lista de actividades indicadas de acuerdo con FRM1.

Para la actividad seleccionada, debe abrirse una hoja en donde el Maintainer, una vez posicionado en la estación de trabajo (máquina)

30

puede empezar (a través de la aplicación), la actividad de mantenimiento.

FRM3 Cuando una actividad es interrumpible, el sistema debe permitir al Maintainer ver la lista de actividades no-planificadas asignadas. En el momento de realización de una actividad, la fecha/hora de finalización debe ser ejecutada, pausando el tiempo de ejecución de dicha actividad.

La detención de la actividad también puede ser realizada manualmente por el Maintainer.

Al reanudar una actividad que fue detenida anteriormente, la fecha/hora debe continuar contando el tiempo.

Esta funcionalidad debe estar desactivada para las actividades interrumpibles.

FRM4 Una vez el trabajo esté finalizado, el Maintainer debe indicar a través de la aplicación, la completitud de la actividad. Esto con la intención de contabilizar el tiempo utilizado para realizar la actividad.

Cuando se indica la completitud de la actividad, la aplicación debe mostrar la lista de actividades pendientes presentadas en FRM1.

FRM5 El sistema debe permitir al Maintainer ver la lista de asignación de las actividades de mantenimiento no planificado y actividades extra (FRP1).

FRM6 El sistema debe permitir seleccionar la actividad no planificada sobre la que se realizarán las operaciones de mantenimiento, desde la lista de actividades indicadas de acuerdo a FRM5.

Para la actividad seleccionada, debe abrirse una hoja en la cual el Maintainer, una vez está posicionado en la estación de trabajo (máquina)

31

puede empezar (a través de la aplicación), la actividad de mantenimiento.

FRM7 Cuando una actividad de mantenimiento no planificada es completada y Job1 verificado, el Maintainer debe indicar la finalización de la actividad a través de la aplicación.

Una vez indicada la finalización de la actividad, la actividad es registrada en la lista de EWO, para ser posteriormente cerrada.

La aplicación debe mostrar la lista de actividades interrumpidas pendientes presentadas en FRM5.

FRM8 Para cada hoja de actividad (FRM2 y FRM5), el sistema debe permitir ver los materiales usados durante la actividad de mantenimiento. (Opcional)

FRM9 El sistema debe permitir al Maintainer ver el resumen de las intervenciones EWO (FRM5) pendientes para ser cerradas al igual que su tiempo de abertura.

Después, el Maintainer debe seleccionar una de las siguientes causas raíces, relacionadas con la avería o fallo:

● CR1: External factors (Factores externos) ● CR2: Human error (Errores humanos) ● CR3: Design defect (Defectos de diseño) ● CR4: Insufficient maintenance (Poco mantenimiento) ● CR5: Wrong operating conditions (condiciones erróneas de

operación) ● CR6: Lack of basic conditions (Ausencia de condiciones básicas)

Finalmente, el Maintainer debe ingresar una descripción de las actividades llevadas a cabo y cerrar el EWO.

32

FRM10 Para cada hoja de actividad (FRM2, FRM5 y FRM9), el sistema debe permitirle grabar notas adicionales.

Fuente: [24]

8.2. Requisitos no funcionales

A continuación, están todas aquellas restricciones y requisitos no funcionales del sistema, estos no hacen parte de mí análisis, sin embargo, son parte de mí desarrollo.

Tabla 5. Requisitos no funcionales

REQ-ID TIPO DESCRIPCIÓN

NFR1 Usabilidad El sistema debe ser intuitivo y fácil de usar en un ambiente web.

RES1 Restricción El sistema debe ser programado en PHP conectado a una base de datos MySQL.

RES2 Restricción El sistema debe ser implementado bajo una arquitectura MVC.

Fuente: [24]

Para conocer más sobre los requisitos y ver los mockups diseñados en esta sección, dirigirse al anexo [17].

8.3. Diagrama Relacional

A continuación, se muestra el diagrama entidad relación desarrollado para el sistema de información.

https://www.zotero.org/google-docs/?QsEfTO

33

Ilustración 9. Diagrama relacional de la base de datos

Fuente: [24]

8.4. Desarrollo del módulo de Administrador

En esta sección se hará un recorrido breve por las interfaces desarrolladas, con el fin de mostrar los resultados obtenidos en el módulo de administrador, este módulo visto a gran escala es un CRUD general a cargo del administrador, este tiene un impacto directo con la base de datos que nutre la aplicación. Todos los submódulos que hacen parte del administrador siguen el mismo diseño de interfaces, por lo tanto, se utilizará como ejemplo el módulo que administra las competencias de los Maintainers, sin embargo, cabe aclarar que todos fueron desarrollados y se encuentran completamente funcionales.

34

Ilustración 10. Menú principal del módulo de administrador

El menú principal del módulo de administración cuenta con un navbar de cuatro (4) botones que siguen la siguiente estructura, primero el home que siempre redireccionará a la página que se muestra en la (Ilustración 10), luego se encuentran los diez (10) módulos que conforman la sección de administrador, un botón de configuración que permite cambiar el idioma (Inglés o Italiano), esto gracias al control de variables asignables implementado por el framework, y por último se encuentra el botón de salida, fundamental para que el usuario pueda realizar el proceso de logout.

Ilustración 11. Módulo de administrador, sección de lectura

35

Los módulos desarrollados en la sección de lectura de los datos siguen la siguiente estructura, Un formulario de búsqueda desarrollado utilizando el componente “searcher” que facilita el framework, esta sección del formato cuenta con los campos listados en la tabla que muestra todos los registros, permitiendo filtrarlos a partir de la búsqueda. Luego se encuentra el listado de todos los registros, esta sección cuenta con componentes como “Datarepeater”, “Sorter” y “Paginator”, el primero es el encargado de hacer la tabla de registros, el segundo organiza la columna en orden ascendente o descendente, por número de ID y por la primera letra, y el tercero permite viajar por las páginas de la tabla además de mostrar el total de registros (Ver ilustración 11).

Ilustración 12. Botón para acceder a la creación de la sección de lectura

Ilustración 13. Módulo de administrador, sección de creación

Una vez presionado el botón de superior de la tabla de registros (Ver ilustración 12), se ejecuta un componente del framework denominado “Record”, este componente permite hacer los procesos de CRUD en la base datos, este botón netamente se refiere a la sección de creación del registro a disposición del administrador (Ver ilustración 13).

36

Ilustración 14. Índices para acceder a la sección de modificación y eliminación del registro

Ilustración 15. Módulo de administrador, sección de actualización y eliminación

Al presionar directamente en los números azul-celeste de la tabla de registros

(usualmente es el id) (Ver ilustración 14), este llama el componente denominado “Record” que trae todos los datos referentes a ese registro y permite realizar los procesos de actualización y eliminación del registro (Ver ilustración 15).

37

8.5. Desarrollo del módulo del Planner

Ilustración 16. Asignación de actividades planificadas y de llamada

Para cumplir con el requisito de la asignación de actividades planificadas y de llamada, se desarrolló la sección del procesamiento respecto al manejo del tiempo al realizar una asignación de una actividad tanto planificada (planned activities) como de llamada (call activities), siguiendo lo anterior, este muestra el porcentaje disponible de los días de semana (Lunes a Sábado) y le asigna un color respectivo de acuerdo con el porcentaje (disponibilidad del Maintainer para realizar la actividad).

En el momento en que se selecciona un día se muestran las horas del día con la misma siguiendo el mismo ejercicio del código de colores cuando se encuentra disponible, medianamente disponible o ocupado, en este caso verde, amarillo o rojo respectivamente, en el momento de seleccionar la hora requerida, se abre otra sección con los minutos referentes a esa hora seleccionada, en dónde a partir de la disponibilidad del Maintainer se le asignará la tarea en específico (Ver ilustración 16).

38

Ilustración 17. Asignación de competencias al momento de crear un registro EWO

En la sección de registro de un nuevo EWO, se desarrolló el módulo de

selección de las competencias seleccionadas por el usuario para el registro en cuestión, en este módulo hay un campo denominado “Competences needed” el cual es un elemento de selección múltiple. Al ser seleccionadas se guardan en un array que luego se ingresa al registro EWO (Ver ilustración 17).

8.6. Desarrollo del módulo del Maintainer

Ilustración 18. Interfaz de control del Maintainer en una actividad planificada y de llamada

En esta sección, se organizó el envío y traída de los tiempos usados en los campos de “Start”, “Stop” y “Job1” para el módulo de actividad de llamada “On call

39

activity”; en el módulo de actividades planificadas se organizaron los campos “Start”, “Stop” que deben cumplir la misma tarea mencionada anteriormente. Finalmente, se trabajó en el botón de actividades de emergencia, esta muestra al mantenedor en tiempo real las actividades de emergencia disponibles (Ver ilustración 18).

Ilustración 19. Cierre de EWO, tipo de causa raíz

En el módulo de cierre de EWO, se implementó la interfaz de selección única

de la causa raíz, actividad necesaria para lograr la culminación y el envío del formulario de la actividad EWO. (Ver ilustración 19).

40

8.7 . Desarrollo de los triggers y funciones relacionadas con la base datos MySQL

Ilustración 20. Entorno de desarrollo MySQL Workbench

Con la finalidad de concluir algunos requisitos funcionales en relación con la

base de datos, se usó la herramienta MySQL Workbench para diseñar elementos como triggers y funciones que desde una mejor interfaz de programación respecto a la de PHPMYADMIN, permitió organizar mejor las ideas y la lógica de programación; en esta sección también se desarrollaron los triggers necesarios para tener el registro de seguridad con relación a los cambios realizados en la base de datos, además funciones que se llaman desde el proyecto con el fin de realizar tareas acordes a los requisitos planteados. (Ver ilustración 20).

9. CONCLUSIONES

De acuerdo a los resultados obtenidos y las metodologías utilizadas se puede concluir que:

● La exploración de herramientas es un ejercicio necesario para el correcto planteamiento de las tareas, además, deja claro el objeto de estudio y contribuye al aprendizaje predesarrollo que mejora la realización de los requisitos.

● La utilización de una metodología de desarrollo para la realización de un proyecto es esencial, esta permite seguir una línea guía de objetivos y controlar su desarrollo constantemente, sin duda es

41

fundamental para evitar el derroche de recursos y pausas prolongadas.

● Aunque los conceptos preconcebidos en la formación académica toman un papel fundamental en el momento del desarrollo de un proyecto, se concluye que, por la naturaleza de la carrera y la exigencia de los proyectos, existen vacíos que le corresponden netamente al estudiante llenar por su cuenta.

● Siempre existe la posibilidad de realizar cambios en aspectos pequeños de los requerimientos con el fin de mejorar y ajustar la estructura del proyecto.

● Llevar un orden en la codificación y el control de las versiones es primordial para llevar un desarrollo saludable del proyecto, principalmente cuando intervienen varios actores en su desarrollo.

42

PROYECTO 2: Predictive Maintenance App

1. DESCRIPCIÓN DEL PROYECTO

El proyecto consiste en el desarrollo de una interfaz de visualización de datos, a manera de tablero de control, en la cual se presentan los resultados de un algoritmo de análisis de datos ejecutado mediante técnicas de Inteligencia Artificial o Machine Learning para conocer el estado de salud de las máquinas y predecir posibles anomalías o fallas. Esto permitirá adoptar las acciones de mantenimiento preventivo correspondientes y tomar decisiones más efectivas basadas en datos que se reciben en tiempo real. Los detalles del sistema de información serán presentados en fases posteriores del proyecto, de acuerdo con la metodología de desarrollo ágil adoptada.

2. FORMULACIÓN DEL PROBLEMA

En un mundo completamente globalizado y con una alta influencia de IoT, se abren las posibilidades de conectar objetos de cualquier tipo entre sí, esto hace posible el acceso a datos de estos objetos de manera masiva; esta enorme cantidad de datos por sí sola no representa nada significativo para una persona, sin embargo, con el procesamiento correcto, pueden llegar a convertirse en una fuente de ingresos importante para cualquier sector productivo. Por otro lado, dada la naturaleza del mundo capitalista y la automatización de las industrias como elemento evolutivo para lograr suplir el fenómeno de oferta y demanda, elementos como el mantenimiento toman un papel fundamental, no solo para mantener el equipo en condiciones funcionales sino para evitar problemas a corto, mediano y largo plazo que amenazan la productividad y que esto se traduce principalmente en pérdidas económicas para la empresa.

Siguiendo las ideas mencionadas anteriormente, se abre una oportunidad de implementación de dispositivos capaces de capturar datos específicos con relación a las máquinas implementadas en los procesos industriales que mueven las fábricas. Estos datos deben ser procesados por elementos de Machine learning capaces de brindar como resultado información relevante a las industrias, información que permita mejorar los procesos productivos y principalmente que se enfoque en la detección temprana de cualquier tipo de problema mecánico u electrónico relacionado directamente con las máquinas de las que se toma la información base. [25]

43

3. OBJETIVOS

3.1 Objetivo General

Desarrollar una interfaz de visualización de datos que facilite el mantenimiento predictivo de equipos industriales, aplicando buenas prácticas de ingeniería software.

4.1 Objetivos específicos

● Realizar la identificación de los requerimientos necesarios para el desarrollo del proyecto.

● Diseñar la arquitectura del sistema de información y las interfaces de usuario. ● Codificar la funcionalidad de los módulos de acuerdo con los requisitos

establecidos. ● Realizar el proceso de testing para asegurar la calidad del software

desarrollado. ● Documentar el proceso de desarrollo del software de acuerdo con la

metodología seleccionada.

4. JUSTIFICACIÓN DEL PROBLEMA

Gracias a los avances tecnológicos respecto a las redes de comunicación y tecnologías como el IoT que cogen cada vez más fuerza, la implementación de dispositivos integrados capaces de recolectar información en plantas de producción y máquinas es cada vez más fácil y económica, en este sentido surgen nuevas posibilidades de detección de anomalías y predicción de fallos que afectan los planes de mantenimiento. Aquí es cuando entra el concepto de mantenimiento predictivo, elemento que usa la información resultante de un procesamiento de datos, proveniente de todos aquellos datos recolectados por los sensores de las máquinas con el objetivo de detectar los próximos fallos antes de que se produzcan y lograr programar acciones correctivas o de mantenimiento que alargue la vida útil de estos equipos; lo mencionado anteriormente, se traduce en un alto ahorro de costos tanto de mano de obra como de maquinaría para una industria. [25]

Siguiendo la idea anterior, y con el objetivo de contribuir a la mejora de los

sectores productivos utilizando herramientas informáticas de innovación como son el IoT y Machine learning, se plantea desarrollar una interfaz de visualización de datos, a manera de tablero de control, en la cual se presentan los resultados de un algoritmo de análisis de datos, con el fin de conocer el estado de salud de las máquinas y predecir posibles anomalías o fallas. Esto permitirá adoptar las acciones de mantenimiento preventivo correspondientes y tomar decisiones más efectivas basadas en datos que se reciben en tiempo real.

44

5. CRONOGRAMA DE ACTIVIDADES

Las actividades para el desarrollo de este proyecto se organizaron de la siguiente manera:

Tabla 6. Cronograma de actividades

DESCRIPCIÓN S13 S14 S15 S16 S17 S18 S19 S20 S21

Introducción al proyecto a desarrollar

Investigación y reconocimiento de la estrategia pedagógica y herramientas

Desarrollo del aplicativo

Análisis de requerimientos

Diseño de interfaces

Programación de los módulos

Pruebas y ajustes

Documentación del software

Documentación del proyecto de grado

6. ENTREGABLES

● Módulo de visualización de datos. ● Manual de usuario de la aplicación. ● Documentación relacionada (manual técnico y de configuración,

implementación de la metodología ágil seleccionada para el proyecto).

7. MARCO CONCEPTUAL

A continuación, se mostrará el ejercicio de investigación exhaustiva que se realizó con el fin de centralizar todas las posibles tecnologías y herramientas necesarias para el desarrollo del proyecto en cuestión; Siguiendo la idea anterior, se nombraran y explicara brevemente aquella metodología de desarrollo empleada, tecnologías, arquitecturas y herramientas que permitieron el desarrollo de los módulos propuestos en la sección de objetivos y entregables del proyecto.

7.1 Metodología de desarrollo

Con el fin de identificar y seleccionar la metodología más adecuada para el desarrollo del proyecto, se realizó un cuadro comparativo entre metodologías de desarrollo ágiles, tradicionales y modelos de ciclo de vida. El cuadro comparativo está constituido por ocho (8) metodologías en donde se aborda una breve

45

descripción, para qué tipo de proyectos está dirigida, etapas del desarrollo, ventajas y desventajas.

46

Tabla 7. Cuadro comparativo de metodologías de desarrollo aplicables al proyecto

Tabla comparativa de las diferentes metodologías de desarrollo de software

Metodología Descripción Proyectos a los que puede acoplarse

Etapas en las que se divide

Ventajas Desventajas

Scrum Metodología ágil enfocada en el control de procesos a través de asegurar que el conocimiento se tome a partir de decisiones desde lo que se conoce. [26]

-Proyectos a los que se requiere descomponer

-Proyectos muy grandes con poca planeación previa

-Proyectos con facilidad de descomposición.

-Equipos de trabajo numerosos.

-Inicio

-Planificación y estimación

-Implementación

-Revisión y retrospectiva

-Lanzamiento

-Manejo de metas cuantificables que ayudan a garantizar la mayor productividad.

-Garantiza la transparencia del proceso, ya que todas las personas conocen el avance.

-Se revisa constantemente el producto, por medio de reuniones diarias.

-Se obtienen resultados rápidos en periodos cortos.

-Cambio de un miembro en el equipo pone en riesgo el proceso.

-Genera estrés a los miembros del equipo, debido a el cumplimiento del plazo de entrega.

-Puede ser difícil el manejo de scrum en proyectos complejos.

-Se puede dificultar la implementación en el cambio cultural que debe tomar la organización.

47

XP Metodología ágil basada en la comunicación, la reutilización del código desarrollado y la retroalimentación. [27], [28]

-Proyectos a corto plazo.

-Proyectos cambiantes.

-Planificación

-Diseño

-Desarrollo

-Pruebas

-Programación organizada.

-Menor tasa de errores debido a la retroalimentación constante.

-Satisfacción del programador.

-El cliente hace parte en todas las etapas del desarrollo.

-Altas comisiones en caso de fallar.

-Falta de documentación en el proceso de diseño.

-Falta de un plan calificado.

-Solo se puede realizar con desarrolladores senior.

OpenUP Modelo de ciclo de vida que aplica un enfoque iterativo incremental, está basado en casos de uso, gestión de riesgo y arquitectura centrada a impulsar desarrollo. [29]

-Proyectos que brindan importancia a la seguridad y contratación de personal.

-Proyectos que incluyan fuertemente el usuario

-Inicio

-Elaboración

-Construcción

-Transición

-Es adaptable a todos los procesos.

-Permite disminuir en su mayoría los riesgos.

-Permite detectar los errores a temprana edad y mejorarlos a través de ciclos iterativos.

-Permite migrar aplicativos a

-No es adecuado en proyectos grandes.

-Estima cubrir muchas necesidades en un plazo corto, muchas veces no pasa.

-Puede llegar a omitir contenido importante para el desarrollo del proyecto.

48

diferentes plataformas.

RUP Metodologías adaptables al contexto y necesidades de la organización, se caracteriza por ser iterativo e incremental y centrarse fundamentalmente en la arquitectura. [30]

Está especializado para varios tipos de proyectos de todos los tamaños.

Inicio

-Elaboración

-Construcción.

-Transición.

-Apropiado para entornos volátiles.

-Estar preparados para el cambio, significa reducir su coste.

-Planificación más transparente para nuestros clientes.

-Permitirá definir en cada iteración cuales son los objetivos de la siguiente etapa.

-Dificulta la delimitación del proyecto.

-Se puede incurrir en un exceso de formalización, que retrasa el proyecto.

49

-Permite tener realimentación de los usuarios.

Prototipado Modelo que consiste en realizar entregas de prototipos del proyecto en donde este tiende a evolucionar respecto al anterior. [31]

-Proyectos a mediano y largo plazo.

-Proyectos con índices medios de riesgo.

-Investigación preliminar, análisis y especificaciones.

-Diseño y construcción del prototipo.

-Evaluación del prototipo.

-Modificación del prototipo.

-Diseño técnico.

-Programación y pruebas de operación.

-Modificación del sistema en etapas tempranas del desarrollo.

-Diseño de sistemas acorde con las necesidades de los clientes.

-Administración difícil.

-Nunca se llegará a un prototipo completo.

-Retrasos en el desarrollo, debido a que la documentación debe ser recuperada con facilidad y los cambios deben ser efectuados de manera controlada.

50

Cascada Modelo tradicional que sigue una serie de secuencia lógica en donde cada etapa es directamente dependiente de que se cumpla la anterior. [28]

-Proyectos gigantes.

-Aquellos para los que se dispone en todas las especificaciones desde el principio.

-Proyectos de reingeniería.

-Proyectos complejos que se entienden bien desde el principio.

-Preanálisis

-Diseño

-Desarrollo

-Pruebas

-Implementación y mantenimiento

-La planificación es sencilla.

-La calidad del producto resultante es alta.

-Permite trabajar con personal poco cualificado.

-Modelo lineal.

-Se requiere tener todos los requisitos desde el principio.

-No hay posibilidad de corregir errores a tiempo.

-Aumento en los costos del desarrollo.

51

Espiral Modelo de ciclo de vida que combina elementos lineales e iterativos. Se centra fuertemente en considerar la gestión de riesgos. [28], [32]

-Proyectos grandes, largos, caros y complejos.

-Planificación

-Análisis de riesgos.

-Implementación

-Evaluación

-Reduce altamente los factores de riesgo.

-El desarrollo es iterativo, puede incorporar funcionalidades al proyecto progresivamente.

-Permite a los desarrolladores tener un enfoque de construcción de prototipos en las etapas de evolución del proyecto.

-Muy complejo para proyectos pequeños.

-Muy costoso.

-Requiere experiencia en la identificación de riesgos.

-Un fallo en los riesgos podría afectar negativamente a todo el proyecto.

52

Modelo V Modelo de ciclo de vida similar al de cascada, pero este contiene subetapas de retroalimentación entre las etapas de análisis mantenimiento, diseño y resolución de errores. [33]

-Proyectos que requieran un desarrollo documental extenso además de actividades y corrección de las mismas.

-Proyectos extensos.

-Proyectos en donde el cliente está más involucrado.

-Especificaciones.

-Diseño preliminar.

-Diseño en detalle.

-Programación

-Prueba de unidad.

-Prueba de integración.

-Prueba de calificación.

“Si algo sale mal en la prueba se devuelve al punto respectivo de esa prueba”

-Comunicación entre todas las partes involucradas a través de términos y responsabilidades definidas.

-Minimización de riesgos y mejor planificación a través de roles, estructuras y resultados fijos.

-Mejora la calidad del producto gracias a las medidas de control integradas en cada fase.

-Ahorra costes gracias al procesamiento transparente a lo largo del ciclo de vida del producto.

-Puede ser complicado mapear todo el proceso desde el punto de vista del desarrollador.

-Respuesta poco flexible gracias a su estructura rígida.

-El producto se obtendrá al final de todo el ciclo de vida.

-El producto final puede que no refleje los requerimientos del usuario.

Fuente: [26], [27]–[30], [32]–[34]

https://www.zotero.org/google-docs/?ciH4jV

53

Una vez realizado el análisis de las metodologías ágiles, modelos de ciclos de vida y metodologías de desarrollo tradicionales, se considera pertinente usar la metodología de desarrollo evolutivo prototipado; Pues, trayendo a colación la poca cantidad de miembros que harán parte del desarrollo del proyecto, el índice medio de riesgo, la naturaleza visual y evolutiva del software, los posibles cambios o modificaciones que empezaran a surgir en las etapas tempranas de su desarrollo y la excelente capacidad de acople de acuerdo al cliente; Hacen que esta metodología de desarrollo se ajuste positivamente tanto a las necesidades de los desarrolladores, el cliente y el proyecto.

Ilustración 21. Fases del modelo de prototipos evolutivos

Fuente: [31]

Como se observa en la (Ilustración 21), el primer paso según el modelo se

encarga de determinar el problema, su ámbito, qué importancia tiene y la idea principal para la solución. Una vez se ha realizado el proceso de investigación, entra la fase de detección de los requerimientos y deseos del usuario acerca de lo que se quiere implementar; Seguido se inicia la fase de planeación estructural y de diseño en base a los requerimientos propuestos, esta estructura suele ser un boceto simple pero completo en cuanto a los aspectos del software propuestos por el cliente. Justo a continuación que se tiene la guía de lo que se va realizar se procede con la construcción de ese boceto que luego se le proporciona al cliente para que lo evalúe y valide o en caso contrario, realice correcciones si se requieren. Aquí es cuando entra el refinamiento fase que abarca los elementos de corrección y rediseño del prototipo, este prototipo corregido procede a producirse de nuevo hasta que se tenga el producto final que requiere el cliente, concluyendo con el proceso de diseño y desarrollo de software.

54

7.2 Herramienta de gestión del proyecto Trello

Ilustración 22. Fases del modelo de prototipos evolutivos

Fuente: (Tablero de actividades del proyecto)

De acuerdo con Trello [35], se define la aplicación como una herramienta de

colaboración que organiza los proyectos en tableros, esto permite conocer las tareas que se llevan a cabo, quien trabaja en cierta tarea y cuál es el estado de la tarea en proceso.

La idea principal de la aplicación es tener un seguimiento simple en forma de

notas adhesivas para cierta tarea, esta tarea se le podrá hacer seguimiento desde cualquier plataforma con acceso a internet y sobre todo por todas aquellas personas que hacen parte del equipo.

7.3 Generador de información de prueba (EMS Data Generator for MySQL)

Es una herramienta de datos de prueba con enfoque MySQL diseñado por EMS Database Management Solutions. Este software permite manipular las tablas y base de datos con las que se quiera trabajar, establecer rango de generación de valores, manejar tipos de datos a generar (incremental o aleatorio) y guardar y editar los scripts de generación de información etc; El programa viene en ediciones separadas para cada uno de los servidores de servidores DBMS (SQL Server, ORACLE, MySQL, PostgreSQL, InterBase/Firebird y DB2), aparte de proporcionar diferentes modos de generación de datos, asegura el control de la integridad referencial de los datos para tablas vinculadas. [36]

55

Ilustración 23. Interfaz del generador de EMS

Fuente: (Programa Data Generator for MySQL)

Esta herramienta cuenta con una interfaz tipo “Wizard application”, amigable

con el usuario; En la primera ventana se muestra información del producto en donde se resalta el periodo de prueba (30 días) (Ver ilustración 23).

Ilustración 24. Sección de preferencias al inicio de la aplicación


56

En la primer interfaz de la aplicación (Ver ilustración 24), sección inferior izquierda se muestra el botón de herramientas “Tools” en el que el usuario puede configurar principalmente elementos de preferencias como es: la cantidad de datos por tanda, límites para los enteros, precisión y escala para los floats, longitud para los strings y finalmente límites para los tiempos y fechas. Además, también permite cambiar elementos generales del software como son componentes de la interfaz, el lenguaje, etc.

Ilustración 25. Interfaz del generador de EMS, sección de configuración del servidor


El primer paso y fundamental para poder generar la información es conectar el

software con la base de datos, esto abarca seleccionar el tipo de servidor, credenciales y por último el puerto del servidor MySQL (Ver ilustración 25).

57

Ilustración 26. Interfaz del generador de EMS, selección de la base de datos y la tabla


Una vez conectado el software con el servidor se procede a seleccionar la base

de datos y la tabla a la cual se le generarán los datos de prueba (Ver ilustración 26).

Ilustración 27. Interfaz del generador de EMS, sección de configuración del servidor


Finalmente, se muestran los campos de la tabla seleccionada y opciones que pasan desde limpiar los datos de la tabla hasta seleccionar los modos de generación de datos, incrementales, aleatorios, precisión, escala, y rango cuando se trata de

58

tiempo (Ver ilustración 27); Una vez se han acordado como serán los datos, se selecciona next en las siguientes dos ventanas y luego el sistema confirma la generación de los datos, en aquella confirmación, se puede volver hacia atrás para cambiar parámetros si es necesario o por lo contrario, seguir generando tandas de datos.

7.4 Librerías para graficar datos

A continuación, se presentarán unas de las librerías que permiten la graficación de datos con el uso de estructuras de datos tipo JSON, esto con el fin de seleccionar la más adecuada para el desarrollo de las necesidades del proyecto.

7.4.1 Librería Morris.js

Morris.js es una librería tipo API que dibuja gráficos de estilo lineal, barras, áreas y tortas; esta librería es desarrollada por Olly Smith y actualmente no se le está dando soporte de correcciones. Sin embargo, logra realizar el trabajo de graficación de manera simple y completa. [37]

Para el uso de esta API se hacen necesarios elementos como:

● jQuery: librería de JavaScript que hace que elementos como manejo de eventos, animación, código AJAX, manipulación de recorrido y manipulación de código HTML sean más simples de usar, además que funcionan en la gran mayoría de navegadores actuales. Se podría definir como una nueva forma de escribir código JavaScript. [38]

● Raphael.js: Librería de JavaScript que está enfocada para diseñadores gráficos, esta herramienta es un pincel que aplica imágenes directamente al lienzo del navegador, principalmente se usa para potenciar Gráficos Vectoriales Escalables (SVG), pues crea dibujos altamente detallados, que con elementos de CSS crean gráficos de información bastante profesionales. [39]

Ilustración 28. Tipos de gráficos desarrollados con Morris.js

Fuente: [37]

59

La aplicación de Morris.js en un sitio web es considerablemente simple,

primero se requiere añadir las dependencias jQuery y Raphaël a la página ya sea por “CDN-hosted assets” (Ver ilustración 29) o extrayendo la API directamente a la estructura del código (Ver ilustración 30).

Ilustración 29. CDN-hosted assets

Fuente: [37]

Ilustración 30. Paquete de la librería Morris.js

Fuente: [37]

Una vez se ha importado la librería, se realiza el script(<script>) de la gráfica, en donde básicamente se le agrega un nombre del elemento, los datos que se mostraran, el orden en ejes del gráfico y las etiquetas (Ver ilustración 31).

60

Ilustración 31. Script del gráfico

Fuente: [37]

Finalmente, lo único que se requiere es llamar el gráfico con el nombre del

elemento en un <div> (Ver ilustración 32).

Ilustración 32. Llamada del gráfico

Fuente: [37]

7.4.2 Librería Chart.js

Biblioteca de código abierto desarrollada en JavaScript por Nick Downie en 2013, es la segunda mejor biblioteca de gráficos en JS más popular en la comunidad de GitHub seguida de D3.js. [40]

La instalación de la librería es posible por “CDN-hosted assets” (Ver ilustración 33) o por instalación de la API directamente al proyecto, esta segunda disponible en todas sus versiones de GitHub (Ver ilustración 34).

61

Ilustración 33. CDN’s disponibles de la librería Chart.js

Fuente: [40]

Ilustración 34. Paquete de la librería Chart.js

Fuente: [40]

A continuación, se muestra un ejemplo de aplicación de la librería en el que se estructura el código de la siguiente manera:

62

1. Llamado del gráfico con el uso de Canvas como elemento de HTML5 que permite la producción de gráficos dinámicos desarrollados en un script, luego se verifica el sí existe el gráfico en el documento y luego se crea el gráfico en el que se le asigna qué tipo de gráfico se va a dibujar (Ver ilustración 35).

Ilustración 35. Llamada y creación del gráfico

Fuente: [40]

2. Luego se organiza el conjunto de datos a mostrar con sus etiquetas y

características específicas (Ver ilustración 36).

Ilustración 36. Configuración del conjunto de datos

Fuente: [40]

63

3. Finalmente, se configura las opciones del gráfico a utilizar, en este punto hay que ser cuidadoso con las características especiales de los diferentes patrones del gráfico ya sean de barras, lineal, radar, áreas, etc (Ver ilustración 37).

Ilustración 37. Configuración del tipo de gráfico

Fuente: [40]

7.4.3 Librería HighChart

Biblioteca de gráficos multiplataforma basada en SVG, está biblioteca facilita la adición de gráficos interactivos a proyectos web y móviles. La biblioteca lleva en desarrollo activo desde el 2009 y cuenta con un sólido conjunto de funciones y documentación extensa de todos sus componentes. [41]

Ilustración 38. Librería tipo CDN

Fuente: [41]

La instalación de la librería es posible por “CDN-hosted assets”, vía npm o

navegador, y debe ser llamada en la sección <head> de la estructura HTML5 (Ver ilustración 38).

Una vez se ha realizado el llamado de la librería correctamente, es necesario llamar la gráfica después de haberse creado, este llamado se puede realizar en la sección de <body> del html y debe ir dentro de una división tipo <div> como se muestra a continuación (Ver ilustración 39).

Ilustración 39. Llamada del gráfico

Fuente: [41]

64

Para realizar la construcción del gráfico, se hace necesario el uso de JavaScript y se compone de la creación del objeto tipo “Chart” al que se le asigna un nombre; Este elemento está compuesto por el tipo del gráfico, título del gráfico, asignación de los títulos de los ejes y finalmente el importe de los datos, en el caso de este ejemplo es “data” conjunto tipo JSON que obtiene la información de la base de datos (Ver ilustración 40).

Ilustración 40. Código de la gráfica

Fuente: [41]

7.5 AJAX y el manejo de JSON entre diferentes servidores

Con el fin de tomar información desde el aplicativo a la base datos se hace necesario el uso de Json y Ajax permite traer este tipo de objeto de JavaScript desde un dominio diferente; Al realizar esta actividad al menos en un servicio local, el navegador bloquea esta petición por la política “same-origin policy” de CORS, para solucionar esto es necesario permitirle el acceso del dominio al que se le está realizando la petición. A continuación, se muestra como permitir el acceso en servicio local con el uso de XAMPP.

Ilustración 41. Configuración del httpd.config del Apache en local

65

En el servidor local del XAMPP hay que buscar el documento de texto llamado httpd.config, este documento contiene toda la configuración y accesos del servidor, a continuación, se debe buscar la sección del encabezado del módulo y dentro de esta sección se debe permitir el acceso de control de origen al sitio en específico (Ver ilustración 41).

7.6 Jupyter Notebook

Jupyter, es un entorno de desarrollo que permite la codificación, principalmente utiliza Python, sin embargo, es compatible con más de doce (12) lenguajes. El libro de trabajo de este entorno de desarrollo son datos estructurados que representan el código, metadatos, contenido y salidas; una vez se guarda en el disco, el libro de trabajo utiliza la extensión .ipynb, y estructura tipo JSON. Jupyer permite el acceso simple y rápido a un sin fin de librerías, entre ellas las relacionadas a inteligencia artificial y procesamiento de datos, que contribuyen el modelado, desarrollo y visualización de los proyectos. Con el fin de entender la portabilidad de Jupyter Notebook y su interfaz se presenta el siguiente diagrama (Ver ilustración 42). [42]

Ilustración 42. Diagrama de relación de Jupyter

Fuente: [42]

7.7 Arquitectura del proyecto

El estilo de arquitectura de software ligada al proyecto es el Modelo Vista Controlador (MVC) al igual que el proyecto 1 de este mismo documento, para profundizar más sobre la arquitectura dirigirse a la sección “7.4 pág 14” del proyecto 1.

7.8 Framework

Webmvcframework, es un potente framework PHP orientado a objetos, ideal para diseñar y desarrollar aplicaciones web. Este framework es realmente eficaz en proyectos web pequeños y medianos enfocados en aplicaciones web intensivas de datos, sitios y API’s web. Para más información acerca de este fragmento dirigirse a la sección “7.1 pág. 11” del Proyecto 1.

66

7.9 Lenguajes usados

Con el objetivo de lograr la conclusión adecuada del proyecto, se utilizaron diversos lenguajes enfocados en web, para el front end, se utilizó HTML y CSS, y en el caso de back end, se usó PHP y MySQL. Para más información acerca de este fragmento dirigirse a la sección “7.2 pág 12” del Proyecto 1.

7.10 Herramientas usadas

A lo largo del desarrollo se emplearon diferentes herramientas que ayudaban al desarrollador a desplegar, probar y compartir los diferentes módulos propuestos en los requisitos funcionales. Estas fueron:

● MYSQL ● VISUAL STUDIO CODE ● APACHE ● XAMPP ● GIT

Para más información acerca de este fragmento dirigirse a la sección “7.3 pág

13” del Proyecto 1.

8. RESULTADOS OBTENIDOS

En esta sección se mostrarán los resultados obtenidos de las etapas de análisis y desarrollo, en este orden de ideas, se abordaron los requerimientos del sistema, el diagrama relacional de la base de datos, los prototipos de las interfaces, el modelo del algoritmo de inteligencia artificial, el desarrollo de la aplicación de visualización y finalmente la sección de pruebas al sistema.

8.1 Requerimientos funcionales

A continuación, se listarán los requerimientos funcionales del sistema, en los cuales se identificarán las funciones principales con las que debe contar la aplicación de visualización de información desarrollada.

Tabla 8. Requerimientos funcionales

REQUERIMIENTOS FUNCIONALES

Identificador Obligatoriedad Interacción Objeto Detalles

RF01

El sistema deberá mostrar

los gráficos lineales

de cada variable que recibe del sensor (corriente, tensión y potencia)

RF02

El sistema

deberá permitir al usuario <visualizar>

la información

perteneciente a cada variable de manera individual y detallada en una nueva ventana

67

RF03

El sistema deberá obtener

los datos de las variables

almacenados en un archivo de texto y cargarlos a la base de datos

RF04

Los gráficos deberán mostrar

dos niveles máximos de valores para cada variable

el nivel inferior para sugerir revisión y el superior para sugerir mantenimiento (corriente 20 - 27, tensión 750 - 1050 y potencia 730 - 950)

RF05

El sistema deberá mostrar

el valor mínimo, valor máximo y la moda

en todos los gráficos de las variables

RF06

El sistema deberá generar

una alerta

cuando los datos de los gráficos superen los niveles establecidos

RF07

El sistema

deberá permitir al usuario <seleccionar>

los límites de tiempo

de la información que quiere visualizar en los gráficos (1 dia, 3 dias y 7 días)

RF08

El sistema deberá permitir el ingreso

a los módulos administrador, maintainer y planner

si estos se encuentran registrados en el sistema

RF09

El sistema deberá permitir visualizar

las alertas

si estos se encuentran registrados en el sistema

RF10 El sistema

deberá permitir almacenar

la información correspondiente

a una determinada máquina

8.2 Requerimientos no funcionales

A continuación, se listarán los requerimientos no funcionales del sistema, en estos se identificarán los atributos de calidad principales que caracterizan las funciones del sistema.

68

Tabla 9. Requerimientos no funcionales

REQUERIMIENTOS NO FUNCIONALES

Identificador Atributo

Obligatoriedad

Interacción Objeto Detalles Medición

NFR1

Disponibilidad

El sistema deberá actualizar

las interfaces

En un tiempo no mayor a 1 minuto

NFR2

Seguridad El sistema deberá mostrar

una interfaz de login

Para todos los usuarios que intenten ingresar

NFR3

Usabilidad El sistema deberá tener

interfaces

intuitivas y fáciles de usar

sin necesidad de programas externos

NFR4

Portabilidad El sistema deberá <adaptar>

las interfaces

a los dispositivos en donde se visualice el sistema

sin necesidad de ajustes de programación

8.3 Análisis de datos (fuentes de datos: CNC Log, Sensor de vibraciones

MONTRONIX)

Esta sección tiene como objetivo identificar y explicar la proveniencia de los datos que alimentan el proyecto. Siguiendo la idea anterior, el núcleo principal definido como KITAMURA Machine, es la máquina de la que se extrae los datos necesarios para realizar un análisis profundo de acuerdo a su funcionamiento, con el fin de identificar y corregir en un futuro cercano las anomalías que se puedan generar. Esta contiene dos dispositivos: un sistema de control numérico (CNC) de la máquina, que permite gestionar la máquina y la adquisición de elementos físicos como son la tensión eléctrica, la corriente y el poder, en este punto, para cada variable anterior existen varios datos representativos siendo el relevante para la elaboración del proyecto el que hace referencia al total del sistema (Tensión: Vsis, Corriente: Asis y Potencia: PAtsis); El otro dispositivo, es un sensor de vibración encargado de reconocer y capturar los datos de la aceleración, velocidad y finalmente el desplazamiento de las vibraciones ocurridas en la máquina (Ver ilustración 43).

69

Ilustración 43. Diagrama fuente de datos

8.4 Diagrama relacional

En esta sección se presenta el diagrama relacional de la base de datos, este fue desarrollado con la herramienta MySQL Workbench y consta de ocho (8) tablas. La idea principal de la base de datos es almacenar toda la información que recopilen los sensores que se encuentran en cada máquina, de acuerdo con los valores de los sensores se almacenarán unas alertas que contendrán información del sensor junto con la máquina en donde se encuentra ubicado, finalmente, existirá un registro de usuarios que contendrán todas aquellas personas que podrán acceder al sistema de acuerdo a unos roles establecidos (Ver ilustración 44).

70

Ilustración 44. Diagrama relacional de la base de datos

8.5 Diseño de interfaces (Prototipos)

A continuación, se mostrarán los dos prototipos de interfaces, uno para el home y el otro para la representación de la información de cada sensor. Estos fueron desarrollados a través de Power point.

8.5.1 Interfaz de home

El interfaz del home contará con unos botones que indicarán el número de alertas generadas por cada variable y cambiarán su color respecto a ese valor; También, mostrará al usuario los datos en forma lineal de cada sensor en un mismo gráfico (Ver ilustración 45).

71

Ilustración 45. Prototipo de interfaz del home

8.5.2 Interfaz de los sensores

El interfaz de los sensores contará con campos que mostrarán información relevante de los datos de cada sensor (como el dato máximo, mínimo y el promedio), también mostrará su gráfico único de los datos de cada sensor; cabe aclarar que cada sensor contará con su pestaña única en donde se visualizará los datos mencionados anteriormente (Ver ilustración 46).

Ilustración 46. Prototipo de interfaz de los sensores

72

8.6 Algoritmo de inteligencia artificial para la predicción (Gaussian Mixtures)

A continuación, se presenta el algoritmo de inteligencia artificial utilizado para procesar los datos provenientes de las máquinas, en este algoritmo se utiliza el modelo de probabilidad Gaussian Mixture, el cual tiene como objetivo agrupar cada punto al cluster más cercano.

En esta fase del algoritmo se importan todas las librerías necesarias para

realizar el entrenamiento del modelo (Ver ilustración 47).

Ilustración 47. Librerías del algoritmo

Una vez importadas las librerías se procede a leer los datos que se encuentran

en un archivo csv localizado en una dirección local (Ver ilustración 48), luego se crea el data frame de pandas (Ver ilustración 49).

Ilustración 48. Importación de los datos

Fuente: (Propia)

Ilustración 49. Creando el dataframe

Luego de que se tiene la información con la que se va a trabajar, se creó una función a la que se le puede pasar el grupo de datos seleccionados a los cuales se les va a aplicar el modelo de inteligencia artificial. Esta función utiliza las filas “value” y “date”, las cuales se normalizan y luego se les aplica el modelo indicando como

73

número de componentes tres (3), finalmente, se crean y se grafican los clusters (Ver ilustración 50 y 51).

Ilustración 50. Función base del algoritmo

Ilustración 51. Gráfica de los clusters

Finalmente, se llama la función y se le envía el conjunto de datos seleccionado

para la aplicación del modelo (Ver ilustración 52 y 53).

Ilustración 52. Conjunto de datos a modelar

74

Ilustración 53. Llamado de función

8.7 Aplicación PDMS

A continuación, se presentarán los resultados obtenidos respecto a las interfaces finales y su funcionamiento, en este orden, se mostrará la interfaz completa y luego se abordará cada ítem contenido en ella, esto con el fin de evidenciar el desarrollo realizado en el proyecto.

8.7.1 Login

Con el fin de brindar seguridad y accesibilidad limitada a la aplicación, se implementó una interfaz de acceso que solo permite el ingreso solamente a aquellos usuarios que hagan parte de la base de datos del sistema; esto con el fin de mantener asilados los datos de naturaleza sensible presentados en las interfaces.

Ilustración 54. Login

Como se observa en la (Ilustración 54), este recibe el email y la contraseña asignada al usuario, también, cuenta con cuatro (4) botones, de izquierda a derecha está el botón de “Login” que permite la validación de la información ingresada y en el caso de ser correcta redirecciona al usuario a la interfaz principal del sistema, luego se encuentran los botones de “Logout” y “Annulla”, estos cierran la sesión y limpian los campos, respectivamente. Finalmente, se encuentra un campo elegible denominado “Remember me” el cual permite recordar los datos ingresados en el proceso de ingreso.

75

8.7.2 Interfaz del home

La interfaz del home, es el centro de monitorización principal, esta es lo primero que observa el usuario, por eso cuenta con herramientas que resumen el funcionamiento general de la aplicación, incluyendo funciones que facilitan acceder a las demás aplicaciones del programa, como es la visualización individual de cada sensor.

Ilustración 55. Interfaz del Home

De acuerdo con la (Ilustración 55), La interfaz principal (HOME) consta con cuatro (4) partes, la primera es el navbar.

Ilustración 56. Navbar

El navbar cuenta con cuatro (4) botones, posicionándonos de izquierda a derecha primero nos encontramos con un botón “Pdms” que hace referencia a la aplicación y además este redirige al home del aplicativo, el siguiente es el que se

76

llama “Home”, su función es redirigir al usuario a la interfaz principal (Ver ilustración 56).

Ilustración 57. Sección de sensores y LogOut

Luego como se observa en la (Ilustración 57) está el botón “Sensors”, este actúa como un menú que contiene cuatro (4) interfaces de acuerdo a las variables que el sistema debe mostrar, finalmente se encuentra el botón de “LogOut” que cierra la sesión del usuario que esté iniciado en ese momento.

Ilustración 58. Alertas del sistema

La siguiente parte del home es la sección de alertas, esta cuenta con cuatro

(4) botones que hacen referencia a cada variable que debe mostrar el sistema en sus interfaces únicas, estos también actúan como redirección para que el usuario pueda dirigirse a la sección de la variable lo más rápido posible. Sin embargo, los botones no solo lucen la cantidad de alertas generadas por esa variable, sino que cambian su color a partir de este número. Los colores varían de verde (0-3 alertas), amarillo (4-6 alertas) y rojo (6+ alertas) (Ver ilustración 58).

Ilustración 59. Información importante de la gráfica

Siguiendo lo presentado anteriormente, la siguiente sección es la encargada de mostrar al usuario datos importantes respecto a la gráfica que se está presentado, esta parte consta de tres (3) cuadros de texto que muestran de izquierda a derecha el valor máximo de la corriente, tensión y poder respectivamente (Ver ilustración 59).

77

Ilustración 60. Gráfico

En último lugar se encuentra el gráfico, antes de empezar a desglosar esta

sección cabe resaltar que está realizado con la librería “HighChart”; este representa tres (3) variables al mismo tiempo (corriente, tensión y poder), como se observa en la (Ilustración 60), el gráfico representa la información en dos ejes X y Y, en donde se encuentra la fecha y el valor respectivamente, además cuenta con unos niveles de advertencia en donde el usuario puede evidenciar si el dato los supera.

Con el fin de comprender todas las funcionalidades de la librería, a

continuación, se abordarán las características de esta.

Ilustración 61. Herramientas de la gráfica

78

La primera característica, hace referencia a las herramientas respecto al gráfico, como se observa en la (Ilustración 61), estas van desde visualizar la gráfica en pantalla completa hasta descargar una foto de esta en formato PDF.

Ilustración 62. Barra histórica de tamaño variable

Finalmente, la librería cuenta con una barra general de la información representada en la gráfica, esta puede ajustarse en tamaño y moverse libremente sobre el histórico, realizar esta acción acomoda la gráfica en tiempo real a la sección seleccionada por el usuario (Ver ilustración 62).

8.7.3 Interfaz de los sensores

En esta sección se cubrirán la interfaz aplicada a los sensores (corriente, tensión y poder), esta es la encargada de mostrar la información netamente de su variable correspondiente. Partiendo de que se usó un modelo de interfaz para la representación de estas tres (3) variables, y con el afán de hacer esta sección ligera, se abordará solo un ejemplo de ellas.

79

Ilustración 63. Interfaz sensor corriente

Ilustración 64. Límites de visualización de datos

Esta sección (Ver ilustración 63) cuenta con tres (3) partes:

● El navbar: El navbar cuenta con cuatro (4) botones, posicionándonos de izquierda a derecha primero nos encontramos con un botón “Pdms” que hace referencia a la aplicación y además este redirige al home del aplicativo, el siguiente es el que se llama “Home”, su función es redirigir al usuario a la interfaz principal (Ver ilustración 56).

● Información importante del gráfico: Esta sección es la encargada de mostrar al usuario datos importantes respecto a la gráfica que se está presentado, esta parte consta de tres (3) cuadros de texto que muestran de izquierda a derecha el valor mínimo, máximo y el promedio respectivamente (Ver ilustración 59).

● El gráfico: este representa la variable de corriente, como se observa en la (Ilustración 65), el gráfico representa la información en dos ejes X y Y, en donde se encuentra la fecha y el valor respectivamente, además

80

cuenta con unos niveles de advertencia en donde el usuario puede evidenciar si el dato los supera. Asimismo, este gráfico también cuenta con una característica mencionada en la sección de “8.7.1 interfaz del home”, que hace referencia, a las herramientas de la gráfica (Ver ilustración 61); por último, cuenta con unos botones encargados de limitar la información de acuerdo al gusto del usuario, siguiendo la (Ilustración 64), se observan estos de 1 día, 3 días, 7 días, 1 mes y All, al presionarse van a seleccionar los datos que hagan parte de esa cantidad de tiempo desde ese momento hacia atrás y los va a reflejar en tiempo real en la gráfica lineal.

Ilustración 65. Gráfico de corriente

8.8 Testing

En esta sección se mostrarán cuatro (4) casos de prueba de las diferentes partes que componen las interfaces del sistema, esto con el fin de identificar y resolver los posibles problemas que se presenten en su uso cotidiano. En la (Tabla 10) se observa el caso de prueba relacionado con el navbar usado en todas las interfaces del sistema, en este se realizaron tres (3) pruebas de caja blanca en donde se probaba la eficiencia de cada botón situado en la barra, esto con el fin de evitar errores de redirección y bloqueos al usuario presionarlos.

81

Tabla 10. Caso de prueba del navbar de las interfaces

Casos de prueba

Incremento IT1: Navbar de las interfaces

Funcionalidad

Respuesta de los ítems del navbar

Tipo de prueba Unitaria

Método Caja blanca

Responsable

Juan Pablo Duque Cruz

Estado caso de prueba Ejecutada

Documento de referencia Documento de requerimientos funcionales

Prerrequisitos

El usuario haya iniciado sesión en el sistema con (usuario y contraseña)

Ítem 1 Se cumple Descripción

Redirección del botón "Pdms" y "Home" a la pantalla principal al presionarse.

Corrida 1 2 3

Si x

No


Al presionarse el botón "Sensors" abrir el menú que muestra cada ventana respectiva del sensors(Current, tension y Power)

Si x

No


Al abrir el menú de "Sensors" redireccionar a la ventana clickeada.

Si x

No


Al presionar el botón de logout se cierra la sesión y redirige al usuario al login.

Si x

En la (Tabla 11) se contempla el caso de prueba relacionado con el sistema de

alertas ubicado en la interfaz principal (Home), en esta se realizaron tres (3) pruebas de caja blanca en donde se probaba principalmente que el sistema trajera de forma correcta la información situada en la base de datos y que sobre todo funcionaran los sistemas de colores ubicados en cada botón. Finalmente, que estos al presionar llevaran al usuario a la interfaz correspondiente.

82

Tabla 11. Caso de prueba de las alertas en la interfaz del home

Casos de prueba

Incremento IT2: Interfaz del home sección de alertas del sistema

Funcionalidad

Indicadores de alertas del sistema


Método Caja Blanca

Responsable




Prerrequisitos

Iniciar en el sistema con (usuario y contraseña)


Cuenta el sistema correctamente las alertas de cada variable respecto a los

datos de la base de datos

Corrida 1 2 3

Si x

No


Se muestran los colores respectivos partiendo del número de alertas

identificadas

Si x

No


Al hacer clic en el cuadro de alerta de la variable en cuestión, el programa

redirecciona a la interfaz de esa variable

Si x

No

En la (Tabla 12) se encuentra el caso de prueba relacionado con los cuadros

de texto que resaltan información de los datos utilizados en la gráfica de cada interfaz, en esta sección se realizaron tres (3) pruebas de caja blanca en donde se probaba que los datos mostrados en los cuadros coinciden con los presentados en la base de datos del sistema.

83

Tabla 12. Caso de prueba de los cuatros con información relevante

Casos de prueba

Incremento IT3: Cuadros con información relevante de la gráfica

Funcionalidad

Indicadores de datos relevantes


Método Caja Blanca

Responsable




Prerrequisitos



Verificar si el dato máximo mostrado coincide con la información de la base de datos y verificar si varía al cambiarlo directamente

Corrida 1 2 3

Si x

No


Verificar si el dato mínimo mostrado coincide con la información de la base de datos y verificar si varía al cambiarlo directamente

Si x

No


Verificar si el dato promedio mostrado coincide con la información de la base de datos mediante una consulta

Si x

No

Por último, en la (Tabla 13) se ubica el caso de prueba relacionado con los las

gráficas lineales que se encuentran en cada interfaz del sistema, en este espacio se realizaron cinco (5) pruebas de caja blanca en donde analizaba si el gráfico está mostrando los datos plasmados en la base de datos, si funcionan las herramientas de seccionamiento de información ubicadas en la parte superior de cada gráfico, si cuentan con los límites visuales para cada variable y finalmente si funciona la barra histórica inferior que ajusta los datos en tiempo real de la gráfica.

Como resultado, se identificó que las herramientas de seccionamiento de

información (1d, 3d, 7d y 1 mes) no están funcionando adecuadamente, al igual que los identificadores en el eje X que pertenecen a la fecha de cada dato; en este punto, se realizaron unos módulos que simulaban los botones de la librería y se les agregaron la función de seccionamiento de información, en cuanto a la fecha del eje X, se logró posicionar la fecha correspondiente a cada dato representado.

84

Tabla 13. Caso de prueba de los gráficos

Casos de prueba

Incremento IT3: Gráfico lineal de cada interfaz

Funcionalidad

Representación de los datos


Método Caja Blanca

Responsable




Prerrequisitos



Muestra el gráfico los datos actuales respecto a la base de datos

Corrida 1 2 3

Si x x x

No


Al presionar los botones que limitan los datos a representar, el gráfico se actualiza

Si x x El sistema no renderiza la información a los límites asignados ya que no existe una fecha asignada a cada dato en el formato de la gráfica. Se crearon unos botones similares a los de la herramienta incorporada con la librería, estos se programaron de manera similar con el objetivo de simular la acción de los de la librería, limitar los datos a visualizar y actualizar la gráfica. No x


La barra histórica de tamaño variable actualiza el gráfico en tiempo real

Si x x x

No


Se muestran los niveles lineados intermitentes a un valor asignado

Si x x x

No


85

En los ejes X y Y de la gráfica se muestra la información respectiva

Si X X En el eje Y el sistema muestra la información adecuada, en cuanto al eje X, no se logra mostrar el formato de la fecha. Se consiguió colocar las fechas del dato en el eje X para las interfaces de los sensores (Current, Tension y Power), en el caso del “Home”, como se traen los últimos 60 datos, estos pertenecen al día en que se observe el gráfico. No x

9. CONCLUSIONES

De acuerdo con los resultados obtenidos y las metodologías utilizadas se puede concluir que:

• La exploración de herramientas es un ejercicio primordial para la correcta ejecución de las tareas, además esto abre el panorama de solución para problemáticas que se puedan generar a lo largo del proceso de desarrollo.

• En la etapa de análisis del sistema, es fundamental realizar los requerimientos tanto funcionales como no funcionales adecuadamente, esto para centrar las ideas de lo que se quiere y tener una bitácora de cara al desarrollador sobre las tareas a programar. De igual manera el diseño de los mockups de las interfaces ayuda a todos los integrantes del equipo concebir una previsualización base que agiliza el proceso de creación y despliegue del proyecto.

• Una vez se conoce la naturaleza del proyecto, realizar un proceso exploración de metodologías que ayude a la identificación de la más acoplable a este, permite el acercamiento a la armonía en los procesos de ciclo de vida del proyecto que evitan situaciones como el derroche de recursos, estancamientos prologados y hasta la pérdida del proyecto.

• Aunque los conceptos preconcebidos en la formación académica toman un papel fundamental en el momento del desarrollo de un proyecto, se concluye que, por la naturaleza de la carrera y la exigencia de los proyectos, existen vacíos que le corresponden netamente al estudiante llenar por su cuenta.

• Llevar un orden en la codificación y el control de las versiones es primordial para llevar un desarrollo saludable del proyecto, principalmente cuando intervienen varios actores en su desarrollo.

• La comunicación asertiva y eficaz con el equipo de desarrollo es fundamental para lograr el cumplimiento de todos los objetivos planteados en el proyecto, además de aterrizar las tareas y permite la corrección de algún elemento que este imperfecto.

• Finalmente, que tener buenas prácticas de testing como realizar pruebas concurrentes mediante y a finales de cada ciclo del prototipo (al menos en

86

proyectos de esta envergadura) contribuyen a la identificación y corrección temprana de bugs y errores; Que si a comparación de realizar el proceso de testing como parte final del proyecto, esto minimiza los tiempos de entrega del proyecto y mejora la calidad del software.

87

10. REFERENCIAS

[1] C. Chen, N. Lu, B. Jiang, and C. Wang, “A Risk-Averse Remaining Useful Life Estimation for Predictive Maintenance,” IEEECAA J. Autom. Sin., vol. 8, no. 2, pp. 412–422, Feb. 2021, doi: 10.1109/JAS.2021.1003835. [2] M. Jasiulewicz-Kaczmarek, K. Antosz, P. Żywica, D. Mazurkiewicz, B. Sun, and Y. Ren, “Framework of machine criticality assessment with criteria interactions,” Eksploat. Niezawodn. - Maint. Reliab., vol. 23, pp. 207–220, Jan. 2021, doi: 10.17531/ein.2021.2.1. [3] H. K. Chan, N. Subramanian, and M. D.-A. Abdulrahman, Eds., “Big Data Analytics for Predictive Maintenance Strategies,” in Supply Chain Management in the Big Data Era, IGI Global, 2017. doi: 10.4018/978-1-5225-0956-1. [4] M. N. Razali, A. F. Jamaluddin, R. Abdul Jalil, and T. K. Nguyen, “Big data analytics for predictive maintenance in maintenance management,” Prop. Manag., vol. 38, no. 4, pp. 513–529, Jan. 2020, doi: 10.1108/PM-12-2019-0070. [5] A. K. S. Jardine, D. Lin, and D. Banjevic, “A review on machinery diagnostics and prognostics implementing condition-based maintenance,” Mech. Syst. Signal Process., vol. 20, no. 7, pp. 1483–1510, Oct. 2006, doi: 10.1016/j.ymssp.2005.09.012. [6] M. P. Groover, Automation, Production Systems, and Computer-Integrated Manufacturing, 4th Edition. Hudson Street, New York: Pearson, 2015. [7] V. L. Trevathan, A Guide to the Automation Body of Knowledge , Research Triangle Park, NC, USA: International Society of Automation. 2018. [8] J.-R. Ruiz-Sarmiento, J. Monroy, F.-A. Moreno, C. Galindo, J.-M. Bonelo, and J. Gonzalez-Jimenez, “A predictive model for the maintenance of industrial machinery in the context of industry 4.0,” Eng. Appl. Artif. Intell., vol. 87, p. 103289, Jan. 2020, doi: 10.1016/j.engappai.2019.103289. [9] B. S. Blanchard, Logistics Engineering and Management, 5th ed. New Jersey: Prentice Hall, 1998. Accessed: Apr. 14, 2021. [Online]. Available: https://www.scribd.com/document/117493584/Logistics-Engineering-and-Management [10] “BS-EN-13306-2010.pdf.” Accessed: Apr. 14, 2021. [Online]. Available: http://irma-award.ir/wp-content/uploads/2017/08/BS-EN-13306-2010.pdf [11] I. Alsyouf, “The role of maintenance in improving companies’ productivity and profitability,” Int. J. Prod. Econ., vol. 105, no. 1, pp. 70–78, Jan. 2007, doi: 10.1016/j.ijpe.2004.06.057. [12] “FULLTEXT01.pdf.” Accessed: Apr. 15, 2021. [Online]. Available: http://www.diva-portal.org/smash/get/diva2:327871/FULLTEXT01.pdf [13] M. Kans, On the utilisation of information technology for the management of profitable maintenance. Växjö: Växjö Univ. Pr, 2008. [14] “rcarvello/webmvcframework,” GitHub. https://github.com/rcarvello/webmvcframework (accessed Apr. 16, 2021). [15] “HTML & CSS - W3C.” https://www.w3.org/standards/webdesign/htmlcss (accessed Apr. 16, 2021). [16] “JavaScript Web APIs - W3C.” https://www.w3.org/standards/webdesign/script.html (accessed Apr. 16, 2021). [17] “PHP: ¿Qué es PHP? - Manual.” https://www.php.net/manual/es/intro-whatis.php (accessed Apr. 16, 2021). [18] “Documentation for Visual Studio Code.” https://code.visualstudio.com/docs (accessed Apr. 16, 2021).

88

[19] “MySQL :: MySQL 8.0 Reference Manual :: 1.2.1 What is MySQL?” https://dev.mysql.com/doc/refman/8.0/en/what-is-mysql.html (accessed Apr. 16, 2021). [20] “About the Apache HTTP Server Project - The Apache HTTP Server Project.” https://httpd.apache.org/ABOUT_APACHE.html (accessed Apr. 16, 2021). [21] “About the XAMPP project.” https://www.apachefriends.org/es/about.html (accessed Apr. 16, 2021). [22] “Git.” https://git-scm.com/ (accessed Apr. 16, 2021). [23] “2016-Scrum-Guide-Spanish.pdf.” Accessed: Apr. 16, 2021. [Online]. Available: https://scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Spanish.pdf#zoom=100 [24] “PMapp v4.0_SRS.docx.” [25] D. J. Fürnkranz, “Knowledge Engineering Group,” p. 83. [26] “2.Scrum.pdf.” [27] J. Izquierdo, “¿Qué es el XP Programming?,” Thinking for Innovation, Sep. 04, 2014. https://www.iebschool.com/blog/que-es-el-xp-programming-agile-scrum/ (accessed Apr. 21, 2021). [28] L. Cardozo, “IMPLEMENTACIÓN DE BUSINESS INTELLIGENCE: TABLA COMPARATIVA : DE ALGUNAS METODOLOGÍAS DE DISEÑO DE SOFTWARE,” IMPLEMENTACIÓN DE BUSINESS INTELLIGENCE, viernes, de diciembre de 2010. http://bicovemcali.blogspot.com/2010/12/tabla-comparativa-de-algunas-de-las.html (accessed Apr. 21, 2021). [29] S. R. Salgado, I. C. H. Raza, and I. R. D. Rodríguez, “APLICACIÓN DE LA METODOLOGIA OPENUP EN EL DESARROLLO DEL SISTEMA DE DIFUSIÓN DE GESTIÓN DEL CONOCIMIENTO DE LA ESPE,” p. 11. [30] Elías, Pedro, “SMARTSOFT - Metodología de Desarrollo Tradicional RUP,” Metodología de Desarrollo Tradicional RUP, Jul. 31, 2018. https://smartsoftcolombia.com/portal/index.php/blog/49-rup (accessed Apr. 21, 2021). [31] “Mprototipo - Modelo de prototipos - EcuRed,” s.f. https://www.ecured.cu/Modelo_de_prototipos#/media/File:Mprototipo.png (accessed Apr. 21, 2021). [32] Fariño, Garo, “Modelo Espiral de un proyecto de desarrollo de software,” p. 9, 2011. [33] “Ciclo De Vida En V,” Ingenieria De Software, s.f. http://ingenieriadesoftwaretdea.weebly.com/ciclo-de-vida-en-v.html (accessed Apr. 21, 2021). [34] itsarellano, “Tabla comparativa- metodologías de desarrollo,” 19:40:51 UTC. Accessed: Apr. 21, 2021. [Online]. Available: https://es.slideshare.net/itsarellano/tabla-comparativa-34977102 [35] “¿Qué es Trello? - Ayuda de Trello,” s.f. https://help.trello.com/article/708-what-is-trello (accessed Apr. 21, 2021). [36] S. Q. L. Manager, “Data Generator for MySQL,” SQL Manager, s.f. https://www.sqlmanager.net/products/mysql/datagenerator (accessed Apr. 21, 2021). [37] “morrisjs/morris.js,” GitHub, 2012. https://github.com/morrisjs/morris.js (accessed Apr. 21, 2021). [38] J. F.- js.foundation, “jQuery,” s.f. https://jquery.com/ (accessed Apr. 21, 2021). [39] “An Intro to Raphaël,” Raphaël, s.f. http://raphaeljs.com/ (accessed Apr. 21, 2021).

89

[40] “Chart.js | Open source HTML5 Charts for your website,” s.f. https://www.chartjs.org/ (accessed Apr. 21, 2021). [41] “Highcharts Documentation | Highcharts,” s.f. https://highcharts.com/docs/index (accessed Apr. 21, 2021). [42] “Architecture — Jupyter Documentation 4.1.1 alpha documentation.” https://jupyter.readthedocs.io/en/latest/projects/architecture/content-architecture.html (accessed May 20, 2021).

Documents

DESARROLLO DE MÓDULOS DE SOFTWARE PARA EL PROYECTO …