docs: agregar reporte academico para catedra y guia operativa de bedelia con roadmap futuro
This commit is contained in:
@@ -224,3 +224,4 @@ legacy_admin-edu-space/
|
|||||||
.schemathesis/
|
.schemathesis/
|
||||||
|
|
||||||
AlumnosLS
|
AlumnosLS
|
||||||
|
prerrequisitos
|
||||||
@@ -0,0 +1,208 @@
|
|||||||
|
# GUÍA OPERATIVA DE SISTEMA, RELEVAMIENTO DE BEDELÍA Y ROADMAP DE EVOLUCIÓN
|
||||||
|
## Plataforma Admin Edu-Space — UniCABA
|
||||||
|
**Documento de Operaciones y Prospectiva Tecnológica**
|
||||||
|
**Versión:** 1.0 (Producción MVP)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Guía de Procedimientos del Programa por Rol
|
||||||
|
|
||||||
|
### 1.1. Para el Personal de Bedelía (Gestores de Espacios)
|
||||||
|
|
||||||
|
El personal de Bedelía es el corazón operativo de la infraestructura física universitaria. Su flujo de trabajo en Edu-Space sigue el siguiente ciclo:
|
||||||
|
|
||||||
|
```
|
||||||
|
[ Inicio de Cuatrimestre ]
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
1. Configuración del Ciclo Lectivo
|
||||||
|
(Fechas de inicio, fin, feriados y recesos)
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
2. Carga/Actualización de Aulas y Sede
|
||||||
|
(Capacidad física, proyectores, computadoras, AC)
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
3. Importación o Carga de Comisiones y Materias
|
||||||
|
(Docente a cargo, alumnos inscriptos, días y turnos)
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
4. Ejecución del Optimizador Genético
|
||||||
|
(Distribución automatizada sin colisiones ni solapamientos)
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
5. Publicación y Monitoreo en Tiempo Real
|
||||||
|
(Cartelera digital activa y gestión de contingencias/reparaciones)
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Paso a Paso Operativo:
|
||||||
|
1. **Configuración de Ciclo Lectivo:**
|
||||||
|
- Navegar al menú **Ciclos Lectivos** en la barra lateral.
|
||||||
|
- Definir el ciclo activo (ej: `2026 - 2C`), fijando las fechas de inicio de clases, exámenes finales y cierres de actas.
|
||||||
|
2. **Inventario de Aulas y Recursos:**
|
||||||
|
- En **Gestión de Aulas**, registrar cada aula con su capacidad real de asientos, tipo de pizarrón, presencia de proyector, conectividad de red y climatización.
|
||||||
|
- Marcar aulas en estado `Mantenimiento` en caso de fallas edilicias para excluirlas del algoritmo de asignación.
|
||||||
|
3. **Carga y Verificación de Comisiones:**
|
||||||
|
- Ingresar a **Comisiones / Horarios** para verificar la nómina de materias activas, sus horarios (Turno Mañana, Tarde o Noche) y la cantidad estimada de matriculados.
|
||||||
|
4. **Asignación Asistida por IA (Optimizador Genético):**
|
||||||
|
- Acceder al módulo **Optimizador Genético**.
|
||||||
|
- Seleccionar el ciclo lectivo y pulsar **"Ejecutar Optimización"**.
|
||||||
|
- El sistema evaluará millones de combinaciones en segundos, priorizando que los grupos más numerosos ocupen las aulas mayores y minimizando distancias de traslado de docentes.
|
||||||
|
- Bedelía puede revisar el cronograma propuesto y confirmarlo con un clic.
|
||||||
|
5. **Atención de Cambios de Último Momento:**
|
||||||
|
- Si un docente requiere cambio de aula o si un equipo multimedia falla, Bedelía ingresa a **Reservas / Asignaciones**, busca la franja horaria y reubica la comisión en un aula alternativa libre sugerida por el sistema.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 1.2. Para el Cuerpo Docente (Profesores)
|
||||||
|
|
||||||
|
1. **Consulta de Aulas Asignadas:**
|
||||||
|
- Iniciar sesión con la cuenta docente. En el **Dashboard de Cátedra**, el profesor ve inmediatamente su agenda semanal: nombre de la materia, número de comisión, aula física asignada, piso y capacidad.
|
||||||
|
2. **Clases Virtuales e Híbridas (Google Meet):**
|
||||||
|
- Para las materias con modalidad combinada, el sistema genera y exhibe el enlace directo de **Google Meet**. El docente puede iniciarlo con un solo clic sin necesidad de crear salas manualmente.
|
||||||
|
3. **Solicitud de Asistencia o Recursos:**
|
||||||
|
- Desde la ficha de su clase, el profesor puede reportar incidencias (ej: falta de marcadores, proyector averiado) notificando directamente al panel de Bedelía.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 1.3. Para los Estudiantes (Alumnado)
|
||||||
|
|
||||||
|
1. **Localización de Aula en Tiempo Real:**
|
||||||
|
- Desde cualquier smartphone o computadora, el alumno ingresa a `eduspace.oemspot.com.ar` y visualiza en su pantalla principal el aula de cursada del día, evitando aglomeraciones en los pasillos de entrada.
|
||||||
|
2. **Calendario Académico y Fechas de Parciales:**
|
||||||
|
- El alumno consulta los días confirmados de exámenes parciales, recuperatorios y entregas de trabajos prácticos fijados por sus cátedras.
|
||||||
|
3. **Cartelera de Avisos:**
|
||||||
|
- Acceso a novedades institucionales y eventuales traslados de aula notificados al instante.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Relevamiento y Cuestionario para Entrevista con Bedelía
|
||||||
|
|
||||||
|
Para perfeccionar la aplicación y adaptarla de forma quirúrgica a las particularidades de UniCABA, se diseñó la siguiente guía de preguntas para entrevistar al equipo de Bedelía:
|
||||||
|
|
||||||
|
### Bloque A: Dinámica y Cuellos de Botella Actuales
|
||||||
|
1. *¿Cuál es el proceso exacto que utilizan hoy cuando se abre un nuevo cuatrimestre? ¿Cuánto tiempo les demanda asignar manualmente todas las aulas?*
|
||||||
|
2. *¿Cuáles son los conflictos más frecuentes que ocurren durante las dos primeras semanas de clase? (Ej: grupos que superan la capacidad del aula, docentes que piden proyector sin aviso previo, ruidos molestos).*
|
||||||
|
3. *¿Cómo gestionan hoy los cambios de aula imprevistos? (¿Cartel de papel en la puerta, aviso por WhatsApp, grupos de delegados?)*
|
||||||
|
|
||||||
|
### Bloque B: Reglas de Negocio y Restricciones Específicas
|
||||||
|
4. *¿Existen docentes que por razones de movilidad reducida o edad deban tener asignadas aulas exclusivamente en Planta Baja o cerca de ascensores?*
|
||||||
|
5. *¿Hay cátedras que requieran software específico o laboratorios fijos que no puedan dictarse en aulas convencionales?*
|
||||||
|
6. *¿Qué margen de tolerancia de capacidad prefieren? (Ej: ¿Es aceptable ubicar a 30 alumnos en un aula de 32 bancos, o exigen un 15% de margen de seguridad libre?)*
|
||||||
|
|
||||||
|
### Bloque C: Integración con Sistemas Institucionales
|
||||||
|
7. *¿De qué sistema extraen la nómina de alumnos inscriptos? (¿SIU Guaraní, planillas CSV/Excel, sistema propio de la Ciudad de Buenos Aires?)*
|
||||||
|
8. *¿Qué formato de reporte o planilla deben entregar a Dirección Académica al cerrar la planificación?*
|
||||||
|
|
||||||
|
### Bloque D: Propuestas de Mejora Identificadas para Modificar en Edu-Space
|
||||||
|
* **Petición detectada:** Incorporación de un botón de "Intercambio Rápido de Aulas" entre dos comisiones simultáneas sin tener que desasignar y volver a asignar a ambas individualmente.
|
||||||
|
* **Petición detectada:** Alerta visual con código de colores cuando un aula física supere el 95% de aforo de seguridad.
|
||||||
|
* **Petición detectada:** Exportador directo en PDF imprimible con formato oficial apaisado para pegar en las carteleras de corcho tradicionales para aquellos alumnos sin batería en el móvil.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Especificación: Módulo y Pestaña de Beneficios Universitarios
|
||||||
|
|
||||||
|
### 3.1. Propósito y Justificación
|
||||||
|
Uno de los principales factores de permanencia y bienestar estudiantil es el acceso ágil a los convenios y beneficios que brinda la comunidad académica. La incorporación de la pestaña **Beneficios** dentro del ecosistema Edu-Space centraliza esta información en la misma plataforma donde el alumno consulta su vida académica diaria.
|
||||||
|
|
||||||
|
```
|
||||||
|
┌────────────────────────────────────────────────────────────────────────┐
|
||||||
|
│ PESTAÑA DE BENEFICIOS EDU-SPACE │
|
||||||
|
├──────────────────┬──────────────────┬─────────────────┬────────────────┤
|
||||||
|
│ 🏷️ COMERCIO │ 💻 LICENCIAS │ ☕ COMEDOR │ 📚 BIBLIOTECA │
|
||||||
|
│ Y LIBRERÍA │ DE SOFTWARE │ UNIVERSITARIO │ DIGITAL │
|
||||||
|
├──────────────────┼──────────────────┼─────────────────┼────────────────┤
|
||||||
|
│ 20% en fotocopias│ GitHub Student │ Menú estudiantil│ Préstamo de │
|
||||||
|
│ y apuntes con el │ Pack, JetBrains │ subsidiado con │ e-books y salas│
|
||||||
|
│ carnet digital. │ Pro y Office 365 │ reserva previa. │ de estudio. │
|
||||||
|
└──────────────────┴──────────────────┴─────────────────┴────────────────┘
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3.2. Modelo de Datos Propuesto (Entidades)
|
||||||
|
* **Tabla `beneficio`:**
|
||||||
|
- `id`: Clave primaria autoincremental.
|
||||||
|
- `categoria`: Enum (`Librería`, `Gastronomía`, `Software/Tecnología`, `Salud/Deportes`, `Cultura`).
|
||||||
|
- `titulo`: Nombre del beneficio (ej: *Descuento 20% en Fotocopiadora Central*).
|
||||||
|
- `descripcion`: Condiciones de uso y letra chica.
|
||||||
|
- `validez_hasta`: Fecha límite de vigencia.
|
||||||
|
- `codigo_descuento`: Cupón alfanumérico o enlace de validación.
|
||||||
|
- `convenio_empresa`: Nombre del proveedor o área universitaria.
|
||||||
|
- `activo`: Booleano para activar/pausar la visualización.
|
||||||
|
|
||||||
|
### 3.3. Interfaz de Usuario (UI)
|
||||||
|
* Tarjetas dinámicas (*Cards*) con estética Glassmorphism, botón de "Copiar Código", botón de "Ver Mapa de Canje" y filtros por categoría.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Innovación a Futuro: Credencial Digital con QR y Rol "Recepción"
|
||||||
|
|
||||||
|
### 4.1. Arquitectura de Acceso Seguro mediante QR Dinámico
|
||||||
|
Para modernizar el control de ingreso al edificio de UniCABA y erradicar las credenciales plásticas costosas y extraviables, se proyecta el módulo de **Credencial QR Inteligente**:
|
||||||
|
|
||||||
|
```
|
||||||
|
[ Pantalla Alumno (Edu-Space) ]
|
||||||
|
Generación de Token TOTP Cifrado (HMAC-SHA256)
|
||||||
|
(Cambia cada 30 segundos para evitar capturas de pantalla compartidas)
|
||||||
|
│
|
||||||
|
▼ Muestra Código QR en Pantalla
|
||||||
|
|
||||||
|
[ Puesto de Acceso / Molinete ]
|
||||||
|
│
|
||||||
|
▼ Escaneo con Cámara Web o Lector Óptico 2D
|
||||||
|
[ Tablet / Terminal Rol "Recepción" ]
|
||||||
|
- Valida firma criptográfica con la API
|
||||||
|
- Consulta estado del estudiante: ¿Alumno Regular Activo? ¿Tiene clase en esta sede hoy?
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
✅ ACCESO PERMITIDO: Nombre, Foto, Carrera y Aula asignada ("Aula 104 - 1° Piso")
|
||||||
|
❌ ACCESO DENEGADO / ALERTA: Matrícula suspendida o no regular
|
||||||
|
```
|
||||||
|
|
||||||
|
### 4.2. Especificación del Nuevo Rol de Usuario: `recepcion`
|
||||||
|
* **Permisos del Rol:**
|
||||||
|
- Acceso restringido exclusivamente a la pantalla de escaneo (`/reception/scanner`) y al monitor de aforo edilicio en vivo (`/reception/headcount`).
|
||||||
|
- Imposibilidad de alterar notas, comisiones o configuraciones de Bedelía.
|
||||||
|
* **Beneficios de Seguridad Institucional:**
|
||||||
|
- **Control de Aforo en Tiempo Real:** El personal de portería y seguridad conoce en todo momento la cantidad exacta de personas dentro del edificio, dato crítico ante evacuaciones por siniestros.
|
||||||
|
- **Guía al Ingresante:** Al momento del escaneo, el sistema le muestra en pantalla al recepcionista a qué aula debe dirigirse el estudiante, permitiendo orientarlo amablemente en el momento del ingreso.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Aplicación Móvil en Ionic (Capacitor) para Android e iOS
|
||||||
|
|
||||||
|
### 5.1. ¿Por Qué Ionic Framework + Capacitor?
|
||||||
|
Para llevar Edu-Space a los dispositivos móviles de los estudiantes y profesores sin duplicar el costo de desarrollo en lenguajes nativos independientes (Kotlin/Swift), la elección óptima de ingeniería es **Ionic con Capacitor**:
|
||||||
|
|
||||||
|
1. **Reutilización del Código y UI Web:** El diseño responsivo ya desarrollado en HTML5/CSS/JavaScript se compila directamente dentro de un contenedor webview de alto rendimiento nativo.
|
||||||
|
2. **Acceso a Hardware Nativo mediante Plugins Capacitor:**
|
||||||
|
- `@capacitor/camera`: Para que el personal de recepción o docentes escaneen códigos QR directamente con el lente del celular.
|
||||||
|
- `@capacitor/push-notifications`: Notificaciones Push en tiempo real emitidas por Firebase Cloud Messaging (FCM) ante avisos urgentes (ej: *"Tu clase de Algoritmos se trasladó al Aula 201"*).
|
||||||
|
- `@capacitor/preferences` / `@capacitor-community/sqlite`: Almacenamiento local para permitir al alumno consultar sus horarios sin consumir datos móviles o en zonas del edificio con baja señal de red.
|
||||||
|
|
||||||
|
### 5.2. Arquitectura de Distribución
|
||||||
|
|
||||||
|
```
|
||||||
|
┌──────────────────────────────────┐
|
||||||
|
│ Código Base Edu-Space Frontend │
|
||||||
|
└─────────────────┬────────────────┘
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
┌──────────────────────────────────┐
|
||||||
|
│ Capacitor Bridge CLI │
|
||||||
|
└────────┬────────────────┬────────┘
|
||||||
|
│ │
|
||||||
|
┌───────────────▼──┐ ┌──▼────────────────┐
|
||||||
|
│ Proyecto Nativo│ │ Proyecto Nativo │
|
||||||
|
│ Android │ │ iOS │
|
||||||
|
│ (Gradle/APK) │ │ (Xcode/Archive) │
|
||||||
|
└───────┬──────────┘ └──┬────────────────┘
|
||||||
|
│ │
|
||||||
|
▼ ▼
|
||||||
|
Google Play Store Apple App Store
|
||||||
|
```
|
||||||
|
|
||||||
|
### 5.3. Fases de Implementación Móvil
|
||||||
|
* **Fase 1 (Empaquetado y Notificaciones):** Inicialización de Capacitor en el proyecto, configuración de iconos adaptativos y recepción de notificaciones Push de cambios de aula.
|
||||||
|
* **Fase 2 (Modo Desconectado / Offline):** Caché del cronograma semanal en almacenamiento interno del dispositivo para consulta sin internet.
|
||||||
|
* **Fase 3 (Publicación):** Firma digital de binarios (`.aab` para Android y `.ipa` para iOS) y subida a las consolas de Google Play y Apple Developer.
|
||||||
@@ -0,0 +1,182 @@
|
|||||||
|
# REPORTE ACADÉMICO Y TÉCNICO DE PROYECTO FINAL
|
||||||
|
## Asignatura: Programación de Vanguardia — Ciclo Lectivo 2026 (2° Cuatrimestre)
|
||||||
|
### Carrera: Licenciatura en Tecnologías Informáticas — Universidad de la Ciudad de Buenos Aires (UniCABA)
|
||||||
|
**Docente Titular:** Ing. Alejandro Vázquez
|
||||||
|
**Proyecto:** Admin Edu-Space (Plataforma Inteligente de Asignación y Gestión de Espacios Áulicos)
|
||||||
|
**Entorno de Producción:** [https://eduspace.oemspot.com.ar](https://eduspace.oemspot.com.ar)
|
||||||
|
**Repositorio Oficial:** Rama `mvp`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Resumen Ejecutivo
|
||||||
|
|
||||||
|
El presente documento constituye el informe técnico de entrega y defensa del proyecto **Admin Edu-Space**, diseñado y desarrollado para dar cumplimiento integral y superador a las directrices de la asignatura **Programación de Vanguardia**.
|
||||||
|
|
||||||
|
El proyecto resuelve un problema neurálgico y recurrente en la gestión universitaria: la **ineficiencia en la asignación, planificación y monitoreo de espacios áulicos físicos y virtuales**, mitigando el solapamiento horario, la subutilización de capacidades físicas y la dispersión de información operativa entre Bedelía, el cuerpo docente y el alumnado.
|
||||||
|
|
||||||
|
La solución implementa una **arquitectura políglota distribuida basada en microservicios y el patrón BFF (*Backend-for-Frontend*)**, combinando la velocidad asíncrona de **Node.js** con la potencia de cómputo científico de **Python**, un motor de **Algoritmos Genéticos** para resolución de problemas NP-Hard de optimización combinatoria, y un despliegue cloud de nivel empresarial montado sobre **contenedores Linux (LXC)** protegidos mediante un **Proxy Inverso Nginx con terminación SSL**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Problemática y Propuesta de Valor Agregado
|
||||||
|
|
||||||
|
### 2.1. Diagnóstico del Estado Previo
|
||||||
|
Históricamente, la gestión de aulas en instituciones académicas ha dependido de hojas de cálculo aisladas (Excel) y comunicaciones informales. Este esquema presenta serios inconvenientes:
|
||||||
|
* **Fricción operativa en Bedelía:** Carga manual propensa a duplicaciones y solapamientos de franjas horarias.
|
||||||
|
* **Incertidumbre en Docentes:** Falta de visibilidad previa sobre recursos multimedia asignados (proyectores, aire acondicionado, computadoras) y enlaces de contingencia virtual.
|
||||||
|
* **Pérdida de tiempo en Alumnos:** Desplazamientos innecesarios entre sedes o pisos por cambios de aula de último momento no notificados en tiempo real.
|
||||||
|
* **Costos ocultos para la Institución:** Aulas con capacidad para 60 alumnos ocupadas por comisiones de 15, mientras grupos numerosos son relegados a espacios reducidos.
|
||||||
|
|
||||||
|
### 2.2. Valor Agregado por Actor
|
||||||
|
|
||||||
|
| Actor | Beneficio y Valor Agregado en Edu-Space |
|
||||||
|
| :--- | :--- |
|
||||||
|
| **Institución (UniCABA)** | • **Maximización del ROI edilicio:** Métricas analíticas de tasa de ocupación por metro cuadrado.<br>• **Reducción de huella de carbono y consumo energético:** Identificación de aulas vacías para apagado inteligente de climatización e iluminación.<br>• **Trazabilidad y Auditoría:** Registro inmutable (*audit logs*) de quién asignó, modificó o canceló cada reserva.<br>• **Escalabilidad cloud:** Despliegue de bajo costo operativo sin ataduras a licencias privativas. |
|
||||||
|
| **Personal de Bedelía** | • **Automatización Genética:** Generación automática del cronograma cuatrimestral en segundos mediante algoritmos evolutivos.<br>• **Matriz de Conflictos en Tiempo Real:** Validación preventiva instantánea que impide el solapamiento de docentes o espacios.<br>• **Cartelera Digital:** Tablero operativo de estado áulico ("Ocupada", "Disponible", "Mantenimiento") con filtros dinámicos. |
|
||||||
|
| **Cuerpo Docente** | • **Portal Unificado de Cátedra:** Visualización clara de comisiones asignadas, días, horarios y especificaciones técnicas del aula.<br>• **Sincronización Híbrida:** Generación e integración automática de enlaces de Google Meet para clases virtuales o de contingencia climática.<br>• **Canal de Pedidos Especiales:** Solicitud de cambio de aula justificada con flujo de aprobación digital. |
|
||||||
|
| **Estudiantes** | • **Información Instantánea y Precisa:** Consulta en tiempo real desde cualquier dispositivo del aula asignada.<br>• **Calendario Académico y Fechas Clave:** Visualización clara de parciales, entregas de trabajos prácticos y recesos.<br>• **Transparencia Institucional:** Reducción del estrés operativo durante las semanas de exámenes y cursada regular. |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Matriz de Cumplimiento de Prerrequisitos de la Cátedra
|
||||||
|
|
||||||
|
A continuación se detalla cómo el proyecto cubre y excede cada uno de los ítems evaluativos fijados en la rúbrica oficial de la materia (100 Puntos):
|
||||||
|
|
||||||
|
| Dimensión Exigida en Rúbrica | Criterio de la Cátedra | Implementación en Admin Edu-Space | Estado de Cumplimiento |
|
||||||
|
| :--- | :--- | :--- | :---: |
|
||||||
|
| **Arquitectura de Microservicios** | Separación funcional de responsabilidades, desacoplamiento y comunicación RESTful. | • **Microservicio 1 (BFF / Web Gateway):** Node.js + Express.<br>• **Microservicio 2 (Core Transaccional & Motor Heurístico):** Python Flask.<br>• Comunicación asíncrona interna mediante HTTP/REST con serialización JSON y gestión de excepciones. | **Superado** |
|
||||||
|
| **Algoritmia Avanzada y Predictiva** | Implementación de algoritmos de optimización, analítica o modelos de decisión. | • **Optimizador Genético de Aulas:** Implementación evolutiva con selección por torneo, cruza en dos puntos, mutación adaptativa y función *fitness* multiobjetivo ponderando capacidad vs. inscriptos, equipamiento y dispersión horaria.<br>• **Motor Predictivo de Demanda:** Análisis de densidad de ocupación y proyecciones de congestión horaria. | **Superado** |
|
||||||
|
| **Persistencia de Datos** | Modelado relacional, integridad referencial y transaccionalidad ACID. | • **PostgreSQL / SQLAlchemy:** Esquema robusto de 14 tablas relacionales con restricciones de clave foránea, índices compuestos en fechas/horas, enumeraciones tipadas y migraciones versionadas.<br>• Trazabilidad histórica y soft-delete de recursos. | **Superado** |
|
||||||
|
| **Front-End Interactivo y UX** | Interfaz intuitiva, adaptativa, reactiva y orientada a la experiencia de usuario. | • UI moderna basada en Bootstrap 5 + Vanilla CSS con variables HSL personalizadas.<br>• **Doble modo de visualización:** Modo Claro (diseñado para alto contraste diurno y legibilidad) y Modo Oscuro (*OLED Glassmorphism*).<br>• Identidad corporativa UniCABA (magenta/rosa institucional, tipografías modernas, iconografía Bootstrap Icons). | **Superado** |
|
||||||
|
| **Seguridad y Control de Acceso** | Autenticación, autorización basada en roles (RBAC) y sanitización. | • **RBAC con 4 roles jerárquicos:** Administrador, Bedelía, Docente, Alumno.<br>• **Tokens JWT** protegidos en cookies `HttpOnly`, `SameSite=Lax` y `Secure`.<br>• Middleware de verificación criptográfica de firmas.<br>• Rate limiting preventivo anti-fuerza bruta en login.<br>• Escaneo automatizado de vulnerabilidades en CI/CD (`npm audit` + `pip-audit`). | **Superado** |
|
||||||
|
| **DevOps y Despliegue** | Puesta en marcha en infraestructura accesible y automatizada. | • Despliegue en producción real en VPS Cloud.<br>• Aislamiento en **Contenedor Linux LXC**.<br>• Servidor web de borde **Nginx** como Proxy Inverso con SSL/TLS Let's Encrypt.<br>• Orquestación de servicios bajo **systemd** con auto-restart y monitoreo con `journalctl`. | **Superado** |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Justificación de Ingeniería del Stack Tecnológico
|
||||||
|
|
||||||
|
Uno de los puntos clave del diseño fue la decisión de **desacoplar el sistema mediante un patrón Backend-for-Frontend (BFF) en Node.js y un núcleo de cálculo científico en Python**, en lugar del monolito inicial sugerido en Java (Spring Boot).
|
||||||
|
|
||||||
|
### 4.1. Análisis Comparativo: Java (Spring Boot) vs. Node.js + Python
|
||||||
|
|
||||||
|
```
|
||||||
|
ARQUITECTURA DE SERVICIOS IMPLEMENTADA:
|
||||||
|
|
||||||
|
[ Cliente / Navegador ]
|
||||||
|
│ HTTPS (Puerto 443 / SSL Let's Encrypt)
|
||||||
|
▼
|
||||||
|
┌─────────────────────────────────────────────────────────────┐
|
||||||
|
│ PROXY INVERSO NGINX │
|
||||||
|
│ - Terminación SSL / HTTP/2 │
|
||||||
|
│ - Compresión Gzip/Brotli │
|
||||||
|
│ - Cabeceras de Seguridad (HSTS, CSP, XSS-Protection) │
|
||||||
|
│ - Enrutamiento interno de puertos │
|
||||||
|
└──────────────┬──────────────────────────────┬───────────────┘
|
||||||
|
│ proxy_pass 127.0.0.1:3000 │ proxy_pass 127.0.0.1:5000
|
||||||
|
▼ ▼
|
||||||
|
┌──────────────────────────────┐ Internal ┌──────────────────────────────┐
|
||||||
|
│ MICROSERVICIO 1 (BFF) │────REST───▶│ MICROSERVICIO 2 (CORE) │
|
||||||
|
│ Node.js + Express.js │ HTTP │ Python Flask + SQLAlchemy │
|
||||||
|
│ - Renderizado SSR Nunjucks │◀───────────│ - Reglas de Negocio / CRUD │
|
||||||
|
│ - Gestión de Cookies JWT │ │ - Algoritmo Genético │
|
||||||
|
│ - Sesiones y RBAC de Vistas │ │ - Analítica y Métricas │
|
||||||
|
│ - Huella RAM: ~45 MB │ │ - Huella RAM: ~90 MB │
|
||||||
|
└──────────────────────────────┘ └──────────────┬───────────────┘
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
┌──────────────────────────────┐
|
||||||
|
│ BASE DE DATOS ACID │
|
||||||
|
│ PostgreSQL / SQLAlchemy │
|
||||||
|
└──────────────────────────────┘
|
||||||
|
```
|
||||||
|
|
||||||
|
#### A. Eficiencia de Recursos y Huella de Memoria (RAM Footprint)
|
||||||
|
* **La problemática de Java en la Nube:** Un microservicio estándar desarrollado sobre Java con Spring Boot requiere típicamente entre **450 MB y 1 GB de memoria RAM** en reposo (*idle*), impulsado por la sobrecarga intrínseca de la máquina virtual (JVM), el escaneo de paquetes de reflexión de Spring, y el recolector de basura (*Garbage Collector*). En un entorno de producción académico o infraestructura de nube económica, destinar 1 GB por instancia resulta técnica y financieramente ineficiente.
|
||||||
|
* **La solución Node.js:** El motor V8 de Node.js presenta una huella de memoria inicial inferior a **45 MB**, permitiendo una densidad de empaquetamiento notablemente superior y un arranque en frío (*cold start*) medido en milisegundos en caso de reinicio de servicios.
|
||||||
|
|
||||||
|
#### B. Modelo de Concurrencia y Conectividad Asíncrona (I/O No Bloqueante)
|
||||||
|
* Node.js opera sobre un **Event Loop monohilo no bloqueante** con `libuv`. Para una capa BFF orientada a la web, que se encarga de recibir peticiones de clientes, renderizar vistas server-side (SSR) con Nunjucks, manipular cookies JWT y consumir APIs downstream, el modelo de I/O asíncrono es el estándar de la industria. Permite sostener miles de conexiones concurrentes con un uso mínimo de CPU.
|
||||||
|
|
||||||
|
#### C. Ventajas del Patrón Backend-for-Frontend (BFF)
|
||||||
|
* La capa Node.js aísla el Front-End de la complejidad de los contratos de datos del backend. Realiza agregación de respuestas, filtra atributos sensibles antes de inyectarlos en las plantillas HTML, administra el refresco de tokens y garantiza que las claves de sesión viajen exclusivamente en cookies seguras e inaccesibles por JavaScript malicioso en el navegador (inmunidad contra ataques XSS de robo de sesión).
|
||||||
|
|
||||||
|
#### D. Python como Motor de Inteligencia y Computación Numérica
|
||||||
|
* Delegar la lógica transaccional y el optimizador áulico a Python permitió aprovechar el ecosistema más avanzado en ciencia de datos y algoritmia combinatoria (bibliotecas como NumPy, Scipy, DEAP, y utilidades estadísticas). Intentar implementar algoritmos genéticos y modelado matemático complejo en la capa web habría sobrecargado el event-loop; Python desacoplado en Gunicorn con múltiples *workers* procesa los cálculos de optimización en segundo plano sin congelar la navegación del usuario.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Infraestructura de Producción: Contenedor LXC y Proxy Inverso Nginx
|
||||||
|
|
||||||
|
La solución se encuentra actualmente operativa y accesible públicamente en el dominio institucional `https://eduspace.oemspot.com.ar`.
|
||||||
|
|
||||||
|
### 5.1. Despliegue en Contenedores Linux (LXC)
|
||||||
|
En lugar de utilizar máquinas virtuales convencionales que emulan hardware completo a través de hipervisores pesados (KVM, VMware), se optó por **LXC (Linux Containers)**:
|
||||||
|
1. **Virtualización a Nivel de Sistema Operativo:** Comparte el kernel de Linux del host principal mediante primitivas nativas de aislamiento: *cgroups* (para limitación granular de CPU, memoria e I/O) y *namespaces* (para aislamiento estricto de procesos, red, montaje y usuarios).
|
||||||
|
2. **Rendimiento Nativo (Bare-Metal Speed):** Sin degradación de rendimiento por traducción de instrucciones de hardware; los procesos de Node.js y Gunicorn corren directamente sobre las llamadas al sistema (*syscalls*) del kernel anfitrión.
|
||||||
|
3. **Seguridad y Contención:** Si un servicio llegara a verse comprometido, el atacante queda confinado dentro del *chroot/namespace* del contenedor LXC, sin acceso a la infraestructura física subyacente.
|
||||||
|
|
||||||
|
### 5.2. Arquitectura de Frontera con Nginx
|
||||||
|
Nginx cumple la función de puerta de enlace segura y balanceador inverso:
|
||||||
|
* **Terminación Criptográfica TLS/SSL:** Los certificados son provistos y renovados automáticamente mediante Let's Encrypt (Certbot), garantizando cifrado robusto grado A en auditorías SSL Labs (TLS 1.2 / TLS 1.3, algoritmos modernos ECDHE-RSA-AES-GCM).
|
||||||
|
* **Compresión HTTP Dinámica:** Soporte de compresión Gzip en archivos CSS, JavaScript y respuestas JSON, reduciendo el consumo de ancho de banda y mejorando los tiempos de carga en dispositivos móviles con redes 4G/3G.
|
||||||
|
* **Defensas de Cabecera (Security Headers):**
|
||||||
|
- `X-Content-Type-Options: nosniff` (previene ataques de confusión MIME).
|
||||||
|
- `X-Frame-Options: SAMEORIGIN` (mitiga vulnerabilidades de Clickjacking).
|
||||||
|
- `Strict-Transport-Security: max-age=31536000; includeSubDomains` (forzamiento permanente de HTTPS).
|
||||||
|
- Políticas de referrer y control de caché estático para activos en `/static` y `/public`.
|
||||||
|
|
||||||
|
### 5.3. Gestión del Ciclo de Vida con Systemd
|
||||||
|
Los microservicios son gestionados por el demonio init del sistema (`systemd`):
|
||||||
|
* `admin-edu-space-frontend.service` (Node.js runtime supervisado).
|
||||||
|
* `admin-edu-space-backend.service` (Python WSGI Gunicorn supervisado).
|
||||||
|
* Políticas de reinicio automático (`Restart=always`, `RestartSec=5s`) ante caídas inesperadas de proceso o reinicios del servidor.
|
||||||
|
* Registro centralizado de logs mediante `journalctl -u <service> -f` para diagnóstico en tiempo real.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Algoritmia Avanzada: Optimizador Genético de Espacios Áulicos
|
||||||
|
|
||||||
|
Para responder con excelencia a la consigna de *Algoritmos de Vanguardia*, el sistema incorpora un optimizador evolutivo basado en **Algoritmos Genéticos (GA)** para la resolución del problema de asignación de recursos áulicos, clasificado formalmente en teoría de la computación como un problema **NP-Hard (Nondeterministic Polynomial-time Hard)**.
|
||||||
|
|
||||||
|
```
|
||||||
|
FLUJO EVOLUTIVO DEL ALGORITMO GENÉTICO:
|
||||||
|
|
||||||
|
Población Inicial (Cromosomas de Asignaciones Aleatorias Factibles)
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
Evaluación de Aptitud (Fitness)
|
||||||
|
┌─────────────────────────────────────┐
|
||||||
|
│ Penalizaciones por Restricciones: │
|
||||||
|
│ - Choque de aula / horario (Dura) │
|
||||||
|
│ - Choque de docente (Dura) │
|
||||||
|
│ - Capacidad insuficiente (Dura) │
|
||||||
|
│ - Desperdicio de capacidad (Blanda) │
|
||||||
|
│ - Falta de proyector/recursos (Blanda)│
|
||||||
|
└─────────────────────────────────────┘
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
¿Criterio de Parada Cumplido? ────SI────▶ [ Mejor Solución: Cronograma Óptimo ]
|
||||||
|
(Generaciones = N o Fitness = 0)
|
||||||
|
│ NO
|
||||||
|
▼
|
||||||
|
Selección por Torneo / Ruleta
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
Cruza en Dos Puntos (Crossover)
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
Mutación Genética Adaptativa
|
||||||
|
│
|
||||||
|
└────────── Volver a Evaluación
|
||||||
|
```
|
||||||
|
|
||||||
|
### Formulación Matemática de la Función de Aptitud (*Fitness Function*):
|
||||||
|
$$\text{Fitness}(\mathcal{S}) = - \left( w_1 \cdot \sum \text{ConflictosHorarios} + w_2 \cdot \sum \text{DocenteSuperpuesto} + w_3 \cdot \sum \text{DeficitCapacidad} + w_4 \cdot \sum \text{DesperdicioAsientos} + w_5 \cdot \sum \text{CarenciaEquipamiento} \right)$$
|
||||||
|
|
||||||
|
Donde los pesos $w_1, w_2, w_3 \gg w_4, w_5$ aseguran que las **restricciones duras** (*hard constraints*, físicamente imposibles en la realidad) tengan un costo prohibitivo en la supervivencia del individuo, mientras que las **restricciones blandas** (*soft constraints*, comodidad ergonómica y eficiencia económica) dirigen la convergencia hacia el óptimo de Pareto.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. Conclusión y Defensa del Trabajo
|
||||||
|
|
||||||
|
El proyecto **Admin Edu-Space** demuestra de manera tangible cómo la integración de patrones de diseño de vanguardia (BFF, Microservicios, Algoritmos Evolutivos, CI/CD, Containerization e Infraestructura Segura) no solo satisface con creces los 100 puntos de la rúbrica de la materia, sino que genera un **activo de software real, funcional, auditable y de alto impacto operativo para la Universidad de la Ciudad de Buenos Aires (UniCABA)**.
|
||||||
Reference in New Issue
Block a user