Facultad de Ingeniería Industrial Escuela Profesional de ...

UNIVERSIDAD NACIONAL DE PIURA Facultad de Ingeniería Industrial

Escuela Profesional de Ingeniería Informática PROGRAMA DE ACTUALIZACIÓN PROFESIONAL EN INGENIERÍA INFORMÁTICA

VERSION XXI – 2020

TRABAJO DE INVESTIGACION

“DESARROLLO DE UN SOFTWARE DE TEMPERATURA Y HUMEDAD PARA EL

CENTRO DE DATOS DE LA UNIVERSIDAD NACIONAL DE PIURA”

PARA OPTAR EL TÍTULO DE INGENIERO INFORMÁTICO

PRESENTADA POR:

Bach. LUIS JUNIOR CRUZ CORREA

Bach. LUIS ENRIQUE LÓPEZ MERINO

Bach. OSCAR DANIEL TALLEDO ALVARADO

ASESOR:

Dr. JONATHAN DAVID NIMA RAMOS

Línea de Investigación:

Informática, Electrónica y Telecomunicaciones

Sub línea de Investigación:

Computación

Piura, Perú

2021

UNIVERSIDAD NACIONAL DE PIURA Facultad de Ingeniería Industrial

Escuela Profesional de Ingeniería Informática




Presentado por: ------------------------------------------------ -----------------------------------------------------

Dr. Jonathan David Nima Ramos. Cruz Correa Luis Junior

Asesor Bachiller ------------------------------------------------------- ----------------------------------------------------

Lopez Merino Luis Enrique Talledo Alvarado Oscar Daniel

Bachiller Bachiller

CARTA DE COMPROMISO DEL ASESOR

"Año de la Universalización de la Salud"

Quien suscribe, Dr. Jonathan David Nima Ramos, con Documento Nacional de identidad

N°42627674, mediante la presente manifiesto que he leído y revisado de manera detallada el

proyecto de investigación titulado: “DESARROLLO DE UN SOFTWARE DE

TEMPERATURA Y HUMEDAD PARA EL CENTRO DE DATOS DE LA UNIVERSIDAD

NACIONAL DE PIURA”, presentado por el(los) tesista(s) Bach. Cruz Correa Luis Junior.

Bach. López Merino Luis Enrique. Bach. Talledo Alvarado Oscar Daniel, identificado(s) con

Documento Nacional de Identidad N° 43087466, 42787610, 43227392 respectivamente,

egresados de la carrera profesional de Ingeniería Informática, para optar el título profesional

de Ingeniero Informático. En mi condición de asesor, considero que el mencionado proyecto,

cumple con lo establecido en el Reglamento de Tesis para optar el título profesional en la

UNP y recomienda su ejecución, por lo que me comprometo a asesorar hasta la sustentación

y publicación, si fuera el caso.

Piura-Perú, 11 de diciembre de 2020

DECLARACIÓN JURADA DE ORIGINALIDAD DE LA INVESTIGACIÓN

Yo: Luis Junior Cruz Correa identificado con CU/DNI N.º 43087466, Bachiller de Escuela

Profesional de Ingeniería Informática, de la Facultad de Ingeniería Industrial y domiciliado

en Carretera Pimentel km 10.5 Urb. Los Ficus Distrito Pimentel Provincia Chiclayo

Departamento Lambayeque Celular: 966952537 Email: [email protected]

DECLARO BAJO JURAMENTO: que la investigación que presento es original e inédita, no

siendo copia parcial ni total de una tesis desarrollada, y/o realizada en el Perú o en el

Extranjero, en caso contrario de resultar falsa la información que proporciono, me sujeto a los

alcances de lo establecido en el Art. N.º 411, del código Penal concordante con el Art. 32º de

la Ley N.º 27444, y Ley del Procedimiento Administrativo General y las Normas Legales de

Protección a los Derechos de Autor. En fe de lo cual firmo la presente.

Piura 31 de enero del 2021.

…………………………….. DNI Nº43087466

Artículo 411.- El que, en un procedimiento administrativo, hace una falsa declaración en relación con hechos o circunstancias que le corresponde probar, violando la presunción de veracidad establecida por ley, será reprimido con pena privativa de libertad no menor de uno ni mayor de cuatro años. Art. 4. Inciso 4.12 del Reglamento del Registro Nacional de Trabajos de Investigación para optar grados académicos y títulos profesionales –RENATI Resolución de Consejo Directivo N.º 033-2016-SUNEDU/CD

mailto:[email protected]


Yo: Oscar Daniel Talledo Alvarado identificado con CU/DNI N.º 43227392, Bachiller

de Escuela Profesional de Ingeniería Informática, de la Facultad de Ingeniería Industrial y

domiciliado en Urb.Cossio del Pomar Mz N3 Lt 11 Distrito Castilla Provincia Piura

Departamento Piura Celular: +56934029800 Email: [email protected] DECLARO

BAJO JURAMENTO: que la investigación que presento es original e inédita, no siendo copia

parcial ni total de una tesis desarrollada, y/o realizada en el Perú o en el Extranjero, en caso

contrario de resultar falsa la información que proporciono, me sujeto a los alcances de lo

establecido en el Art. N.º 411, del código Penal concordante con el Art. 32º de la Ley N.º

27444, y Ley del Procedimiento Administrativo General y las Normas Legales de Protección

a los Derechos de Autor. En fe de lo cual firmo la presente.


……………………………

DNI Nº43227392

Artículo 411.- El que, en un procedimiento administrativo, hace una falsa declaración en relación con hechos o

circunstancias que le corresponde probar, violando la presunción de veracidad establecida por ley, será

reprimido con pena privativa de libertad no menor de uno ni mayor de cuatro años. Art. 4. Inciso 4.12 del Reglamento del Registro Nacional de Trabajos de Investigación para optar grados académicos y títulos profesionales –RENATI Resolución de Consejo Directivo N.º 033-2016-SUNEDU/CD



Yo: Luis Enrique López Merino identificado con CU/DNI N.º 42787610, Bachiller de

Escuela Profesional de Ingeniería Informática, de la Facultad de Ingeniería Industrial y

domiciliado en Ca. Gonzales Farfán MZ Z1 Lt 02 Urb. Los Ficus Distrito Piura Provincia

Piura Departamento Piura Celular: 925209405 Email: [email protected] DECLARO

BAJO JURAMENTO: que la investigación que presento es original e inédita, no siendo copia

parcial ni total de una tesis desarrollada, y/o realizada en el Perú o en el Extranjero, en caso

contrario de resultar falsa la información que proporciono, me sujeto a los alcances de lo

establecido en el Art. N.º 411, del código Penal concordante con el Art. 32º de la Ley N.º

27444, y Ley del Procedimiento Administrativo General y las Normas Legales de Protección

a los Derechos de Autor. En fe de lo cual firmo la presente.


…………………………

………………. DNI Nº42787610

Artículo 411.- El que, en un procedimiento administrativo, hace una falsa declaración en relación con hechos o

circunstancias que le corresponde probar, violando la presunción de veracidad establecida por ley, será reprimido

con pena privativa de libertad no menor de uno ni mayor de cuatro años. Art. 4. Inciso 4.12 del Reglamento del Registro Nacional de Trabajos de Investigación para optar grados académicos y títulos profesionales –RENATI Resolución de Consejo Directivo Nº 033-2016-SUNEDU/CD


UNIVERSIDAD NACIONAL DE PIURA Facultad De Ingeniería Industrial

Escuela Profesional de Ingeniería Informática




MIEMBROS DEL JURADO

MSc. Víctor Enrique Crisanto Palacios. MSc. Roxani Keewong Zapata

Secretario Vocal Dr. Moisés David Saavedra Arango

Presidente

DEDICATORIA

Agradezco a Dios y a la Buena Madre

por permitirme alcanzar este gran

sueño.

Dedico este proyecto a mis padres

Oscar y Micaela por su gran amor y

motivación, a mi amada Erly, a mis

hermanas y sobrinos, y a todas las

personas que han sido parte

fundamental para llevar a cabo este

proyecto.

Br. Oscar Daniel Talledo Alvarado

AGRADECIMIENTO

Expresamos nuestro agradecimiento a la

Universidad Nacional de Piura por

seguir apostando por la educación en

nuestro país; a nuestro asesor y

maestros por inculcarnos valores e

incentivarnos a la investigación.

A nuestras familias por su incondicional

apoyo.

INDICE

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

I. ASPECTOS DE LA PROBLEMÁTICA ............................................................................................................ 2

1.1 DESCRIPCIÓN DE LA REALIDAD PROBLEMÁTICA. ................................................................... 2

1.2 FORMULACIÓN Y PLANTEAMIENTO DEL PROBLEMA DE INVESTIGACIÓN ....................... 3

1.2.1. Problema general ........................................................................................................................ 3

1.2.2 Justificación e importancia de la investigación ....................................................................... 3

1.3 OBJETIVOS ........................................................................................................................................... 4

1.3.1. Objetivo general .......................................................................................................................... 4

1.3.2. Objetivos específicos .................................................................................................................. 4

1.4 DELIMITACIÓN DE LA INVESTIGACIÓN ......................................................................................... 4

1.4.1. Delimitación Espacial: ................................................................................................................ 4

1.4.2. Delimitación Temporal: .............................................................................................................. 4

II. MARCO TEÓRICO ....................................................................................................................................... 5

2.1 ANTECEDENTES DE LA INVESTIGACIÓN. .................................................................................... 5

2.2 BASES TEÓRICAS. .............................................................................................................................. 6

2.2.1. Norma ANSI/TIA 942 .................................................................................................................. 6

2.2.2. APP Inventor ................................................................................................................................ 6

2.2.3. Servidor en la Nube .................................................................................................................... 7

2.2.4. Raspberry PI 3 B+ ....................................................................................................................... 9

2.2.5. Raspbian .................................................................................................................................... 11

2.2.6. Python ......................................................................................................................................... 11

2.2.7. Arduino Uno ................................................................................................................................... 11

2.2.8. Lenguaje de Programación para Arduino .................................................................................. 13

2.2.9. Medición de la Temperatura ........................................................................................................ 13

2.2.10. Administración De Bases De Datos En La Nube (Base De Datos Como Servicio) ............. 14

2.2.11. Proteus ............................................................................................................................................ 15

2.2.12. Proceso Unificado de Rational (Rational Unified Process, RUP) ........................................... 16

2.2.13. UML ................................................................................................................................................. 18

2.2.14. Centro de Datos ............................................................................................................................ 19

2.3 GLOSARIO DE TÉRMINOS BÁSICOS............................................................................................ 20

2.4 MARCO REFERENCIAL .................................................................................................................... 21

2.4.1. Oficina Central de Informática y Telecomunicaciones. ....................................................... 21

2.4.2. Misión. ........................................................................................................................................ 21

2.4.3. Visión. ......................................................................................................................................... 21

III. MARCO METODOLÓGICO. .................................................................................................................. 22

3.1 ENFOQUE Y DISEÑO ........................................................................................................................ 22

3.2 SUJETOS DE LA INVESTIGACIÓN ................................................................................................. 22

3.3 MÉTODOS Y PROCEDIMIENTOS. ................................................................................................. 22

3.3.1 Método ........................................................................................................................................ 22

3.3.2. Procedimiento ................................................................................................................................... 23

3.4 TECNICAS E INSTRUMENTOS ....................................................................................................... 67

3.5 ASPECTOS ÉTICOS ......................................................................................................................... 67

REFERENCIAS BIBLIOGRÁFICAS ................................................................................................................. 75

ANEXOS ............................................................................................................................................................... 77

INDICE DE FIGURAS

Figura 2.1. Estructura de la norma ANSI/TIA- 942 ........................................................................................... 6

Figura 2.2. Raspberry pi 3 B+ ............................................................................................................................... 9

Figura 2.3. Pines de Raspberry Pi 3 B+ ............................................................................................................. 10

Figura 2.4. Arduino Uno...................................................................................................................................... 12

Figura 2.5. Sensor de temperatura y humedad DHT11. ................................................................................... 14

Figura 2.6. Tradicional VS servicios de datos en la nube ................................................................................. 15

Figura 2.7. Metodología RUP .............................................................................................................................. 16

Figura 2.8. Fases de RUP ..................................................................................................................................... 17

Figura 2.9. Diagrama de caso de uso validación de usuario ............................................................................. 40

Figura 2.10. Diagrama de caso de uso sesión de usuario .................................................................................. 41

Figura 2.11. Diagrama de caso de uso gestión de usuario ................................................................................ 41

Figura 2.12. Diagrama de caso de uso gestión de Permisos y Tipo de usuario. ........................................... 42

Figura 2.13. Diagrama de caso de uso gestión de sensores ............................................................................... 42

Figura 2.14. Diagrama de caso de uso diagrama general del sistema .............................................................. 43

Figura 2.15. Diagrama de secuencia, validación de usuario. ............................................................................ 47

Figura 2.16. Diagrama de secuencia, consultar variable. ................................................................................. 48

Figura 2.17. Diagrama de colaboración, validación de usuario. ...................................................................... 49

Figura 2.18. Diagrama de colaboración, consultar variable............................................................................. 50

Figura 2.19. Diagrama de actividades, iniciar sesión ........................................................................................ 51

Figura 2.20. Diagrama de actividades, consultar variable. .............................................................................. 52

Figura 2.21. Diagrama de actividades, envió de notificación. .......................................................................... 53

Figura 2.22. Diagrama de componentes ............................................................................................................. 54

Figura 2.23. Diagrama de despliegue del sistema ................................................................................................. 54

Figura 2.24. Captura de Pantalla del Login del aplicativo web sistema control de temperatura y humedad.

............................................................................................................................................................................... 56

Figura 2.25. Captura de pantalla del Inicio de sesión del sistema ................................................................... 57

Figura 2.26. Captura de pantalla del módulo de usuario ................................................................................. 57

Figura 2.27. Captura de pantalla de registro de usuario. ................................................................................. 58

Figura 2.28. Captura de pantalla de listado de usuarios. ................................................................................. 58

Figura 2.29. Captura de pantalla del módulo sensor. ....................................................................................... 59

Figura 2.30. Captura de pantalla del módulo reporte. ..................................................................................... 60

Figura 2.31 Diagrama de base de datos. ............................................................................................................. 61

Figura 2.32. Captura de Diagrama de clases. .................................................................................................... 65

Figura 2.33. Comunicación entre las capas del sistema. ................................................................................... 66

Figura 2.34. Prueba física del sensor. ................................................................................................................. 68

Figura 2.35. Prueba física cambio de temperatura. .......................................................................................... 69

Figura 2.36. Prueba física cambio de temperatura. .......................................................................................... 70

Figura 2.37. Prueba física temperatura ambiente. ............................................................................................ 71

Figura 2.38. Prueba física del control de temperatura y humedad. ................................................................ 71

INDICE DE TABLAS

Tabla 2.1. Precisión y rendimiento DHT11. ............................................................................................... 14

Tabla 2.2. Definición del problema ............................................................................................................. 24

Tabla 2.3. Requerimiento validar usuario. ................................................................................................ 25

Tabla 2.4. Requerimiento cerrar. ............................................................................................................... 26

Tabla 2.5. Requerimiento actualizar contraseña. ...................................................................................... 26

Tabla 2.6. Requerimiento nuevo usuario. .................................................................................................. 27

Tabla 2.7. Requerimiento actualizar usuario. ........................................................................................... 27

Tabla 2.8. Requerimiento eliminar usuario. .............................................................................................. 28

Tabla 2.9. Requerimiento crear tipo de usuario. ....................................................................................... 28

Tabla 2.10. Requerimiento eliminar tipo de usuario. ............................................................................... 29

Tabla 2.11. Requerimiento actualizar tipo de usuario. ............................................................................. 29

Tabla 2.12. Requerimiento asignar permiso a tipo de usuario. ............................................................... 30

