Ideas clave
- El análisis estático comprueba los datos por sí solos; el dinámico comprueba datos y restricciones juntos.
- Los problemas críticos de cualquiera de las dos etapas bloquean la optimización hasta corregirse.
- Block build, combing charts y clash tables llevan las revisiones de viabilidad de la planificación a la validación.
- Una validación limpia aumenta las probabilidades de un horario viable; no puede prometerlo.
Etapa uno: análisis estático
El análisis estático pregunta si los datos en bruto son utilizables: ¿faltan valores?, ¿hay registros duplicados?, ¿tiene docente cada lección? Son problemas de datos, y tienen responsables de datos. Todavía no interviene ninguna lógica de colocación.
Corríjalos en esta etapa porque aquí son más baratos. Un tipo de aula faltante que encuentra el análisis estático es un campo por rellenar; la misma laguna encontrada a mitad de la generación es una ejecución fallida por diagnosticar.
Etapa dos: análisis dinámico
El análisis dinámico combina los datos con las restricciones activas. Puede revelar que una colocación obligatoria es imposible, que las restricciones se contradicen entre sí o que una estructura no puede cumplir sus propios compromisos. Nada de eso es visible para las comprobaciones estáticas, porque cada registro parece correcto por sí solo.
Las rutinas de viabilidad del lado de la planificación (block build, combing chart, clash table) pertenecen en espíritu a esta etapa: prueban si la estructura planificada puede encajar antes de colocar las lecciones. Si la planificación ya muestra un choque, corrija la estructura en lugar de pedir al motor que lo redescubra.
Valide como una puerta, en orden
Cada pasada se gana la siguiente; la optimización llega la última.
- Ejecute el análisis estático sobre los datos del horario.
- Corrija en origen los valores faltantes, los duplicados y las lecciones sin docente.
- Ejecute el análisis dinámico contra las restricciones activas.
- Resuelva todos los problemas críticos; aparque el resto con una nota.
- Vuelva a comprobar las salidas estructurales (block build, clash table) si las restricciones cambiaron.
- Inicie la optimización solo cuando los problemas restantes estén entendidos y aceptados.
Cómo hacerlo en Smootables: errores tipificados antes y después de resolver
Fall 2026
Recurring weeks18.8.2026 - 20.12.2026 / 18 weeks
Validation errors
Teacher hours exceeded (1)
Teacher "J. Rivera" has 28 hours/week assigned; maximum is 24 hours/week.
Reduce this teacher's workload or increase their weekly maximum hours.
View teacher
Insufficient rooms (1)
This period needs at least 3 room(s) for your student groups, but only 2 are available.
Add more rooms in Resources or reduce the number of student groups with lessons in this period.
Go to rooms
La misma división aparece en Smootables en dos puntos. Antes de la generación, el plan de periodo se comprueba en busca de problemas de datos: el botón Ver errores abre la hoja de Errores de validación, donde los hallazgos están tipificados (Docente faltante, Aula faltante, Horas de docente excedidas, Aulas insuficientes) y cada uno enlaza con su arreglo mediante Ver colocación, Ver docente o Ir a aulas.
El lado de las restricciones se explica cuando una resolución falla: el informe nombra la causa del conflicto, como un docente con demasiadas lecciones para los huecos disponibles o un conjunto de aulas demasiado pequeño, y empareja cada causa con una acción sugerida, como reducir la carga de un docente, cambiar de aulas o añadir franjas horarias. Léalo como salida del análisis dinámico: le dice qué estructura cambiar.
Qué nombra un resultado de validación útil
Un hallazgo sobre el que puede actuar nombra cuatro cosas: si es un error de datos o un conflicto de restricciones, qué docente, clase, aula o lección está implicado, si bloquea la generación o puede esperar, y qué volver a comprobar tras el arreglo.
Los hallazgos que no pasan esta prueba van a una lista de aparcamiento, no al modelo. Los hallazgos que la pasan se enrutan solos: los errores de datos a los responsables de la preparación de datos, los conflictos de restricciones a la taxonomía de restricciones duras.
Preguntas que los planificadores hacen sobre la validación
¿Por qué falló la generación después de pasar la validación?
La validación hace la viabilidad más probable, nunca segura. Algunos conflictos solo aparecen cuando la colocación combina restricciones de formas que ninguna comprobación previa enumera. Trate el informe del fallo como la siguiente pasada de validación.
¿Qué son los block builds, combing charts y clash tables?
Rutinas de viabilidad previas a la programación, heredadas de la planificación. Prueban si la estructura planificada puede encajar antes de colocar ninguna lección individual, que es la forma estructural de la validación.
¿Quién corrige lo que encuentra la validación?
Se reparte por etapa. Los hallazgos estáticos son arreglos de datos para quien posee los registros. Los hallazgos dinámicos son decisiones de planificación: un conflicto de restricciones suele significar que una estructura o un compromiso tiene que cambiar.