# 01 — Resumen ejecutivo *(Entregable A)* ## Qué es SIGA **SIGA** es una plataforma web de gestión académica para instituciones educativas colombianas. Cubre el ciclo completo de la operación escolar: configuración institucional, estructura académica, matrícula, evaluación, comunicación con la comunidad, generación de boletines y promoción al año siguiente. La primera implementación se despliega para **un solo colegio**, pero el modelo de datos y la arquitectura de aplicación se construyen desde el primer día para admitir **múltiples instituciones** sin reconstruir el sistema. --- ## El problema que resuelve Un colegio que no tiene sistema académico —o que tiene uno rígido— pierde tiempo administrativo en tareas que son repetitivas y mecánicas por naturaleza: | Tarea | Cómo se hace hoy sin sistema | Qué costo tiene | |---|---|---| | Matricular un estudiante | Formato en papel o Excel, se redigita cada año | 15–25 min por estudiante, con errores de transcripción | | Crear el año siguiente | Se recrean cursos, áreas y asignaturas desde cero | Días de trabajo de coordinación, idénticos al año anterior | | Promover el curso al siguiente grado | Lista manual, curso por curso | Horas, y sin trazabilidad de quién decidió qué | | Consolidar notas | Cada docente envía un Excel, alguien lo unifica | Días por periodo, con riesgo alto de error de consolidación | | Generar boletines | Plantilla de Word rellenada a mano o mail-merge frágil | La semana completa de entrega de boletines | | Responder "¿por qué cambió esta nota?" | No se puede responder | Conflicto con acudientes sin evidencia | SIGA ataca directamente estos seis puntos. **La automatización de lo repetitivo no es una característica secundaria del sistema: es su razón de ser** (§62 de la especificación). Cada decisión de diseño de esta propuesta se evaluó contra la pregunta *"¿cuántos clics le quita esto a la coordinación?"*. --- ## Los cuatro pilares del diseño ### 1. Nada se borra — todo se cierra El sistema **jamás elimina físicamente** información con valor académico o histórico (§48). Una matrícula retirada sigue existiendo con estado *Retirado*; un año cerrado sigue siendo consultable; una nota corregida conserva su valor anterior en la auditoría. El registro académico de un colegio es un documento con implicaciones legales, y se trata como tal. ### 2. El permiso se decide en el servidor, siempre El menú de un docente muestra solo sus cursos, pero eso es cosmética. **Cada operación revalida en el servidor** que el usuario tenga derecho sobre el recurso concreto que está tocando (§50). Un docente que manipule una petición para calificar la asignatura de otro obtiene un rechazo, no una nota guardada. ### 3. El año pasado se copia, no se vuelve a escribir Crear el año 2027 no significa recrear 18 cursos, 9 áreas y 40 asignaturas. Significa **copiar la estructura de 2026 y ajustar lo que cambió** (§18). Lo mismo con la promoción: el sistema propone el destino de cada estudiante y el coordinador confirma o corrige (§26). ### 4. La familia ve el rendimiento, no las notas Estudiantes y acudientes acceden a un dashboard que comunica **cómo va** el estudiante —tendencia, nivel, evolución— sin exponer calificaciones individuales ni boletines (§9, §10, §41). Es una decisión pedagógica del colegio que el sistema respeta de forma estricta. *(Ver [DP-01](00-hallazgos-y-decisiones.md#dp-01--el-padre-y-el-estudiante-no-ven-notas-pero-sí-ven-promedio-general-y-puesto): esta regla necesita una precisión del cliente.)* --- ## Alcance de la versión 1 ### Se construye [RC] | Bloque | Contenido | |---|---| | **Institucional** | Datos del colegio, logo, escudo, encabezados de boletín, firmas | | **Parametrización** | Años, periodos, escala de desempeño, año/periodo predeterminados, configuración de notas | | **Estructura académica** | Grados, cursos, áreas, asignaturas, asignación de docentes titulares y directores de curso | | **Personas** | Docentes, estudiantes, acudientes, usuarios y roles | | **Matrícula** | Búsqueda por documento, wizard de matrícula, histórico, traslados, estados | | **Evaluación** | Banco de desempeños, digitación rápida de notas, recuperaciones, observaciones | | **Cálculo** | Promedios por asignatura y generales, periodo y acumulados, niveles de desempeño, puestos | | **Comunicación** | Tareas y comunicados con destinatarios por curso / grado / institución | | **Boletines** | PDF individual y masivo por curso, con histórico, logros, puesto y gráfica de evolución | | **Promoción** | Promoción masiva y asistida al año siguiente, con sugerencia de curso destino | | **Reportes** | Administrativos, académicos, de docentes y de tareas, con filtros y exportación | | **Auditoría** | Registro completo de operaciones sensibles con valor anterior y nuevo | | **Seguridad** | Autenticación, roles y permisos, protección de sesión, control de archivos, registro de eventos | ### Se prepara pero no se construye [FF] Multi-colegio operativo · Asistencia · Horarios · Entrega de tareas por el estudiante · Notificaciones por correo, WhatsApp o SMS · Integración con SIMAT · Aplicación móvil nativa · Marcado de logros por estudiante · Notas parciales con ponderación. "Preparar" significa: el modelo de datos, la estructura de carpetas y los puntos de extensión están diseñados para que estos módulos se agreguen **sin migrar datos ni rehacer módulos existentes**. ### Queda fuera [FA] Facturación y cartera · Nómina docente · Inventarios · Biblioteca · Transporte · Restaurante escolar · Plataforma de contenidos o aula virtual. --- ## Tecnología propuesta | Capa | Elección | Nota | |---|---|---| | Lenguaje | **PHP 8.2+** | La especificación pide "8.0 o superior"; se sube el piso porque 8.0 no recibe parches de seguridad — ver [RG-01](00-hallazgos-y-decisiones.md#rg-01--php-80-está-fuera-de-soporte-de-seguridad--crítico) | | Base de datos | **MariaDB 10.11 LTS**, InnoDB, `utf8mb4` | Conforme a la especificación | | Acceso a datos | **PDO** con sentencias preparadas, sin excepción | Conforme a la especificación | | Arquitectura | **MVC modular con capa de servicios**, sin framework pesado | Sin Laravel, según la especificación | | Interfaz | **Bootstrap 5.3 + CSS propio + JavaScript moderno**, sin build obligatorio | Despliegue por FTP viable | | PDF | **mPDF** *(recomendado)*, TCPDF como alternativa | Ver [10 — Boletines](10-boletines.md) para la justificación | | Gráficas | **SVG generado en servidor** para el PDF, **Chart.js** en pantalla | Sin dependencia de navegador sin interfaz | | Exportación | **CSV UTF-8** siempre, **XLSX** vía PhpSpreadsheet donde aporte | Ver [11 — Reportes](11-reportes.md) | | Dependencias | Composer, todas de **licencia libre** | Sin licencias comerciales obligatorias | Todo el conjunto funciona en **hosting compartido con PHP y MariaDB**, sin exigir Node.js en producción, sin contenedores obligatorios y sin servicios de pago. --- ## Cifras de referencia del proyecto | Métrica | Valor estimado | |---|---| | Módulos funcionales | 16 | | Entidades principales de base de datos | ~34 (+ catálogos) | | Roles del sistema | 5 (+ 1 sub-rol derivado: director de curso) | | Fases de desarrollo | 10, cada una entregable y demostrable | | Decisiones pendientes bloqueantes | 9 — ver [documento 00](00-hallazgos-y-decisiones.md) | --- ## Qué se necesita para arrancar 1. **Aprobar esta propuesta** o marcar los ajustes requeridos. 2. **Resolver las 9 decisiones pendientes** del documento 00 (o al menos DP-08 y RG-01, que desbloquean la Fase 1). 3. **Confirmar el entorno de despliegue**: hosting compartido o VPS, versión de PHP disponible, acceso a la base de datos y a un dominio o subdominio de pruebas. 4. **Entregar los insumos institucionales**: logo, escudo, datos del colegio, escala de desempeño vigente, listado de áreas y asignaturas, y el SIEE si se desea configurar la regla de promoción. Con eso, el desarrollo comienza por la Fase 0 descrita en [14 — Plan de desarrollo](14-plan-de-desarrollo.md).