Tabla 2.13. Requerimiento presentar pantalla de inicio. .......................................................................... 31

Tabla 2.14. Requerimiento generar respaldo. ........................................................................................... 32

Tabla 2.15. Requerimiento habilitar y deshabilitar sensor. ..................................................................... 33

Tabla 2.16. Requerimiento configurar parámetros de valores del sensor de temperatura y humedad.

....................................................................................................................................................................... 34

Tabla 2.17. Requerimiento envío de alarmas. ........................................................................................... 35

Tabla 2.18. Requerimiento mostrar última lectura del sensor. ................................................................ 35

Tabla 2.19. Requerimiento visualizar reportes de eventos de sensor. ..................................................... 36

Tabla 2.20. Requerimiento visualizar reportes de eventos de sensor. ..................................................... 36

Tabla 2.21. Requerimiento exportar reportes a archivos. ........................................................................ 37

Tabla 2.22. Requerimiento de seguridad. .................................................................................................. 37

Tabla 2.23. Requerimiento interfaz de usuario. ........................................................................................ 37

Tabla 2.24. Requerimiento interfaz de hardware. .................................................................................... 38

Tabla 2.25. Requerimiento interfaz de software. ...................................................................................... 38

Tabla 2.26. Roles de los módulos ................................................................................................................ 39

Tabla 2.27. Descripción de caso de uso, validación de usuario. ............................................................... 44

Tabla 2.28. Descripción de caso de uso, sesión de usuario. ....................................................................... 44

Tabla 2.29. Descripción de caso de uso, gestión de usuarios .................................................................... 45

Tabla 2.30. Descripción de caso de uso, gestión de permisos y tipo de usuario. ..................................... 45

Tabla 2.31: Descripción de caso de uso, gestión de sensores. ................................................................... 46

Tabla 2.32. Diccionario de datos tabla usuario.......................................................................................... 62

Tabla 2.33. Diccionario de datos tabla rol.................................................................................................. 62

Tabla 2.34. Diccionario de datos tabla rol_operaciones. .......................................................................... 63

Tabla 2.35. Diccionario de datos tabla operaciones. .................................................................................. 63

Tabla 2.36. Diccionario de datos tabla modulo. ......................................................................................... 63

Tabla 2.37. Diccionario de datos tabla lectura. .......................................................................................... 64

Tabla 2.38. Diccionario de datos tabla alarma. .......................................................................................... 64

Tabla 2.39. Diccionario de datos tabla alarma_humedad. ........................................................................ 65

Tabla 2.40. Técnicas e instrumentos. .......................................................................................................... 67

Tabla 2.41. Matriz de consistencias. ............................................................................................................ 77

RESUMEN

El presente proyecto para solicitar la obtención del título de ingeniero consiste en el desarrollo de un software de temperatura y humedad para un Data Center a través de la implementación de diferentes dispositivos (sensor DHT11, Raspberry pi,) para recopilar al usuario un histórico de las mediciones de variables más resaltantes (temperatura, humedad) en todo el proceso de monitoreo. Para poder lograr estas medidas hemos usado un sensor DHT11 el emite las medidas de temperatura y humedad estas variables será medidas y enviadas al Raspberry mediante las conexiones el cual recibirá los datos y los enviara a un servidor mediante el cable ethernet para poder luego realizar una comunicación con la aplicación creada en PHP para almacenar los datos en la base de datos SQL, tendremos luego la representación gráfica de las medidas de temperatura y humedad por intervalos de tiempo, para poder ver el comportamiento de las variables con el pasar del tiempo, además le permite al usuario final poder descargar históricos de un Excel2013 para realizar análisis estadísticos. Palabras clave: Desarrollo, proceso de monitoreo, análisis estadísticos, Data Center, sensor.

ABSTRACT

The present project to apply for the degree of engineer consists in the development of temperature and humidity monitoring for a Data Center through the implementation of different devices (DHT11 sensor, Raspberry pi,) to collect from the user a history of the most outstanding variable measurements (temperature, humidity) throughout the monitoring process. In order to achieve these measurements we have used a DHT11 sensor which emits the temperature and humidity measurements these variables will be measured and sent to the Raspberry through the connections which will receive the data and send it to a server using the ethernet cable so that we can then communicate with the application created in PHP to store the data in the SQL database , we will then have the graphical representation of temperature and humidity measurements by time intervals, to be able to see the behavior of the variables over time, in addition it allows the end user to be able to download historicals from an Excel2013 to perform statistical analysis. Key words: development, monitoring process, statistical análisis, data center, sensor.

1

INTRODUCCIÓN En la actualidad la información cumple un rol importante dentro del crecimiento de las empresas, esto ha llevado a que tengan un respaldo confiable, seguro y duradero, por ello, estas se han visto en la necesidad de implementar sus propios centros de datos que son lugares especializados de gestión de datos que permiten la integración y control de los sistemas de información de manera eficiente. Los centros de datos trabajan las 24 horas del día y los datos almacenados en los servidores tienen un crecimiento constante, lo que genera un incremento de operaciones para acceder a la información requerida, esta sobrecarga de trabajo hace que sus componentes sufran un aumento de temperatura. Si esta alcanza un punto crítico, los dispositivos de los servidores no podrán funcionar correctamente y en el peor de los casos la recarga de temperatura dañará al procesador. De ahí nace la importancia que los centros de datos tengan un sistema de monitoreo que mantenga la temperatura y humedad en rangos óptimos para un buen funcionamiento. El presente proyecto tendrá como objetivo desarrollar un software de temperatura y humedad para el centro de datos de la Universidad Nacional de Piura (UNP), para el mejor funcionamiento de sus equipos, esto se llevará a cabo bajo los estándares recomendados de la norma ANSI/TIA (norma de telecomunicaciones para la infraestructura de un centro de datos). Esta investigación se encuentra estructurada en 5 capítulos, que de forma resumida se detallarán a continuación. En el capítulo I se encontrará la realidad problemática, el planteamiento del problema como tal, que fue lo que nos motivó a realizar el estudio sobre la temperatura y humedad del centro de datos (OCIT), de la misma manera se detalla la justificación e importancia, los objetivos a alcanzar y delimitación del mismo. En el capítulo II se encontrará el marco teórico, que comprende los antecedentes del estudio y se fundamentará teóricamente. En el capítulo III de este proyecto se hallará el marco metodológico, que contempla el enfoque, diseño, nivel y tipo de investigación, así como la metodología RUP que se utilizará para el análisis, implementación y documentación del mismo. Terminando este capítulo se encuentran los aspectos éticos que están basados en la Ley Nro. 28611- Ley general del ambiente y así contribuir a una efectiva gestión. En el capítulo IV de este proyecto tenemos las referencias bibliográficas las cuales están redactadas con el formato APA, esto facilitará la ubicación de las fuentes citadas en los textos. En el capítulo V y último, tenemos los anexos donde encontraremos la matriz básica de consistencia que nos permite observar la lógica interna de la propuesta de estudio.

2

I. ASPECTOS DE LA PROBLEMÁTICA

1.1 DESCRIPCIÓN DE LA REALIDAD PROBLEMÁTICA.

Hoy en día las grandes empresas disponen de un enorme y creciente volumen de datos, ante esto tienen la necesidad de implementar sus propios centros de datos, que es un ambiente que contiene componentes electrónicos de red como UPS, Switch, firewall, además de comunicaciones unificadas como servidores, telefonía IP, controladores inalámbricos, entre otros dispositivos que están conectados mediante una red de cableado estructurado que pueden ser de cobre o de fibra óptica, el funcionamiento diario de estos equipos conllevan a disipar calor lo cual hace que frecuentemente varíen sus temperaturas ocasionando recalentamiento y con probabilidades altas de poder dañarse. Gallegos, (2018). En su tesis “Desarrollo de un software de monitoreo y predicción en tiempo real de incidencias ambientales para Data Center de Telecomunicaciones” hace mención que la empresa de Telecomunicaciones Bitel, no se llevaba un control adecuado de los valores ambientales en el centro de datos. Se registró un sobrecalentamiento de los equipos de red debido a la avería del sistema de ventilación y genero el alarmado de superación del límite de temperatura. Este problema dejó una pérdida de más de $600 000 dólares en equipos, que, al haber tenido un monitorio correcto con una predicción de fallos, se hubiese tenido un tiempo de reacción mayor a 30 minutos antes del incidente. De igual manera, se menciona diversos incidentes ocasionados por fallos ambientales como en el Banco de la Nación, Claro, etc. En EEUU el 28 de agosto del 2015 en el centro de datos del Century Link se incendiaron servidores por las altas temperaturas de trabajo causado por las fallas del sistema de aire acondicionado. Este centro de datos no contaba con un software de monitoreo de temperatura y humedad adecuado. Hoy en día las empresas que tienen un centro de datos, se ven afectadas por diferentes niveles de temperatura y humedad que existen en estos ambientes; al no llevar un control adecuado de monitoreo, perjudican el funcionamiento de su sistema lo cual conlleva al deterioro de sus equipos y por ende a la pérdida de información. Esta realidad es la misma en la Oficina Central de Informática y Telecomunicaciones (OCIT) que se encuentra en la Universidad Nacional de Piura, donde el aire acondicionado deja de funcionar por averías externas o por falta de mantenimiento a sus equipos de refrigeración. Cuando pasa esto sus servidores se sobrecalientan y como consecuencia directa los equipos se apagan y todo su sistema de información quedan sin funcionar. Cuando sus técnicos o encargados del Centro de Datos iban al OCIT se encontraban con equipos dañados por el sobrecalentamiento ocurrido. Ante esta situación se planteará el desarrollo de un software de monitoreo de temperatura y humedad para el centro de datos de la Universidad Nacional de Piura (OCIT), que ayude a que sus equipos tengan un pleno funcionamiento y una mayor duración de vida, con ello no solo ahorrarían costos de daño, sino que asegurarían la información almacenada en ella.

3

1.2 FORMULACIÓN Y PLANTEAMIENTO DEL PROBLEMA DE INVESTIGACIÓN

1.2.1. Problema general

¿De qué manera se desarrollará el Software de temperatura y humedad para el Centro de Datos de la Universidad Nacional de Piura?

1.2.2 Justificación e importancia de la investigación

1.2.2.1 Justificación

En la actualidad la necesidad de contar con información confiable en las empresas a dado paso a la evolución de los centros de datos; es de suma importancia para ellos asegurar el adecuado desempeño de sus equipos que lo conforman, así como prevenir y salvaguardar la información ya sea por variantes de temperatura o error humano. Los picos de temperatura y humedad pueden causar graves daños a los equipos y con ello la inactividad inesperada de un servidor originando caos en la empresa, como también en los usuarios de la misma y hasta la suspensión de operaciones de la organización. La humedad es la amenaza menos visible dentro de un centro de datos. A medida que aumenta la temperatura del aire, aumenta la capacidad para retener agua, por lo cual es fundamental mantener la temperatura controlada. Cuando el aire frío pasa desde el frente de los servidores, sale con mayor temperatura y con mayor capacidad de retener agua. Muchas empresas no tienen la capacidad de prevenir estos tipos de eventos y mucho menos advertirlos cuando se presentan.

Para Pacio (2014) la importancia de un centro de datos es sin duda el rol estratégico que cumple para el buen desarrollo de cualquier empresa a la hora de proteger el correcto funcionamiento del sistema ya que una interrupción es sus servicios (de red eléctrica o enfriamiento) puede impactar a los servidores generando millones de dólares en pérdidas económicas directas o indirectamente por ese motivo es vital tener el control completo sobre las instalaciones para saber qué pasa en todo momento y en caso de problemas, trabajar de forma inmediata en el problema presentado.

El desarrollo del software de monitoreo de temperatura y humedad para el Centro de Datos de la Universidad Nacional de Piura, ayudará a que sus equipos tengan un buen control y una mayor duración de vida, con ello no solo ahorrarían costos de daño, sino que asegurarían la información almacenada en ella.

1.2.2.2 Importancia

En el aporte práctico es importante porque el desarrollo de un software de monitoreo de temperatura y humedad beneficiará a la UNP para el buen funcionamiento de los equipos que se encuentran en su centro de datos. En lo científico la investigación contribuirá en el modelo de desarrollo de un software de monitoreo de temperatura y humedad para centro de datos, este desarrollo ayudará como base a las investigaciones posteriores. Y para las empresas el desarrollo de un software permitirá monitorear las variantes de temperatura y humedad en el centro de datos, contribuyendo al buen funcionamiento de sus equipos, obteniendo beneficios económicos y salvaguardando su información.

4

1.3 OBJETIVOS

1.3.1. Objetivo general

Desarrollar un software de temperatura y humedad para el centro de datos de la Universidad Nacional de Piura.

1.3.2. Objetivos específicos

• Identificar los requerimientos en la fase de inicio de la metodología RUP del

desarrollo de un software de monitoreo de temperatura y humedad para el centro de datos de la Universidad Nacional de Piura.

• Diseñar el software de monitoreo de temperatura y humedad para el centro de datos de la Universidad Nacional de Piura en la fase de elaboración de la metodología RUP.

• Implementar el software de monitoreo de temperatura y humedad para el centro de datos de la Universidad Nacional de Piura en la fase de construcción de la metodología RUP.

• Alinear el software a los parámetros de la norma ANSI/TIA

1.4 DELIMITACIÓN DE LA INVESTIGACIÓN

1.4.1. Delimitación Espacial:

Esta investigación se realizará para el centro de datos de la Universidad Nacional de Piura ubicada en la Urbanización Miraflores s/n del distrito de castilla, provincia de Piura, departamento de Piura.

1.4.2. Delimitación Temporal:

La investigación se realizará desde el 21 de noviembre del 2020 hasta marzo del 2021.

5

II. MARCO TEÓRICO

2.1 ANTECEDENTES DE LA INVESTIGACIÓN.

Medina, (2014). Ex alumno de la Facultad de Ciencias Exactas y Tecnologías Aplicadas en su tesis “Diseño e implementación de un sistema de climatización para el Data Center de la corporación CENACE” realizan un enfoque principalmente en el estudio a fortalecer el funcionamiento de los equipos albergados en la Data Center del Centro Nacional de Control de Energía CENACE, mediante el estudio térmico de los dispositivos y análisis de flujo de aire. También trata del diseño e implementación de un módulo de adquisición de datos que permitirá analizar, monitorear y generar un registro de información del comportamiento de la temperatura y humedad de manera ininterrumpida. Se relaciona con el proyecto porque se enfoca en monitorear la temperatura de los equipos albergados en el centro de datos. Sánchez y Tintinago, (2015). Ex alumnos de la Facultad de Ingeniería de Sistemas en la Universidad Politécnica Salesiana de Guayaquil en su tesis “Análisis, diseño e implementación de un prototipo para un dispositivo de monitoreo ambiental de centros de cómputo de bajo costo basado en tecnología ARM y software de código abierto aplicable a una pequeña y mediana empresa” realizan un enfoque sobre la existencia de riesgo de interrupción de la continuidad del negocio a causa de la indisponibilidad de las tecnologías de la información y comunicación (TIC) debido a la falta de monitoreo y control de los factores físicos y ambientales que provocan fallos en los equipos ubicados en los centros de cómputo de las pymes en Ecuador. Aporta al proyecto la implementación de software de código abierto y hardware de bajo costos

