Bitácora de alcance¶

Responde: ¿en qué se diferencia lo construido de lo que el anteproyecto comprometió, y por qué?

No es una lista de incumplimientos. Un proyecto de un año que no se desvía de su anteproyecto o no aprendió nada o no lo registró. Lo que importa en una defensa es poder decir qué cambió, cuándo y con qué fundamento — y distinguir un desvío fundamentado de una omisión.

Cada afirmación se contrasta contra el texto del anteproyecto y contra el código.

1 · El desvío de cronograma¶

Es el más grande y el más fácil de medir.

El proyecto lleva unos once meses más que su ventana completa, y sigue en curso.

La distribución de commits muestra que el desvío no fue parejo: no es que todo se corrió, es que los componentes arrancaron en momentos muy distintos.

Factores verificables¶

No hay registro de las causas, así que esto es lo que se puede afirmar desde los repositorios:

• Hay meses sin actividad: junio de 2026 no tiene commits en ningún repositorio, y diciembre de 2025 y enero de 2026 tienen muy poca.
• El equipo son dos personas, como el anteproyecto preveía, en un proyecto que incorporó un subsistema no planificado (§4) y un componente externo (§3).
• No hay informes de avance en el repositorio. Los tres estaban planificados y su página sigue pendiente.

2 · Tecnologías: lo previsto y lo usado¶

El anteproyecto listó tecnologías previstas. El contraste es favorable en lo esencial y tiene tres adiciones no previstas.

Las tres adiciones tienen fundamento registrado, y conviene decir que ninguna reemplazó a una tecnología prevista: las previstas se usaron todas.

3 · La adición conceptual más grande: el modelo AAS¶

Por qué es un desvío favorable, y cómo defenderlo. El objetivo específico 6 compromete "estructurar los datos recolectados para habilitar futuras tareas de análisis e inteligencia de negocio". El anteproyecto no dice cómo. Adoptar un estándar de la industria para la semántica de las variables es una forma considerablemente más fuerte de cumplir ese objetivo que un esquema propio, y conecta el trabajo con el marco de Industria 4.0 que el objetivo general invoca.

El costo, que también hay que decir. La dependencia de un repositorio externo introdujo:

• un contrato transversal sin dueño declarado ni versión, que es el origen de la divergencia de los aasPath de alarma;
• un componente que el equipo no controla y cuyo calendario no gobierna;
• un servidor AAS que no tiene consumidores dentro del sistema: SYS-ADR-008.

4 · Alcance agregado: multi-tenancy y RBAC¶

El objetivo específico 7 pide "interfaces para el monitoreo adaptadas a los perfiles de usuario (fabricante y cliente)". Lo construido es considerablemente más grande que eso:

Cómo defenderlo. El sistema se entrega a un fabricante que vende máquinas a varios clientes: sin separación por cliente, el producto no es instalable más de una vez. La decisión es razonable. Lo que no ocurrió es registrarla como cambio de alcance en su momento, y eso es lo que esta bitácora corrige retroactivamente.

El costo verificable. El subsistema trajo consigo la mayor parte de la complejidad de seguridad del sistema, y su aislamiento lo impone el código y no la base, sin ninguna prueba automatizada que lo verifique: ver seguridad.

5 · Comprometido y no construido¶

Lo que el anteproyecto lista como entregable o componente del alcance y hoy no existe.

Lo que no es defendible sigue siéndolo: presentar el CRUD de reglas como si fuera el sistema de alertas.

Queda una grieta que conviene nombrar antes de la defensa: **el registro de widgets no lee
ese indicador**, así que los tres widgets de alarma dependen de su propia marca. Ver
[widgets](../usuarios/widgets.md).

6 · Desvíos de diseño dentro de lo construido¶

Decisiones que cambiaron respecto de lo especificado, ya con ADR que las respalda.

Lo que esta página no puede afirmar¶

• Por qué se produjo el desvío de cronograma. No hay actas, informes de avance ni registro de impedimentos en los repositorios. Lo de §1 es lo que se deduce de las fechas de commit, que muestran qué pasó y no por qué.
• Si hubo cambios de alcance acordados con la dirección del proyecto. No hay registro en los repositorios. Si existieron por otra vía, incorporarlos acá cambia varias conclusiones: un desvío acordado no es un desvío no registrado.
• El estado de las especificaciones del Cloud, el Edge y el historian, que todavía no tienen su bitácora de componente.

Fuentes¶

• Objetivos, alcance, tecnologías previstas, entregables, cronograma e informes de avance: docs/_process/pendiente-hub/embolsadora-4.0.md del frontend, que es el anteproyecto a la espera de migrar a su página
• Ausencia de toda mención al AAS en el anteproyecto: búsqueda sobre el texto completo, sin resultados
• Distribución temporal: git log por mes sobre la rama de referencia de cada repositorio
• Ausencia del motor de alarmas y de un servicio de reportes: los árboles internal/api/handler/ e internal/app/ del Cloud tienen alarm_rules —CRUD— y ningún módulo de reportes ni de evaluación de reglas
• Bitácora del frontend y su auditoría de 19 especificaciones: docs/_process/bitacora-de-alcance.md y specs/README.md del frontend

Relacionado¶

• Matriz de evidencias — objetivo por objetivo, con su evidencia
• Visión y alcance — el estado de los diez objetivos
• Decisiones de arquitectura — las ocho SYS-ADR