Stundenplanerstellung

Statische und dynamische Validierung für Schulstundenpläne

Zwei Validierungsstufen, was jede findet, und die kritischen Probleme, die vor der Optimierung behoben sein müssen.

Juho Isola, Gründer von Smootables

Stundenplan-Validierung geschieht in zwei Stufen, und wer sie verwechselt, verliert Zeit. Die statische Analyse prüft die Daten für sich: fehlende Werte, Duplikate, unbesetzter Unterricht. Die dynamische Analyse kombiniert Daten mit Regeln und findet die Probleme, die statische Prüfungen nicht sehen können.

Die Reihenfolge ist fest: Kritische Probleme aus beiden Stufen müssen gelöst sein, bevor die Optimierung läuft. Und das Versprechen ist begrenzt: Bestandene Validierung macht einen machbaren Stundenplan wahrscheinlich, nie sicher.

Dieser Leitfaden behandelt beide Stufen und die Machbarkeitsroutinen, die sie mit der Planung verbinden. Die Datenarbeit vor der Validierung steht in Datenvorbereitung; das migrationsspezifische Gate steht in Stundenplandaten prüfen.

Das Wichtigste auf einen Blick

  • Die statische Analyse prüft Daten allein; die dynamische Analyse prüft Daten und Regeln gemeinsam.
  • Kritische Probleme aus beiden Stufen blockieren die Optimierung, bis sie behoben sind.
  • Block Build, Combing Charts und Clash Tables tragen die Machbarkeitsprüfungen der Planung in die Validierung.
  • Eine saubere Validierung erhöht die Chance auf einen machbaren Stundenplan; versprechen kann sie ihn nicht.

Stufe eins: statische Analyse

Die statische Analyse fragt, ob die Rohdaten nutzbar sind: Fehlen Werte, sind Datensätze doppelt, ist jede Stunde besetzt. Das sind Datenprobleme, und sie haben Datenverantwortliche. Platzierungslogik ist noch nicht im Spiel.

Beheben Sie sie in dieser Stufe, weil sie hier am günstigsten sind. Ein fehlender Raumtyp aus der statischen Analyse ist ein auszufüllendes Feld; dieselbe Lücke mitten in der Generierung ist ein gescheiterter Lauf, der diagnostiziert werden muss.

Stufe zwei: dynamische Analyse

Die dynamische Analyse kombiniert die Daten mit den aktiven Regeln. Sie kann zeigen, dass eine Pflichtplatzierung unmöglich ist, dass Regeln einander widersprechen oder dass eine Struktur ihre eigenen Verpflichtungen nicht unterbringen kann. Nichts davon ist für statische Prüfungen sichtbar, weil jeder Datensatz für sich in Ordnung aussieht.

Die planungsseitigen Machbarkeitsroutinen (Block Build, Combing Chart, Clash Table) gehören dem Geist nach zu dieser Stufe: Sie testen, ob die geplante Struktur passen kann, bevor Stunden platziert werden. Zeigt schon die Planung einen Clash, korrigieren Sie die Struktur, statt den Solver ihn neu entdecken zu lassen.

Validierung als Gate, in fester Reihenfolge

Jeder Durchlauf verdient den nächsten; die Optimierung kommt zuletzt.

  1. Statische Analyse auf den Stundenplandaten ausführen.
  2. Fehlende Werte, Duplikate und unbesetzten Unterricht an der Quelle beheben.
  3. Dynamische Analyse gegen die aktiven Regeln ausführen.
  4. Jedes kritische Problem lösen; den Rest mit einer Notiz parken.
  5. Strukturelle Ergebnisse (Block Build, Clash Table) erneut prüfen, wenn sich Regeln geändert haben.
  6. Die Optimierung erst starten, wenn die verbleibenden Probleme verstanden und akzeptiert sind.

So geht es in Smootables: typisierte Fehler vor und nach dem Lauf

Typisierte Befunde benennen die Korrektur, nicht nur den Fehler.

Dieselbe Aufteilung zeigt sich in Smootables an zwei Punkten. Vor der Generierung wird der Periodenplan auf Datenprobleme geprüft: Die Schaltfläche Fehler anzeigen öffnet die Übersicht Validierungsfehler, in der Befunde typisiert sind (Fehlende Lehrkraft, Fehlender Raum, Lehrkraftstunden überschritten, Nicht genug Räume) und jeder mit Platzierung anzeigen, Lehrkraft anzeigen oder Zu den Räumen zu seiner Korrektur verlinkt.

Die Regelseite wird erklärt, wenn ein Lauf scheitert: Der Bericht benennt die Konfliktursache, etwa eine Lehrkraft mit zu vielen Stunden für die verfügbaren Slots oder einen zu kleinen Raumpool, und stellt jeder Ursache eine empfohlene Aktion zur Seite, etwa die Last einer Lehrkraft reduzieren, Räume ändern oder Zeitfenster ergänzen. Lesen Sie ihn als Ergebnis der dynamischen Analyse: Er sagt Ihnen, welche Struktur sich ändern muss.

Was ein brauchbares Validierungsergebnis benennt

Ein Befund, auf den Sie reagieren können, benennt vier Dinge: ob es ein Datenfehler oder ein Regelkonflikt ist, welche Lehrkraft, Klasse, welcher Raum oder Unterricht betroffen ist, ob er die Generierung blockiert oder warten kann, und was nach der Korrektur erneut zu prüfen ist.

Befunde, die diesen Test nicht bestehen, kommen auf eine Parkliste, nicht ins Modell. Befunde, die ihn bestehen, sortieren sich selbst: Datenfehler an die Verantwortlichen der Datenvorbereitung, Regelkonflikte in die Taxonomie der harten Regeln.

Fragen von Planenden zur Validierung

Warum ist die Generierung gescheitert, obwohl die Validierung bestanden war?

Validierung macht Machbarkeit wahrscheinlicher, nie sicher. Manche Konflikte erscheinen erst, wenn die Platzierung Regeln auf eine Weise kombiniert, die keine Vorprüfung aufzählt. Behandeln Sie den Fehlerbericht als den nächsten Validierungsdurchlauf.

Was sind Block Builds, Combing Charts und Clash Tables?

Machbarkeitsroutinen vor der Platzierung, übernommen aus der Planung. Sie testen, ob die geplante Struktur passen kann, bevor eine einzelne Stunde platziert wird; das ist die strukturelle Form der Validierung.

Wer behebt, was die Validierung findet?

Das teilt sich nach Stufe. Statische Befunde sind Datenkorrekturen für die Verantwortlichen der Datensätze. Dynamische Befunde sind Planungsentscheidungen: Ein Regelkonflikt bedeutet meist, dass eine Struktur oder eine Verpflichtung sich ändern muss.

Weitere Leitfäden zu diesem Thema

So passt Smootables zu Ihrer Schule

Buchen Sie eine Produktdemonstration – wir ordnen Smootables Ihrem Planungs-, Arbeitslast- und Stundenplanprozess zu.