Quiñones, (2008). En su tesis titulada “Auditoría de los Sistemas Informáticos de la Escuela de Postgrado de Chiclayo de la Universidad Nacional Pedro Ruiz Gallo”, pretendió determinar los problemas bajo la modalidad de auditoría de sistemas que se presentan en la unidad de Informática de la escuela de postgrado de esta universidad. El estudio realizado definió varias falencias en la gestión de seguridad física y lógica de esta unidad informática puntualizando en problemas como: pérdida de información confidencial por falta de control de acceso de usuarios, deterioros de los equipos de cómputo por variantes de temperatura y ausencia de medidas de prevención de catástrofes como incendios. Según esta tesis, gracias a la auditoría se logró determinar qué aspectos estaban fallando, mejorando la gestión de la seguridad física y lógica en la unidad de informática de la escuela de posgrado de esta Universidad. Según las conclusiones se logró mejorar al 100% las pérdidas de información incorporando un adecuado control de acceso del personal a las instalaciones de CPD. El aporte para el proyecto es el análisis del tipo de variables de Temperatura y humedad para el centro de datos, esto significará un gran aporte frente a las condiciones tradicionales de nuestro entorno.

6

2.2 BASES TEÓRICAS.

2.2.1. Norma ANSI/TIA 942

La norma TIA-942 fue hecha para especificar la manera de cómo diseñar la infraestructura de un centro de datos cubriendo áreas como distribución del espacio, del cableado y consideraciones del ambiente apropiado (Bracamonte, 2016). De acuerdo con la norma ANSI/TIA-942 (Normas de Telecomunicación para la Infraestructura de centro de datos) se detallará los rangos para las variables ambientales que se utilizará en el software propuesto. Esta norma es seguida por todos los centros de datos para una mejor administración ambiental (Muccio, 2012). En la figura 2.1 se muestra la estructura estándar para el centro de datos.

Figura 2.1. Estructura de la norma ANSI/TIA- 942 Fuente: (Bracamonte,2016)

Según la norma los parámetros operacionales de la temperatura, la humedad y punto de rocío se deben controlar según los siguientes rangos continuos de funcionamiento:

• Temperatura de bulbo seco: 20 °C (68 °F) a 25 °C (77 °F)

• Humedad relativa del aire: 40% a 55%

• Punto de rocío máximo: 21 °C (69.8 °F)

• Tasa máxima de cambio: 5 °C (9 °F) por hora

• Equipos de humidificación y deshumidificación pueden ser requeridos

dependiendo de las condiciones ambientales locales. La temperatura ambiente y la humedad se miden después de que el equipo esté en funcionamiento. Las mediciones se realizan a una distancia de 1,5 m (5 ft) por encima del nivel del suelo cada 3 m a 6 m (10 ft a 30 ft), a lo largo de la línea central de los pasillos fríos y en cualquier ubicación en la toma de aire de los equipos de funcionamiento. Las mediciones de temperatura se deben de tomar en varios lugares de la toma de aire de cualquier equipo con posibles problemas de refrigeración.

2.2.2. APP Inventor

App Inventor es un entorno de desarrollo de aplicaciones para dispositivos Android. Para desarrollar aplicaciones con App Inventor sólo necesitas un navegador web y un teléfono o Tablet Android (si no lo tienes podrás probar tus aplicaciones en un emulador). App Inventor se basa en un servicio web que te permitirá almacenar tu trabajo y te ayudará a realizar un seguimiento de tus proyectos.

7

Se trata de una herramienta de desarrollo visual muy fácil de usar, con la que incluso los no programadores podrán desarrollar sus aplicaciones (Wolber, 2011). Para crear aplicaciones en App Inventor se tiene las siguientes fases:

1.- En el proceso del diseño se muestra el display de un teléfono celular inteligente en el que se va a desarrollar una interfaz de usuario en la que se puede agregar distintas partes: botones, imágenes, texto, audio, etc. Además, esta herramienta toma en cuenta el aspecto gráfico, comportamiento, etc.

2.- El editor de bloques es el que permite mediante el uso de bloques realizar la programación de una forma visual e intuitiva con el flujo del funcionamiento de un programa etc.

3.- Cuando ya se ha terminado la aplicación se puede generar el instalador APK para teléfonos celulares inteligentes Android y se obtiene un código QR (Quick Response Code, Código de Respuesta Rápida) para realizar su descarga (Wolber, 2011).

Para proceder a utilizar el software App Inventor se tiene que acceder a la dirección: http://ai2.appinventor.mit.edu/ a través del navegador, si ya se tiene una cuenta Google, se procede a ingresar a la misma mediante el usuario y contraseña (Gray, 2012). Esta herramienta de software permite escoger el idioma requerido y testear las aplicaciones directamente de dos formas:

• En la primera opción se conecta el dispositivo Android a la Pc o Laptop para realizar el testeo y consiste en la instalación de la aplicación MIT AI2 Campanion para establecer la conexión requerida con la página web http://ai2.appinventor.mit.edu/. Como requerimiento se necesita que la Pc o Laptop y el dispositivo Android se encuentren en la misma red (Gray, 2012).

• La segunda opción para testear es mediante una conexión USB desde el

ordenador al dispositivo Android (Gray, 2012).

2.2.3. Servidor en la Nube

El servidor en la nube se define como una infraestructura que puede ser virtual o física para almacenar datos y procesar aplicaciones e información. Este está creado mediante la división de un servidor físico en varios servidores virtuales. Para procesar cargas de trabajo y guardar información se requiere la utilización de un modelo de Infraestructura como servicio (IaaS). Se puede tener acceso al servidor virtual mediante el uso de una interfaz de forma remota (Prahland, 2012; McCrory, 2009).

Las características principales de un servidor en la nube son: Basándose en el uso de la infraestructura de computación, el servidor puede ser físico, virtual, o una combinación de ambas.

• Posee la capacidad de un servidor local.

• Puede almacenar información de grandes volúmenes y cargas de trabajo

intensivos.

• Con el propósito de acceder bajo demanda a servicios

automáticos es indispensable el uso de APIs (Application

Programming Interface, Interfaz de programación de

aplicaciones).

• Existe la posibilidad de realizar el pago mensualmente o por consumo.

• En función de las necesidades se puede escoger un plan de hosting

about:blank

about:blank

http://ai2.appinventor.mit.edu/

about:blank

about:blank

8

compartido

• Escalable (Prahland, 2012).

La rentabilidad en los servidores en la nube permite que el usuario u organizaciones interesadas paguen por lo que requieren y por consiguiente el gasto de mantener el hardware del servidor se reduce (Chen, 2016). Con el objetivo de satisfacer las necesidades cambiantes los usuarios pueden escalar los recursos de informática y almacenamiento para empresas que tienen necesidades cambiantes (Prahland, 2012; McCrory, 2009). Clasificación de los tipos de nube: Nube privada o dedicada: Usualmente esta nube es usada para una empresa u organización en la que se tiene hardware dedicado, tiene un mejor rendimiento en general y es una gran opción para la seguridad (Yin, 2017). El despliegue de esta nube generalmente se realiza en un proveedor de servicios o en las oficinas de los usuarios o clientes. El uso de un centro de datos externo es recomendado ya que es eficaz en temas de seguridad (D. Wolber, 2011; Yin, 2017). Las ventajas de esta nube es que la seguridad es mayor a cualquier otra nube que se utilice, ayudando a los procesos internos de seguridad y confiabilidad, el rendimiento también es superior ya que este hardware no se comparte con otros clientes. El costo del uso de este servidor es mayor, pero es justificado frente a sus ventajas (Chen, 2016). Nube pública o compartida: Esta nube da un servicio donde el almacenamiento de la información y la memoria se utiliza de forma compartida entre todos los usuarios de la red. El usuario debe tener una gran habilidad técnica ya que realiza el trabajo por medio del despliegue de un portal. Las ventajas de este tipo de nube es que no existen contratos para tener permanencia, hay una autonomía para administrar recursos, existe la posibilidad de tener servicios híbridos y ahorrar en los costos (Chen, 2016; Yin, 2017). Las desventajas de este tipo de nube son que no se tienen políticas de privacidad y confidencialidad para sus procesos internos. Pueden existir brechas de seguridad ya que no hay destrucción inmediata de los datos al quitar el servicio, la información que yace en la nube queda expuesta. Si el cliente no es experto los costos son altos ya que se requiere soporte. Nube comunitaria: Es una nube que funciona agrupando a empresas, organizaciones que tienen necesidades en común y por lo tanto se abaratan los costos (Chen, 2016). Nube Híbrida: Con el fin de conmutar datos o extender funcionalidades diferentes las nubes se fusionan de dos o más grupos permitiendo la realización de los planes de continuidad de negocios y extender los servicios por muchas localizaciones geográficas. Es recomendada para centros de datos ya que requiere una red de alta velocidad (Yin, 2017).

9

2.2.4. Raspberry PI 3 B+

Figura 2.2. Raspberry pi 3 B+ Fuente: (Alchemister, 2016)

Es una minicomputadora con una placa reducida SBC de costo bajo. Raspberry Pi usa hardware libre y tiene funcionamiento en base al microcontrolador ATmega644. Fue desarrollado en Reino Unido con el objetivo de ser un ordenador desnudo, es decir, que se pueden eliminar accesorios sin que se vea afectado el funcionamiento de este (Upton, 2014).

Raspberry pi 3 B+ viene con una capacidad inalámbrica mejor a sus antecesores, con W802.11ac de doble banda que funciona con 2.4 GHz y 5 GHz proporcionando un mejor alcance en entornos inalámbricos desafiantes (Upton, 2014). El blindaje de metal que está pintado en el lado superior actúa como un disipador de calor y de presión, pero es recomendable adaptar otros disipadores para reducir el calentamiento de los circuitos. Con respecto a los modelos anteriores de Raspberry Pi el modelo B+ es tres veces más rápido que el Pi 2 y 3 por lo tanto es capaz de ejecutar múltiples funciones a un ritmo bastante aceptable (Upton, 2014). El Raspberry Pi 3 Modelo B+ es el último modelo lanzado al mercado en el rango de Raspberry Pi 3. Las partes de la Raspberry pi son:

• Broadcom BCM2837B0, Cortex-A53 64-bit SoC a 1.4GHz. 2.4GHz y 5GHz IEEE802.11.b/g/n/ac Wireless LAN. Bluetooth 4.2, BLE.

• RAM de 1GBLPDDR2 SDRAM.

• Gigabit Ethernet sobre USB 2.0 (Máximo throughput 300Mbps).

• buses USB 2.0. • 1 puerto HDMI.

• Puerto para display MIPI DSI. Puerto para cámara MIPI CSI. • salidas estéreo polo y puerto de video compuesto. Pines para la entrada

y salida con objetivo general. Salida analógica de video RCA. • Alimentación por medio de un conector micro USB de 5V máximo. Lector

10

de Tarjetas SD. • H.264, decodificador MPEG-4 (1080p30); codificador H.264 (1080p30);

OpenGL ES 1.1, 2.0 para gráficos multimedia (Zhao, 2015)

Figura 2.3. Pines de Raspberry Pi 3 B+ Fuente: (Zhao, 2015)

Raspberry pi 3 B+ posee un encabezado de 4 pines que está agregado al tablero situado cerca del encabezado de 40 pines. Este encabezado de 4 pines permite el uso de PoE (Power Over Ethernet, Alimentación a través de Ethernet) en otras palabras, brinda la corriente eléctrica que necesita el dispositivo ya que utiliza cables de datos en vez de cables de alimentación reduciendo la cantidad de cables que se necesitan la instalar un dispositivo en los proyectos que se realice con Raspberry (Upton, 2014; Zhao, 2015).

El encabezado poseedor de los 40 pines es utilizado para el realizar la conexión externa con la Raspberry y en la versión B+ se tiene que es igual a las anteriores. De la cabecera de 40 pines se usan 26 para pines de entrada y salida E/S digitales y 9 de los 14 pines que quedan son denominados pines de E/S dedicados, lo que muestra que no vienen con una función alternativa (Upton, 2014; Zhao, 2015). Los pines 3 y 5 poseen una resistencia de extracción de 1.8 KΩ y los pines 27 y 28 se encuentran dedicados a la ID EEPROM (ID Electrically Erasable Programmable Read- Only Memory, Identificación de la ROM programable y borrable eléctricamente) El cabezal GPIO (General Propósito Input/Output, Entrada/Salida de Propósito General) esta reposicionado para permitir un mayor espacio en el orificio de montaje extra (Upton,2014). Los sistemas operativos soportados por Raspberry son de software libre como Linux, que tiene muchas alternativas con sus diferentes sistemas operativos como Debian, Fedora Remix y Arch Linux (Zhao, 2015).

11

2.2.5. Raspbian

Es un sistema operativo basado en Debian para la minicomputadora Raspberry Pi, es una distribución Linux y de software libre (Smith, 2013).

Este sistema operativo es un port no oficial de Debian para la Raspberry Pi, el cual posee un soporte destinado para realizar cálculos en coma flotante por hardware. Permitiendo dar mayor rendimiento la placa computadora. Las versiones de este sistema operativo son:

• Raspbian Píxel es la versión completa que posee un entorno gráfico con menús, iconos, fondos de pantalla, etc. (Smith, 2013).

• Raspbian Lite es la versión carente de entorno gráfico es decir que solo se

trabaja mediante la consola (Smith, 2013).

2.2.6. Python

Es un lenguaje de programación que se caracteriza por su sencillez en su escritura y sintaxis. Tiene como filosofía hacer que se tenga un código legible. Además, que tiene estructuras de control que se organizan por medio de tabulaciones y no es necesario el uso de llaves, algo muy bueno en Python es que tiene limpieza y claridad sin igual (Marzal, 2002). Gracias a que Python es un lenguaje interpretado, no se necesita compilar para que este sea ejecutado. El modo interactivo de Python permite la ejecución de instrucciones directo en el intérprete (Marzal, 2002). Adicionalmente, es un lenguaje de programación multiplataforma y accede a la expansión de sus funciones con el uso de múltiples librerías como C/C++, estas se utilizan para dar servicio a páginas web, aplicaciones Android, videojuegos 3D, etc. (Marzal, 2002). Python posee grandes facilidades para realizar programación orientada a objetos. Está basado en lenguaje ABC e influenciado por otros como C, Modula-3, etc.

2.2.7. Arduino Uno

Es una plataforma que se encuentra basada en código abierto y su función principal es captar información del mundo físico. Su funcionamiento se encentra basado en una placa con un microcontrolador y el entorno de desarrollo para crear diferentes softwares para esta plataforma (Arduino, 2015). Con Arduino se puede realizar una variedad de proyectos ya que puede leer datos de muchas clases de interruptores, sensores, etc. y controlar múltiples actuadores físicos (Badamasi,2014). Está construido con un microcontrolador ATmega328, su alimentación puede ocurrir de varias maneras por medio de su interfaz USB (Universal Serial Bus, Bus Universal en Serie) conectándolo a la computadora o a una fuente externa. Opera de

12

7-12V con la fuente externa, los pines digitales de entrada y salida son 14 y de estos 6 proveen una salida PWM (Pulse- Width Modulation, Modulación por Ancho de Pulso). También cuenta con 6 pines analógicos. Tiene memoria flash de 32 KB una SRAM (Static Random Access Memory, Memoria Estática de Acceso Aleatorio) de 2KB, EEPROM (Electrically Erasable Programmable Read-Only Memory, Memoria de solo Lectura Programable y Borrable Eléctricamente) de 1KB. La velocidad del reloj es de 16 MHz (Arduino, 2015).

Figura 2.4. Arduino Uno. Fuente: (Arduino,2015)

