SensorOffice
Sistema de monitoreo ambiental para el Estudio Contable Gómez

1. Control de Cambios

Registro de las modificaciones realizadas sobre la documentación y el alcance del proyecto, con fecha, responsable y detalle del cambio. Cada validación con Valeria que derive en un cambio de requerimiento se anota como una fila nueva (es un hito del control de cambios, según los Lineamientos 2026).

2. Diagnóstico: Árbol de Problemas y Soluciones

Diagnóstico original elaborado por el equipo a partir del relevamiento de campo en el Estudio Contable Gómez. Es la pieza que fundamenta todas las decisiones de diseño que siguen: el problema central y sus causas explican por qué el sistema mide lo que mide, y los medios del árbol de soluciones son el origen directo de los requerimientos funcionales y de hardware que se especifican más adelante.

Problema central

Causas

Condiciones que producen el problema central. Cada una se relevó en las entrevistas y se traduce después en un requerimiento concreto.

Efectos

Consecuencias que el problema central produce hoy en el estudio. Sus valores actuales son los que forman la línea de base contra la que después se mide el proyecto.

Árbol de soluciones

Cada medio del árbol de soluciones neutraliza una causa identificada más arriba, y se convierte después en uno o varios requerimientos del sistema.

Los fines son el espejo de los efectos: expresan a qué valor debería llegar cada uno con el sistema funcionando.

3. Introducción

3.1. Propósito

El propósito del proyecto es dotar al Estudio Contable Gómez de una forma objetiva y en tiempo real de conocer el estado ambiental de sus oficinas, para dejar de depender de que un empleado se queje para enterarse de que un ambiente está incómodo. Hoy el control es 100% manual y visual: nadie mide temperatura, humedad ni calidad del aire, y los equipos de climatización se manejan a criterio de cada persona.

SensorOffice busca resolver tres problemas medibles: la detección tardía de la incomodidad ambiental, el gasto eléctrico de los splits que quedan encendidos sin ocupación, y la falta de ventilación de la oficina del fondo (que "siempre huele a cerrado" porque nadie mide el CO₂).

3.2. Alcance

El sistema incluye: una red de nodos de sensores (ESP32) instalados en cada ambiente, un backend que recibe y almacena las lecturas, un dashboard web (PC y celular) que muestra el estado en tiempo real y el historial, un sistema de alertas por umbral, un reporte mensual de consumo por sector, y la integración con Samsung SmartThings para apagar los splits de forma remota.

El sistema no incluye el apagado automático de los splits sin intervención humana, el control de actuadores de ventilación, ni la integración con el software contable del estudio. El detalle completo del límite del alcance está en el apartado de Limitaciones (dentro de 5.1) y se formaliza en el Contrato (sección 9).

3.3. Personal Involucrado

Roles del equipo de proyecto (según los Lineamientos 2026: PM, desarrollo Frontend/Backend, UX/UI, microcontrolador, base de datos e infraestructura de red). En proyectos de hardware se suma el rol de Técnico instalador.

3.4. Definiciones, acrónimos y abreviaturas

3.5. Referencias

Formato APA 7ª edición.

• Pedaci, L. (2026). Evaluación de Proyectos - Módulo 01: El Proyecto y sus generalidades. Instituto Leonardo Murialdo.
• Pedaci, L. (2026). Evaluación de Proyectos - Módulo 02: Fases de un Proyecto. Instituto Leonardo Murialdo.
• Pedaci, L. (2026). Evaluación de Proyectos - Módulo de Documentación. Instituto Leonardo Murialdo.
• Pedaci, L. (2026). Lineamientos y Metodologías de Trabajo - Proyecto Tecnológico Interdisciplinario. Instituto Leonardo Murialdo.
• Universidad Tecnológica Nacional. (2012). Buenas Prácticas para Proyectos Informáticos. edUTecNe. ISBN 978-987-1896-01-1.
• Project Management Institute. (s.f.). PMBOK - Fases del proyecto.

