UNIVERSIDAD AUTÓNOMA DE CIUDAD JUÁREZ
Instituto de Ingeniería y Tecnología
Departamento de Ingeniería Eléctrica y Computación
PROTOTIPO DE BITÁCORA DE MANTENIMIENTO WEB PARA GRUPO CEMENTOS DE CHIHUAHUA
Reporte Técnico de Investigación presentado por:
Emmanuel Duarte Bistrain 108567
Requisito para la obtención del título de
INGENIERO EN SISTEMAS COMPUTACIONALES
Asesor
M. C. Arnulfo Castro Vázquez
Ciudad Juárez, Chihuahua Noviembre de 2017
1
2
3
4
Agradecimientos
En primera instancia agradezco a Dios por la vida que tengo, por todas las oportunidades que me ha dado y, sobre todo, por mi familia, ya que, sin ellos, no hubiese podido lograr esta meta.
Agradezco a mis padres José Luis Duarte y Mercedes Bistrain Cabrera que me mostraron cuán grande puede ser un corazón que, a pesar de todo, continúan siendo generosos con las personas, ellos me enseñaron el valor del trabajo desde niño, también a no darme por vencido por más difícil que estuviera cualquier situación, la paciencia necesaria para pensar en alguna solución y la entereza para enfrentar la vida, sin perder los valores que me inculcaron. A mi hermano Luis Hernán Duarte Bistrain quien me ha enseñado, principalmente, el apoyo incondicional que siempre debe existir entre los hermanos.
Agradezco a mi asesor Mc. Arnulfo Castro Vázquez quien me tuvo la paciencia, me enseño los pasos a seguir y con el Mtro. René Noriega Armendáriz me dieron una buena lección de vida. Y en general, agradezco a todos los maestros y compañeros que tuve a lo largo de la carrera, por todo lo compartido y lo convivido.
5
Dedicatoria
Sin duda alguna, este trabajo y todos mis logros los dedico a mi familia, a mis padres, mi hermano y, actualmente a mi única hija Joanna Lizeth Duarte Medina y a la familia que llegue.
6
Índice de contenido
Declaración de Originalidad ... Error! Bookmark not defined.
Agradecimientos ... 4
Dedicatoria ... 5
Índice de contenido ... 6
Índice de figuras ... 8
Resumen ... 10
Introducción ... 11
I. Planteamiento del problema ... 12
1.1 Antecedentes ... 12
1.2 Definición del problema ... 13
1.3 Objetivos ... 13
1.3.1 Objetivos Específicos... 13
1.5 Justificación ... 14
II. Marco Referencial ... 16
2.1 Marco teórico ... 16
2.1.1Arquitectura Cliente-Servidor ... 16
2.1.2 Direcciones IP y el servicio DNS ... 16
2.1.3 Los paquetes... 17
2.1.4 PHP ... 17
2.1.5 Seguridad ... 17
2.1.6 Base de datos... 18
2.1.7 Definición ... 18
2.1.4 Lenguaje de Consulta Estructurada (SQL) ... 19
2.1.5 Definición de datos ... 20
III. Desarrollo del proyecto ... 21
3.1 Introducción ... 21
3.2 Previa estructura... 21
3.3 Diagrama de módulos ... 22
3.4 Diagrama de clases ... 24
3.4.1 Clase de Paros ... 25
3.4 Diagramas de secuencia ... 27
3.5 Proceso de construcción de la solución ... 28
3.6 Desarrollo principal ... 32
IV. Resultados y Discusiones ... 38
4.1 Resultados ... 38
4.2 Discusiones ... 40
V. Conclusiones ... 42
Referencias ... Error! Bookmark not defined. Apéndices ... 46
Diagrama de clases ... 46
7
Clase SíntomaCausa... 46
Clase Motivos ... 47
Clase Empleado ... 47
Clase Naturaleza ... 48
Clase GFHS ... 48
Clase Producción ... 49
Clase Notas ... 50
Clase de Pendientes... 51
Clase Operaciones ... 52
Diagramas de secuencia ... 53
8
Índice de figuras
Ilustración 1 Diagrama general ... 21
Ilustración 2 Diagrama de modelos ... 22
Ilustración 3 Diagrama de clases ... 25
Ilustración 4 Clase de Paros ... 26
Ilustración 5 Diagrama de secuencia de Pendientes ... 27
Ilustración 6 Diagrama de secuencia de Producciones ... 28
Ilustración 7 Edicion del nombre y Estandarizacion ISO ... 28
Ilustración 8 Panel de edición de áreas ... 29
Ilustración 9 Panel de edición de equipos ... 29
Ilustración 10 Panel de edición de tarifas horarias ... 29
Ilustración 11 Panel de edición de turnos ... 30
Ilustración 12 Panel de ingreso de estándares de la planta ... 30
Ilustración 13 Panel de edición de secciones de producción ... 31
Ilustración 14 Panel de selección de archivo OEE ... 31
Ilustración 15 Ventana principal ... 32
Ilustración 16 Panel de Notas ... 33
Ilustración 17 Panel de Operaciones ... 33
Ilustración 18 Panel de Paros ... 33
Ilustración 19 Panel de pendientes ... 34
Ilustración 20 Ejemplo de correo de notificación de pendiente sin terminar ... 34
Ilustración 21 Ejemplo de notificación de pendiente terminado ... 35
Ilustración 22 Ventana de Producciones ... 35
Ilustración 23 Menú de reportes ... 36
Ilustración 24 Ventana de mensaje al programador ... 37
Ilustración 25 Ejemplo de notificación al programador de un mensaje... 37
Ilustración 26 Clase de SintomaCausa ... 46
Ilustración 27 Clase Motivos ... 47
Ilustración 28 Clase Empleado ... 47
Ilustración 29 Clase Naturaleza ... 48
9
Ilustración 30 Clase GFHS ... 48
Ilustración 31 Clase Producción ... 49
Ilustración 32 Clase Notas ... 50
Ilustración 33 Clase Pendientes ... 51
Ilustración 34 Clase Operaciones ... 52
Ilustración 35 Diagrama de secuencia de Configuración ... 53
Ilustración 36 Diagrama de secuencia de Operaciones ... 54
10
Resumen
Grupo Cementos de Chihuahua tuvo un rezago en la forma de realizar sus operaciones diarias, que conllevan a una falta de comunicación entre sus empleados, deficiencia que no puede continuar en una empresa de su magnitud.
Por lo que se desarrolló un sistema que da solución a puntos importantes en el trabajo que realizan cada uno de los empleados de la planta productora de cemento, al término e implementación de dicho sistema, se logró eficientar el proceso laboral de la zona operativa.
11
Introducción
Aún cuando Grupo Cementos de Chihuahua es una empresa de talla internacional, tiene ciertas deficiencias, como todas las empresas, en su organización y el procesamiento de la información que le ayuden a aumentar la calidad de un modelo empresarial que la distinga de otros grupos de su ramo.
La cementera se ha caracterizado por la obtención de certificaciones importantes, mostrándoles a sus clientes la calidad de su producto, con diferentes procesos adoptados que cumplen con los requisitos y llegan a sobrepasar estas expectativas. Por ello se ha posicionado con dicha talla.
En estas situaciones, la empresa se ha dado la tarea de llenar los “huecos” en sus procesos, detalles que no apoyan a su crecimiento, quedando rezagada en ciertas áreas.
Como bien se sabe, el correcto procesamiento de la información es de gran beneficio para todas las empresas, tener las mejores herramientas para cumplir, satisfactoriamente, con los requerimientos del mismo. Por estas razones se inició con el proyecto de la Bitácora de Operaciones.
La solución que en un principio fue de registro de movimientos, paso a ser parte importante de la organización de la cementera en su aspecto de procesos operativos y, sobre todo resolver los problemas de comunicación entre las áreas y su pronto informe con la dirección. En el mercado hay herramientas que sirven para registrar de eventos, pero no hay sistema que se ajuste a las necesidades de un grupo cementero. Por lo que se dio a la tarea de solventar esta situación por medio del siguiente proyecto.
En el primer capítulo se describe la situación por la que atravesó la cementera durante largo tiempo, con ciertas carencias en cuestiones de su organización y, tomando esto como fundamento, el planteamiento de la solución. En el segundo capítulo, se encuentra la teoría que forma parte de la base de este proyecto. Dentro del tercer capítulo se detalla el desarrollo que se llevó para este proyecto. Para verificar el impacto que tuvo este proyecto en el cuarto capítulo se muestran las opiniones de varios empleados, de diferentes, rangos que han sido beneficiados con el sistema. En el quinto capítulo se muestra la conclusión a la que se llegó.
12
I. Planteamiento del problema
1.1 Antecedentes
En los sistemas actuales existe software capaz de llevar una bitácora como un simple diario, sin las medidas de seguridad necesarias para su confidencialidad y restricciones.
También existen programas que se muestran como bitácoras de producción, pero no se ajusta a las necesidades particulares de Grupo Cementos de Chihuahua (GCC). La manera de llevar el control de los eventos en la empresa es con una aplicación desarrollada previamente con Visual Basic para Aplicaciones, donde su base de datos es un archivo de Excel, en este se han tenido dificultades con las versiones del mismo, el almacenamiento de los datos e inclusive la memoria que ocupaba dicho programa.
En la industria del software existen sistemas que podrían asistir al proceso de organización de la cementera, como:
Cuaderno de Bitácora: En este se puede organizar toda la música, archivos, sitios visitados en Internet, libros y videos, pero no es especializado para empresas de este giro.
RedNoteBook: En el cual se registra cualquier texto dependiendo del día, pero no es el indicado para GCC.
DBXTRA: En este programa se puede realizar el diseño de reportes con hojas de datos, tablas y gráficas; es una herramienta muy práctica y flexible, ya que esta puede accesar a las bases de datos más conocidas, como lo es SQL, MySQL, Access, Oracle entre otros, pero requiere licenciamiento.
Por lo tanto, no se encontró en el mercado, un software que se adapte a las necesidades de la industria cementera para controlar los eventos tales como: producción, operaciones, paros de maquinaria, seguimiento de pendientes, entre otros.
13
1.2 Definición del problema
En Grupo Cementos de Chihuahua no se cuenta con un sistema de registro de eventos operacionales de cada planta, que además cuente con seguridad y precisión de los datos de cada evento. Estos eventos afectan en las operaciones de la planta, el registro de los paros de las máquinas y seguimiento de pendientes de producción; por mencionar algunos.
El programa actual tiene deficiencias en sus registros, además de ocupar archivos de Excel como modo de almacenamiento, es complicado de usar para los empleados y no tiene escalabilidad. Por parte de la seguridad no cuenta con al menos una contraseña, debido a que su información se encuentra en la misma computadora, los usuarios pueden ingresar y cambiar cualquier información.
Por otro lado, las actualizaciones del paquete de Microsoft Office afectan al programa ya que se bloquea y no permite ningún registro más.
Por todas estas áreas de oportunidad que se tienen en la forma actual de administrar los eventos de las plantas con el programa, se ha determinado la necesidad de implementar un sistema que controle dichos eventos, con la capacidad de ser accesible mediante la intranet y con la seguridad necesaria para cada departamento y rango de los empleados.
1.3 Objetivos
Desarrollar un prototipo de sistema de información web en donde se realice la captura y consulta de eventos y datos estadísticos de cada planta del grupo.
1.3.1 Objetivos Específicos
Subir y bajar imágenes que brinden a mayor detalle la situación actual.
Enviar notificaciones por correo al momento de surgir cualquier pendiente.
Generar de forma automática los reportes que deberán ser enviados por correo interno.
Implementar seguridad al ingresar al sistema.
14
1.5 Justificación
Implementando el sistema, GCC cuenta con un mayor control en los procesos, con estadísticas de funcionamiento, de paros y de pendientes, permitiéndole administrar los eventos y realizar acciones preventivas, con lo que se lograría una reducción de su tiempo muerto hasta del 10% y una eficiencia de 40% en el manejo de los datos, respecto a la generación de reportes e informes ejecutivos. Los beneficios disponibles para el empleado son:
Una interfaz más sencilla de usar.
La capacidad de almacenamiento mayor de la que se ha manejado.
Registro automático de datos relevantes para su proceso.
Registro de operaciones manteniendo su integridad.
Mandar avisos por correo a los encargados de cada área.
Tener un registro histórico de cada movimiento realizado en la bitácora.
Diseñar reportes necesarios para cada planta
Autenticación de usuarios.
Las personas beneficiadas son los empleados de Grupo Cementos de Chihuahua que laboren en la Sala de Control, estén encargados de las áreas de Eléctrica, Instrumentación, Ambiental, Calidad, Procesos y Mantenimiento. Contar con un sistema de esta naturaleza permite centralizar la información, generando la posibilidad de acceder a los datos y revisar en tiempo real los eventos producidos en cada planta, ya sea Planta Juárez, Samalayuca, Chihuahua, Canteras, Tijeras en Nuevo México, Pueblo en Colorado, Rapid City en South Dakota, Odessa en Texas, entre otras.
15 Se mejoró la organización de la empresa, los gerentes pueden ver cuál es la situación actual de cada planta y, con esto, tomar decisiones, medidas de seguridad, producción, operación, calidad, entre otras. La utilidad principal de este proyecto es la organización administrativa y de procesos. Este problema se volvió significativo en el momento que no se tiene en conocimiento la situación de las plantas y otros negocios de GCC, con la correcta información, puede darse un correcto funcionamiento.
16
II. Marco Referencial
2.1 Marco teórico
2.1.1Arquitectura Cliente-Servidor
Para poder proceder a la comunicación de la base de datos con la página web se requiere de la utilización de diversos conceptos de red, tales como la dirección IP (Internet Protocol) y esta marca el origen o el destino de los paquetes enviados por la red usando este Protocolo. [1]
2.1.2 Direcciones IP y el servicio DNS
Al momento de que el usuario quiere accesar a alguna página web, escribe el nombre de esta con su respectivo dominio y existen servidores llamados DNS (Servidor de Nombres de Dominio) el cual tiene una base de datos con la relación de los nombres escritos en el buscador con las direcciones IP, que le pertenecen a cada uno. Una dirección IP es un conjunto de cuatro números de 0 a 255 cada uno de ellos separados por un punto, la cual es una dirección única en el mundo, por lo que no podrá haber error de escribir una página y que el navegador lo dirija a otra. [1]
La versión que se utiliza actualmente en la dirección IP es la 4, el estándar que lleva esta normalización de las direcciones IPv4 es en la RFC 791, estándares que se establecen por el IETF (Internet Engineering Task Force), pero estas direcciones IP resultaron ser insuficientes a tal grado que en el año 1994 se creó un nuevo protocolo de internet llamado IPv6, el cual fue establecido en la estándar RFC 1883. [2]
Una dirección IP se conforma por 32 bits divididos en cuatro octetos, como anteriormente fue descrito. En otros tiempos se tenía una simple forma de organizar las IP llamado Sistema de Direccionamiento IP y que el día de hoy es llamado como Esquema de Direccionamiento con Clases. Estas clases son: [3]
Clase A: Donde los primeros 8 bits son los que identifican a la red y los restantes 24 son los que diferencian a cada host o cliente. Esta clase es normalmente asignada a grandes organizaciones con cientos de miles de millones de hosts para conectarse a internet.
17
Clase B: En esta clase los primeros 16 bits identifican a la red y los otros 16 identifican a los hosts. Normalmente este tipo de clase es usado para
organizaciones medianas con cientos de miles de hosts que necesitan conectarse a internet.
Clase C: Los bits utilizados para identificar la red son 24 y el número de bits para los hosts son de 8, esta clase es usada para organizaciones pequeñas con no más de 250 hosts para conectarse a internet.
Clase D: Para esta clase esta apartada la dieciseisava parte de las direcciones IP del mundo y estas están para la multidifusión IP.
Clase E: Al igual que la clase D esta es la dieciseisava parte de las direcciones IP, pero están reservadas para uso experimental.
2.1.3 Los paquetes
Para que la información pueda viajar por la nube es necesario que se seccione en paquetes, estos paquetes contienen la información en código binario además de la dirección IP origen y la IP destino y un tráiler, este, siendo la última parte del paquete, asegura que la información este completa al llegar al destino, el dispositivo que lo recibe toma todos estos paquetes y los vuelve a unir para mostrar la información completa. [1]
2.1.4 PHP
PHP (Hypertext PreProcessor) es una herramienta para desarrollar páginas web, realizando el diseño de interfaces dinámicas capaces de responder inteligentemente a las peticiones del cliente, logrando la automatización de tareas. Este entorno de desarrollo proporciona opciones avanzadas al programador profesional, tales como: comunicación con bases de datos, comunicación por sockets, generación de gráficos, entre otras. [4]
2.1.5 Seguridad
La computación en el mundo está siendo atacada todos los días volviendo a los sistemas de información vulnerables o en riesgo.
18 Aún cuando se disponga de un alto nivel de seguridad nunca podrá estar 100%
seguro, si un sistema, pagina web o aplicación recibe y envía paquetes es posible se personas o software malintencionado ingresen a la información. Las brechas de seguridad existentes no son problemas sencillos, tanto en la teoría como en la práctica y es necesario conocer los principios de una seguridad elevada [5]
Existen tres grandes problemas en la seguridad de la computación:
Mantener datos secretos: Las computadoras sin sistemas de información donde se manejan datos exclusivos de las empresas, esta información puede contener contraseñas que protegen el acceso a los recursos del sistema, los datos que permiten accesar a los usuarios identificados y datos de la vida personal de cada individuo que podría dañar su seguridad física.
Escasos recursos: cada computadora tiene un número limitado de ciclos por segundo del procesador, un límite en memoria, en el espacio en disco y de comunicación en la banda ancha. Parte de la seguridad es prevenir el agotamiento de estos recursos, así que ya sea por accidente o intencionalmente es necesario autentificar a los usuarios de cada sistema.
Cibernauta: cuando una computadora se conecta a Internet, la necesidad de seguridad toma otro sentido. El compromiso de que puede aparecer a los recursos locales o datos confidenciales que puedan afectar las computadoras alrededor del mundo. Cada programador y administrador de sistemas tiene la responsabilidad con otros de asegurarse que el código y los sistemas son libres de mal intenciones que podría comprometer otros sistemas en la red. Según el autor, tu reputación como buen cibernauta depende de la seguridad sobre tus sistemas “Your reputation as a good netizen thus depends on the security of your systems”. [5]
2.1.6 Base de datos
En esta sección se detalla los conceptos básicos acerca de las bases de datos, su uso y aplicaciones, esta parte es muy importante para la aplicación web ya que se almacenará toda la información en una base de datos.
2.1.7 Definición
19 Un sistema de base de datos es una colección de datos interrelacionado, La colección de datos contiene información de mucha relevancia para una empresa. La meta de estos sistemas de bases de datos es proveer una manera para guardar y obtener la información que consideremos conveniente y eficiente. [6]
Una base de datos está diseñada para procesar grandes cantidades de información.
Los manejadores de datos tienen definidas estructuras para almacenar la información y tiene mecanismos de manipulación y cualquier sistema manejador de base de datos debe estar lo suficientemente seguro para salvaguardar cada uno de los datos. [6]
El propósito de los sistemas de base de datos surgió como una respuesta para los métodos de computación para manejar los datos comerciales, principalmente de los bancos. Permitir a los usuarios la manipulación de la información, el sistema tiene un número de programas de aplicaciones que manipulan los archivos. [6]
2.1.4 Lenguaje de Consulta Estructurada (SQL)
El Lenguaje de Consulta Estructurada ha ido evolucionando a través del tiempo, con el cual se han establecido estándares del lenguaje de base de datos relacional. Así también tenemos definiciones como: [7]
Lenguaje de Definición de Datos (DDL): el cual provee comandos para la definición de esquemas, eliminar relaciones y modificarlas.
Integridad: Incluye comandos para especificar que el almacenamiento de los datos debe satisfacer.
Definición de vistas: Debe incluir comandos para la definición de vistas.
Autorización: Existen comandos para especificar el acceso correcto a las relaciones y vistas.
Lenguaje de Manipulación de Datos (DML): Esta definición incluye un lenguaje de consulta basado en el álgebra relacional y el cálculo relacional. Contiene también métodos de inserción, eliminación, actualización y establecimiento de tuplas.
20
Control de transacción: Los comandos de SQL también están para especificar el inicio y fin de las transacciones de información.
SQL Incrustado y dinámico: estos definen como las consultas de SQL pueden ser colocadas sin propósito general de los lenguajes de programación.
2.1.5 Definición de datos
El conjunto de relaciones en una base de datos debe ser especificado para un sistema por medio de un lenguaje de definición de datos. Esta DDL no solo permite especificaciones del conjunto de relaciones, sino de la información de cada una de las relaciones. [7]
En el siguiente capítulo se cubrirá el desarrollo del proyecto, con cada uno de los pasos que se siguió para ello.
21
III. Desarrollo del proyecto
3.1 Introducción
Iniciando con el desarrollo de este proyecto se definirá el diagrama que el sistema seguirá para poder satisfacer las necesidades operacionales de las plantas. Para estructurar el sistema se deben tener contemplados varios conceptos como la base de datos en donde todos los dispositivos se conectarán por medio de la interfaz para obtener los registros y resultados requeridos
3.2 Previa estructura
Ilustración 1 Diagrama general
También se tienen los dispositivos finales que son la computadora de escritorio o portátil en ambas se pueden estar consultando e ingresando los datos para resultados más precisos, también se tiene el concepto de correo electrónico ya que en éste se configurará la opción de enviar los pendientes de manera automática a los departamentos implicados.
22
3.3 Diagrama de módulos
Ilustración 2 Diagrama de modelos
Para la bitácora de operaciones de GCC, se proporcionaron los módulos que este sistema debía procesar. En primera instancia se requiere la parte de las notas, estas son mensajes que un empleado deja para que otros puedan visualizarla, ya que es de relevancia para el proceso. El segundo módulo es el de las operaciones que el encargado deberá ingresar, siendo estás las condiciones de las áreas que se tuvieron durante el turno y se deberá realizar en cada turno, las áreas para cada planta normalmente son:
El horno que es una maquinaria de forma cilíndrica, el cual gira a una determinada velocidad según el material que se esté procesando, se da la reacción química que convierte a la materia prima en cemento o mortero, teniendo una temperatura elevada.
El molino de materias primas, como su nombre lo dice, es la que tritura la materia prima que entra al horno para su proceso.
Bitácora de Operaciones
Notas
Operaciones
Paros
Pendientes
Producción
23
El molino de cemento, maquinaria que se encarga de terminar de triturar el material que sale del molino de materias primas para mejorar su finura, en algunas plantas hay un molino y en otras hay dos. Así como estás ahí otras áreas de las cuales se debe tener registro de estas operaciones.
El tercer módulo es el de los paros, en este se ingresan los paros que han tenido cada una de las áreas, teniendo en cuenta el tipo de paro, fecha y hora de inicio y de fin, la máquina que fue afectada con un código de identificación de la máquina, la naturaleza ya sea de proceso, instrumentista, ambiental, eléctrica, mecánica y otras, se registra también el síntoma y la causa del paro, así como una breve descripción del mismo.
El cuarto módulo es de pendientes, en este módulo se ingresan al sistema las tareas que van surgiendo y que deben de ser atendidas a la brevedad y, como tal, se debe de notificar al encargado de resolver cada tipo de tarea según su naturaleza. Como Quinto y último módulo se tiene el de producciones, en esta parte se registran los acumulados de cada material producido del día.
Al tener estos primeros detalles se realizaron entrevistas a los operadores del sistema principal de la sala de control para conocer su punto de vista del programa de Excel que utilizan, brindando información de la deficiencia en funcionalidad de este.
Después se realizó una entrevista a los encargados de cada área o naturaleza para saber sus inquietudes y qué es lo que ellos esperan del sistema.
Se realizó un estudio acerca de los datos que se manejaría en la bitácora diariamente y se dedujo la capacidad del servidor debía tener, para soportar esta base de datos, se tuvo una reunión previa a la realización del diseño para afinar detalles de los requerimientos de la bitácora de operaciones, en esta reunión se determinó principalmente que se debía tener una validación de usuarios y registro de movimientos del sistema, a pesar de ser este prototipo para la planta de Samalayuca se debía generar una configuración en donde otras plantas pudieran dar de alta o de baja las áreas, turnos, equipos, etcétera, Según la estructura de cada una.
24 Teniendo esta información relevante se decidió utilizar como administrador de base de datos MySQL, y se realizará el sistema usando el modelo vista controlador, se comenzó con el estudio de una herramienta proporcionada siendo un framework qué facilita el trabajo. Después se realizó el diseño de la base de datos del prototipo de la bitácora, se generaron las tablas principales de paros, operaciones, pendientes, correos, producciones, notas, configuración OEE (Overall Equipment), máquinas, síntomas y causas, registro de movimientos, cada uno con sus respectivas columnas.
Se inició el diseño de la interfaz, las vistas que cada usuario tendrá dependiendo al puesto que ocupa ya sea operador de la sala de control , encargados de cada naturaleza, gerentes de cada departamento, gerente de planta y director de división (hay un director de división Estados Unidos y otro de división México), se diseñaron las vistas que el sistema debía mostrar para cada usuario y los datos que cada uno podría ingresar o consultar, después se continuo con la interfaz de inicio de sesión en la que se brindará el usuario que provee el departamento de sistemas de la cementera y la contraseña previamente ingresada por el administrador de la base de datos.
3.4 Diagrama de clases
En el siguiente diagrama representa la organización central del sistema, enlazando la información de cada módulo y su interacción con el resto. Se definen las clases de Empleados, siendo las personas que utilizarían el sistema en sus diferentes rangos en la empresa.
Las Notas, que representan grado de importancia en el proceso y enfoque en alguna situación que esté pasando la producción o algún otro aspecto de la cementera, las Operaciones este es el resumen del estado de cada una de las áreas durante el turno, la clase de los Motivos, esta es una lista de las descripciones que pueda tener un paro, la clase de Producción, registro automático de las producciones marcadas por el sistema principal que controla toda la operación de la planta. La clase de las Naturalezas siendo estas las que determinan la organización de los datos para su proceso informativo a cada uno de los departamentos.
25 La clase de los Síntomas y las Causas este es un expendio separado por cada naturaleza, la cual define que se notó y la razón por la que se dio el paro. En la clase de GFH se describen todos los códigos y nombres de las máquinas de la planta, cada parte tiene su respectivo número de identificación. Clase de Paros, en esta clase se definen todas las características del paro, generando su enlace con otras clases para su mejor organización. La clase de Pendientes, esta clase es de las más importantes de la estructura ya que contiene la información de todas las tareas relevantes para su procesamiento y que se deben atender lo más pronto posible.
Ilustración 3 Diagrama de clases
Enseguida se define una de las clases más importantes para el sistema, la Clase de Paros, siendo compuesta por varias clases.
3.4.1 Clase de Paros
26
Ilustración 4 Clase de Paros
La clase de Paros describe esencialmente los percances que suceden en la planta, desde paros que se producen de manera programada, hasta los que suceden inesperadamente.
En esto se puede resultar en datos estadísticos que muestran las tendencias y el estado de las maquinarias.
En cada uno de los atributos de esta clase, se tienen los siguientes:
IdParo: Número de identificación de los paros.
IdNaturaleza: Número que identifica la naturaleza que le corresponde al paro.
Fecha: Es la fecha de ingreso del paro.
Turno: Es el tiempo que se generó el paro.
Equipo: La agrupación de empleados que laboraron en este turno.
Responsable: Líder del equipo a cargo de las operaciones de ese turno.
Área: Lugar donde se realizó el paro.
Tipo: Modo en que el paro se generó, ya sea Programado (posiblemente por mantenimiento) o por falla (en dado caso que se presente un percance involuntario).
27
Inicio: Fecha y hora en que el paro se produjo.
Fin: Fecha y hora en que el paro terminó y continúan las operaciones con normalidad.
GFH: Código de la maquinaria que se vió afectada.
Síntoma: Descripción de lo que se visualizó para que se diera el paro.
Causa: La razón por la que se dio el paro.
Descripción: Breve escritura que define al paro.
3.4 Diagramas de secuencia
Ilustración 5 Diagrama de secuencia de Pendientes
En este proceso el operador de la sala de control ingresa los percances que surgen durante el turno y que deben ser atendidos en breve para continuar con regularidad la operación de la planta, debido a esto, los pendientes se vuelven de alta importancia.
Al momento de que el empleado escribe el pendiente, selecciona la naturaleza (Proceso, Instrumentista, Mecánica, Eléctrica, Ambiental, Calidad y Otras), además de quien haya reportado el pendiente y quien es el empleado que le dará seguimiento, de esta manera se almacena en la base de datos y, posteriormente, el sistema conjunta los pendientes según la naturaleza y los envía a los empleados que deberán atenderlos.
28 Consecuente a esto el sistema realiza un análisis de los pendientes ingresados, relacionando el historial de las descripciones e identificando, con las coincidencias, cuáles son los puntos vulnerables de las maquinarias, también con el tiempo de ejecución del pendiente.
Ilustración 6 Diagrama de secuencia de Producciones
3.5 Proceso de construcción de la solución
Una vez terminado el diseño en papel, se comenzó a realizar la codificación de la configuración para que por medio de estas determine cada una de las plantas y sus diferentes estados.
Se realiza el diseño del módulo de configuración agregando una interfaz donde se ingresa el nombre de la planta, el número de ISO, recordando que este sistema esta validado cumpliendo las expectativas de reportes del ISO 9001.
Ilustración 7 Edición del nombre y estandarización ISO
Se agrega la sección donde se asigna el nombre del área, el tipo (En este caso si es área con operaciones y paros o solamente operaciones y, se determina, si aplica la tarifa o no.
29 Esta es la que impone la Comisión Federal de Electricidad (CFE) a las empresas para que eviten gastar gran cantidad de energía en cierto período, ya que el consumo se eleva en un determinado tiempo en la ciudad, y el sistema bloquea el registro de inicio de operación de la máquina en la que aplique, esto se debe de determinar ya que, normalmente, el horno es el que nunca debe de parar, a menos que se le haga mantenimiento; el resto de las áreas si se encuentra en esta condición.
Ilustración 8 Panel de edición de áreas
También se realizó la codificación de ingreso, edición y eliminación de nombres de equipo que, generalmente son 4 grupos en cada planta.
Ilustración 9 Panel de edición de equipos
La sección de tarifas, la cual incluye el nombre, los días y las horas en las que aplica, cualquiera de estas, puede cambiar en un cierto periodo del año, según la CFE, normalmente se encuentran entre 6:00 pm y 8:00 pm.
Ilustración 10 Panel de edición de tarifas horarias
30 Consecuente a esto se realizó la parte de configuración de los turnos, en cada planta es diferente su manejo, los turnos asignan en periodos de 12 horas (de 7 de la mañana a 7 de la noche y de 7 de la noche a 7 de la mañana) o de 8 horas (que es de 7 de la mañana a 3 de la tarde a 11 de la noche y de 11 de la noche a 7 de la mañana).
Ilustración 11 Panel de edición de turnos
Pasando a otro ámbito de la codificación, está el módulo de producción en donde se codificó la posibilidad de ingresar los estándares de producción esperados de cada día.
Ilustración 12 Panel de ingreso de estándares de la planta
31 También la interfaz donde se enlistan las secciones del proceso, como el horno, definido por el número 51 y, a partir de este, el código GFH de la maquinaria que le pertenece tienen como prefijo este número (otras secciones son los molinos de crudo, cemento, carbón, el área de la Fracción Residual Orgánica de Eficiencia Energética
“FROEE”, entre otras maquinarias).
Ilustración 13 Panel de edición de secciones de producción
Otra parte de esta configuración es donde se selecciona el archivo de Overall Equipment (OEE), este es un formato estándar que se utiliza para mostrar un resumen de las producciones, eficiencia, entre otros ámbitos de las plantas. El sistema realiza la exportación de los datos de los paros y de las producciones a este archivo de manera automática.
Ilustración 14 Panel de selección de archivo OEE
En la siguiente sección aparece la configuración de los usuarios, donde se codificó la administración de los datos de los empleados tales como el nombre del empleado, el departamento al que pertenecen, así como su correo de la planta.
32 Como siguiente instancia tenemos la configuración de las máquinas, este no es más que un listado del código que utilizan, llamado Grupo Funcional Homogéneo (GFH), con el nombre de la máquina, también se encuentra un listado de motivos que tienen un número de identificación y la descripción del mismo, son los utilizados para describir la razón por la que paró la máquina, en algunas situaciones estos motivos se repiten. Como última instancia de la configuración, se tiene la determinación del periodo en que un pendiente se encuentra activo en el sistema.
Se comenzó con el diseño de la autenticación de usuarios con una imagen distintiva de GCC y su respectiva codificación para validar usuarios. Enseguida se realizó el diseño del módulo principal con una imagen de Planta Samalayuca, el diseño de los iconos del sistema del menú y de las diferentes opciones que contiene.
3.6 Desarrollo principal
La parte principal está definida por varias secciones y cada una de ellas realiza una función importante para el desarrollo de las actividades diarias de la planta.
Ilustración 15 Ventana principal
La primera sección es la de operaciones, en este, aparecen tres diferentes módulos:
33
Módulo de Notas: El cual es un mensaje para todos los usuarios de la bitácora, este muestra una situación en la que se debe de tener cuidado durante los turnos que se encuentre habilitado.
Ilustración 16 Panel de Notas
Módulo de Operaciones: En este se ingresa la situación de cada una de las áreas.
Este es un diario del estado en el que se reciben las áreas, los movimientos que se realizaron y algún aspecto extraño en su funcionamiento. Para una descripción detallada, está disponible la opción de colocar uno o varios archivos adjuntos.
Ilustración 17 Panel de Operaciones
Módulo de Paros: En el que se encuentra una tabulación con los datos relevantes para su control diario, controles para detallado de nuevos paros, dando la posibilidad de seleccionar el tipo de paro (ya sea programado por falla), fecha y hora de inicio y de fin, el código GFH (en automático se selecciona el nombre de la máquina), la naturaleza, síntoma, causa y descripción, teniendo en cuenta que la fecha y hora de fin de paro no puede corresponder a una tarifa horaria, en esta tarifa horaria no está permitido encender la mayoría de las áreas ya que generarían una carga alta de electricidad, sólo está permitido encender el horno por su indispensable funcionamiento en sus producciones.
Ilustración 18 Panel de Paros
34
Módulo de Pendientes, estos son de gran importancia, son los altercados que se deben solucionar lo más pronto posible para no afectar la producción de cualquier material, pueden ser de las naturalezas de Proceso, Mecánica, Instrumentista, Eléctrica, Ambiental, Calidad y Otras.
Ilustración 19 Panel de Pendientes
En esta parte, el sistema inserta los registros en la base de datos, y envía los pendientes al correo de cada empleado. Mostrándolos de esta manera:
Ilustración 20 Ejemplo de correo de notificación de pendiente sin terminar
Un correo de pendiente terminado se mostrará de la siguiente manera:
35
Ilustración 21 Ejemplo de notificación de pendiente terminado
Se realizó el diseño de esta sección con la tabulación de los pendientes y campos para el ingreso de los mismos, también la forma de consulta ya sea ver los pendientes que ya han sido atendidos o no y de qué procedencia se tenga (puede ser de sala de control, junta diaria o junta de guardia).
Módulo de Producción: en este módulo se registran todas las producciones que tuvo la planta en un día determinado, ingresando los datos de la fecha, tipo de producción, cantidad producida, cantidad de merma, código de la sección, área o máquina y comentarios. También se tiene la función de exportar al archivo OEE y la tabulación que muestra las producciones mensuales.
Ilustración 22 Ventana de Producciones
36 Este sistema genera los reportes requeridos para las juntas y otras acciones de la empresa:
Operaciones diarias: Reporte en el que se muestran las operaciones que se ingresaron al sistema el día seleccionado para su revisión.
Operaciones por fechas: Reporte en el que se muestran las operaciones en un rango de fechas.
Pendientes sin terminar: Reporte que muestra todos los pendientes que no han sido atendidos.
Pendientes por fechas: Reporte que muestra los pendientes de un rango de fechas que no han sido terminados.
Pendientes mostrados: Reporte que se genera con los pendientes que se muestran con determinada búsqueda que el usuario realiza.
Paros mostrados: Reporte de paros que el usuario busca en el sistema.
Para cada uno de ellos, se tiene la opción de impresión directa, exportar a formato Excel o PDF.
Ilustración 23 Menú de reportes
En este sistema también se colocó una opción donde pueden contactar al desarrollador del sistema, para cualquier duda, comentario, sugerencia, etc. Que pueda surgir en el proceso de esta información.
37
Ilustración 24 Ventana de mensaje al programador
En esta función se deja el nombre de la persona y el mensaje, el programador recibe el mensaje incluyendo el nombre de usuario y la computadora en la que fue procesado.
El mensaje se muestra de la siguiente manera:
Ilustración 25 Ejemplo de notificación al programador de un mensaje
Con esto los usuarios del sistema pueden estar en constante comunicación para atender dudas, aclaraciones, comentarios, directamente con el desarrollador de la plataforma.
Dentro del siguiente capítulo se mostrarán los resultados que obtuvieron con este desarrollo y sus diferentes complementos, tomando en cuenta las opiniones de algunos empleados con diferentes rangos en la empresa.
38
IV. Resultados y Discusiones
4.1 Resultados
En las observaciones que se tuvieron en este proceso, se dio a relucir la forma sencilla y práctica de la utilización de esta herramienta. Los usuarios llegaron a entender rápidamente las funciones de la misma, así como el ingreso de los datos, su consulta y procesamiento.
Los comentarios recibidos acerca de esta aplicación fueron los siguientes:
Ing. Hugo Gasca, Gerente de Producción de Planta Samalayuca: “Se me ha hecho una herramienta muy buena, a mí se me facilita ver los pendientes del día a día, la operación, todo lo veo muy rápido, si ahorita se captura un pendiente, no me tengo que esperar hasta el día de mañana para que lo vea cada uno de los responsables, si sale un pendiente mecánico y si es riesgoso normalmente lo veíamos hasta mañana o el siguiente turno y se nos facilita, al momento que el operador lo captura llega rápido, eso se nos ha hecho muy bien. Hemos tenido cuatro intentos de bitácora y ninguna ha trabajado. A mí se me hace muy bien, ventajas que la podemos seguir enriqueciendo todo lo que queramos y es fácil la podemos ver por especialidad, por equipo, por turno, todo el día, o toda general, a mí me ha servido, los mensajes por correo me llegan a mi celular, no tenemos que esperar, lo tenemos todo al tiempo. Ha mejorado bastante el porcentaje del procedimiento, los operadores han batallado en algunas partes pero solo hace falta que la persona se acostumbre, al final de cuentas es una herramienta que nos está ayudando. El diseño es muy amigable, demasiado amigable, al final de cuentas es lo que me gusta que le facilita para que el operador lo capture y para que uno le entienda, muy sencillo, yo digo que así hay que hacer a nivel operativo”.
Ing. Francisco Prieto González, Gerente de Mantenimiento, Planta Samalayuca:
“El diseño a mí me parece muy profesional realmente, es una idea que surgió hace mucho tiempo y se hicieron muchos previos de bitácoras con un Excel muy básico pero el diseño que tiene ahorita realmente está muy profesional.
39 Me parece bastante sencillo, yo creo que cualquier persona con unos 10 minutos o 15 minutos de capacitación puede llenarlo realmente los campos son muy lógicos, bastante sencilla, bastante práctica, que es lo que se requiere. En realidad ha mejorado todo el sistema, la bitácora es una herramienta de ese sistema y ha sido parte esencial del mismo, pero el hecho que ya le confiamos, de que ya se obliga a que se documente ahí, que todo mundo tiene acceso desde su computadora, esa es una parte muy importante, antes no existía, antes tenías que ir a sala, todo eso ha favorecido a que el seguimiento de los pendientes sea de una manera más profesional, es la palabra, y más confiable para todo el mundo, a tal grado que ya muchos le damos seguimiento a través de esto, incluso la dirección, revisar pendientes, a veces a través de la bitácora, el director revisa el resumen que se hace de los pendientes que están en la bitácora con una minuta que se hace en las juntas, El que lleguen los pendientes por correo es una gran ventaja, llega, ves el resumen y tú puedes tomar decisiones en base a ello y puedes hablar con la gente responsable y si el pendiente es repetitivo puedes actuar o solicitar y dar instrucciones para que ya se termine con esos pendientes y se les dé prioridad”.
Ing. Jorge Godínez, Depto. Instrumentación: “A mí me parece muy funcional, muy práctica, casi toda la gente que la ha usado con poco que le expliques ya la empieza a usar, creo que cumplen con las necesidades básicas que te pedimos al inicio, incluso se excedió, positivamente lo que esperábamos, y a lo mejor tiene algunas cosas que mejorar, funciona muy bien, nos da muy buen servicio. Corre sin tener que ponerle parches o aplicaciones, es una ventaja muy buena. En la sección de pendientes, antes no se reportaban o se reportaban algunos si y otros no, ahora casi todos, y algo muy importante, también los ejecutores de los pendientes los documentamos, mediante el uso de la bitácora y le retroalimentan al cliente inicial o cliente de mantenimiento. Hay una vía oficial por la que nos solicitan algunas correcciones y por donde nosotros le retroalimentamos esas correcciones, antes era informal, verbal o a veces no informábamos ahora ya es más formalizado, oye me pediste esto, y ya termine.”
40
Ing. Luis Escárcega, Depto. Mecánica: “Está trabajando muy bien, diseño amigable, fácil de usar.
Ing. Guillermo Jaramillo, Operador de Sala de Control: “Un diseño amigable, de fácil uso, no he batallado al ingresar los datos, guarda lo escrito ”
4.2 Discusiones
Por medio de los anteriores resultados se puede destacar que la aplicación resultó estar con una interfaz comprensible para el usuario, lógicamente estructurado para que con intuición, el mismo usuario pueda, de manera autosuficiente, entender las funciones y procedimientos de la bitácora.
Los usuarios que directamente usan la Bitácora, tienen el sistema fácil de usar y que no es necesario hacer mayor esfuerzo para aprender cada función. Los empleados que indirectamente usan la bitácora, que son los que reciben las notificaciones de los pendientes, se encuentran con una manera más rápida de procesar su trabajo, así como el detalle de lo requerido y pueden eficiente su trabajo y generar respuestas rápidas a estas peticiones de trabajo. Así mismo, se ha mejorado la forma de procesar la información mediante el sistema, ya que genera los reportes que requieren para continuar con los procesos, inclusive, generar informes gerenciales.
Ya que este sistema presenta un cierto grado de organización para la planta, se ha adoptado como parte de sus procesos, en donde todas las cuestiones operacionales deben ser realizadas a través de este sistema, y se presentan los resultados de las actividades por medio de esta aplicación.
Para el usuario operativo, es realmente eficiente, poder hacer las operaciones lo más sencillo y rápido posible, por esto se dio a relucir que no es necesario un gran proceso para que él ingrese los datos para su procesamiento, ya sea de operaciones, paros, pendientes o producciones.
Para los usuarios de cada departamento resultó ser de gran ayuda para clasificar los trabajos que debían ser procesados con prontitud y se dieron cuenta que, a partir de este sistema, no tenían que esperar al siguiente día para atender estas tareas.
41 Los usuarios de nivel gerencial, tienen una forma de verificar que todos los trabajos se realicen de manera concreta, y sabiendo a quien se deben dirigir para que estos problemas sean resueltos.
42
V. Conclusiones
Analizando la organización de registros de eventos operacionales del grupo cementero, se vio la necesidad de, no solo tener un archivo donde se guarden los eventos de la operación, sino tener un sistema para su procesamiento y cumplimiento de tareas, por lo que se comenzó a desarrollar este proyecto de manera inmediata.
Se logró el desarrollo de un sistema que asiste en todo momento las necesidades de registro y documentación de los eventos de la planta, además se realizó la notificación automática de los pendientes generados, la seguridad en el sistema ya que solamente en la red de GCC se puede acceder al mismo, y la generación de reportes que, inclusive la dirección de la planta utiliza.
Durante este trabajo se realizaron diferentes funciones para satisfacer la necesidad de la empresa que, desde hace tiempo tenia y no se había logrado concretar hasta la llegada de este sistema, por lo que fue de gran impacto para las operaciones de la cementera y del mismo, aunque la intensión de este proyecto era hacer un prototipo, se comenzó a utilizar en el área operativa de la planta, dando resultados positivos con organización laboral.
Por lo tanto, se puede concluir que, por medio de esta interfaz y funcionalidad de la bitácora de operaciones, se consolidó como un sistema importante del grupo cementero, además que también, aunque el objetivo era colocarlo en planta Samalayuca ha sido adoptado por planta Juárez y, próximamente por planta Chihuahua.
Este sistema empezó a ser parte de las operaciones de la planta, con la posibilidad de volverse complejo y abundante en sus funciones, sin dejar de ser sencillo para el usuario y cumplir requerimientos para mostrar que la empresa ha mejorado en su forma de trabajar y lograr mayores certificaciones a nivel nacional.
Los trabajos futuros que se puede desarrollar y ya salieron a petición, son los siguientes:
43
Agregar una aplicación en sistema operativo Android, con la que se pueda dar de alta pendientes desde campo, agregándole una imagen para su pronto reconocimiento, y ser almacenada directamente en la base de datos.
Poder enlazar la Bitácora de Operaciones con un sistema llamado SuccessFactors, el cual se pretende genere órdenes de trabajo de manera automatizada.
Agregar un módulo de control de combustible alterno, el cual es basura que sustituye al carbón o gas.
44
Referencias
[1] J. López Quijano, Domine PHP y MySQL, México: Alfaomega, 2013.
[2] J. M. Huidobro Moya y R. J. Millán Tejedor, Redes de datos y convergencia IP, México: Alfaomega Grupo Editor, 2007.
[3] C. M. Kozierok, TCP/IP GUIDE, San Francisco: William Pollock, 2005.
[4] A. Gutiérrez y G. Bravo, PHP5 a través de ejemplos, México, D.F.: ALFAOMEGA GRUPO EDITOR S.A. de C.V., 2005.
[5] C. Snyder, T. Myer y M. Southwell, Pro PHP Security, New York: Paul Manning, 2010.
[6] A. Silverschatz, H. F. Korth y S. Sudarshan, Database system concepts, New York:
McGraw-Hill, 2011.
[7] G. Harrison y S. Feuerstein, MySQL stored procedure programming, Sebastopol, CA:
O'Reilly, 2006.
[8] L. Welling y L. Thomson, PHP and MySQL Web development, New Jersey: Upper Saddle River, 2013.
[9] H. Spona, Programación de bases de datos con MySQL y PHP, México: Alfaomega, 2010.
[10] C. Gilberto, Responsive web design with jQuery, Birmingham: Packt Publishing, 2013.
[11] M. David, HTML5: Designing rich Internet applications, New York: Focal Press, 2013.
[12] J. Duckett, HTML & CSS: design and build websites, Indianapolis, IN: John Wiley &
Sons, 2011.
[13] «Google Developers,» Google, [En línea]. Available: https://developers.google.com/.
[14] «WampServer Apache, PHP, MySQL on Windows,» WampServer, [En línea].
Available: http://www.wampserver.com/en/.
[15] F. J. Ceballos Sierra, Java interfaces gráficas y aplicaciones para internet, Madrid:
Paracuellos del Jarama, 2015.
[16] A. Bradford y P. Haine, HTML5 mastery: semantics, standards and styling, New York:
Apress, 2011.
45 [17] J. Keith y J. Zeldman, HTML5 for web designers, New York: A Book Apart, 2010.
[18] J. Gómez López, Diseño y creación de portales web, Bogotá: Ediciones de la U, 2011.
[19] S. Chris, HTTP Developer´s Handbook, Indianapolis: Sams Publishing, 2003.
46
Apéndices
Diagrama de clases
Clase SíntomaCausa
Para esta clase se enlistan todos los síntomas que pueden notarse previo a realizarse el paro, que describe que es lo que notaron los empleados para verificar si un paro debe realizarse y las listas de las causas que son los motivos por las que se dio el paro, que conlleva a una descripción mayor de la razón. En esto existen síntomas y causas para las diferentes áreas.
Ilustración 26 Clase de SintomaCausa
En esta se definen los siguientes puntos:
IdSC: Es el número de identificación de un síntoma o causa.
Naturaleza: Es el departamento al que pertenecen estas circunstancias.
Tipo: En este se determina si es síntoma o causa.
Descripción: Este es el detalle de lo que se trata el síntoma o la causa
AgregarSintoma(): En este se agrega de manera automática la descripción de los síntomas según la selección de los paros.
AgregarCausa(): En este se agrega el detalle de la causa del paro, según la selección, al momento de ingresar el registro de los paros.
47 Clase Motivos
En esta clase se detallan las descripciones de todos los paros con un número de identificación previamente colocado por una norma estandarizada en la cementera.
Ilustración 27 Clase Motivos
IdMotivo: Es la clave de identificación de los motivos que son asignados por GCC.
Descripción: Es el detalle del motivo.
IngresarMotivo(): en este método se agregan de manera automática los nuevos motivos que pueden estar surgiendo.
ActualizarMotivo(): Este es el método utilizado para editar la descripción en el dado caso que surja un error.
Clase Empleado
En esta clase se detallan los parámetros necesarios para los empleados, los cuales, son los usuarios del sistema, además de otros beneficiarios que, indirectamente, este sistema le asiste en su jornada diaria.
Ilustración 28 Clase Empleado
IdEmpleado: Número de identificación de los empleados de la cementera.
48
Nombre: Nombre de los usuarios.
Rango: Posición en la que se encuentran en la planta.
Departamento: El área en la que está asignado cada empleado.
Correo: Correo electrónico de la empresa.
IngresaUsuario(): Método en el que se agregan los usuarios del sistema.
EditarUsuario(): Método en el que se editan las características de los usuarios.
EliminarUsuario(): Método en el que se borra el registro de un empleado.
Clase Naturaleza
Clase en la que se describen todas las naturalezas o departamentos de la planta.
Ilustración 29 Clase Naturaleza
En esta se comprenden solo dos campos:
IdNaturaleza: Es el número de identificación de la naturaleza o departamento.
Nombre: Es el nombre o descripción de la misma. (Por ejemplo: Proceso, Eléctrica, Instrumentación, etc.)
Clase GFHS
En esta clase se describen los códigos de las máquinas de cada área de la planta, cada una de las maquinas lleva esta.
Ilustración 30 Clase GFHS
49
GFH: Código de identificación de la máquina.
Maquina: Nombre de la maquinaria.
AgregarGFH(): Agrega un nuevo GFH con su respectiva máquina.
EditarGFH(): Edita el nombre y el código de cada registro.
Clase Producción
En esta clase se detallan las producciones diarias de la planta, según tiempos, cantidades y códigos de áreas.
Ilustración 31 Clase Producción
IdProducción: Número de identificación de las producciones.
Inicio: Fecha y hora de inicio de la producción.
Fin: Fecha y hora de fin de la producción.
Tipo: Nombre del producto elaborado.
Producción: Cantidad en toneladas de la producción de cada tipo.
Mermas: Cantidad desperdiciada de esta producción.
GFH: Código del área en donde fue la producción.
Comentarios: Detalles existentes acerca de la producción de ese día.
50
IngresarProduccion(): Método en el que se ingresan las producciones de cada día.
ActualizarProduccion(): Método que edita la producción de cada día.
ExportarProduccionOEE(): Método que manda los datos de la Bitácora de Operaciones a un archivo estandarizado en las plantas para llevar el control diario del grupo.
ConsultarProduccion(): Método que ejecuta la búsqueda de las producciones según la fecha seleccionada y proporciona el acumulado mensual.
Clase Notas
En esta clase se describen los parámetros requeridos para procesar las notas o mensajes que se deja al resto de los empleados por un tiempo predeterminado.
Ilustración 32 Clase Notas
IdNota: Número de identificación de las notas.
Fecha: Campo en el que se almacena la fecha en que fue escrita la nota.
Responsable: Nombre de la persona que esta de responsable en ese turno.
Descripción: Escrito de la nota.
Visible: Define si la nota está o no visible para los empleados.
AgregarNota(): Método que guarda la nota al momento de escribirla.
EditarNota(): Método en el que se cambia la nota cuando es editada en el mismo día, en caso contrario se almacena una nueva nota.
51
OcultarNota(): Método en el que se ocultan las notas cuando ya no son requeridas.
Clase de Pendientes
Clase en la que se describen los pendientes generados en la planta y su respectivo seguimiento para su término.
Ilustración 33 Clase Pendientes
IdPendiente: Número de identificación del pendiente.
Turno: Sección del día en el que fue generado el pendiente.
Equipo: grupo de empleados que estuvo laborando en ese turno.
Reportó: Nombre de la persona que dio de alta el pendiente.
Responsable: Nombre del empleado que es responsable del seguimiento de este pendiente.
Descripción: Detalle del pendiente.
Naturaleza: Departamento que debe hacerse cargo del pendiente.
Procedencia: Lugar en el que surgió el pendiente.
52
Terminado: Atributo booleano que indica si el pendiente fue finalizado o no.
Comentarios: Información complementaria de la resolución del pendiente.
BajaPor: Nombre del empleado que dio termino al pendiente.
IngresarPendiente(): Método utilizado para dar de alta el pendiente.
EditarPendiente(): Método utilizado para modificar el pendiente.
TerminarPendiente(): Método que termina el pendiente de manera manual o automática.
EnviarNotificación(): Método utilizado para notificar a los empleados de un nuevo pendiente según el departamento en el que laboren.
Clase Operaciones
Clase en el que se almacena el diario de todos los movimientos de la empresa.
Ilustración 34 Clase Operaciones
IdOperación: Número de identificación de la operación.
Fecha: Campo en el que se registra la fecha de la operación.
Turno: Parte del día que fue realizada dicha operación.
Equipo: Grupo de empleados laborando en este turno.
Responsable: Líder del grupo que está en el control de las maquinas.
53
Área: Zona de la planta que está siendo descrita.
Descripción: Detalles acerca del recibimiento, funcionamiento y comportamiento del área.
AgregarOperación(): Método en el que se ingresa el registro de la operación.
EditarOperación(): Método de actualización de la operación.
AdjuntarImagen(): Método en el que se puede adjuntar una imagen al registro.
ConultarOperaciones(): Método en el que refresca las operaciones según las opciones seleccionadas.
Diagramas de secuencia:
En esta sección se muestran los diagramas de secuencia que sigue cada uno de los módulos.
Ilustración 35 Diagrama de secuencia de Configuración
54
Ilustración 36 Diagrama de secuencia de Operaciones
Figura 1 Diagrama de secuencia de Paros
