Ideas clave
- Los errores críticos de datos estáticos bloquean un resultado viable; corríjalos antes de cualquier generación.
- El análisis dinámico viene después de las comprobaciones estáticas y antes de la optimización.
- Las comprobaciones block build, combing chart y what-if demuestran que la estructura puede programarse.
- Haga dos migraciones de prueba: la primera encuentra los huecos, la segunda demuestra que están corregidos.
Corrija primero los errores críticos
La validación tiene un orden. Los errores críticos de datos estáticos van primero porque bloquean un resultado viable: mientras quede uno, ninguna ejecución del solucionador puede tener éxito, sean cuales sean los ajustes.
Después viene el análisis dinámico. Solo cuando ambos pasan, la optimización merece su tiempo de ejecución. El orden protege el tiempo del solucionador y evita que el equipo lea errores de datos como problemas de diseño del horario.
Demuestre que la estructura puede programarse
Un conjunto de datos puede estar limpio y aun así no poder programarse. Las comprobaciones de viabilidad como block build, combing chart y las pruebas what-if existen para demostrar que la estructura puede programarse antes de confiar en una generación automática.
Si estas comprobaciones exponen problemas estructurales, corrija la estructura. Los ajustes de optimización no pueden compensar un modelo que no tiene una respuesta viable.
Ordene el punto de control
Ejecute el punto de control en este orden; cada paso asume que el anterior se cumplió.
- Haga la primera migración de prueba y liste cada hueco de asignación y de calidad de datos que exponga.
- Corrija los huecos en el origen, en los datos o en la asignación.
- Haga la segunda migración de prueba para confirmar las correcciones.
- Corrija todos los errores críticos de datos estáticos que informe.
- Ejecute el análisis dinámico y resuelva lo que señale.
- Ejecute las comprobaciones de viabilidad, y empiece la optimización solo cuando la estructura las pase.
Cómo hacerlo en Smootables: validación previa a la generación
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
Smootables ejecuta la validación antes de gastar tiempo del solucionador: Generar horario comprueba primero el plan de periodos e informa de los problemas en lugar de intentar una ejecución condenada. El botón Ver errores abre la hoja Errores de validación, donde cada hallazgo tiene su tipo (Falta docente, Falta aula, Horas del docente superadas, Aulas insuficientes) y enlaza con la corrección: Ver colocación, Ver docente o Ir a aulas.
Si la generación falla de todos modos, el informe posterior explica por qué, con causas de conflicto tipificadas y acciones sugeridas, como reducir la carga de un docente o añadir aulas. El punto de control salva la ejecución; el informe explica la ejecución que aun así falló.
Por qué dos migraciones de prueba
La primera migración de prueba revela los huecos de asignación y de calidad de datos. La segunda confirma que los huecos están corregidos. Si se salta la segunda, no puede saber si las reparaciones aguantaron o si tuvo suerte.
Trate el par como una sola unidad de trabajo. Una migración que ha pasado una vez está probada; una migración que ha pasado dos veces está verificada.
Cuando una comprobación falla
Cuando una comprobación nombra un fallo concreto, vaya directamente a su reparación: corregir un docente con doble reserva o resolver un choque de aulas.
Los fallos estructurales suelen ser problemas de restricciones disfrazados. La división entre ambos se cubre en restricciones duras.
Preguntas de planificadores antes de generar
¿Basta una migración de prueba si pasa?
El trabajo de la primera ejecución es exponer los huecos de asignación y de calidad de datos, así que una primera ejecución limpia es rara. La segunda ejecución, tras las correcciones, es la prueba de que las reparaciones funcionaron.
¿Cuál es la diferencia entre comprobaciones estáticas y comprobaciones de viabilidad?
Las comprobaciones estáticas preguntan si los datos son válidos por sí mismos: campos presentes, referencias intactas. Las comprobaciones de viabilidad preguntan si unos datos válidos pueden realmente producir un horario. Ambas pueden fallar por separado.
¿Qué son las comprobaciones block build, combing chart y what-if?
Técnicas de viabilidad de la práctica de horarios escolares, usadas para demostrar que la estructura puede programarse antes de una generación automática. Si su herramienta no usa esos nombres, busque las comprobaciones que respondan a la misma pregunta: ¿puede esta estructura programarse siquiera?