3.6. Resumen Ejecutivo

SensorOffice es un sistema de monitoreo ambiental de hardware y software pensado para el Estudio Contable Gómez (Caseros, Tres de Febrero): tres oficinas, ~180 m², 8 empleados y 2 socios. El sistema instala nodos de sensores en cada ambiente que miden temperatura, humedad, CO₂, luminosidad, presencia y consumo eléctrico, y los envía a un dashboard web donde Valeria y los empleados ven el estado en tiempo real, reciben alertas cuando una variable se sale de rango y pueden apagar los splits de forma remota.

Público objetivo: pymes de oficina de superficie chica-media que necesitan controlar confort y consumo sin instalar equipos de climatización nuevos. Resultados esperados: bajar las quejas de temperatura de 3-4 por semana a un máximo de 1, detectar problemas ambientales en menos de 5 minutos (contra "horas, cuando alguien avisa") y generar por primera vez un reporte mensual de consumo por sector que permita cuantificar el ahorro.

4. Descripción General

4.1. Perspectiva del producto

SensorOffice es un sistema nuevo: hoy el estudio no tiene ningún sistema de monitoreo, el control es 100% manual. No reemplaza ni mejora un software existente, y tampoco es una parte de un sistema mayor. Sí se apoya en infraestructura que el estudio ya tiene (conexión Claro Fibra 600 MB, PC de escritorio y celular Samsung con la app SmartThings instalada) y en los splits actuales, que se integran mediante enchufes inteligentes en lugar de reemplazarse.

Arquitectura en tres capas (hardware de captura, backend de procesamiento y frontend de visualización):

4.2. Funcionalidad del producto

A nivel general (sin entrar todavía en los requisitos funcionales del apartado 5.1), el producto permite:

• Medir de forma continua las condiciones ambientales de cada oficina (temperatura, humedad, CO₂, luminosidad, presencia) y el consumo eléctrico por circuito.
• Mostrar el estado actual de cada ambiente en una pantalla única, en lenguaje claro y sin jerga técnica.
• Guardar el historial de lecturas para poder ver la evolución en el tiempo.
• Avisar automáticamente (alerta) cuando una variable se sale del rango configurado.
• Detectar equipos encendidos en ambientes sin ocupación y permitir apagarlos a distancia desde el celular.
• Generar un reporte mensual de consumo por sector.

4.3. Características de los Usuarios Buenas Prácticas UTN p.56/57

Siguiendo el formato de la tabla de usuarios del libro UTN (tipo de usuario, formación y actividades). El sistema define dos perfiles con acceso a la interfaz (administradora y empleado) y un tercer perfil operativo propio de los proyectos con hardware (técnico instalador).

4.4. Restricciones Buenas Prácticas UTN p.57

4.4.1. Políticas reguladoras

El sistema se desarrolla con software libre y de código abierto (Node.js, PostgreSQL, Mosquitto, React, framework Arduino). No hay costo de licencia de software. La única política de pago externa posible es el alojamiento del backend en la nube (ver 4.4.2). El repositorio se publica en GitHub; si se publica como privado, se incluye al equipo docente como colaborador.

4.4.2. Limitaciones de hardware

El backend necesita estar disponible 24/7 para no perder lecturas. El estudio no cuenta con un servidor propio siempre encendido, por lo que se resuelve con un servicio cloud (por ejemplo Railway, Render o AWS) o una Raspberry Pi local. Los nodos se alimentan por cable USB desde tomacorriente (hay toma en todos los ambientes), no por batería. El sensor MQ-135 (CO₂/gases) es de bajo costo y da valores orientativos, no de precisión de laboratorio.

4.4.3. Interfaces con otras aplicaciones

El sistema se integra con la API de Samsung SmartThings para enviar comandos de encendido/apagado a los enchufes inteligentes de los splits. No se integra con ningún software contable, ERP ni sistema interno del estudio (queda fuera del alcance).