El pin VIN (Voltage Input, Voltaje de Entrada) es la fuente de la tensión de entrada que contiene la tensión a la que se está alimentando al Arduino por la fuente externa (Arduino, 2015). El pin que indica 5V tiene una tensión regulada de 5V que pude venir del pin VIN, también pude venir de una fuente externa de 5V o a través de USB (Badamasi, 2014). El pin que muestra 3.3V es un pin de fuente interna que ha sido generada por un regulador interno y su consumo de corriente es 50mA máximo (Badamasi, 2014). El Pin GND (Ground, Puesta a Tierra) que indica el pin a tierra (Badamasi, 2014). Arduino tiene 14 pines digitales que se pueden utilizar como una entrada o salida, estos pines pueden recibir como máximo 40 mA con resistencias pull-up de 20 a 50 K Ohm (Badamasi, 2014). Los pines 0 (RX) y 1 (TX) son utilizados para transmisión y recepción de información o datos serie TTL (Badamasi, 2014). Los Pines 2 y 3 consisten en las interrupciones externas. Los pines 3, 5, 6, 9,10 y 11 Son pines por modulación de ancho de pulso que constituyen 8 bits de salida con la función analogWrite () (Arduino, 2015). Los pines 10 SS (Slave Select, Seleccionar Esclavo), 11 MOSI (Master Out Slave In, Maestro fuera y Esclavo Dentro), 12 MISO (Master In Slave Out, Maestro en y Esclavo Fuera), 13 SCK (Serial Clock, Reloj serial), son pines de apoyo para realizar la comunicación SPI (Serial Peripheral Interface, Interfaz Periférica Serial) (Badamasi,2014).

13

El pin 13 tiene un led conectado a el que indica si el pin el de valor alto encendiéndose y si el pin es de valor bajo este led se encuentra apagado (Arduino, 2015). Arduino tiene 6 entradas analógicas con etiquetas desde A0 hasta A5 que brindan cada uno 10 bits de resolución lo que quiere decir que se obtienen 1024 estados. Cada uno tiene un voltaje de 5V (Badamasi, 2014; Arduino, 2015).

2.2.8. Lenguaje de Programación para Arduino

El lenguaje estandarizado para programar en Arduino es C++, siendo posible la programación del mismo en otros lenguajes, pero no es un lenguaje puro C++, es un arreglo que viene de avr- libc la misma que brinda una librería de C con muy alta calidad para el uso con GCC (GNU Compiler Collection, Colección de Compiladores GNU) en los microcontroladores como el que posee Arduino ATmega328 (Evans, 2011). Arduino brinda el uso de librerías facilitando así la programación del ATmega328 (Evans, 2011).

2.2.9. Medición de la Temperatura

El sensor por utilizar será el DHT11 que es compatible con Arduino y Raspberry. El sensor de temperatura y humedad utilizado en este trabajo es el DHT11. Este es un sensor analógico diseñado para detectar el cambio físico en el calor y la humedad cuando se expone al aire con el cableado y la programación adecuados (Molina, 2016). Su pequeño tamaño, su bajo precio, su bajo consumo de energía y sus rápidas respuestas son las características para ser una de las mejores opciones para muchos usuarios. El sensor DHT11 es aplicable en HVAC (calefacción, ventilación y aire acondicionado), se puede usar en Pruebas e inspección de equipos y bienes de consumo. El uso del sensor DHT11 ha demostrado su utilidad para medir y controlar la temperatura y la humedad en aparatos domésticos, médicos y en muchos otros sectores. La Figura 2.5 muestra el sensor de humedad y temperatura DHT11, el rango de precisión y rendimiento se muestra en la tabla 2.1 (Molina, 2016)

14

Tabla 2.1. Precisión y rendimiento DHT11. Fuente: (Electronics. 2016).

Temperatura Humedad

Rango de medición

0 a 50 grados centígrados

20 a 90 RH

Precisión ± 2% ±5%

Figura 2.5. Sensor de temperatura y humedad DHT11.

Fuente: (Molina., 2016)

2.2.10. Administración De Bases De Datos En La Nube (Base De Datos Como Servicio)

La DBMS (Data Base Management System, Administración de datos y Bases de datos) son la parte integral de varias aplicaciones. En particular, los DBMS se han utilizado masivamente debido a los beneficios que estos ofrecen: (Xiong, 2011). Su funcionalidad en general ofrece un modelo intuitivo y simple para modelar diferentes tipos de aplicaciones. Consistencia: Datos siempre disponibles y sin errores sin importar las cargas de trabajo concurrentes y que los datos no estén sincronizados. Rendimiento: Baja latencia y alto funcionamiento de las bases de datos. Fiabilidad:

Datos persistentes y seguros en presencia de diferentes tipos de fallas (Xiong,

2011).

Los DBMS tradicionales no están diseñados para ejecutarse sobre la arquitectura shared-nothing (máquinas independientes que realizan una tarea con un mínimo uso de recursos) y no proporcionan las herramientas necesarias para escalar a una gran cantidad de máquinas (Xiong, 2011). Líderes en tecnología como Google, Amazon y Microsoft han demostrado que los centros de datos que comprenden miles de nodos de cómputo ofrecen escala sin precedentes, ya que varias aplicaciones pueden compartir una infraestructura común. Las tres compañías han proporcionado marcos tales como AWS (Amazon Web Services, Servicios Web de Amazon), App Engine de Google y Microsoft Azure para alojar aplicaciones de terceros en sus nubes (infraestructuras de centros de datos) (Xiong, 2011).

15

A medida que el avance tecnológico va hacia el ámbito de la computación en la nube, que normalmente incluye centros de datos con miles de servidores, el enfoque manual de la administración de la base de datos ya no es viable. En cambio, existe una creciente necesidad de hacer que la capa de gestión de datos sea autónoma o auto gestionable, especialmente cuando se trata de la redistribución de la carga, la escalabilidad y la elasticidad (Kuang, 2016).

Figura 2.6. Tradicional VS servicios de datos en la nube

Fuente: (Kuang, 2016).

Como se puede observar en la Figura 2.6, la administración de los servicios de las bases de datos debe realizarse de manera automatizada ya sea las actualizaciones, los respaldos, las réplicas, entre otros. Además, la administración de seguridad de las bases de datos es centralizada (Kuang, 2016).

2.2.11. Proteus

Proteus es un software para realizar simulaciones digitales y analógicas de una manera viable y práctica (Breijo, 2012). Es un programa muy completo que permite visualizar las diferentes conexiones y realizar diferentes diseños independientemente de los componentes que posea el circuito. Permite la ejecución de diversos proyectos que tienen componentes electrónicos en todas sus diferentes etapas: (Breijo, 2012). • Diseño del esquema electrónico • Arquitectura del circuito impreso • Simulación total del diseño La ventaja de utilizar Proteus es que gracias a sus diferentes fases de prueba no existe necesidad de realizar nuevos prototipos (Breijo, 2012). Proteus posee de dos softwares principales: ISIS y ARES (Breijo, 2012). ISIS es un software que da la facilidad de realizar esquemas o planos electrónicos de diferentes prototipos o conexiones de circuitos con los componentes necesarios para cada uno. Cada diseño que se ha desarrollado en ISIS está disponible para ser simulado en tiempo real con la ayuda del módulo VSM que es una de las ventajas y partes de Proteus (Breijo, 2012).

16

ARES es la herramienta utilizada para realizar el enrutamiento, edición y ubicación de los elementos del prototipo realizado. Con esta herramienta se pueden fabricar las láminas de circuito Impreso (Breijo, 2012).

2.2.12. Proceso Unificado de Rational (Rational Unified Process, RUP)

