Don’t repeat yourself: Effektive Informations-Verwaltung im Systementwicklungsprozess

Referenzen auf nichtexistierende Kapitel oder Dokumente, veraltete Abbildungen, inkonsistente Bezeichnungen!

Eine ungepflegte Systemarchitektur-Dokumentation wirft oft mehr Fragen auf, als sie zu beantworten im Stande ist. Dementsprechend sollte darauf geachtet werden, dass alle Informationen immer auf Stand gehalten werden.

Doch selbst mit den besten Vorsätzen, präzise definierten Arbeitsabläufen und streng eingehaltenen Entwicklungsprozessen, werden sich immer wieder einmal Fehler einschleichen. Dies hat zur Folge, dass man den Informationen doch nicht immer ganz vertraut und öfter auch in der Implementation nachsieht.

Im Folgenden wird das Problem des Informations-Managements im Systementwicklungsprozess beleuchtet. Dabei werden die Schwächen des «klassischen» dokumentenzentrierten Ansatzes angesprochen und alternative Ansätze aufgezeigt.

Wieso ist es so schwierig die, Informationen aktuell zu halten?

Eine Systemarchitektur hat eine hierarchische Struktur, welche üblicherweise in einem oder mehreren Dokumenten mittels Abbildungen und Text, beschrieben wird.

In Abbildung 1 ist ein Beispiel für die Struktur einer Systemarchitektur dargestellt. Die Pfeile stellen zum einen die hierarchische Abhängigkeit dar und zum anderen den Informationsfluss (Bezeichnungen etc.) im Zuge des Design-Prozesses.

Die Informationen sind also über mehrere Dokumente und Abbildungen verteilt und wenn eine Information an mehreren Stellen verwendet wird, handelt es sich immer um eine Duplikation. Man erstellt also jedes Mal eine Kopie der Information, wobei keinerlei Verbindung mehr zur Ursprungsinformation besteht.

Damit ist das Problem schon offensichtlich. Um eine Änderung korrekt durchzuführen, muss die Information an allen Stellen, wo diese verwendet wird, angepasst werden. Dies ist nicht nur sehr zeitaufwändig, sondern auch fehleranfällig, da völlig unbekannt ist, wo die entsprechende Information überall verwendet wird.

Das fortlaufende Kopieren und Weitergeben einer Information erinnert stark an das wohl allen bekannte Kinderspiel «Stille Post», wobei hier der Reiz gerade darin liegt, dass es unvermeidlich zu Fehlern kommt.

In Abbildung 2 dient dieses einfache Spiel, zum Aufzeigen dessen, was mit einer Parameterbezeichnung passieren könnte – in diesem Fall sogar, ohne einen inhaltlichen Fehler einzuführen. Für die Verständlichkeit einer Systemarchitektur ist dies jedoch auch sehr abträglich.

Wie kann das divergieren von Informationen verhindert werden?

Wenn wir uns das «Stille Post»-Beispiel ansehen, ist die Lösung wohl offensichtlich.

Und so einfach ist der ganze Spass des Spiels zunichtegemacht. Für alle anderen Fälle, in denen abweichende Informationen keinen Spass machen, bringt dies jedoch einen grossen Vorteil.

In der Softwareentwicklung gibt es ein Grundprinzip, welches genau darauf abzielt: «Don’t repeat yourself». Hauptziel ist, Redundanz zu vermeiden, um die Widerspruchsfreiheit zu erhöhen. Dieses Prinzip kann auch auf eine

Systemarchitektur angewendet werden. Damit wäre es möglich, diese einfach und mit geringem Fehlerrisiko auf Stand zu halten, wovon nicht nur der Design-Prozess profitiert, sondern auch der Entwicklungs- und LifeCycle-Prozess.

Ein weiterer Weg, dies zu erreichen, ist die andauernde Synchronisation der Informationen. Dabei wird die Änderung einer Information automatisch an alle Instanzen, welche diese benutzen, propagiert. Dabei handelt es sich um einen dezentralen Ansatz, bei welchem eine Softwareentwicklungs-Analogie am ehesten einem Git-Repository, mit der Möglichkeit zum Zusammenführen (merge), mehrerer Informationsbestände entspricht.

Wie lässt sich dies umsetzen?

Single Point of Definition

Ebenfalls aus der Softwareentwicklung kommt ein Ansatz, den man entweder als pragmatisch oder radikal betrachten kann, «the Code is the design». Vielleicht ist dieser Ansatz auch ein Resultat des «Law of the Instrument» («Wer nur einen Hammer hat, sieht in jedem Problem einen Nagel»).

Und obwohl die Schlichtheit dieser Idee einen gewissen Reiz hat, bringt sie zu viele Limitierungen mit sich.

• Limitierung auf reine Software-Projekte.
• Die Verständlichkeit leidet enorm an einer Überfrachtung mit zu vielen unnötigen Details.
• Das rein textbasierte Medium erlaubt keinerlei grafische Elemente zur Erläuterung.

