docs: estado de migracion, arquitectura objetivo UniCABA, roadmap MVP y changelog oficial
This commit is contained in:
+131
@@ -0,0 +1,131 @@
|
||||
# ROADMAP MVP — Sistema Integral UniCABA
|
||||
## Gestión de Espacios Áulicos, Actividad de Cursada y Seguimiento Académico
|
||||
|
||||
**Institución:** Universidad de la Ciudad de Buenos Aires (UniCABA)
|
||||
**Versión:** 2.1.0
|
||||
**Fecha de Actualización:** 19 de Septiembre de 2026
|
||||
**Rama Base:** `testing`
|
||||
|
||||
---
|
||||
|
||||
## 🗺️ Visión del Proyecto
|
||||
Construir y evolucionar la plataforma de gestión académica y espacial de **UniCABA** hacia un sistema integral de clase universitaria, desacoplado en una arquitectura **Backend RESTful (Python/Flask) + Frontend BFF (Node.js/Express/Nunjucks)**, capaz de gobernar tanto los espacios físicos de la sede central como la dinámica áulica del campus virtual, garantizando una experiencia fluida para **Administradores**, **Bedelía**, **Docentes** y **Estudiantes**.
|
||||
|
||||
---
|
||||
|
||||
## 📊 Estado Global de Progreso
|
||||
|
||||
```
|
||||
Fase 0: Desacople y Arquitectura Base [████████████████████] 100% (Completado)
|
||||
Fase 1: Paridad Legacy y Estabilización [████████████████████] 100% (Completado)
|
||||
Fase 2: Co-docencia y Matriz Conflictos [░░░░░░░░░░░░░░░░░░░░] 0% (Próxima)
|
||||
Fase 3: Hitos Evaluativos y Calificaciones[░░░░░░░░░░░░░░░░░░░░] 0% (Planificada)
|
||||
Fase 4: UI/UX Drag & Drop e Impersonación[░░░░░░░░░░░░░░░░░░░░] 0% (Planificada)
|
||||
Fase 5: Despliegue Producción e Integrac.[░░░░░░░░░░░░░░░░░░░░] 0% (Planificada)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Detalle de Fases y Estadios
|
||||
|
||||
### Fase 0: Desacople y Arquitectura Base ✅ *(Completada)*
|
||||
* **Objetivo:** Separar el monolito Jinja2 legacy en dos servicios independientes de alto rendimiento.
|
||||
* **Entregables:**
|
||||
* [x] Creación del Backend Flask como API REST pura bajo `/api/v1/` retornando exclusivamente JSON.
|
||||
* [x] Implementación del Frontend BFF en Node.js + Express con renderizado de plantillas mediante Nunjucks.
|
||||
* [x] Autenticación desacoplada mediante JWT (`access_token`) transportado en Cookie `HttpOnly` segura.
|
||||
* [x] Pipeline de seguridad `SecurityFilterChain` con cabeceras de blindaje OWASP y rate limiting dinámico.
|
||||
* [x] Cliente HTTP Axios centralizado con inyección automática de Bearer token y manejo de sesiones.
|
||||
|
||||
---
|
||||
|
||||
### Fase 1: Paridad Legacy, Estabilización de Virtualidad y BFF Core ✅ *(Completada)*
|
||||
* **Objetivo:** Alcanzar paridad funcional total con la versión legacy, subsanando defectos críticos de virtualidad y dotando de interfaz específica a cada rol.
|
||||
* **Entregables:**
|
||||
* [x] **Importador de Google Sheets Corregido:**
|
||||
* Eliminación de la colisión de horarios en el aula virtual única (`Campus Virtual · VIRTUAL`).
|
||||
* Incremento de reservas registradas de 363 a 643 (incorporando 280 clases virtuales que se descartaban).
|
||||
* Generación y persistencia automática de enlaces de Google Meet institucional por comisión y reserva.
|
||||
* [x] **Dashboards Especializados por Rol:**
|
||||
* Dashboard interactivo para **Bedelía** (aulas físicas, salas virtuales, aprobaciones pendientes).
|
||||
* Dashboard interactivo para **Docente** (clases del día, comisiones, enlaces directos a Meet).
|
||||
* Dashboard interactivo para **Alumno** (brújula de cursada *"¿Dónde curso hoy?"*, hitos y calendario).
|
||||
* Cockpit institucional para **Admin** (métricas de capacidad, auditoría RBAC, demanda mensual).
|
||||
* Selector dinámico de vista previa / roles en tiempo real (`?role=...`).
|
||||
* [x] **Cartelera del Día (`today_schedule`):**
|
||||
* Grilla temporal por bloques horarios (07:00 a 21:00 hs) con indicadores físicos y virtuales.
|
||||
* Filtro dinámico para ocultar clases virtuales (`hide_virtual=1`) y segmentación por piso o turno.
|
||||
* [x] **Acople de Ficha de Reserva (`schedule.view_reservation`):**
|
||||
* Ruteo en BFF (`/schedule/view_reservation?id=...` y `/view/:id`).
|
||||
* Endpoint REST `/api/v1/reservations/<id>` con enriquecimiento relacional (aula, comisión, docente).
|
||||
* Soporte para modificar reserva (`edit_reservation`) con selectores en cascada, confirmación y cancelación.
|
||||
* [x] **Gestión de Comisiones (`admin/commissions_list`):**
|
||||
* Botón y modal interactivo `+ Nueva Comisión` (`#modalAddCommission`).
|
||||
* Vinculación obligatoria y explícita a la **Asignatura / Materia**, indicando cuatrimestre, año lectivo, turno, docente a cargo, cupo y enlace virtual.
|
||||
* Visualización en tabla de la materia vinculada con su código y carrera asociada.
|
||||
|
||||
---
|
||||
|
||||
### Fase 2: Co-docencia, Matriz de Conflictos y Regla Diaria ⏳ *(En curso / Inmediata)*
|
||||
* **Objetivo:** Implementar las reglas de negocio académicas complejas para asignación de cátedras y cursada de alumnos.
|
||||
* **Estadios:**
|
||||
1. **Estadio 2.1 — Modelo de Co-docencia:**
|
||||
- [ ] Tabla relacional `commission_teachers` para soportar múltiples docentes por comisión (titulares, adjuntos, ayudantes).
|
||||
- [ ] Endpoints `/api/v1/commissions/<id>/teachers` para asociar y desvincular docentes de cátedra.
|
||||
- [ ] Adaptación de vistas de Bedelía y Comisiones para visualizar el equipo docente completo.
|
||||
2. **Estadio 2.2 — Matriz de Conflictos y Validación:**
|
||||
- [ ] Validación estricta de conflicto físico: bloqueo de doble asignación de aula en mismo día y horario.
|
||||
- [ ] Validación de conflicto docente: detección de superposición horaria del profesor, con soporte de excepción justificada cuando la comisión cuenta con co-docencia.
|
||||
- [ ] Validación de aforo: bloqueo cuando la cantidad de alumnos excede la capacidad del aula física.
|
||||
3. **Estadio 2.3 — Regla de Restricción Diaria del Alumno:**
|
||||
- [ ] Validación al matricular: un alumno no puede cursar dos asignaturas regulares en el mismo día calendario.
|
||||
- [ ] Excepción parametrizable: autorización automática si al menos una de las materias es un "curso corto" o si existe autorización manual de Bedelía (`allow_same_day_exception`).
|
||||
|
||||
---
|
||||
|
||||
### Fase 3: Gestión de Hitos Evaluativos y Libro de Calificaciones 📅 *(Planificada)*
|
||||
* **Objetivo:** Proveer al cuerpo docente y estudiantil el seguimiento completo de instancias evaluativas.
|
||||
* **Estadios:**
|
||||
1. **Estadio 3.1 — Calendario de Evaluación por Comisión:**
|
||||
- [ ] Programación de parciales, recuperatorios, entregas de trabajos prácticos y exámenes finales.
|
||||
- [ ] Notificaciones preventivas en el dashboard del alumno con cuenta regresiva para exámenes.
|
||||
2. **Estadio 3.2 — Libro de Calificaciones (*Gradebook*):**
|
||||
- [ ] Matriz de carga rápida de notas para docentes con autoguardado asíncrono.
|
||||
- [ ] Consulta individualizada de calificaciones y retroalimentaciones pedagógicas para alumnos.
|
||||
- [ ] Cierre de actas de regularidad y promoción para Bedelía.
|
||||
|
||||
---
|
||||
|
||||
### Fase 4: UI/UX Avanzada para Bedelía & Modo Impersonación 🖥️ *(Planificada)*
|
||||
* **Objetivo:** Dotar a la oficina de Bedelía y a la Administración de herramientas interactivas de última generación.
|
||||
* **Estadios:**
|
||||
1. **Estadio 4.1 — Grilla Semanal Interactiva (Drag-and-Drop):**
|
||||
- [ ] Interfaz tipo TimeGrid interactiva con arrastre de comisiones para asignación rápida de aulas y turnos.
|
||||
- [ ] Detección visual en tiempo real de aulas ocupadas o incompatibles.
|
||||
2. **Estadio 4.2 — Modo Impersonación del Superadmin:**
|
||||
- [ ] Funcionalidad de *login as* o vista previa con cabecera `X-Impersonate-User` para replicar exactamente lo que ve cualquier docente o alumno.
|
||||
- [ ] Trazabilidad obligatoria de acciones bajo impersonación en el registro de auditoría (`audit_logs`).
|
||||
3. **Estadio 4.3 — Integración del Optimizador Genético:**
|
||||
- [ ] Acople del motor predictivo de algoritmos genéticos a la base de datos real para sugerir redistribución óptima de aulas según aforo.
|
||||
|
||||
---
|
||||
|
||||
### Fase 5: Producción Institucional, CI/CD e Integraciones 🏢 *(Planificada)*
|
||||
* **Objetivo:** Puesta en marcha definitiva en la infraestructura de servidores de UniCABA.
|
||||
* **Estadios:**
|
||||
1. **Estadio 5.1 — Despliegue e Infraestructura:**
|
||||
- [ ] `docker-compose.yml` productivo orquestando Flask (Gunicorn), Node.js BFF (PM2) y PostgreSQL 15.
|
||||
- [ ] Proxy inverso Nginx con certificados SSL/TLS y compresión Brotli/Gzip.
|
||||
2. **Estadio 5.2 — Integraciones Universitarias:**
|
||||
- [ ] Módulo de exportación/importación compatible con SIU Guaraní 3.
|
||||
- [ ] Sincronización automática de aulas virtuales con Moodle institucional.
|
||||
3. **Estadio 5.3 — Pruebas de Carga y Hardening:**
|
||||
- [ ] Pruebas de estrés de concurrencia en días pico de inicio de cuatrimestre (10.000 solicitudes simultáneas).
|
||||
|
||||
---
|
||||
|
||||
## 📈 Criterios de Aceptación del MVP
|
||||
1. **Zero Colisiones Físicas:** Imposibilidad absoluta de asignar dos materias simultáneas a una misma aula física.
|
||||
2. **Virtualidad Fluida:** Acceso con un clic a reuniones virtuales válidas para el 100% de las comisiones remotas.
|
||||
3. **Roles Seguros:** Separación total de permisos donde ningún alumno o docente acceda a configuración global ni a datos privados de otras comisiones.
|
||||
4. **Respuesta Sub-segundo:** Carga de carteleras y calendarios en menos de 300 ms en el BFF Node.js.
|
||||
Reference in New Issue
Block a user