Según (Debrauwer, y otros, 2009), RUP es un proceso de realización o de evolución de software enteramente basado en UML. Está constituido por un conjunto de directivas que permiten producir software a partir del pliego de condiciones (requisitos). Cada directiva define quién hace qué y en qué momento. Un proceso permite, por tanto, estructurar las diferentes etapas de un proyecto informático. RUP es un producto comercial suministrado en forma de sitio web reservado a los clientes que han comprado la licencia a Rational Software (http://www.rational.com). Los principios de RUP proceden del Proceso Unificado; los tres autores de este último son los mismos que los de UML. La diferencia entre RUP y el Proceso Unificado es el gran número de modelos disponibles que ofrecen un ahorro de tiempo en RUP. De acuerdo a (Rueda, 2006), RUP tiene dos dimensiones: - El eje horizontal, representa el tiempo y demuestra los aspectos del ciclo de vida del proceso. - El eje vertical, representa las disciplinas, que agrupan actividades definidas lógicamente por la naturaleza.

Figura 2.7. Metodología RUP

Fuente: (Rueda,2006)

Fases El ciclo de vida del software del RUP se descompone en cuatro fases secuenciales (figura 2.7). En cada extremo de una fase se realiza una evaluación (actividad: Revisión del ciclo de vida de la finalización de fase) para determinar si los objetivos de la fase se han cumplido. Una evaluación satisfactoria permite que el proyecto se mueva a la próxima fase.

http://www.rational.com/

17

Figura 2.8. Fases de RUP Fuente: (Rueda, 2006)

El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versión del producto, cada ciclo está compuesto por fases y cada una de estas fases está compuesta por un número de iteraciones, estas fases son: 1. Concepción, Inicio o Estudio de oportunidad Según (Rueda, 2006):

Define el ámbito y objetivos del proyecto.

Se define la funcionalidad y capacidades del producto 2. Elaboración De acuerdo a (Rueda, 2006):

• Tanto la funcionalidad como el dominio del problema se estudian en profundidad.

• Se define una arquitectura básica.

• Se planifica el proyecto considerando recursos disponibles. 3. Construcción Según (Rueda, 2006):

• El producto se desarrolla a través de iteraciones donde cada iteración involucra tareas de análisis, diseño e implementación.

• Las fases de estudio y análisis sólo dieron una arquitectura básica que es aquí refinada de manera incremental conforme se construye (se permiten cambios en la estructura).

• Gran parte del trabajo es programación y pruebas - Se documenta tanto el sistema construido como el manejo del mismo.

• Esta fase proporciona un producto construido junto con la documentación.

4. Transición De acuerdo a (Rueda, 2006):

• Se libera el producto y se entrega al usuario para un uso real. • Se incluyen tareas de marketing, empaquetado atractivo, instalación,

configuración, entrenamiento, soporte, mantenimiento, etc. • Los manuales de usuario se completan y refinan con la información anterior.

• Estas tareas se realizan también en iteraciones.

18

2.2.13. UML

Existen muchos conceptos con respecto a la metodología UML en donde según (Alarcón,2000) define que es un lenguaje en donde se define la maquetación y se utiliza varios componentes para el desarrollo del software, que no tan solo puede utilizarse para el desarrollo de un sistema informático, sino que también para un sistema web como tan solo es un lenguaje de desarrollo se puede implementar en esos tipos de sistemas. Según (Gacitúa,2003) describe que UML es un lenguaje muy reconocido a nivel universal y que sirve para realización de diferentes sistemas y que muchas personas especializadas en este rubro de desarrolladores de software lo utilizan. Consideran que UML está compuesto por muchos elementos importantes que sirve para el desarrollo de un sistema entre ellos se encuentran: Diagrama de casos de uso: Este diagrama de casos de uso es la descripción de lo que debe realizar el sistema, donde interactúa el usuario con los clientes especificados como actores que participan en los procesos, que de alguna manera facilitara la comunicación entre ellos. Diagrama de clases: Estos diagramas se especifican a través de clases que contienen atributos, los métodos y objetos que forman parte del sistema y que a la vez que se comunican entre sí. Diagrama de secuencia: Estos diagramas están compuestos por objetos que se interactúan entre sí en un momento determinado y que son representados por unas series de flechas y líneas verticales que expresa el proceso del mensaje que es enviado de un objeto a otro. Diagrama de colaboración: Este diagrama es similar al diagrama de secuencia, pero este se enfatiza en la relación entre objetos y la topología en pocas palabras indica la situación del proceso dentro del sistema y es representada por flechas que expresa la secuencia de los mensajes. Diagrama de estado: Este diagrama demuestra el estado de un objeto o podría describirse como la vida y los cambios que se producen en un objeto y que podría afectar su funcionamiento. Diagrama de actividad: Son actividades que están unidas a objetos que se dan dentro de los procesos del sistema, que son representadas por una clase y un caso de uso. Diagrama de componentes: Este diagrama especifica o describe las componentes necesarias para el software es decir describe de forma física la elaboración del sistema. Diagrama de implementación: Estos diagramas muestran los aspectos y relaciones de los componentes físicos en tiempo real. Diagrama de relaciones de entidad: Es un tipo de diagrama de flujo que ilustra cómo las "entidades", como personas, objetos o conceptos, se relacionan entre sí dentro de un sistema. Los diagramas ER se usan a menudo para diseñar o depurar bases de datos relacionales en los campos de ingeniería de software (Lucidchart, 2010).

19

2.2.14. Centro de Datos

Según la norma ANSI/TIA-942 (2010), el cual es un Estándar de Infraestructura en Telecomunicaciones para centro de datos, es un edificio o parte de un edificio cuya función esencial es albergar una sala de informática y sus áreas de asistencia. Las principales funciones de un centro de datos son centralizar y consolidar recursos de tecnología de la información, alojar operaciones de red, facilitar el comercio electrónico y brindar servicio continuo a operaciones de procesamiento de datos críticos para la misión. Los centros de datos pueden clasificarse como centro de datos empresariales (privados) o centros de datos de ubicación compartido (públicos). Los centros de datos empresariales son de propiedad privada y son operados por entidades corporativas, institucionales o gubernamentales de carácter privado; admiten transacciones y procesamientos de datos internos, como así también servicios Web, y cuentan con el soporte y administración del equipo interno de Tecnologías de la Información (c3comunicaciones, 2020) Los centros de datos compartidos son propiedad y están bajo la administración de compañías de telecomunicaciones o de proveedores de servicios competitivos no regulados, y ofrecen servicios de tecnología de la información a través de terceros. Los servicios típicos que prestan los centros de datos incluyen acceso a Internet, aplicación o alojamiento Web, distribución de contenidos, almacenamiento y resguardo de archivos, administración de bases de datos, bloqueo ante fallas, controles de climatización, seguridad, e infraestructura de cableado de alto rendimiento. Las áreas funcionales del centro de datos pueden ser desglosadas de la siguiente manera: (c3comunicaciones, 2020). Conmutación

• Zona del Punto de Presencia (PoP - Point of Presence).

• Zona del Área del Servidor.

Almacenamiento

• Red de Área de Almacenamiento (SAN - Storage Área Network).

2.2.14.1. Zona del Punto de Presencia (PoP)

Esta área del centro de datos es también conocida en algunas ocasiones como el “punto de encuentro”. Es usualmente el área donde el proveedor de servicio permite el acceso a sus redes. Esta área contiene muchos Routers y Switches centrales.

2.2.14.2. Zona del Servidor

Esta área del centro de datos proporciona la conexión del lado del usuario a los servidores de la base de datos. Esta área tiene muchos Switches y Servidores. Los protocolos utilizados para comunicarse en esta área son Ethernet de 1 gigabit y de 10 gigabits.

2.2.14.3. Zona de Almacenamiento

Esta área del centro de datos proporciona la conexión del lado del servidor a los datos. Esta área contiene diferentes tipos de dispositivos de almacenamiento. Los protocolos utilizados para comunicarse en esta área son canales de fibra o interfaces Ethernet.

20

2.3 GLOSARIO DE TÉRMINOS BÁSICOS

ANSI/TIA-942: Asociación de la Industria de las Telecomunicaciones; American National Standards Institute – Telecomunications Industry Association, Instituto Nacional Estadounidense de Normas.

ARES: Software de Edición y Ruteo Avanzado (Avancé Routing and Editing Software), es la herramienta de enrutado, ubicación y edición de componentes, se utiliza para la fabricación de placas de circuito impreso

ARM: Conjunto Reducido de Instrucciones (Reduced Instruction Set Computer), la arquitectura ARM es el conjunto de instrucciones de 32 bits más ampliamente utilizado en unidades producidas. Concebida originalmente por Acorn Computers para su uso en ordenadores personales.

APK: Paquete de Aplicación Android (Android Application Package), es decir un archivo con extensión APK es un paquete para el sistema operativo Android. Este formato es una variante del formato JAR de Java y se usa para distribuir e instalar componentes empaquetados para la plataforma Android. AWS: Servicios Web de Amazon (Amazon Web Services). CENACE: Centro Nacional de Control de Energía

DBMS: Administración de datos y Bases de datos (Data Base Management System), es una colección de software muy específico, orientado al manejo de base de datos, cuya función es servir de interfaz entre la base de datos, el usuario y las distintas aplicaciones utilizadas.

GND: Puesta a Tierra (Ground).

HVAC: calefacción, ventilación y aire acondicionado

ISIS: Sistema de Enrutado de Esquemas Inteligente (Intelligent Schematic Input System), permite diseñar el plano eléctrico del circuito que se desea realizar con componentes muy variados, desde simples resistencias, hasta alguno que otro microprocesador o microcontrolador, incluyendo fuentes de alimentación, generadores de señales y muchos otros componentes con prestaciones diferentes.

IAAS: Infraestructura como servicio (Infrastructure as a Service), es un servicio informático en la nube que da acceso a una infraestructura de TI altamente flexible a través de Internet.

MISO: Maestro dentro y Esclavo Fuera (Master In Slave Out).

POE: Alimentación a través de Ethernet (Power Over Ethernet), es una tecnología que incorpora alimentación eléctrica a una infraestructura LAN estándar. Permite que la alimentación eléctrica se suministre a un dispositivo de red (switch, punto de acceso, router, teléfono o cámara IP, etc.) usando el mismo cable que se utiliza para la conexión de red.

RUP: Proceso Unificado de Rational (Rational Unified Process) SCK: Reloj serial (Serial Clock). SPI: Interfaz Periférica Serial (Serial Peripheral Interface).

UML: lenguaje unificado de modelado, es el lenguaje de modelado de sistemas de software

21

UPS: Sistema de Respaldo de Batería.

VSM: Sistema Virtual de Modelado (Virtual System Modeling), es el módulo de simulación de circuitos.

2.4 MARCO REFERENCIAL

2.4.1. Oficina Central de Informática y Telecomunicaciones.

Jefe: Ing. Jassayra Chulle Chapilliquen Dirección: Campus Universitario, Urb. Miraflores s/n, Castilla- Piura Apartado Postal 295.

2.4.2. Misión.

Conducir, administrar y velar por la integridad del parque informático, red informática, comunicación de los sistemas e información con otros organismos e instituciones nacionales e internacionales de su competencia. Así mismo somos los responsables del respaldo y seguridad de la información y de los sistemas de la UNP, de las necesidades de mantenimiento y servicios de equipos informáticos con alta calidad, precios justos y excelente servicio.

2.4.3. Visión.

Ser la unidad líder de todo el sistema universitario de la región Grau en brindar soluciones tecnológicas idóneas que estén alineadas a los objetivos institucionales con la finalidad de satisfacer las necesidades de la institución, para ello nuestro compromiso es innovar y mejorar la calidad de servicio para satisfacción de nuestros clientes bajo lineamientos de buenas prácticas profesionales y la eficiencia de nuestro sistema de gestión de calidad.

22

III. MARCO METODOLÓGICO.

3.1 ENFOQUE Y DISEÑO De acuerdo con Hernández, Fernández y Baptista (2014), el enfoque del proyecto es cuantitativo porque permitirá conocer las variables de temperatura y humedad del centro de datos de OCIT de la UNP, este monitoreo brindara reportes que pueden ser utilizados como indicadores de mantenimiento.

De acuerdo con Hernández, Fernández y Baptista (2014), es un diseño no experimental porque no habrá manipulación de variables solo la adquisición de los datos de temperatura y humedad.

3.2 SUJETOS DE LA INVESTIGACIÓN

Selección De La Población La población está conformada por los centros de datos de las universidades de la ciudad de Piura, según información obtenida de la Superintendencia Nacional de Educación Superior Universitaria son 3 universidades las que cuentan con licenciamiento y las mencionamos a continuación. Universitaria:

• Universidad Nacional de Frontera

• Universidad Nacional de Piura,

• Universidad Privada de Piura. Selección de Muestra Para la selección de la muestra se utilizó el método de muestreo por conveniencia que según (Hernández Sampieri, Roberto; Fernández Collado, Carlos y Baptista Lucio, Pilar. 1998 metodología de la investigación. México: McGraw-Hill. 2º edición), en su libro Metodología de la investigación, es un muestreo no probabilístico, en este tipo de muestreos la “representatividad” la determinamos de modo subjetivo. Basándose en dichos autores la muestra obtenida fue la Oficina Central De Informática Y Telecomunicaciones de la Universidad Nacional de Piura la cual fue la única que acepto la aplicación de la tesis, por ello se utilizó la muestra por conveniencia debido a que es la única universidad que se logró tener acceso

3.3 MÉTODOS Y PROCEDIMIENTOS.

3.3.1 Método

Se utilizará la metodología de desarrollo RUP, la cual es el estándar más común para el análisis, implementación y documentación de sistemas orientados a objetos, cuyas principales características son: el desarrollo iterativo, la disciplina de asignación de tareas y responsables, la implementación en Ingeniería de Software, la administración de requisito, el uso de arquitectura basada en componentes, el modelado visual del software y la verificación de la calidad del software. (SMARTSOFT, 2018)

23

3.3.2. Procedimiento

3.3.2.1 Fase de inicio

En esta fase se define el alcance, propósito, definición del problema, el modelo de negocio en base a los requerimientos obtenidos, se especifican los casos de uso, requerimientos funcionales y no funcionales del desarrollo del software de monitoreo de temperatura y humedad para el centro de datos del OCIT de la UNP.

3.3.2.1.1 Alcance:

El sistema informático esta desarrollado para plataformas web basado en lenguaje de programación y estructuras de código abierto, se utilizara un Raspberry PI que tiene un papel fundamental en este proyecto ya que es la encargada de recoger todos los datos que son enviados por el sensor DHT11, los almacena en una base de datos y los representa en la plataforma web las cuales se pueden acceder mediante una table o un celular, esto tiene como finalidad satisfacer las necesidades del OCIT en obtener información donde se aprecie las diferentes variantes de temperatura y humedad dentro del centro de datos.

3.3.2.1.2 Propósito

El propósito del siguiente proyecto de investigación es desarrollar un software de temperatura y humedad para el centro de datos de la Universidad Nacional de Piura. El sistema se encargará de brindar información oportuna de las variantes de temperatura y humedad que se registran de los equipos ubicados en el centro de datos y así poder controlar y prever daños a estos y por ende una posible pérdida de información.

Las tareas que cubre el sistema se especificaran en los casos de uso, el cual nos brindara información vital para el desarrollo del software.

24

3.3.2.1.3 Definición del Problema

Tabla 2.2. Definición del problema

EL PROBLEMA

El centro de datos de la universidad de Piura no cuenta con un sistema que le permita obtener información de las variantes de temperatura y humedad de sus equipos informáticos y puedan prever algún daño en sus equipos.

QUE AFECTA

Afecta a una pérdida económica debido al mal funcionamiento de sus equipos y por consecuencia a la perdida de la data almacenada en ellas.

IMPACTO

Retraso de sus procesos, por el mal funcionamiento de sus equipos informáticos por la falta de seguridad y perdida de su información.

SOLUCION

El Desarrollo de un software de temperatura y humedad para el centro de datos de la Universidad Nacional de Piura que permita monitorear las variantes de estas contribuyendo al buen funcionamiento de sus equipos y salvaguardando la información almacenada en ella.

25

3.3.2.1.4 Requerimientos funcionales

3.3.2.1.4.1 Módulo Usuario

Tabla 2.3. Requerimiento validar usuario.

Requerimiento

Descripción

Validar Usuario

Cada usuario registrado deberá ingresar al sistema usando la validación de acceso, el cual es su nombre y contraseña, si es correcta se mostrará la pantalla de inicio.

Preferencia Alta.

Entradas Nombre de usuario. Contraseña.

Salidas

Pantalla de inicio. Acceso a los menús para el usuario validado.

Proceso El usuario ingresará sus datos en la pantalla de inicio de sesión, tanto usuario y contraseña serán validadas por el sistema de acuerdo a la información almacenada en la base de datos; si son correctos, le mostrará una pantalla con los accesos a los menús para dicho usuario, caso contrario le volverá a mostrar la pantalla de inicio de sesión.

Precondición El nombre y contraseña de los usuarios estén almacenados y creados en la base de datos del sistema.

Postcondiciones Usuario ingresa al sistema

26

Tabla 2.4. Requerimiento cerrar.

Requerimiento Cerrar sesión

Descripción El Sistema deberá permitir al usuario cerrar sesión cuando previamente se haya validado.

Preferencia Alta.

Entradas Nombre de usuario.

Salidas Pantalla de inicio de sesión.

Proceso El usuario tendrá en su pantalla principal un botón que le permitirá cerrar la sesión en uso.

Precondición Usuario deberá estar autenticado en el sistema.

Postcondiciones Sesión de usuario finaliza

Tabla 2.5. Requerimiento actualizar contraseña.

Requerimiento Actualizar contraseña

Descripción El sistema permitirá actualizar la contraseña Preferencia Baja.

Entradas Contraseña actual. Contraseña Nueva.

Salidas Confirmación de contraseña nueva actualizada.

Proceso El usuario tendrá en su pantalla principal un botón el cual le permitirá actualizar su contraseña.

Precondición Usuario deberá estar autenticado en el sistema.

Postcondiciones La contraseña del usuario se actualizo y deberá ingresar con la nueva contraseña al sistema.

27

Tabla 2.6. Requerimiento nuevo usuario.

Requerimiento Nuevo usuario

Descripción El sistema permitirá agregar nuevos usuarios que podrán autenticarse.

Preferencia Alta.

Entradas Nombre de usuario. Contraseña. DNI. • Tipo de Usuario. Nombre y apellido. Teléfono Dirección de correo electrónico. Fecha nacimiento.

Salidas Lista de usuarios registrados.

Proceso El sistema mostrará un formulario donde se ingresarán los datos a registrar del nuevo usuario. Luego valida y se registra en la base de datos.

Precondición Ingresar como administrador para crear los nuevos usuarios.

Postcondiciones El nuevo usuario queda registrado y puede usar el sistema con sus credenciales.

Tabla 2.7. Requerimiento actualizar usuario.

.

Requerimiento Actualizar usuario

Descripción El sistema permitirá actualizar los datos de un usuario

Preferencia Alta.

Entradas

Nombre de usuario. Contraseña. Teléfono.

Dirección de correo electrónico


Proceso El sistema mostrará el listado de los usuarios registrados, el administrador deberá elegir el registro a modificar y presionará el botón de editar para realizar los cambios.

Precondición El usuario deberá estar registrado en el sistema

Postcondiciones La nueva información ingresada correspondiente a dicho usuario quedará actualizada y registrada en la base de dato del sistema.

28

Tabla 2.8. Requerimiento eliminar usuario.

Requerimiento Eliminar usuario

Descripción El sistema permitirá eliminar los datos de un usuario.

Preferencia Alta. Entradas Nombre de usuario.


Proceso El sistema mostrará el listado de los usuarios registrados, el administrador deberá elegir el registro y presionará el botón de eliminar el cual arrojará un mensaje de confirmación indicando si desea efectuar el proceso, si la respuesta es positiva se eliminará de la base de datos, caso contrario queda sin efecto.

Precondición El usuario deberá estar registrado en el sistema.

Postcondiciones La nueva información ingresada correspondiente a dicho usuario quedará actualizada y registrada en la base de dato del sistema.

Tabla 2.9. Requerimiento crear tipo de usuario.

Requerimiento Crear Tipo de Usuario

Descripción El sistema permitirá crear tipos de usuarios para asignar permisos.

Preferencia Alta. Entradas Nombre del tipo de usuario y descripción


Proceso El sistema mostrará un formulario donde se ingresarán los datos a registrar de los tipos de usuarios. Luego el sistema valida y se registrará en el sistema

Precondición Ingresar como administrador para crear el tipo de usuario.

Postcondiciones La nueva información ingresada de dicho usuario quedará actualizada y registrada en la base de datos.

29

Tabla 2.10. Requerimiento eliminar tipo de usuario.

Requerimiento Eliminar Tipo de Usuario

Descripción El Sistema deberá permitir eliminar tipo de usuario.

Preferencia Alta

Entradas Nombre del tipo de usuario.

Salidas Listado de los tipos de usuarios existentes en el sistema.

Proceso El sistema mostrará el listado de los tipos de usuarios existentes. El usuario administrador seleccionará el tipo de usuario a eliminar, oprimirá el botón eliminar y confirmará la acción. Posteriormente el tipo de usuario será eliminado de la base de datos del sistema.

Precondiciones Ingresar con usuario administrador, el cual está por defecto y cuenta con los permisos para eliminar los tipos de usuarios

Postcondiciones El tipo de Usuario quedará eliminado del sistema.

Efectos colaterales Los usuarios nuevos creados ya no podrán ser asignados al tipo de usuario eliminado.

Tabla 2.11. Requerimiento actualizar tipo de usuario.

Requerimiento Actualizar Tipo de Usuario

Descripción El sistema permitirá actualizar o modificar los datos de un tipo de usuario.

Preferencia Alta

Entradas Nombre del tipo de usuario y descripción.

Salidas Listado de los tipos de usuarios existentes en el sistema.

Proceso El sistema mostrará el listado de los tipos de usuarios existentes. El usuario administrador escogerá el tipo de usuario a actualizar, oprimirá el botón editar y registrará los datos si son correctos, caso contrario se mostrará el error existente.

Precondiciones Los tipos de usuarios deberán estar creados en el sistema. Solo el usuario administrador puede actualizar los datos del tipo de usuario.

Postcondiciones La información almacenada en el tipo de usuario es actualizada.

Efectos colaterales Se modifica un registro de la base de datos con los cambios de datos del tipo de usuario.

30

Tabla 2.12. Requerimiento asignar permiso a tipo de usuario.

Requerimiento Asignar permiso a Tipo de Usuario

Descripción El sistema deberá permitir asignar permisos a los tipos de usuarios.

Preferencia Alta

Entradas Nombre del tipo de usuario.

Salidas Listado de los permisos de los tipos de usuarios.

Proceso El sistema mostrará el listado de todos los permisos existentes. El usuario administrador escogerá el tipo de usuario al cual afectarán los permisos y seleccionara los permisos que se le darán al tipo de usuario en particular dentro del sistema.

Precondiciones El tipo de usuario deberá estar creado en el sistema. El administrador puede agregar los permisos.

Postcondiciones Los permisos se asignarán al tipo de usuario elegido.

Efectos colaterales Los usuarios que están asignados en el tipo de usuario tendrán en el sistema permisos que se hayan asignado.

31

3.3.2.1.4.2 Módulo Sistema

Tabla 2.13. Requerimiento presentar pantalla de inicio.

Requerimiento Presentar pantalla de inicio

Descripción Cuando el usuario se haya validado correctamente, el sistema presentará una pantalla de inicio y mostrará información acerca del estado de los sensores y alertas

Preferencia Media

Entradas • •

Registros de la base de datos. Información obtenida del sistema operativo.

Salidas La Pantalla de inicio brinda información acerca del sistema.

Proceso Si el usuario es validado correctamente por el sistema, entonces se presentará una pantalla de inicio con información del estado de los sensores y alertas. La información a mostrar es conseguida de la base de datos. Los indicadores e información importante a mostrar se dividen en 2 secciones, las cuales son: Estado de los sensores: Estado (OK/Fallo) de los dos sensores a instalar, que son: temperatura, humedad. Estado de alertas: Estado de los eventos generados por los sensores en las últimas 24 horas, 1 semana y 1 mes.

Precondiciones El usuario deberá validarse correctamente en el sistema.

Postcondiciones El usuario ingresará al sistema.

Efectos colaterales Ninguno.

32

Tabla 2.14. Requerimiento generar respaldo.

Requerimiento Generar respaldo

Descripción El sistema deberá permitir realizar un

archivo de respaldo de la información

almacenada en la base de datos

Preferencia Media

Entradas • Base de datos del sistema.

Salidas • Archivo comprimido en formato TAR.

Proceso El sistema generará un archivo comprimido

de respaldo en formato TAR, el cual

contendrá todos los archivos de información

existentes en la base de datos del sistema.

Precondiciones El usuario autenticado deberá tener

privilegios para generar archivos de

respaldo.

Postcondiciones El archivo de respaldo será creado con

extensión tar.gz.


33

3.3.2.1.4.3 Módulo Sensores

Tabla 2.15. Requerimiento habilitar y deshabilitar sensor.

Requerimiento Habilitar y deshabilitar sensor

Descripción El sistema deberá permitir habilitar y

deshabilitar el funcionamiento de un sensor.

Preferencia Media

Entradas Ninguna

Salidas • Confirmación de habilitación y des habilitación del sensor

Proceso En la pantalla de configuración del sensor, el usuario escogerá si desea habilitar o deshabilitar el mismo. Oprimirá el botón Guardar para efectuar los cambios realizados.

Precondiciones El usuario validado deberá tener los permisos necesarios para acceder a la configuración de los sensores.

Postcondiciones El sensor queda habilitado o deshabilitado.

Efectos colaterales Si el sensor se habilita generará un reporte del ambiente, caso contrario no generará

ningún reporte y no se almacenarán en la base de datos.

34

Tabla 2.16. Requerimiento configurar parámetros de valores del sensor de temperatura y humedad.

Requerimiento Configurar parámetros de valores del sensor

de temperatura y humedad.

Descripción El sistema deberá permitir configurar los valores mínimos y máximos del sensor de temperatura y humedad del dispositivo.

Prioridad Alta

Entradas Datos obligatorios:

• Valor mínimo.

• Valor máximo.

Salidas Confirmación de cambio de los valores de temperatura y humedad.

Proceso En la pantalla de configuración de los sensores de temperatura y

humedad, el usuario configurará los valores m í n i m o s y máximos.

Precondiciones El usuario autenticado deberá tener

privilegios para acceder a la configuración de

los sensores. Postcondiciones Se modificarán los parámetros de los

valores mínimos y máximos.

Efectos colaterales Al modificarse los valores mínimos y máximos, los eventos generados por el sistema por sobrepasar el límite de estos valores se verán alterados.

35

Tabla 2.17. Requerimiento envío de alarmas.

Requerimiento Envío de alarmas

Descripción El sistema deberá permitir seleccionar el usuario al cual se le enviarán las alarmas a través del correo electrónico asignado, esto en caso de ocurrencia de un evento para un sensor.

Prioridad Alta

Entradas Listado de los usuarios existentes en el sistema.

Salidas Confirmación.

Proceso En la pantalla de configuración del sensor, el usuario administrador seleccionará a cuál usuario se enviarán las alarmas. Presionará el botón Guardar para aplicar los cambios.

Precondiciones El usuario autenticado debe tener los

permisos necesarios para acceder a la

configuración del sensor. Postcondiciones El envío de alarmas al usuario seleccionado

queda habilitado. Efectos colaterales El envío de alarmas se habilita para un

usuario en particular, por lo tanto, si otro usuario recibía las alarmas anteriormente, ya no las recibirá más.

Tabla 2.18. Requerimiento mostrar última lectura del sensor.

Requerimiento Mostrar última lectura del sensor

Descripción El sistema debe permitir presentar la última lectura generada por el sensor.

Prioridad Media

Entradas Valor de última lectura del sensor.

Salidas Muestra de la última lectura del sensor.

Proceso En la pantalla de configuración de un sensor en particular, el usuario observa la última lectura generada por el sensor.

Precondiciones El usuario autenticado debe tener privilegios para acceder a la configuración de los sensores.

Postcondiciones Se muestra la última lectura del sensor en cuestión.


36

3.3.2.1.4.4 Módulo Reporte

Tabla 2.19. Requerimiento visualizar reportes de eventos de sensor.

Requerimiento Visualizar reportes de eventos de sensor Descripción El sistema debe permitir visualizar reportes de

los eventos generados por los sensores del dispositivo.

Prioridad Alta Entradas • Tipo de sensor.

• Rango de fecha. Salidas Registros de eventos del sensor seleccionado. Proceso El usuario selecciona el tipo de sensor y el

rango de fecha de los registros a visualizar. Precondiciones El usuario debe tener privilegios para visualizar

los reportes. Postcondiciones Se genera el reporte para el sensor dado. Efectos Colaterales Ninguno

Tabla 2.20. Requerimiento visualizar reportes de eventos de sensor.

Requerimiento Visualizar reportes de datos de sensor Descripción El sistema debe permitir visualizar reportes

de los datos generados por los sensores del dispositivo.

Prioridad Alta Entradas • Tipo de sensor.

• Rango de fecha. Salidas • Registros de datos del sensor

seleccionado. Proceso El usuario selecciona el tipo de sensor y el

rango de fecha de los registros a visualizar. Precondiciones El usuario debe tener privilegios para visualizar

los reportes. Postcondiciones Se genera el reporte para el sensor dado. Efectos Colaterales Ninguno

37

Tabla 2.21. Requerimiento exportar reportes a archivos.

Requerimiento Exportar reportes a archivos Descripción El sistema debe permitir exportar los

diferentes reportes a archivos XLSX y PDF.

Prioridad Media Entradas • Registros del Reporte Generado Salidas • Archivo XLSX y PDF Proceso El usuario selecciona el tipo de archivo a

exportar los reportes. Precondiciones El usuario debe tener privilegios para visualizar

los reportes. Postcondiciones Se genera el archivo de reportes y puede ser

almacenado en el computador del usuario.

Efectos Colaterales Ninguno

3.3.2.1.5 Requerimientos no funcionales

Tabla 2.22. Requerimiento de seguridad.

El usuario tendrá que autenticarse para entrar al sistema y su acceso debe ser

contrastado con los registros previamente almacenados en la base de datos.

La contraseña del usuario estará almacenada en la base de datos de una manera

cifrada.

La interfaz de usuario podrá acceder mediante el protocolo HTTPS para suministrar

cifrados y seguridad a la conexión durante el inicio y hasta el final de la sesión.

El sistema tendrá que ser configurado para poder acceder a través de una dirección

IP privada, y no a través de una dirección IP pública enlazada directamente a

Internet.

Tabla 2.23. Requerimiento interfaz de usuario.

Interfaz de usuario

La interfaz de usuario a realizar será web

Se empleará un navegador web para ingresar a la aplicación. Deberá trabajar con

navegadores Google Chrome y Mozilla Firefox.

Siendo un modelo web, la interfaz podrá ser utilizada desde cualquier computadora o

dispositivo móvil, similar a un teléfono inteligente o tableta.

La resolución óptima necesaria es de 1280 x 768 pixeles.

38

Tabla 2.24. Requerimiento interfaz de hardware.

Interfaz de hardware

El sistema será instalado en una computadora de placa única Raspberry Pi

modelo B, para lo que deberá trabajar con un procesador de 700 MHz de

velocidad, 512 MB de memoria RAM y sobre una memoria microSD de 4GB.

El sistema tendrá que interactuar con los siguientes elementos de hardware

instalados sobre la placa Raspberry Pi:

• Tarjeta de memoria SD.

• Interfaz de red alámbrica RJ45.

• Sensor de temperatura.

• Sensor de humedad.

Tabla 2.25. Requerimiento interfaz de software.

Interfaz de

software El sistema permitirá trabajar sobre el sistema operativo Raspbian Linux.

El sistema desarrollado podrá ejecutarse sobre el servidor Apache.

El sistema estará enlazado con el motor de base de datos Mysql para el

almacenamiento de registros.

El sistema utilizará el módulo php-mysql para permitir la conexión entre el lenguaje

PHP y la base de datos MySQL.

Para la comunicación con los sensores, el sistema internamente utilizará el

lenguaje de programación C.

El sistema empleará la librería libmysqlclient-dev para proveer una interfaz de

comunicación entre el lenguaje C y la base de datos MySQL, para el

almacenamiento de las lecturas de los sensores.

3.3.2.1.6 Descripción de los roles en los módulos

El sistema tiene dos tipos de actores o usuarios:

• Administrador. - Es el que realiza las configuraciones críticas en el sistema.

• Técnico. - Es el usuario que pertenece a un tipo de usuario creado por el administrador del sistema. Cada uno de estos actores o usuarios cumplen con ciertos roles con respecto a los módulos establecidos en el sistema, detallados a continuación en la tabla 2.21.

39

Tabla 2.26. Roles de los módulos

Módulos Tareas ROLES Administrador Técnico

Usuario Validar usuario. X X Cerrar sesión. X X

Actualizar contraseña X X

Nuevo, eliminar y actualiza un usuario.

X

Nuevo tipo de usuario, eliminar tipo de usuario y actualizar tipo de usuario.

X

Asignar permisos a un tipo de usuario.

X

Sistema Presentar pantalla de inicio.

X

X

Generar respaldo X X Sensores Habilitar y

deshabilitar sensor.

X

X

Configurar parámetros de valores del sensor de temperatura y humedad.

X

X

Envío de alarmas X

X

Mostrar última lectura del sensor

X

X

40

3.3.2.1.7 Casos de uso

a) Validar de usuario