4.4.4. Función de control

Autenticación con usuario y contraseña, y control de acceso por rol. La administradora (Valeria) tiene acceso total; los empleados tienen acceso de solo lectura y no pueden modificar umbrales ni configuración. Toda operación que modifica el estado del sistema (cambio de umbral, comando a un enchufe) queda registrada con usuario, fecha y hora (trazabilidad).

4.4.5. Requisitos del lenguaje

Toda la interfaz y el manual de uso están en español. El estado del ambiente se comunica en lenguaje natural ("Temperatura OK", "CO₂ elevado, ventile la sala") y no como valores crudos sin contexto, dada la comodidad tecnológica media de la usuaria administradora.

4.4.6. Protocolos señalados

Comunicación nodo → servidor por MQTT (estándar IoT de bajo consumo). Comunicación servidor → dashboard por HTTP/REST. Integración con SmartThings por HTTPS con autenticación OAuth 2.0.

4.4.7. Requisitos de fiabilidad

Cada nodo debe reconectarse solo a la red WiFi si pierde señal (reintento cada 30 segundos, sin reiniciar ni perder lecturas). La pérdida de lecturas por problemas de red debe ser menor al 2% del total de muestras esperadas, gracias al repetidor WiFi. Cada lectura se almacena con fecha, hora y sector de origen. Los nodos deben operar sin interrupciones por más de 72 horas consecutivas en la prueba de campo.

4.4.8. Credibilidad de la aplicación

La confianza del usuario se sostiene sobre dos pilares: la latencia baja (menos de 5 segundos entre lectura y visualización, para que la alerta en tiempo real tenga sentido) y un indicador físico de estado en cada nodo (LED verde: OK / rojo: error) que permite ver si el sistema funciona sin abrir el dashboard.

4.4.9. Consideraciones de seguridad

Contraseñas almacenadas con hash (no en texto plano), sesiones con token (JWT), acceso restringido por rol, y el broker MQTT protegido (usuario/contraseña, y TLS en el puerto 8883 si el backend se aloja en la nube). Los datos ambientales no son sensibles a nivel personal, pero el acceso a la configuración y al control de los splits sí se restringe a la administradora.

4.5. Suposiciones y dependencias

• Se asume que la conexión a Internet del estudio (Claro Fibra 600 MB) se mantiene estable; el router está en la oficina central.
• El proyecto depende de instalar un repetidor WiFi antes de desplegar los nodos, porque la red actual solo cubre la oficina central (RHW06).
• Se asume disponibilidad de tomacorriente en todos los ambientes (confirmado en Bloque F), lo que evita el uso de batería.
• El control remoto de los splits depende de que los enchufes SmartThings queden correctamente vinculados a la cuenta Samsung del estudio.
• Se asume que Valeria está dispuesta a pagar si el ahorro se justifica (a confirmar el rango en entrevista).

4.6. Evolución previsible del sistema

Mejoras identificadas para versiones futuras (surgen de las Limitaciones del apartado 5.1):

• v2 - Apagado automático de splits con confirmación configurable y período de gracia, una vez validado el PIR en campo.
• v2 - Sensor de CO₂ de mayor precisión (SCD40, NDIR) si el usuario requiere medición certificada.
• v2 - Integración con un extractor de techo inteligente compatible con SmartThings para la oficina del fondo.
• v3 - Publicación como PWA instalable en el celular sin tienda de aplicaciones.
• Escalabilidad: agregar un nodo nuevo en otro ambiente en menos de 30 minutos, sin modificar el software (es un KR del Objetivo 4, replicabilidad).

5. Requisitos Específicos

5.1. Requerimientos funcionales Buenas Prácticas UTN p.59/60

Acciones concretas que el sistema debe poder realizar. Cada requerimiento indica su prioridad y el origen (síntoma o bloque de la entrevista del que surge). Los que dependen de hardware se marcan con HW.

Requerimientos no funcionales (RNF)

