Clase 21 de 24 • Curso de Fundamentos de Arquitectura de Software
Contenido del curso
Jair Israel Avilés Eusebio
Gabriel Obregón
MARIA TERESA PANIAGUA RIVERA
JEAN PEREZ
jefred bedoya
John Eduard Meneses González
Considero que el agregar un componente para resolver el requerimento de etiquetados modifica las prioridades al asignar valor en cuanto a la necesidad de revisar estadisticas de lectura asociadas a cada recurso asociado.
Por lo tanto, considero esto un cambio importante. La arquitectura puede que no cambie mucho puesto que agregaria un componente dedicado a la persistencia y analisis de uso de labels.
Sin embargo los requerimientos funcionalides deben de considerar costos y optimizacion para la manipulacion de datos asociados a etiquietas ¿Cuanto tiempo quiero persistir estos datos, que tipo de base de datos es optimo para la carga de trabajo de este nuevo componente? ¿Que tan importante es generar esta informacion para analizarla en tiempo real o estoy bien con que sea eventualmente consistente?
🧩Escalar un Producto Mínimo Viable (MVP)
🚀 1. Propósito Central
👉 Diseñar un MVP simple, funcional y escalable. El equilibrio perfecto entre sencillez inicial y capacidad de crecimiento futuro.
🧠 2. Nuevas Necesidades que Impulsan la Evolución
🔸 Etiquetado automático más inteligente.
🔸 Visualizaciones tipo mapa mental.
🔸 Estadísticas para monitorear intereses de los usuarios.
💭 Cada nueva necesidad obliga a revisar la arquitectura del sistema.
⚙️ 3. Nuevas Funcionalidades para Escalar
Componentes añadidos sin perder eficiencia:
🧩 1. Integración con Telegram → Comunicación directa y automatización de tareas.
🧩 2. Integración con el sistema de archivos → Mejor gestión y acceso a documentos.
🧩 3. Módulo interno (in house) → Automatiza el etiquetado documental con librerías open source.
💡 Gracias a la abstracción de dependencias hecha antes, estas integraciones se suman fácilmente.
🏗️ 4. Decisión Estratégica: Rediseñar o Evolucionar
Preguntas clave que guían la decisión 👇
🔹 ¿La arquitectura actual soporta eficientemente las nuevas funciones?
🔹 ¿Conviene usar herramientas externas o desarrollos propios?
🔹 ¿Se requieren nuevos estándares de rendimiento, escalabilidad o mantenimiento?
🔍 5. Autoevaluación Arquitectónica
🧭 Reflexiona sobre:
Gracias
1. MVP inicial propuesto
El módulo empieza simple:
Asistente registra datos diarios → IA consolida información → Supervisor revisa → Sistema genera reporte Word/PDF/Excel → Se guarda en SUPERVISOR IA.
Este MVP resuelve el dolor principal: recopilar, ordenar fotos y redactar reportes diarios.
2. Nuevas funcionalidades para escalar
Según la Clase 21, al crecer el MVP aparecen nuevos componentes. Para SUPERVISOR IA serían:
Nueva funciónComponente necesario
Registro desde celular
App móvil o formulario web responsive
Orden automático de fotos
Módulo de fotos con fecha, frente, actividad y GPS
Redacción con IA
Motor de generación de texto
Detección de riesgos
Módulo IA de alertas
Exportación Word/PDF/Excel
Módulo de reportes
Historial de obra
Base de datos central
Revisión del supervisor
Flujo de aprobación
Dashboard diario
Panel de indicadores
3. Pregunta arquitectónica clave
La pregunta de la Clase 21 sería:
¿El sistema SUPERVISOR IA actual puede soportar este módulo como una función más, o necesita evolucionar su arquitectura?
Mi recomendación:
No hacerlo como módulo aislado. Debe integrarse con los datos compartidos de:
Proyectos → Frentes de trabajo → Partidas → Personal → Materiales → Fotos → Incidencias → Reportes.
Nada de mock data suelta. Ahí está el truco elegante.
4. Estilo arquitectónico recomendado
Para esta etapa, recomiendo:
Monolito modular escalable
No microservicios todavía. Sería matar una mosca con misil intercontinental.
Estructura sugerida:
SUPERVISOR IA│├── Módulo Proyectos├── Módulo Partidas├── Módulo Personal├── Módulo Materiales├── Módulo Fotos├── Módulo Incidencias├── Módulo Reporte Diario IA├── Módulo Aprobación Supervisor└── Módulo Exportación Word/PDF/Excel
5. Requisitos no funcionales nuevos
La Clase 21 pide revisar rendimiento, escalabilidad y mantenimiento. Para este caso:
RequisitoAplicación
Rendimiento
Generar reportes rápido aun con muchas fotos
Escalabilidad
Soportar varias obras a la vez
Seguridad
Cada usuario ve solo sus proyectos
Trazabilidad
Saber quién registró, editó y aprobó
Mantenibilidad
Módulos separados pero con base de datos común
Costo
Controlar uso de IA, almacenamiento y exportaciones
6. Evolución del MVP
Primera versión:
Registro diario + generación de reporte.
Segunda versión:
IA detecta riesgos, retrasos e inconsistencias.
Tercera versión:
Dashboard predictivo de obra.
Cuarta versión:
Integración con valorizaciones, cronograma, seguridad, calidad e INFOBRAS.
7. Conclusión arquitectónica
La Clase 21 nos dice que el MVP no debe quedarse como una “funcioncita bonita”, sino prepararse para crecer. En SUPERVISOR IA, el módulo Reporte Diario Inteligente debe nacer como parte del ecosistema general, usando datos compartidos, base única y arquitectura modular.
El MVP debe priorizar la simplicidad extrema para validar rápido, manteniendo una estructura base que permita el crecimiento futuro sin sobreingeniería.
Al escalar, la ambición debe equilibrarse con la sostenibilidad técnica, evitando añadir complejidad innecesaria que bloquee la agilidad lograda en las etapas iniciales del proyecto.
🧠 Evolución Arquitectónica y Proyección de Costos
🏗️ ¿Hacia qué estilo evoluciona tu arquitectura?
La solución basada en el modelo C4 para automatizar la transferencia Telegram–Remarkable evoluciona naturalmente hacia un estilo de microservicios con orquestación basada en eventos, por las siguientes razones:
🤖 ¿Cómo afecta el caso de uso de autoetiquetado la proyección de costos?
El autoetiquetado introduce una capa de inteligencia que impacta directamente en el OpEx y en la arquitectura técnica:
🔺 Costos que pueden aumentar:
🔻 Costos que pueden disminuir:
📊 Proyección estratégica
🎯 Valor Estratégico