Ein etwas generellerer Ansatz ist die Verwendung eines zentralen Informationsmanagers, welcher Informationen zentral verwaltet und für die unterschiedlichen Einsatzgebiete zur Verfügung stellt. Diese Idee ist auch nicht neu und wird in der Softwareentwicklung zum Beispiel im «Model View Controller»-Konzept verwendet. In der Systementwicklung spricht man dabei oft von «Model based …» oder «Model driven …». Dabei versteht man unter «Model» den Ort, an dem die zentralen Daten abgelegt bzw. verwaltet werden.

In Abbildung 4 ist das weiter oben gezeigte Beispiel der Struktur einer Systemarchitektur dargestellt, wobei eine zentrale Informationsmanagement-Instanz hinzugefügt wurde.

Dieser Ansatz benötigt aber eine stärkere Unterstützung durch spezifische Softwarelösungen, da Informationen vom «System Model» bezogen werden müssen. Als Folge dessen sind die Architektur-Dokumente nicht mehr das direkte Ausgangsprodukt des Designprozesses, sondern müssen in einem gesonderten Schritt, aus dem «System Model», generiert werden.

Doch auch, wenn dies eine gewisse Umstellung in den gewohnten Arbeitsmitteln mit sich bringt, überwiegen die Vorteile einer solchen Lösung. Dies ist nicht zuletzt daran zu sehen, dass sich ähnliche Konzepte in anderen Gebieten bereits durchgesetzt haben. Als Beispiele seien hier die CAD-Software für die Mechanikentwicklung oder ECAD-Software für die Elektronikentwicklung erwähnt. In der IMT werden hierfür zum Beispiel «SOLIDWORKS 3D CAD» und «Altium Designer» eingesetzt.

Synchronisation

Eine geläufige Bezeichnung für diesen Ansatz ist «Roundtrip engineering», dabei sollen Informationen in unterschiedlichen Dokumenten, Software-Artefakten, etc. synchron gehalten werden.  Es beschreibt damit so etwas, wie das Idealbild einer Software Architektur oder gar einer ganzen Produktumsetzung. Unabhängig an welcher Stelle ich eine Information verändere wird diese automatisch an allen Stellen, wo sie verwendet wird, nachgeführt. Es verspricht sogar noch mehr, unabhängig davon, ob eine neue Komponente in der Architektur oder der Implementation hinzugefügt wird, erhält man denselben vollständigen Satz an Dokumenten, Software-Artefakten, etc. So schön dies auch wäre, beginnt hier diese Utopie etwas zu bröckeln.

Das grundlegende Problem ist, dass dies eine eineindeutige Beziehung zwischen allen hierarchischen Ebenen voraussetzt. Dies würde nicht nur zu sehr strikten Einschränkungen bei der Umsetzung führen, sondern ist in manchen Fällen zudem nicht erreichbar, da durch die Abstraktion auf höheren Ebenen gar nicht die gesamte Information vorhanden ist.

Doch betrachten wir das etwas pragmatisch, zeigt sich, dass dies für den Anwendungsfall der Systementwicklung auch gar nicht nötig ist. Vielmehr scheint es für mich viel verständlicher, wenn klar definiert ist, auf welcher Ebene welche Information definiert ist. Mit der Ausnahme dieser Einschränkung kann die zentrale Datenhaltung, welche zuvor vorgestellt wurde, dieselbe Funktionalität zur Verfügung stellen.

Kann die zentrale Information auch über die Systemarchitektur hinaus verwendet werden?

Natürlich wäre es konsequent, in möglichst allen Aspekten der Systementwicklung, diese zentralen Daten zu verwenden. Dies erfordert jedoch eine Integration aller dafür notwendigen Funktionen in eine Softwarelösung, oder zumindest eine definierte Schnittstelle, um die Informationen zu teilen. Da die unterschiedlichen Gebiete der Systementwicklung jedoch jeweils sehr spezifische Anforderungen haben und es dafür bereits sehr gute eigenständige Softwarelösungen gibt (z.B. «SOLIDWORKS 3D CAD» und «Altium Designer»), wäre es wohl mit einem enormen Aufwand verbunden, die Informationen auch direkt in den spezifischen CAD-Anwendungen zu verwenden.

Für den agilsten Teil der Systementwicklung, die Softwareentwicklung, ist es aber gut möglich, mit Hilfe von Code-Generierung, die Struktur und sogenannten «Boilerplate-Code», für die Implementation zu erzeugen. Damit können die Vorteile des zentralen Informationsmanagements bis in die Umsetzung hinein genutzt werden. Die IMT setzt hierfür auf das eigene, im Haus entwickelte Software-Tool «DATAFLOW Designer», welches neben dem Bereitstellen von Boilerplate-Code auch beim Nachweis der Normenkonformität unterstützt.

Das Ziel ist eine aktuelle, widerspruchsfreie und verständliche System Architektur, welche jedem Entwickler die benötigten Informationen einfach und schnell zur Verfügung stellt. Um dies zu erreichen, sollte die Entwickler bei der Erstellung und Anpassung bestmöglich unterstützt werden. Ein fundamentaler Baustein dafür stellt das zentrale Informations-Management dar, mit dem es möglich ist, die Entwickler vom Design bis zur Umsetzung auf vielseitige Weise zu unterstützen. Die erzielbaren Effizienz- und Qualitätssteigerungen kommen dabei sowohl dem Kunden als auch dem Entwickler zugute.