Condiciones de calidad, rendimiento y protocolos que el sistema debe cumplir (no son funcionalidades, sino cómo se comporta).

Limitaciones del alcance

Definen qué no hace el sistema en esta entrega. No son debilidades: son un contrato de honestidad con el usuario. Cada limitación puede convertirse en una versión futura (ver 4.6). Esta tabla se muestra y se discute explícitamente en la validación del prototipo, antes de la firma del contrato.

5.2. Interfaces de usuario Buenas Prácticas UTN p.58

El único punto de contacto de Valeria y los empleados con el sistema es el dashboard web, diseñado con criterio de Interacción Humano-Computadora (HCI): la interfaz no se diseña por estética sino por usabilidad, según la formación y la comodidad tecnológica del usuario real (3/5). El estado se comunica en lenguaje natural, con semáforos de color y sin obligar a interpretar valores crudos. Es responsive (misma interfaz en PC y celular, sin instalar nada) y presenta una vista de estado actual, una vista de historial con gráficos, un panel de alertas activas y (solo para la administradora) la configuración de umbrales.

5.2.1. Diseño de interfaz (Figma)

Antes de programar, el equipo diseña el mockup interactivo en Figma y lo valida con Valeria; el feedback se registra como hito en el control de cambios (Lineamientos 2026).

5.3. Interfaces de hardware Buenas Prácticas UTN p.59

Requerimientos que condicionan el diseño físico del nodo y de la instalación (marcados HW). Definen forma, alimentación, ubicación y prerequisitos de infraestructura.

5.3.1. Visualización 3D del producto

La carcasa del nodo se modela en 3D (Tinkercad o Fusion 360) antes de fabricarla, respetando RHW01 (dimensiones y prolijidad) y RHW04 (ventilación para el MQ-135).

5.4. Interfaces de software Buenas Prácticas UTN p.59

Componentes de software del sistema y cómo se comunican entre sí. No es lo mismo que los RNF (rendimiento y protocolos) ni que los RF (funcionalidades).

5.5. Interfaces de comunicación Buenas Prácticas UTN p.59

Cómo interactúa el sistema con otras aplicaciones, APIs y bases de datos.

5.6. Modelo Entidad-Relación de la base de datos

Modelo de datos relacional que sostiene la persistencia del sistema (componente ISW04). Representa qué guarda el sistema y cómo se relacionan las entidades: los ambientes del estudio, los nodos físicos instalados en cada uno, los sensores que integra cada nodo y las lecturas que generan; los umbrales que configura la administradora, las alertas que se disparan cuando una lectura los supera, y los enchufes inteligentes con el registro de comandos de encendido/apagado. El color de cada entidad sigue la convención del proyecto: azul para la lógica del sistema, violeta para lo vinculado al hardware y verde para el dato de alto volumen.

Entidades

Relaciones

Esquema relacional (PostgreSQL)

Definición de tablas (DDL) que materializa el modelo. Sirve como diccionario de datos con tipos y claves.

-- Usuarios del sistema (admin / empleado)
CREATE TABLE usuario (
  id_usuario     SERIAL PRIMARY KEY,
  nombre         VARCHAR(80)  NOT NULL,
  email          VARCHAR(120) NOT NULL UNIQUE,
  password_hash  VARCHAR(255) NOT NULL,
  rol            VARCHAR(20)  NOT NULL DEFAULT 'empleado'
                 CHECK (rol IN ('admin','empleado')),
  activo         BOOLEAN NOT NULL DEFAULT TRUE
);

-- Ambientes / sectores del estudio
CREATE TABLE ambiente (
  id_ambiente    SERIAL PRIMARY KEY,
  nombre         VARCHAR(80) NOT NULL,
  superficie_m2  NUMERIC(6,2),
  ubicacion      VARCHAR(120)
);

