Orari scolastici

Validazione statica e dinamica per gli orari scolastici

Le due fasi di validazione, cosa rileva ciascuna e i problemi critici da correggere prima che parta l’ottimizzazione.

Juho Isola, fondatore di Smootables

La validazione dell’orario avviene in due fasi, e confonderle fa perdere tempo. L’analisi statica controlla i dati da soli: valori mancanti, duplicati, lezioni senza docente. L’analisi dinamica combina i dati con i vincoli e trova i problemi che i controlli statici non possono vedere.

L’ordine è fisso: i problemi critici di entrambe le fasi devono essere risolti prima che parta l’ottimizzazione. E la promessa è limitata: superare la validazione rende probabile un orario fattibile, mai certo.

Questa guida copre entrambe le fasi e le routine di fattibilità che le collegano alla pianificazione. Il lavoro sui dati che precede la validazione è in preparazione dei dati; il controllo specifico per la migrazione è in verifica dei dati dell’orario.

Punti chiave

  • L’analisi statica controlla i dati da soli; l’analisi dinamica controlla dati e vincoli insieme.
  • I problemi critici di entrambe le fasi bloccano l’ottimizzazione finché non sono corretti.
  • Block build, combing chart e clash table portano nella validazione i controlli di fattibilità della pianificazione.
  • Una validazione pulita aumenta le probabilità di un orario fattibile; non può prometterlo.

Fase uno: analisi statica

L’analisi statica chiede se i dati grezzi sono utilizzabili: mancano valori, ci sono record duplicati, ogni lezione ha un docente. Sono problemi di dati, e hanno responsabili dei dati. Nessuna logica di collocazione è ancora coinvolta.

Correggili in questa fase perché è qui che costano meno. Un tipo di aula mancante trovato dall’analisi statica è un campo da compilare; la stessa lacuna trovata a metà generazione è un’esecuzione fallita da diagnosticare.

Fase due: analisi dinamica

L’analisi dinamica combina i dati con i vincoli attivi. Può rivelare che una collocazione obbligatoria è impossibile, che i vincoli si contraddicono a vicenda o che una struttura non può contenere i propri impegni. Nulla di tutto questo è visibile ai controlli statici, perché ogni record sembra a posto da solo.

Le routine di fattibilità lato pianificazione (block build, combing chart, clash table) appartengono nello spirito a questa fase: verificano se la struttura pianificata può stare nella griglia prima che le lezioni vengano collocate. Se la pianificazione mostra già un clash, correggi la struttura invece di chiedere al solver di riscoprirlo.

Valida come una porta, in ordine

Ogni passaggio si guadagna il successivo; l’ottimizzazione viene per ultima.

  1. Esegui l’analisi statica sui dati dell’orario.
  2. Correggi valori mancanti, duplicati e lezioni senza docente alla fonte.
  3. Esegui l’analisi dinamica rispetto ai vincoli attivi.
  4. Risolvi ogni problema critico; parcheggia il resto con una nota.
  5. Ricontrolla gli output strutturali (block build, clash table) se i vincoli sono cambiati.
  6. Avvia l’ottimizzazione solo quando i problemi rimanenti sono compresi e accettati.

Come farlo in Smootables: errori tipizzati prima e dopo la risoluzione

Le segnalazioni tipizzate nominano la correzione, non solo il fallimento.

La stessa divisione compare in Smootables in due punti. Prima della generazione, il piano del periodo viene controllato per problemi di dati: il pulsante Visualizza errori apre il pannello Errori di validazione, dove le segnalazioni sono tipizzate (Docente mancante, Aula mancante, Ore del docente superate, Aule insufficienti) e ognuna rimanda alla sua correzione con Vedi collocazione, Vedi docente o Vai alle aule.

Il lato dei vincoli viene spiegato quando una risoluzione fallisce: il report nomina la causa del conflitto, come un docente con troppe lezioni per gli slot disponibili o un insieme di aule troppo piccolo, e abbina a ogni causa un’azione suggerita, come ridurre il carico di un docente, cambiare aule o aggiungere slot orari. Leggilo come output dell’analisi dinamica: ti dice quale struttura cambiare.

Cosa nomina un risultato di validazione utile

Una segnalazione su cui puoi agire nomina quattro cose: se è un errore di dati o un conflitto di vincoli, quale docente, classe, aula o lezione è coinvolta, se blocca la generazione o può aspettare, e cosa ricontrollare dopo la correzione.

Le segnalazioni che non superano questo test finiscono in una lista di parcheggio, non nel modello. Quelle che lo superano si instradano da sole: gli errori di dati ai responsabili della preparazione dei dati, i conflitti di vincoli alla tassonomia dei vincoli rigidi.

Domande dei pianificatori sulla validazione

Perché la generazione è fallita dopo che la validazione era passata?

La validazione rende la fattibilità più probabile, mai certa. Alcuni conflitti compaiono solo quando la collocazione combina i vincoli in modi che nessun controllo preventivo può enumerare. Tratta il report del fallimento come il prossimo passaggio di validazione.

Cosa sono block build, combing chart e clash table?

Routine di fattibilità pre-programmazione ereditate dalla pianificazione. Verificano se la struttura pianificata può stare nella griglia prima che qualsiasi singola lezione venga collocata: è la forma strutturale della validazione.

Chi corregge ciò che la validazione trova?

Si divide per fase. Le segnalazioni statiche sono correzioni di dati per chi possiede i record. Le segnalazioni dinamiche sono decisioni di pianificazione: un conflitto di vincoli di solito significa che una struttura o un impegno deve cambiare.

Altre guide su questo argomento

Scopri come Smootables si adatta alla tua scuola

Prenota una demo: mapperemo Smootables sul tuo processo di pianificazione, carico docente e orari.