Das Wichtigste auf einen Blick
- Kritische statische Datenfehler blockieren ein machbares Ergebnis; beheben Sie sie vor jedem Solve.
- Die dynamische Analyse kommt nach den statischen Prüfungen und vor der Optimierung.
- Prüfungen mit block build, combing chart und What-if belegen, dass die Struktur planbar ist.
- Führen Sie zwei Testmigrationen aus: Die erste findet die Lücken, die zweite belegt, dass sie behoben sind.
Beheben Sie kritische Fehler zuerst
Validierung hat eine Reihenfolge. Kritische statische Datenfehler kommen zuerst, weil sie ein machbares Ergebnis blockieren: Solange einer übrig ist, kann kein Solverlauf gelingen, egal mit welchen Einstellungen.
Die dynamische Analyse folgt. Erst wenn beides besteht, ist die Optimierung ihre Laufzeit wert. Die Reihenfolge schützt Solverzeit, und sie verhindert, dass das Team Datenfehler als Stundenplandesignprobleme liest.
Belegen Sie, dass die Struktur planbar ist
Ein Datenbestand kann sauber und trotzdem nicht planbar sein. Machbarkeitsprüfungen wie block build, combing chart und What-if-Tests existieren, um zu belegen, dass die Struktur planbar ist, bevor Sie einem automatischen Solve vertrauen.
Wenn diese Prüfungen strukturelle Probleme aufdecken, beheben Sie die Struktur. Optimierungseinstellungen können ein Modell nicht ausgleichen, das keine machbare Antwort hat.
Bringen Sie das Gate in eine Reihenfolge
Führen Sie das Gate in dieser Reihenfolge aus; jeder Schritt setzt voraus, dass der vorherige gehalten hat.
- Führen Sie die erste Testmigration aus und listen Sie jede Mapping- und Datenqualitätslücke auf, die sie aufdeckt.
- Beheben Sie die Lücken an der Quelle, in den Daten oder im Mapping.
- Führen Sie die zweite Testmigration aus, um die Korrekturen zu bestätigen.
- Beheben Sie alle kritischen statischen Datenfehler, die sie meldet.
- Führen Sie die dynamische Analyse aus und räumen Sie aus, was sie meldet.
- Führen Sie die Machbarkeitsprüfungen aus und starten Sie die Optimierung erst, wenn die Struktur besteht.
So geht das in Smootables: Validierung vor der Generierung
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 führt die Validierung aus, bevor es Solverzeit ausgibt: Stundenplan generieren prüft zuerst den Periodenplan und meldet Probleme, statt einen aussichtslosen Lauf zu versuchen. Die Schaltfläche Fehler anzeigen öffnet die Übersicht Validierungsfehler, in der jeder Fund typisiert ist (Fehlende Lehrkraft, Fehlender Raum, Lehrkraftstunden überschritten, Nicht genug Räume) und zur Korrektur verlinkt: Platzierung anzeigen, Lehrkraft anzeigen oder Zu den Räumen.
Scheitert die Generierung trotzdem, erklärt der anschließende Bericht warum, mit typisierten Konfliktursachen und vorgeschlagenen Maßnahmen, etwa die Belastung einer Lehrkraft zu verringern oder Räume hinzuzufügen. Das Gate spart den Lauf; der Bericht erklärt den Lauf, der trotzdem gescheitert ist.
Warum zwei Testmigrationen
Die erste Testmigration deckt Mapping- und Datenqualitätslücken auf. Die zweite bestätigt, dass die Lücken behoben sind. Lassen Sie die zweite aus, können Sie nicht sagen, ob die Reparaturen gehalten haben oder ob Sie Glück hatten.
Behandeln Sie das Paar als eine Arbeitseinheit. Eine Migration, die einmal bestanden hat, ist getestet; eine Migration, die zweimal bestanden hat, ist verifiziert.
Wenn eine Prüfung scheitert
Wenn eine Prüfung einen konkreten Fehler benennt, gehen Sie direkt zu seiner Behebung: eine doppelt gebuchte Lehrkraft beheben oder einen Raumkonflikt auflösen.
Strukturelle Fehler sind oft verkleidete Randbedingungsprobleme. Die Trennlinie zwischen beiden behandelt harte Randbedingungen.
Fragen von Planern vor dem Generieren
Reicht eine Testmigration, wenn sie besteht?
Die Aufgabe des ersten Laufs ist, Mapping- und Datenqualitätslücken aufzudecken, ein sauberer erster Lauf ist also selten. Der zweite Lauf, nach den Korrekturen, ist der Beleg, dass die Reparaturen funktioniert haben.
Was ist der Unterschied zwischen statischen Prüfungen und Machbarkeitsprüfungen?
Statische Prüfungen fragen, ob die Daten für sich genommen gültig sind: Felder vorhanden, Verweise intakt. Machbarkeitsprüfungen fragen, ob gültige Daten tatsächlich einen Stundenplan ergeben können. Beide können unabhängig voneinander scheitern.
Was sind block build, combing chart und What-if-Prüfungen?
Machbarkeitstechniken aus der Praxis der Schulstundenplanung, mit denen vor einem automatischen Solve belegt wird, dass die Struktur planbar ist. Wenn Ihr Werkzeug diese Namen nicht verwendet, suchen Sie nach den Prüfungen, die dieselbe Frage beantworten: Kann diese Struktur überhaupt geplant werden?