Figura 2.9. Diagrama de caso de uso validación de usuario

41

b) Sesión de usuario

Figura 2.10. Diagrama de caso de uso sesión de usuario

c) Gestión de usuario

Figura 2.11. Diagrama de caso de uso gestión de usuario

42

d) Gestión de Permisos y Tipo de usuario

Figura 2.12. Diagrama de caso de uso gestión de Permisos y Tipo de usuario.

e) Gestión de sensores

Figura 2.13. Diagrama de caso de uso gestión de sensores

43

f) Diagrama General del Sistema

Figura 2.14. Diagrama de caso de uso diagrama general del sistema

Registrar Nuevo Tipo de Usuario

Configurar Parametros del Sensor

Asignar permisos a un tipo de

usuario

Actualizar Usuario

Eliminar Usuario

Registrar Nuevos Usuarios


Iniciar Sesion

Habilitar Sensor

Deshabilitar SensorAdministrador

Generar Reporte

Generar Reporte

Iniciar Sesion

Habilitar Sensor

Deshabilitar Sensor

Tecnico


44

3.3.2.2 Fase de elaboración

En esta fase se describen las especificaciones de los casos de uso, se elaboran los diagramas de secuencia, clases, colaboración, actividades, componentes, diseño de pantallas y diagrama de base de datos.

3.3.2.2.1 Descripción de los casos de uso

Tabla 2.27. Descripción de caso de uso, validación de usuario.

Nombre: Validación de usuario.

Actores: Administrador. Técnico.

Descripción Describe el proceso para el ingreso con sus credenciales de acceso a la aplicación.

Flujo principal Eventos Actor Eventos Sistema

1. Ingresar al aplicativo.

1. Cargar interfaz.

2. Pulsar botón de inicio de sesión

2. Cargar interfaz de inicio de sesión.

3. Digitar el usuario y la contraseña.

3. Verificar usuario y contraseña ingresada.

4. Esperar respuesta de validación.

4. Generar respuesta.

Precondición El usuario y la contraseña deben de estar almacenados en la base de datos.

Postcondición Cargar la interfaz con los permisos.

Tabla 2.28. Descripción de caso de uso, sesión de usuario.

Nombre: Sesión de usuario. Actores: Administrador.

Técnico. Descripción Una vez iniciada la sesión, el usuario podrá cerrar su

sesión o cambiar la contraseña. Flujo principal

1. El usuario inicia sesión. 2. El usuario puede cerrar sesión y actualizar su

contraseña. Precondición El usuario debe estar autenticado en el sistema.

45

Tabla 2.29. Descripción de caso de uso, gestión de usuarios

Nombre: Gestión de usuarios. Actores: Administrador. Descripción El usuario administrador será el único encargado de la

creación de usuario que podrán acceder al sistema. A su vez también es el único de eliminar y modificar usuarios.

Flujo principal

1. El administrador crea el usuario. 2. El administrador puede consultar los usuarios

creados. 3. El administrador puede eliminar un usuario

registrado o creado. 4. El administrador puede crear un usuario registrado

o creado. Precondición Ingresar al sistema como administrador el cual ya existe

por defecto.

Tabla 2.30. Descripción de caso de uso, gestión de permisos y tipo de usuario.

Nombre: Gestión de permisos y tipo de usuario. Actores: Administrador. Descripción El usuario administrador será el único encargado de la

creación de tipo de usuario y asignar los permisos para estos tipos de usuarios. A su vez también es el único de eliminar y modificar.

Flujo principal

1. El administrador crea el tipo de usuario. 2. El administrador le asigna el permiso al tipo de

usuario. 3. El administrador puede consultar los tipos de

usuario registrado o creado. 4. El administrador puede eliminar un tipo de usuario

registrado o creado. 5. El administrador puede actualizar un tipo de

usuario creado Precondición Ingresar al sistema como administrador el cual ya existe

por defecto.

46

Tabla 2.31: Descripción de caso de uso, gestión de sensores.

Nombre: Gestión de sensores. Actores: Administrador.

Técnico Descripción Los usuarios con los permisos permitidos son los que

pueden gestionar las configuraciones de los sensores de los dispositivos como deshabilitar y habilitar sensores, observar la lectura actual de los sensores, habilitar y deshabilitar envió de alarmas.

Flujo principal

1. El usuario puede habilitar un sensor. 2. El sistema muestra la lectura del sensor. 3. El usuario puede configurar los valores de umbral

del sensor mínimos y máximos. 4. El usuario puede habilitar el envío de mensajes. 5. El usuario puede deshabilitar el envío de mensajes. 6. El usuario puede deshabilitar un sensor

Precondición El usuario debe de estar autenticado en el sistema y tener los permisos correspondientes.

47

3.3.2.2.2 Diagramas de secuencia.

Figura 2.15. Diagrama de secuencia, validación de usuario.

:

Administrador,Tecnico

:


INTERFAZINTERFAZ VALIDARFORMULARIOVALIDARFORMULARIO VALIDARSESIONVALIDARSESION USUARIOUSUARIO BASEDATOSBASEDATOS TABLAUSUARIOTABLAUSUARIO

1:Cargar Interfa()

2: Interfaz Cargada()

3: Enviar Datos De Logeo()

4: Validar Datos

5: Datos Correctos()

6: Enviar Datos()

7: Obtener Tipo de Usuario()

8: Realizar Conexion()

9: Conexion Establecida()

10: Colsultar Usuario()

11: Usuario Conectado()

12: Asignar Datos De Sesion()

13: Iniciar Sesion()

14: Mostrar Sesion Iniciada()

48

Figura 2.16. Diagrama de secuencia, consultar variable.

:


:


INTERFAZINTERFAZ FORMULARIODEVARIABLESFORMULARIODEVARIABLES VALIDARFORMULARIOVALIDARFORMULARIO TEMPERATURA,HUMEDADTEMPERATURA,HUMEDAD BASEDATOSBASEDATOS TABLA TEM, HUMTABLA TEM, HUM

1: Cargar Interfaz()


3: Seleccionar Variable a Consultar()

4: Enviar Variable a Consultar()

5: Validar Datos()

6: Datos Validados()

7: Enviar Seleccion()

8: Realizar Conexiòn ()

9: Conexiòn Establecida()

10: Consultar Datos Solicitados()

11: Envia Datos Solicitados()

12: Mostrar Variables Solicitadas()


49

3.3.2.2.3 Diagramas de colaboración

Figura 2.17. Diagrama de colaboración, validación de usuario.

:


INTERFAZ VALIDARSESION

USUARIO

BASEDATOS

TABLAUASUARIO

1: Cargar Interfaz()2: Interfaz Cargada()

VALIDARFORMULARIO

3: Enviar Datos de Logeo

4: Validar Datos()

