Punti chiave
- Gli errori critici nei dati statici bloccano un risultato fattibile; correggili prima di qualsiasi solve.
- L’analisi dinamica viene dopo i controlli statici e prima dell’ottimizzazione.
- I controlli block build, combing chart e what-if dimostrano che la struttura può produrre un orario.
- Esegui due migrazioni di test: la prima trova le lacune, la seconda dimostra che sono state corrette.
Correggi prima gli errori critici
La validazione ha un ordine. Gli errori critici nei dati statici vengono per primi perché bloccano un risultato fattibile: finché ne resta uno, nessuna esecuzione del solver può riuscire, qualunque siano le impostazioni.
L’analisi dinamica segue. Solo quando entrambi passano l’ottimizzazione vale il suo tempo di esecuzione. L’ordine protegge il tempo del solver e impedisce al team di leggere gli errori nei dati come problemi di progettazione dell’orario.
Dimostra che la struttura può produrre un orario
Un set di dati può essere pulito e comunque non pianificabile. I controlli di fattibilità come block build, combing chart e i test what-if esistono per dimostrare che la struttura può produrre un orario prima di fidarti di un solve automatico.
Se questi controlli espongono problemi strutturali, correggi la struttura. Le impostazioni di ottimizzazione non possono compensare un modello che non ha una risposta fattibile.
Metti in sequenza il gate
Esegui il gate in questo ordine; ogni passaggio presuppone che il precedente abbia tenuto.
- Esegui la prima migrazione di test ed elenca ogni lacuna di mapping e di qualità dei dati che espone.
- Correggi le lacune alla fonte, nei dati o nel mapping.
- Esegui la seconda migrazione di test per confermare le correzioni.
- Correggi tutti gli errori critici nei dati statici che segnala.
- Esegui l’analisi dinamica e risolvi ciò che solleva.
- Esegui i controlli di fattibilità e avvia l’ottimizzazione solo quando la struttura passa.
Come farlo in Smootables: validazione prima della generazione
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 esegue la validazione prima di spendere tempo di solver: Genera orario controlla prima il piano del periodo e segnala i problemi invece di tentare un’esecuzione destinata a fallire. Il pulsante Visualizza errori apre la scheda Errori di validazione, dove ogni risultato ha un tipo (Docente mancante, Aula mancante, Ore del docente superate, Aule insufficienti) e rimanda alla correzione: Visualizza posizionamento, Visualizza docente o Vai alle aule.
Se la generazione fallisce comunque, il report che segue spiega perché, con cause di conflitto per tipo e azioni suggerite come ridurre il carico di un docente o aggiungere aule. Il gate salva l’esecuzione; il report spiega l’esecuzione che è fallita comunque.
Perché due migrazioni di test
La prima migrazione di test rivela le lacune di mapping e di qualità dei dati. La seconda conferma che le lacune sono corrette. Salta la seconda e non puoi sapere se le riparazioni hanno tenuto o se hai avuto fortuna.
Tratta la coppia come una sola unità di lavoro. Una migrazione passata una volta è stata testata; una migrazione passata due volte è stata verificata.
Quando un controllo fallisce
Quando un controllo nomina un fallimento specifico, vai dritto alla sua riparazione: correggere un docente prenotato due volte o risolvere un conflitto di aula.
I fallimenti strutturali sono spesso problemi di vincoli sotto mentite spoglie. La distinzione tra i due è trattata in vincoli rigidi.
Domande dei pianificatori prima di generare
Una sola migrazione di test basta se passa?
Il compito della prima esecuzione è esporre le lacune di mapping e di qualità dei dati, quindi una prima esecuzione pulita è rara. La seconda, dopo le correzioni, è la prova che le riparazioni hanno funzionato.
Qual è la differenza tra controlli statici e controlli di fattibilità?
I controlli statici chiedono se i dati sono validi di per sé: campi presenti, riferimenti integri. I controlli di fattibilità chiedono se dati validi possono davvero produrre un orario. Entrambi possono fallire indipendentemente.
Cosa sono i controlli block build, combing chart e what-if?
Tecniche di fattibilità della pratica di pianificazione degli orari scolastici, usate per dimostrare che la struttura può produrre un orario prima di un solve automatico. Se il tuo strumento non usa quei nomi, cerca i controlli che rispondono alla stessa domanda: questa struttura può produrre un orario?