-- Nodos ESP32 (uno o varios por ambiente)
CREATE TABLE nodo (
  id_nodo          SERIAL PRIMARY KEY,
  id_ambiente      INT NOT NULL REFERENCES ambiente(id_ambiente),
  mac              VARCHAR(17) NOT NULL UNIQUE,
  estado           VARCHAR(12) NOT NULL DEFAULT 'offline'
                   CHECK (estado IN ('ok','error','offline')),
  version_firmware VARCHAR(20),
  fecha_instalacion DATE
);

-- Sensores que integra cada nodo
CREATE TABLE sensor (
  id_sensor     SERIAL PRIMARY KEY,
  id_nodo       INT NOT NULL REFERENCES nodo(id_nodo),
  tipo          VARCHAR(20) NOT NULL   -- temperatura, humedad, co2, luminosidad, presencia, consumo,
  modelo        VARCHAR(20),          -- DHT22, MQ-135, BH1750, PIR, SCT-013
  unidad        VARCHAR(10),
  intervalo_seg INT NOT NULL DEFAULT 60
);

-- Lecturas (alto volumen; candidata a TimescaleDB)
CREATE TABLE lectura (
  id_lectura  BIGSERIAL PRIMARY KEY,
  id_sensor   INT NOT NULL REFERENCES sensor(id_sensor),
  valor       NUMERIC(10,2) NOT NULL,
  timestamp   TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_lectura_sensor_ts ON lectura (id_sensor, timestamp);

-- Umbrales configurados por la administradora
CREATE TABLE umbral (
  id_umbral        SERIAL PRIMARY KEY,
  id_ambiente      INT NOT NULL REFERENCES ambiente(id_ambiente),
  id_usuario_config INT NOT NULL REFERENCES usuario(id_usuario),
  tipo_variable    VARCHAR(20) NOT NULL,
  valor_min        NUMERIC(10,2),
  valor_max        NUMERIC(10,2),
  fecha_config     TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- Alertas disparadas al violarse un umbral
CREATE TABLE alerta (
  id_alerta   SERIAL PRIMARY KEY,
  id_umbral   INT NOT NULL REFERENCES umbral(id_umbral),
  id_lectura  BIGINT REFERENCES lectura(id_lectura),
  mensaje     VARCHAR(160),
  estado      VARCHAR(12) NOT NULL DEFAULT 'activa'
              CHECK (estado IN ('activa','resuelta')),
  timestamp   TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- Enchufes inteligentes SmartThings (uno por split)
CREATE TABLE enchufe_inteligente (
  id_enchufe    SERIAL PRIMARY KEY,
  id_ambiente   INT NOT NULL REFERENCES ambiente(id_ambiente),
  st_device_id  VARCHAR(80) NOT NULL,
  nombre        VARCHAR(60),
  estado        VARCHAR(10) NOT NULL DEFAULT 'apagado'
);

-- Comandos de encendido/apagado (trazabilidad)
CREATE TABLE comando (
  id_comando  SERIAL PRIMARY KEY,
  id_enchufe  INT NOT NULL REFERENCES enchufe_inteligente(id_enchufe),
  id_usuario  INT REFERENCES usuario(id_usuario),
  accion      VARCHAR(10) NOT NULL CHECK (accion IN ('encender','apagar')),
  origen      VARCHAR(10) NOT NULL DEFAULT 'manual',
  timestamp   TIMESTAMPTZ NOT NULL DEFAULT now()
);

6. Oferta de Gestión

6.1. GANTT

Cronograma de tareas, responsables y duración estimada, organizado por las etapas del proyecto (E01 a E06). El GANTT se lleva en una planilla de cálculo (Google Sheets) y se actualiza a medida que avanza el proyecto.

Vista en vivo de la plantilla de cronograma que usa la materia, a modo de ejemplo del formato esperado. El embed se actualiza solo: lo que se carga en la planilla de cálculo se refleja acá sin volver a tocar el documento. Las solapas de la parte inferior permiten pasar del GANTT a las referencias y a la estimación de costos.

6.2. Infraestructura administrativa Buenas Prácticas UTN p.62

Organización interna del equipo y herramientas de trabajo. Siguiendo el esquema del libro UTN, el equipo se organiza en un grupo de dirección/gestión y un grupo de desarrollo, adaptado a la escala del proyecto de 7mo.

El equipo

Presentación de los integrantes, uno por cada rol del cuadro anterior (hasta 5 personas). Cada tarjeta lleva el nombre y apellido y una foto de perfil de estilo profesional: fondo neutro, encuadre de busto, buena luz y la misma proporción en todas, para que el documento se lea como una presentación de equipo y no como un collage.

7. Oferta Económica

Cotización de los servicios e insumos necesarios para el funcionamiento del sistema. Los valores se completan con cotizaciones reales al momento de armar el presupuesto (van en la planilla de estimación, sección 8).

7.1. Proveedores de conectividad y hosting

El estudio ya cuenta con Internet (Claro Fibra 600 MB), por lo que no se cotiza el enlace principal. Lo que sí se cotiza es el alojamiento del backend (si se opta por la nube) y el repetidor WiFi.

7.2. Proveedores de insumos electrónicos

Placas, sensores y componentes por nodo. Cantidad estimada: 4 nodos (uno por ambiente a monitorear) más repuestos.

7.3. Proveedores de insumos varios

8. Estimación Económica

Presupuesto total del proyecto. Suma el costo de insumos (secciones 7.1 a 7.3) más el esfuerzo en horas hombre, diferenciado por categoría profesional y su costo por hora (transparencia en el esfuerzo, según los Lineamientos 2026).

9. Contrato

Documento que explicita el acuerdo entre el equipo desarrollador y el cliente (Valeria Gómez, Estudio Contable Gómez). Se firma en la reunión de validación del prototipo, habiendo leído las limitaciones (5.1).

10. Bitácora del Proyecto

Documento de trabajo del equipo. Registra la investigación de campo (entrevistas y minutas) y el seguimiento de la iteración (cambios sobre el mockup y avances técnicos por etapa). A diferencia del resto de la carpeta, no describe el sistema sino el proceso, y se actualiza a medida que el proyecto avanza.

10.1. Registro de Entrevistas

Instancias de relevamiento con el cliente y con los usuarios del estudio. Cada entrevista alimenta un apartado concreto de esta carpeta, por eso se registra el objetivo junto a la fecha.

10.2. Minutas de Reunión

Acta breve de cada reunión con el cliente o del equipo. Se completa una minuta por reunión, siempre con los mismos seis campos, para que cualquier participante pueda reconstruir qué se decidió y quién quedó a cargo de qué.

Plantilla de minuta

Minuta 01 · Validación del mockup con el cliente (E04)

10.3. Registro de Cambios del Mockup

Modificaciones aplicadas al prototipo de Figma después de validarlo con Valeria. Es la trazabilidad de la iteración con el usuario: muestra que el diseño de la interfaz no se cerró en el escritorio del equipo sino con la usuaria real delante.

10.4. Bitácora de Avances Técnicos

Hitos técnicos cerrados, en orden cronológico, siguiendo las etapas del cronograma (6.1). Registrar la fecha real de cierre permite comparar el avance efectivo contra el GANTT planificado.

11. Guía de Inicio Rápido

Guía de puesta en marcha para el usuario final del estudio (Quick Start Guide). Cubre las seis operaciones que resuelven el uso diario del sistema, en el orden en que se aprenden. Está escrita sin jerga técnica, con el mismo criterio que la interfaz (5.2): quien la lee no necesita saber qué es un nodo ni qué es MQTT.

12. Preguntas Frecuentes

Las preguntas que el cliente y los usuarios del estudio hacen con más frecuencia sobre el producto, con la respuesta y la referencia al requerimiento o a la limitación que la respalda. Sirve de material de apoyo en la reunión de validación y como respaldo del equipo durante la defensa del proyecto.