5: Datos Correctos()

6: Enviar Datos()

7: Obtener Tipo de Usuario()


9: Conexion Establecida()10: Consultar Usuario()

11: Usuario Conectado()

12: Asignar Datos de Sesion()

13: Iniciar Sesion()14: Mostrar Sesion Iniciada()

50

Figura 2.18. Diagrama de colaboración, consultar variable.

: Administrador,Tecnico

INTERFAZ

VALIDARFORMULARIO

TEMPERATURA,HUMEDAD TABLA TEM, HUM

FORMULARIODEVARIABLES

BASEDATOS

1: Cargar Interfaz()


3: Seleccionar Variable a Consultar()

5: Validar Datos()


9: Conexion Establecida() 10: Consultar Datos Solicitados()

11: Enviar Datos Solicitados



4: Enviar Variable a Consultar()

6: Datos Validados()

7: Enviar Seleccion()

51

3.3.2.2.4 Diagrama de Actividades

Figura 2.19. Diagrama de actividades, iniciar sesión

52

Figura 2.20. Diagrama de actividades, consultar variable.

53

Figura 2.21. Diagrama de actividades, envió de notificación.

54

3.3.2.2.5 Diagrama de Componentes

Figura 2.22. Diagrama de componentes

3.3.2.2.6 Diagramas de despliegue del sistema

Figura 2.23. Diagrama de despliegue del sistema.

55

Los nodos representativos en el diagrama de despliegue de la figura 2.23 se detallan a continuación:

Estación Cliente: En este nodo se ejecuta la conexión al sistema. La cual se conecta con el nodo servidor a través del protocolo TCP/IP. Sensor: En este nodo se encuentran los dispositivos de hardware que se conectan al servidor para capturar los valores del ambiente del data center. Este componente se comunica a través de una conexión Serial con nuestro servidor. Servidor: En este nodo es donde se encuentran los componentes de la arquitectura en tres capas del sistema: la interfaz gráfica, la lógica del negocio y la base de datos. Navegador Web: Software mediante el cual el usuario utiliza para acceder al sistema. Interfaz GUI: Es la interfaz gráfica desarrollada en lenguaje PHP, HTML y librerías CSS y JavaScript, logrando que el usuario se relacione con el sistema y visualice la información. Apache: Es un software servidor de páginas web utilizado para el alojamiento de la aplicación y realiza la comunicación mediante la red LAN o Internet. PHP. Es el lenguaje de programación orientado a objetos que se usa para el desarrollo de la aplicación. Librería php5-mysql: Componente de software que ayuda a la comunicación entre el lenguaje de programación PHP y el motor de base de datos MySQL para conseguir y guardar los datos de la aplicación. Motor MySQL: Gestor de base de datos que permite guardar los datos de la aplicación. Librería mysqlclient-dev: Componente de software que logra la comunicación con el lenguaje de programación C y el motor de base de datos MySQL. Librería C: Componente de software que logra la comunicación entre el servidor y el sensor.

56

3.3.2.2.7 Diseño de pantalla del sistema

Acceso a la interfaz web El dispositivo es gestionado a través de una interfaz web de manejo fácil. Se podrá acceder a través de una red local o internet, podrá ser accedido mediante acceso remoto. Para acceder al software, conectar a la red. Abrir un navegador web Se podrá acceder el dominio que se haya creado para el sistema o desde la ip del servidor. se mostrará una pantalla de sesión de inicio que solicitará usuario y contraseña.

Figura 2.24. Captura de Pantalla del Login del aplicativo web sistema control de temperatura y humedad.

57

Pantalla de inicio (Dashboard) al validar al usuario y contraseña, nos llevara a una pantalla de inicio o de nombre Dashboard en la cual detalla las opciones del sistema, con sus respectivos módulos.

Figura 2.25. Captura de pantalla del Inicio de sesión del sistema

Módulo de usuario:

• Usuario: El software puede crear nuevos usuarios al sistema por parte del

administrador. El cual podrá agregar, eliminar y actualizar usuario.

• Tipo de Usuario: Tenemos acá por defecto a dos usuarios Administrador y

Técnico ambos con sus propias claves de acceso, se ingresarán los usuarios

que administrarán al sistema con sus permisos que asignara el administrador.

Figura 2.26. Captura de pantalla del módulo de usuario

58

Usuario: El Sistema crea usuarios para manejar el software de temperatura y humedad. Por defecto trabaja con el usuario administrador que ya se encuentra creado,

Figura 2.27. Captura de pantalla de registro de usuario.

Figura 2.28. Captura de pantalla de listado de usuarios.

59

Módulo de sensores:

• Sensor de Temperatura: Muestra en grados centígrados la temperatura.

• Sensor de Humedad: Muestra en grados centígrados la humedad.

Figura 2.29. Captura de pantalla del módulo sensor.

Módulo de Reportes:

• Reportar Datos del Sensor: este sub modulo me reportara los datos del sensor

de temperatura y humedad, con los rangos y fechas.

• Seleccionar Sensor: en este sub modulo se realizará la configuración del sensor,

si esta apagado o si está activo, valor máximo y valor mínimo.

• Enviar Reporte por Correo: se enviará el reporte por correo en un determinador

intervalo de tiempo al administrador o al encargado o a las personas que se les

asignen dichas tareas.

60

•

Figura 2.30. Captura de pantalla del módulo reporte.

61

3.3.2.2.8 Diagrama de base de datos.

Figura 2.31 Diagrama de base de datos.

62

Diccionario de Datos:

En el diagrama lógico de la base de datos de las figuras anteriores, se hará uso de la

base de datos DHT11, la cual almacenará los datos relacionados al sistema para el

desarrollo de la interfaz de usuario del sistema y toma de lectura del sensor

a.- Diccionario de la base de datos sistemacontroltemperaturadb

Tabla 2.32. Diccionario de datos tabla usuario.

Tabla Usuario

Descripción Encargada de almacenar los datos de los usuarios del sistema

Key Nombre Tipo dato Nulo Predeterminado Descripción

PK idusuario INT (11) Yes Código identificador

único del

usuario nombre VARCHAR (50) NULL Descripción o nombre

completo del usuario correo VARCHAR (100) NULL Dirección de correo

electrónico del usuario

usuario VARCHAR (15) NULL Nombre de usuario

clave VARCHAR (100) NULL Contraseña del usuario

encriptada con

algoritmo MD5

idrol INT (11) NULL Código del rol

estatus INT (11) NULL Descripción o nombre

completo del usuario

Tabla 2.33. Diccionario de datos tabla rol.

Tabla Rol

Descripción Almacena la información de los roles del sistema


PK idrol INT (11) Yes Código identificador

único del

grupo

rol VARCHAR (20) NULL Nombre del rol

descripción VARCHAR (20) NULL Descripción del rol

63

Tabla 2.34. Diccionario de datos tabla rol_operaciones.

Tabla rol_operaciones

Descripción Almacena la relación rol operaciones, es decir qué, operación

pertenecen a cada rol


PK idroloperaciones INT (11) Yes Identificador de la

relación

FK idoperacion INT (11) Yes ‘0’ Identificador de la

operación

FK idrol INT (11) Yes ‘0’ Identificador del

rol.

Tabla 2.35. Diccionario de datos tabla operaciones.

Tabla operaciones

Descripción Almacena las acciones posibles a realizar sobre un recurso o

menú del sistema, tales como leer, modificar, eliminar, etc.


PK idoperacion INT (11) Yes Identificador único de

la acción

nombre VARCHAR (50) NULL Nombre de la acción

FK idmoulo INT (11) NULL Identificador del

Modulo.

Tabla 2.36. Diccionario de datos tabla modulo.

Tabla Modulo

Descripción Almacena la información de los recursos del sistema menús y

submenús


PK idmodulo INT (11) Yes Identificador único del

recurso

nombre VARCHAR (50) NULL Nombre del recurso

64

Tabla 2.37. Diccionario de datos tabla lectura.

Tabla Lectura

Descripción Almacena la información de la última lectura del sensor

Key Nombre Tipo dato Nulo Predeterminad

o

Descripción

PK id INT (11) Yes Identificador único del

sensor

FK idalarma INT (11) Yes Identificador alarma

temperatura Char (4) Yes Valor de la muestra

actual

humedad Char (4) Yes Valor de la muestra

actual

Fecha_hora TIMESTAMP Yes CURRENT_

TIMESTAM

Fecha y hora de la

muestra actual

FK Idalarma_humedad INT (11) Yes Identificador

alarma_humedad

FK idusuario INT (11) Yes NULL Identificador usuario

Tabla 2.38. Diccionario de datos tabla alarma.

Tabla Alarma

Descripción Almacena la configuración de la alarma de temperatura


PK id INT (11) Yes Identificador de la

alarma

temp_min INT (11) Yes Temperatura mínima

Temp_max INT (11) No NULL Temperatura máxima

estado INT (11) Yes Estado de la alarma

fechahora TIMESTAMP Yes CURRENT_ Fecha y hora de la

alarma TIMESTAM P

65

Tabla 2.39. Diccionario de datos tabla alarma_humedad.

Tabla Alarma_humedad

Descripción Almacena la configuración de la alarma de humedad


PK id INT (11) Yes Identificador de la

alarma

Hum_min INT (11) Yes Humedad mínima

Hum_max INT (11) No NULL Humedad máxima

estado INT (11) Yes Estado de la alarma

fechahora TIMESTAMP Yes CURRENT_ Fecha y hora de la

alarma TIMESTAM P

3.3.2.2.9 Diagrama de Clases

Figura 2.32. Captura de Diagrama de clases.

66

3.3.2.3 Fase construcción

Los componentes, características y requisitos propuestos son implementados, integrados y probados, obteniendo una versión estable del producto.

3.3.2.3.1 Implementación

Para el diseño del sistema, se establecen 3 capas: modelo, vista y controlador adicionalmente, se tiene la capa de datos donde radica la base de datos propiamente dicha

Figura 2.33. Comunicación entre las capas del sistema.

3.3.2.3.1.1 Capa de Datos

En esta capa se encuentran los datos del modelo de negocio. Para esto, se utiliza el gestor de base de datos relacional MySQL, donde se definen las bases de datos: sistema control temperatura_ db y sensor db. La base de datos sistema control temperatura_ db, usada, es la encargada de almacenar los usuarios y sus permisos con respecto a los menús y opciones en la interfaz web del sistema. En tanto, que la base de datos sensor db se encarga de almacenar los datos obtenidos por el sensor conectado al dispositivo y sus configuraciones.

3.3.2.3.1.2 Capa modelo

Esta capa se encarga de las transacciones para obtener y enviar datos a la capa de datos. La librería php5-mysql permite la comunicación entre el lenguaje PHP y el gestor de base de datos MySQL, en tanto que la librería libmysqlclient-dev permite la comunicación entre el lenguaje C y el gestor MySQL. El sistema, basado en PHP y usado para el desarrollo de la interfaz web del sistema, para conectarse a la base de datos sistema control temperatura_ db. Para que el sensor conectado a la placa Raspberry Pi, a través de una conexión serial y que se comunique con el sistema a través del lenguaje C, puedan almacenar los valores obtenidos en la base de datos sensordb, se utiliza la clase getMySQLConnect

67

3.3.2.3.1.3 Capa controlador

Esta capa se encarga de recoger los datos y entregarlos a la capa de vista. Para recoger los datos se usan los métodos GET y POST establecidos en los formularios HTML generados con la codificación existente en un archivo index.php, el cual a su vez invoca a otros archivos de clase. En el sistema, cada opción existente en un menú es tratada como un módulo independiente y posee su propio árbol de directorios

3.3.2.3.1.4 Capa vista

Esta capa contiene la interfaz gráfica del sistema y sus componentes. Para hacer el sistema más amigable e interactivo con el usuario, se utiliza código JavaScript. Para incluir este código en la programación de los módulos del sistema.

3.3.2.4 Fase de transición

En esta fase se realizarán las pruebas de configuración y simulación del producto.

3.4 TECNICAS E INSTRUMENTOS

Tabla 2.40. Técnicas e instrumentos.

3.5 ASPECTOS ÉTICOS

Durante el desarrollo de la presente investigación, basado en la Ley Nro. 28611- Ley general del ambiente, se ha considerado principios y normas básicas para asegurar el efectivo ejercicio del derecho a un ambiente saludable, equilibrado y adecuado, así como el cumplimiento del deber de proteger y contribuir a una efectiva gestión ambiental. Así mismo la originalidad del proyecto no viola el derecho de integridad intelectual de los libros utilizados y de las fuentes electrónicas consultadas, necesarias para realizar el marco teórico.

Técnica Objetivo Instrumento Aplicado en

Encuesta

Permitirá conocer las expectativas que tienen los usuarios del nuevo sistema, saber sus necesidades y que información les seria de utilidad para el mejor manejo de sus equipos y una mejor toma de decisiones.

Cuestionarios (anexo 02)

Centro de datos de la Universidad Nacional de Piura

68

IV RESULTADOS Y DISCUSION

4.1 RESULTADOS El proyecto de investigación tiene como objetivo el desarrollo un software de temperatura y humedad para el centro de datos de la Universidad Nacional de Piura, que permite monitorear las variantes de estas temperaturas contribuyendo al buen funcionamiento de sus equipos, obteniendo beneficios económicos y salvaguardando su información. La siguiente información lo hemos obtenido del sensor DHT11 el cual está conectado a nuestro Raspberry Pi, obteniendo valores de temperatura y humedad en tiempo real, esta información se almacena en una base de datos que permitirá llevar un control adecuado del funcionamiento de los equipos en el centro de datos.

Figura 2.34. Prueba física del sensor.

En la figura 2.34 podemos observar que el sensor de temperatura y humedad DHT11 nos arroja los resultados obtenidos en un ambiente con temperatura de 29° C.

69

Figura 2.35. Prueba física cambio de temperatura.

En la figura 2.35 se observa los diferentes cambios de temperatura donde aumenta parcialmente hasta llegar a los 44°C y disminuyendo la humedad en un 42 % respectivamente.

70

Figura 2.36. Prueba física cambio de temperatura.

En la figura 2.36 podemos observar la prueba del sensor de temperatura y humedad correspondiente a un api donde se puede visualizar a través del internet en modo gráfico, en el primer cuadrante se detalla el alza de temperatura, en el segundo cuadrante la baja de humedad, en el tercer cuadrante se observa la ubicación de donde se está realizando las pruebas y por último en el cuarto cuadrante se observa una gráfica tipo reloj donde apreciamos de diferente forma el nivel de temperatura.

71

Figura 2.37. Prueba física temperatura ambiente.

En la figura 2.37 podemos observar que el sensor arroja niveles de temperatura y

humedad en estado normal o ambiente.

Figura 2.38. Prueba física del control de temperatura y humedad.

La figura 2.38 corresponde a la gráfica del control de temperatura y humedad donde se visualiza en tiempo real, las subidas y bajadas de las mismas.

72

4.2 DISCUSIÓN

Después de haber obtenido los resultados que arrojó el software de temperatura y humedad y comparado con los pocos datos que obtenían de forma empírica en el centro de datos de la OCIT, se puede afirmar que la aplicación del software, resulto eficiente para lograr resolver la problemática de este tema de investigación, obtenido datos de manera oportuna que arrojan diferentes valores de temperatura y humedad almacenando la información a una base de datos y a través de esta tener un mejor control para el mantenimiento de los equipos del centro de datos de la OCIT.

Para establecer la metodología de desarrollo en la presente investigación, se utilizó como contribución el proyecto de Figueroa y Castañeda, (2016); la metodología RUP y UML ya que permite estructurar las diferentes etapas de un proyecto informático y poder alcanzar los objetivos establecidos. Mediante esta metodología Figueroa y Castañeda, logro identificar 4 actores (Administrador, encargado, acudiente y estudiante), así mismo se especificó 16 casos de uso que se plasmaron en dicho proyecto. En comparación con la presente investigación, se lograron identificar 2 actores del sistema (Administrador y Técnico) y se especificaron 5 casos de uso.

