Wie prüfen Sie die Qualität komplexer Produkte? Und was tun Sie wenn Ihr Produkt ein komplexer Optimierungsalgorithmus ist?
Normalerweise testet man "bottom up", also zuerst die kleine Bausteine isoliert, dann diese zu größeren Einheiten integriert im Zusammenspiel - bis man dann das fertige Produkt testet.
Wie gehen sie aber vor, wenn man zwar die Korrektheit ermittelter Lösungen prüfen kann, aber nicht nachweisen kann, dass die beste Lösung gefunden wurde?
Bei den heute weit verbreiten Fahrplanauskunftssystemen besteht dieses Problem systematisch, weil diese Algorithmen zu Zeiten des Intel 286 entworfen wurden. Man war damals (Ende der 80er Jahre) einfach gezwungen Heuristiken einzusetzen, welche die optimale Qualität nicht garantieren können, um mit akzeptabler Rechenzeit zu guten Ergebnissen zu kommen.
Also stellte sich nicht nur bei den Herstellern dieser Systeme, sondern auch bei deren großen Kunden immer das Problem zu prüfen, wie man zu besseren Ergebnissen kommt und welche Kosten (= Rechenzeit, Arbeitszeit) das verursacht. Dazu setzt man als übliches Mittel Regressionstests ein, wobei die alte Version gegen die neue Version getestet wird. Ein aufwändiges Unterfangen, bei dem man nur schrittweise vorankommt und das doch nie garantieren kann, dass ein optimales Ergebnis erzielt wird.
Wie geht man in anderen Bereichen solche Probleme an? Das Zauberwort lautet “Diversitäre Redundanz”.
Redundanz ist normalerweise die Installation mehrerer Komponenten in der Weise, dass eine Komponente die Aufgaben einer anderen Komponente bei deren Ausfall übernehmen kann. Die gleiche Komponent existiert dabei technisch identisch mehrfach, z.B. bei redundaten Netzteilen oder Netzwerkschnittstellen in ausfallsicheren Rechnern. Aber was passiert, wenn ein System aufgrund eines konstruktionsbedingten Fehlers ausfällt? Dann wird das Notfallsystem aus dem gleichen Grund ausfallen! Kein schöner Gedanke bei kritischen Systemen.
Daher setzt man bei solchen kritischen Systeme auf diversitäre Refundanz (Wikipedia). Das entscheidende Kriterium hier ist, dass möglichst jede Komponente doppelt und eigenständig (z.B. andere Hardware, andere Software) entwickelt wird und es damit sehr unwahrscheinlich wird, dass dabei Fehler wiederholt werden. Man baut also letztlich das System zwei Mal … mit allen Konsequenzen auch in Hinsicht auf die Kosten.
In der konkreten Situation standen 2001 umfassende Erweiterungen eines bestehenden Fahrplanauskunftssystems bei dessen größtem Kunden an. Eine Qualitätssicherung nur durch Regressionstests zwischen verschiedenen Versionen des gleichen Systems schien nicht ausreichend zu sein. Ferner war es für Weiterentwicklungen auch auf Dauer gesehen sinnvoll, das produktive System gegen ein unabhängig entwickeltes System vergleichen zu können.
Glücklicherweise hatte das Team am Lehrstuhl von Prof. Karsten Weihe (damals Bonn) Erfahrung in der Thematik, dadurch waren die Kosten für ein reines System zur Qualitätssicherung überschaubar. Der Gedanke war geboren und es entstand Mitte 2002 der erste voll funktionsfähige Vorläufer von MOTIS. Als wichtigste Voraussetzung wurde festgelegt, dass durch den algorithmischen Ansatz jederzeit die Optimalität der Auskunftsergebnisse garantiert sein muss.
Auch wenn MOTIS sich seitdem deutlich weiterentwickelt hat, seine Rolle in der Qualitätssicherung übt es weiter tagtäglich aus – und garantiert natürlich immer noch die Optimalität der Ergebnisse.