Sistema de información web para el monitoreo y control remoto de los servicios básicos para una casa estándar, implementado en hardware libre

Abstract

Se desarrolló un sistema de monitoreo y control remoto de los servicios básicos de una casa estándar bajo la implementación de hardware libre, el cual le permite a sus habitantes disfrutar de la sensación de seguridad cuando estén fuera de la misma, ya que podrán ver el estado de los servicios de iluminación, acceso, gas y suministro de agua de la casa en tiempo real y realizar acciones sobre estos gracias a una serie de alertas y notificaciones que son enviadas a través de correo electrónico y se pueden observar en el sistema de forma gráfica. El proceso de desarrollo de software usado fue SCRUM, según SCRUMstudy (2013), permitiendo iniciar el proyecto estableciendo una visión de los servicios de la casa a través de diagramas de UML como Casos de Usos para ver la interacción del usuario con el sistema. Luego planificar su desarrollo a través de diagramas de secuencias para el funcionamiento de cada módulo que integra al sistema, diagramas de despliegue para conocer cómo se encuentra distribuida cada una de las partes que conforman el sistema, diagramas de actividades para conocer el funcionamiento general del sistema. Para la implementación se usó sublime text 3 y brackets para la programación web, MySQL como manejador de bases de datos, el IDE de Arduino para la programación del Arduino y XAMPP como servidor web, todo esto montado sobre una placa Arduino MEGA, que cuenta con Arduino Ethernet shield para la comunicación vía internet, sensores y actuadores implementados en Arduino, procesador Intel aton 1.6 Ghz, RAM 2 GB y disco duro de 80 GB que funciona como servidor del sistema. El sistema se revisó de manera que cuando terminó cada uno de los Sprint se hace la revisión del mismo. El Scrum master y a la vez el Product Owner no sólo revisaba el entregable del producto o los módulos sino también la calidad del trabajo. La revisión del Sprint también implicaba que el equipo hablase sobre lo que funciona y lo que no, y se acordaban que cambios se querían intentar. Se dejaba claro “qué fue bien” y “qué se puede mejorar”, buscando causas y previniéndolas en el próximo Sprint