La elección de las herramientas de desarrollo como los lenguajes de programación se plasmó bajo el aporte de Sánchez y Tintinago, (2015); cuyo aporte fue el uso de código abierto para la programación de la Raspberry PI y los sensores empleados que pudieron desarrollar una solución económica. En comparación con la presente investigación se utilizó tanto para el servidor como para el cliente el lenguaje de programación PHP y del lado del cliente, FRAMEWORK NEO. A diferencia de Sánchez y Tintinago utilizaron la versión 5 de PHP, la presente investigación se optó por usar la versión 7 del mismo debido a que esta incluye actualización a nivel de seguridad y correcciones de errores.

Vista Controlador (MVC), es un patrón de diseño que clasifica la información, la lógica del sistema y la interfaz que se presente al usuario, la cual nos ayudó a obtener el diseño y abstracción de las interfaces de usuario, lógica del negocio y los datos del prototipo web con la finalidad de lograr una mayor abstracción; a diferencia de Sánchez y Tintinago, en la presente investigación se agregaron niveles adicionales dentro de la capa de datos para obtener una arquitectura de proyecto más robusta y que será capaz de escalar a gran velocidad y adaptarse a las necesidades de la institución.

Para definir los parámetros de temperatura y humedad se utilizó como aporte la tesis de Medina (2014); donde utilizaron la norma ANSI/TIA -942 asignándole parámetros para controlar rangos continuos de funcionamiento. En comparación con la siguiente investigación utilizamos esta norma que a través de consultas y gráficas se dio a conocer la información vital de los rangos de temperatura y humedad para ayudar a la decisión en cuanto al mantenimiento de sus dispositivos. Este beneficio se basa en prevenir daños que afecten a los equipos y por ende salvaguardar la información almacenadas en ellos y dar a conocer información que no se conocía de manera precisa, la cual puede observarse en los reportes de consultas presentados.

73

CONCLUSIONES

Una vez realizada la presente investigación se llegaron a las siguientes conclusiones:

• Los 19 requerimientos funcionales obtenidos a través de la aplicación de encuestas en la fase de inicio de la metodología RUP se pudo lograr un mejor análisis de la información, permitiendo definir el alcance del proyecto, logrando obtener una guía para las siguientes fases, mejorando el desarrollo de los diagramas UML como son los diferentes niveles de acceso al sistema por los usuarios, los módulos que contiene el sistema, los roles de los usuarios.

• En la fase de elaboración se obtuvieron 16 especificaciones de caso de uso, que corresponde a los procesos del sistema desde el control de temperatura y humedad hasta su finalización por parte del envío de reportes al usuario final. Estas especificaciones a su vez generaron 9 diagramas que representan los procesos dentro del centro de datos. Con el diseño del software de temperatura y humedad propuesto, se realizó para que sea amigable para el usuario y a su vez capaz de adaptarse a cualquier dispositivo donde se visualice, se implementó el diseño de la base de datos, obteniendo siete tablas.

• La fase de construcción permitió al sistema desarrollar su funcionalidad con la pantalla principal, pantalla de acceso a la interfaz web, pantalla de inicio, pantalla módulo de usuario, pantalla de registro de usuario, pantalla de listado de usuarios, pantalla del módulo reporte.

• En las pruebas realizadas con la implementación del software de temperatura y humedad se logró mostrar datos que antes no se tenía de manera precisa. La información se presenta a través de cuadros y gráficas que resultan siendo más ventajosa, representativa y explicativa. De esta manera se podrá tomar una mejor decisión a la hora de realizar los mantenimientos preventivos.

• La norma ANSI/TIA ayudo a establecer un rango de variables en la implementación del software, para ello se realizaron pruebas que permitieron alertar a través del envió de datos por un correo electrónico cuando sobrepasa los límites definidos de temperatura y humedad.

74

RECOMENDACIONES

• Se recomienda continuar el software de temperatura y humedad agregando nuevos módulos que detecten el acceso de personas no autorizadas al centro de datos (CCAA) de tal forma que se logre controlar la seguridad del mismo.

• Se recomienda la instalación del sistema de contra incendio NOVEC 1230 -3M y a su vez agregar un módulo que permita controlar la activación del sistema en mención para la detección de incendios, utilizando un sensor de humo, de tal forma que logre detectar y extinguir un posible amago.

• Se debe monitorear el sistema diariamente para evitar posibles daños a los

equipos.

• Se debe capacitar al personal para el uso adecuado del sistema.

• Implementar políticas de seguridad para garantizar el resguardo de los datos almacenados en los equipos.

• Utilizar navegadores Mozilla Firefox o Google Chrome para acceder a la Interfaz.

• Contratar personal capacitado para la instalación física de los dispositivos en el OCIT.

75

REFERENCIAS BIBLIOGRÁFICAS

Alarcón., R. (2000.). Diseño orientado a objetos con UML. Madrid.: Marín P.

Alchemister, R. (2016). Raspberry the New Release. Liverpool: Smart Home. Arduino.

(2015). Arduino, store Arduino, Arduino LLC.

Badamasi, Y. A. (2014.). The Working Principle of an Arduino.

Bracamonte. (2016). bracamonte. Obtenido de

http://bracamontedatacenters.weebly.com/norma-tia-

942.html#:~:text=Infraestructura%20de%20Telecomunicaciones%20para%20Data%

20Centers%3A%20Norma%20TIA%20942&text=La%20norma%20TIA%2D942%20f

ue,y%20consideraciones%20del%20ambiente%20apropiado.

Breijo, E. G. (2012). COMPILADOR C CCS Y SIMULADOR PROTEUS PARA MICROCONTROLADORES PIC. New York,USA.

c3comunicaciones. (23 de noviembre de 2020). Obtenido de

https://www.c3comunicaciones.es/data-center-el-estandar-tia-942/

Chen, Y. a. (2016). IEEE transactions on information forensics and security. vol 11.

D.Wolber. (2011). "SIGCSE",de App inventor and real-world motivation. San Francisco.

ELECTRONICS, M. (2016). MOUSER ELECTRONICS. Obtenido de

https://www.mouser.com/datasheet/2/758/DHT11-Technical-Data-Sheet-Translated-

Version-1143054.pdf

Evans, B. (2011). Beginning Arduino Programming. Orlando,USA.

Gacitúa, R. (12 de Diciembre de 2003). Métodos de desarrollo de software. El desafío pendiente de la estandarización. Redaly.

Gray, J. A. (2012). Gray, J., Abelson, H., Wolber, D., & Friend, M., Teaching CS principles with app inventor. In Proceedings of the 50th Annual Association for

Computing Machinery Southeast Conference, ACM-SE'12 (pp. 405-406). (Proceedings

of the Annual Southeast Conference. In Proceedings of the 50th Annual Association for Computing Machinery Southeast Conference, ACM-SE'12 (pp. 405-406). (Proceedings

of the Annual Southeast Conference. Alabama, USA.

Kuang, W. (2016). sciencedirect. Obtenido de

https://www.sciencedirect.com/science/article/abs/pii/S0169204615002054

Lucidchart. (2010). Obtenido de https://www.lucidchart.com/pages/es/que-es-un-

diagrama- entidad-relacion

Marzal, I. G. (2002.). "Introducción a la Programación con Python y C". Barcelona.

McCrory, D. D. (2009). virtual server cloud interfacing. Washington DC.

Molina, G. (2016). Plataforma Cloud de adquisición, tratamiento y visualización de

información de sistemas fotovolcanico asilados. .

http://bracamontedatacenters.weebly.com/norma-tia-

http://www.c3comunicaciones.es/data-center-el-estandar-tia-942/

http://www.mouser.com/datasheet/2/758/DHT11-Technical-Data-Sheet-Translated-

http://www.sciencedirect.com/science/article/abs/pii/S0169204615002054

http://www.lucidchart.com/pages/es/que-es-un-diagrama-

http://www.lucidchart.com/pages/es/que-es-un-diagrama-

76

Muccio, C. D. (06 de Juio de 2012). es.slideshare. Obtenido de es.slideshare:

https://es.slideshare.net/LogicalisLatam/tendencias-de-infraestructura-para-data-

centers

Prahland, A. a. (2012). Data object store and server for a cloud storage environment,

including data depuplication and management across multiple cloud storage sites.

Rueda, J. C. (2006). Obtenido de

http://biblioteca.usac.edu.gt/tesis/08/08_7691.pdf. SMARTSOFT, C. (2018).

Metodología de Desarrollo Tradicional RUP. Obtenido de

https://smartsoftcolombia.com/portal/index.php/blog/49-rup

Smith, B. (2013). Raspberry Pi Assembly Language RASPBIAN Beginners. Los

Angeles,USA.

UNP. (s.f.). UNP. Obtenido de

http://www.unp.edu.pe/transparenciaunp/down/organigramaunp124.pdf Upton, E. a. (2014). Raspberry Pi. Xiong, P. (2011). researchgate. Obtenido de

https://www.researchgate.net/publication/224237591_Intelligent_management_of_virt

ualized_resources_for_database_systems_in_cloud_environment.

Yin, Y. a. (2017). International Joint Conference on Neural Network (IJCNN).

Zhao, C. W. (2015). International Journal of Computer Network and Applications. vol. 2.

http://biblioteca.usac.edu.gt/tesis/08/08_7691.pdf

http://www.unp.edu.pe/transparenciaunp/down/organigramaunp124.pdf

http://www.unp.edu.pe/transparenciaunp/down/organigramaunp124.pdf

http://www.researchgate.net/publication/224237591_Intelligent_management_of_virt

77

ANEXOS

ANEXO 1. MATRIZ BÁSICA DE CONSISTENCIA Título del Proyecto

“DESARROLLO DE UN SOFTWARE DE TEMPERATURA Y HUMEDAD PARA EL CENTRO DE DATOS DE LA UNIVERSIDAD NACIONAL DE PIURA”

Nombre del Tesista(s) Bach. Luis Junior Cruz Correa.

Bach. Luis Enrique López Merino.

Oscar Daniel Talledo Alvarado.

Tabla 2.41. Matriz de consistencias.

Pregunta Objetivos

G ¿De qué manera se desarrolla el software de temperatura y humedad para el centro de datos del OCIT de la UNP?

Desarrollar un software de temperatura y humedad para el centro de datos de la Universidad Nacional de Piura.

E1 ¿Cuáles son los requerimientos del desarrollo de un software de temperatura y humedad para el centro de datos del OCIT de la UNP?

Identificar los requerimientos en la fase de inicio de la metodología RUP del desarrollo de un software de monitoreo de temperatura y humedad para el centro de datos del centro de informática y telecomunicaciones de la Universidad Nacional de Piura.

E2 ¿Cuál será el diseño del prototipo del

desarrollo de un software de

temperatura y humedad para el

centro de datos del OCIT de la UNP?

Diseñar el software de monitoreo de temperatura y humedad para el centro de datos de la Universidad Nacional de Piura en la fase de elaboración de la metodología RUP.

E3 ¿Cuál será la implementación del

desarrollo de un software de


centro de datos del OCIT de la UNP?

Implementar el software de monitoreo de temperatura y humedad para el centro de datos de la Universidad Nacional de Piura en la fase de construcción de la metodología RUP.

E4 ¿Cuáles serán las pruebas aplicadas

al desarrollo de un software de


centro de datos del CIT de la UNP?

Alinear el software a los parámetros de la norma ANSI/TIA

78

ANEXO 2. BANCO DE PREGUNTAS

1. ¿Tienen personal que administre el centro de datos?

Sí NO

Administrador (X) ( )

Supervisor ( ) (X)

Técnico (X) ( )

2. ¿existen otras personas que tengan acceso al centro de datos?

Sí ( ) No (X)

3. ¿Tienen implementado algún sistema de seguridad físico y/o ambiental?

Sí (X) No ( )

4. ¿Cuentan con un software de monitoreo de temperatura y humedad en el

centro de datos?

Sí ( ) No (X)

5. ¿El centro de datos de la OCIT cuenta con un sistema de climatización?

Sí (X) No ( )

6. ¿La temperatura del centro de datos de la UNP es la adecuada para los

equipos informáticos?

Sí (X) No ( )

7. ¿Se han presentado problemas de sobrecalentamiento de equipos electrónicos

en los últimos años en el centro de datos?

Sí (X) No ( )

8. ¿Qué tipo de daños ocasionó el sobrecalentamiento de los equipos electrónicos?

• Caída de sistema ( X)

• Equipos dañados ( )

• Perdida de información ( )

79

9. ¿Se ha visto exceso de humedad en los equipos electrónicos?

Sí ( ) No (X)

10. ¿Cada que tiempo se realizan los mantenimientos preventivos a los equipos del

centro de datos de la UNP?

• Mensual ( )

• Trimestral ( )

• Anual (X )

11. ¿Qué equipos electrónicos conforman el centro de datos?

SWITCH´

S

SERVIDO

RES

12. ¿Alguna vez los servidores se han sobrecalentado o saturado, de ser

positiva la respuesta, indicar que acciones se tomaron?

SI, SE AUMENTO EL ALMACENAMIENTO

13. ¿Qué beneficios piensa usted que tendría implementar un sistema de

monitoreo de temperatura y humedad en el centro de datos?

MUCHOS BENEFICIOS YA QUE ESTARIAMOS AL TANTO EN

TIEMPO REAL DE LA TEMEPRATURA QUE SE ENCUNTRA EL

CENTRO DE DATOS.

14. ¿Qué problemática se solucionaría con este sistema?

EL SOBRECALENTAMIENTO DE LOS EQUIPOS YA Q SABRIAMOS EL

MENTO EXACTO QUE AUMENTA LA TEMPERATURA Y TOMARIAMOS

MEDIDAS EN EL MOMENTO.

15. ¿Quiénes tendrían acceso al sistema de monitoreo de temperatura y humedad?

LOS ENCARGADOS DEL AREA DE REDES

16. ¿Cuáles serán los límites de acceso al sistema según cargo de los colaboradores?

DE SOLO LECTURA PARA TRABAJADORES Y LECTURA Y ESCRITURA

PARA EL ENCARGADO DEL AREA

17. ¿Qué tipo de aplicación se adecua a sus necesidades?,

• Aplicación web (X )

80

• Aplicación escritorio ( )

18. ¿Sus Servidores pueden trabajar con Software Libre?

Sí (X) No ( )

19. ¿Considera usted que al implementar un sistema de monitoreo de temperatura y humedad contribuya a tener un adecuado mantenimiento preventivo de los equipos electrónicos?

Sí (X) No ( )

20. ¿considera usted que se deba llevar un registro de los cambios de

temperatura y humedad en el centro de datos?

Sí (X) No ( )

21. ¿cree que sería conveniente informar y alertar al personal encargado de algún

cambio de temperatura en el centro de datos?

Sí (X) No ( )

22. ¿considera usted que sería conveniente alertar a través de?

• Correo electrónico ( )

• Mensaje de texto ( )

• Ambos (X)

23. ¿Dentro de las opciones básicas de un sistema de monitoreo de temperatura y

humedad, que opciones le serían más útiles?

• Reporte de Temperatura ( ) • Reporte de Humedad ( ) • Cuadro comparativo de Temperaturas Elevadas ( ) • Gráficos de Temperatura

81

(X)ANEXO 3. ORGANIGRAMA DE LA UNIVERSIDAD NACIONAL DE PIURA

En el siguiente organigrama se encuentra la Oficina central de informática y telecomunicaciones donde se realiza la presente investigación.

Figura 2.9: Organigrama institucional de la

UNP Fuente: (UNP)

Facultad de Ingeniería Industrial Escuela Profesional de ...

Documents

Transcript of Facultad de Ingeniería Industrial Escuela Profesional de ...