Lückenschlussmaßnahme

Oder: "Ceci n'est pas une pipe."

Immer, wenn mich jemand fragt, was ich "so beruflich mache", dann finde ich das relativ schwer zu erklären. Vor einigen Tagen saß ich mit einem fachfremden Freund bei einigen Bieren zusammen und kam dabei auf folgende Erklärung: Ich versuche, Lücken klein zu halten. Prinzipiell geht es beim Systems-Engineering und insbesondere beim Anforderungsmanagement genau darum. Ich versuche das in den folgenden Absätzen zu erklären.

Als Einstieg will ich ein Gedankenkonstrukt vorstellen, dass sich mit den grundlegenden Unterschieden zwischen der Realität und der Vorstellung der Realität auseinandersetzt.

Prinzipiell ist es so, dass jedes reale Objekt ziemlich komplex ist, auch ein einfaches, wie z.B. die Mehrfachsteckdose, an die mein Notebook gerade angeschlossen ist. Alleine die äußere Form der Steckdose ist in der Realität wahrscheinlich zu kompliziert, um sie vollständig zu beschreiben.

"Moment mal, das ist doch nur ein Kasten!" mag man jetzt einwenden, aber genau das stimmt eben nicht. Die Steckdose ist in der Realität kein Kasten (oder Quader, um es korrekt zu bezeichnen). Die 12 Kanten - die dann genau gerade sein müssten - sind alles andere als genau gerade, sondern um zehntel Millimeter gebogen und geschwungen, durch Fertigungsungenauigkeiten, Temperatureinflüße oder weil man sich irgendwann mal aus Versehen draufgesetzt hat. Geht man noch näher heran, stellt man fest, dass die Oberfläche leicht aufgeraut ist, also aus Millionen und Abermillionen von kleinen Einbuchtungen besteht. Alleine die daraus entstehende dreidimensionale Fläche vollständig zu beschreiben, dürfte nicht mehr machbar sein.

Dennoch reicht es in der überwiegende Zahl der Fälle aus, wenn man die Steckdose als Kasten auffasst, der 15 Zentimeter lang ist, 5 cm breit und 3 cm hoch und aus rauem Plastik. Dieses einfache Modell repräsentiert alle Eigenschaften hinreichend genau um beispielsweise zu entscheiden, ob man das Teil hinter den Fernseher gefummelt bekommt oder eben nicht.

Will sagen: Was wir im Kopf haben, ist niemals das Ding an sich oder eine vollständige, identische Abbildung davon, sondern ein vereinfachtes Modell. Anders könnten wir mit der Komplexität unserer Welt gar nicht umgehen. Und das gilt nicht nur für Mehrfachsteckdosen, Legosteine und Vollkornschrippen, sondern erst recht für Verkehrsflugzeuge, das Handynetz oder Hochgeschwindigkeitszüge. Es hat aber genau so auch für die Beziehung zur Freundin, die Dynamik in unseren sozialen Netzen oder für unser politisches System Gültigkeit.

Wenn wir über Sachverhalte nachdenken, sie kommunizieren oder dokumentieren, machen wir das anhand von vereinfachten Modellen.

Nach [STA] machen dabei die folgenden drei Merkmale ein Modell aus:

• Abbildung: Ein Modell ist eine Repräsentation eines wie auch immer gearteten Objektes
• Vereinfachung: Das Modell gibt nur die für die momentane Aufgabenstellung relevanten Eigenschaften wieder
• Pragmatik: Das Modell ist nur für einen bestimmten Zeitraum, für bestimmte Nutzer und unter bestimmten Randbedingungen anwendbar

Das trifft es eigentlich ziemlich gut.

Gut, aber was hat das nun alles mit der Ausgangsfragestellung zu tun?

Dazu ein kurzer Exkurs in die technische Welt. Dort macht man oftmals genau das, was ich zwei Absätze weiter oben beschrieben habe: Man durchdenkt, kommuniziert und dokumentiert komplexe technische Systeme. In meinem konkreten Fall mache ich das überwiegend für Systeme, die es noch nicht gibt. Ich erstelle Anforderungsspezifikationen; das sind Dokumente, die beschreiben, was ein zukünftiges System einmal machen soll.

Anders als bei der Mehrfachsteckdose von oben steht dabei meist nicht die äußere Form im Mittelpunkt der Betrachtungen, sondern das Verhalten eines Systems. Und auch hier gilt: Das Verhalten der Systeme ist in der Realität mit all den physikalischen Eigenschaften, allen Abhängigkeiten und Emergenzen viel zu komplex, um es vollständig zu beschreiben.

Deswegen werden auch hierbei Modelle verwendet, überwiegend jedoch implizit. Z.B. dadurch, dass jeder Beteiligte - ob er will oder nicht - ohnehin ein gedankliches Modell des zukünftigen Systems in seinem Kopf hat oder dadurch, dass man durch z.B. eine schriftliche Dokumentation ein solches implizites Modell erschafft.

Das Problem dabei ist nun, dass alle diese Modelle - wie oben festgestellt - Vereinfachung des realen Systems darstellen, dieses also nicht 100%ig genau beschreiben. Es verbleibt eine Lücke zwischen dem System, so wie es durch das Modell abgebildet ist und dem System, wie es später in der Realität einmal tatsächlich sein wird. Das bedeutet auch, dass das Verhalten eines Systems in dieser Lücke undefiniert ist.

Und genau das kann zum Problem werden. Die Systeme, mit denen ich mich beschäftige haben ziemlich oft Sicherheitsverantwortung (im Sinn der Betriebssicherheit), was bedeutet, dass ein funktionales Fehlverhalten unangenehme Folgen kann. Entweder, weil die Aufzugsteuerung plötzlich entscheidet, die Kabine trotz offener Tür losfahren zu lassen. Oder weil die Waschmaschine nicht erkennt, dass mehr Wasser nicht hineinpasst und dieses sich daraufhin in der Küche verteilt. Und bei den oben angesprochenen Hochgeschwindigkeitszügen und Verkehrsflugzeugen kann ein funktionales Fehlverhalten dann nicht nur unschön werden, sondern katastrophale Folgen haben.

Und damit kommen wir endlich zu dem, was ich "so beruflich mache". Ich versuche, die Lücke zwischen Modell und Realität an den entscheidenden Stellen so klein wie möglich zu halten. Damit soll hinreichend unwahrscheinlich werden, dass das, was da drin dann eben nicht definiert ist, etwas wirklich Schlimmes anrichtet.

Eine wirtschaftliche - nennen wir es mal "Herausforderung" - ist dabei, dass das um so aufwändiger (und damit: teurer) wird, je kleiner die Lücke schon ist. Es ist daher sinnvoll, erst einmal die Bereiche des Systemverhaltens zu identifizieren, die potenziell bedeutend für die Sicherheit und Benutzbarkeit des zukünftigen Systems sind. In diesen Bereichen gibt man sich bei der Spezifikation der Anforderungen dann besondere Mühe, wohingegen in den eher unwichtigen Bereichen auch ein stark vereinfachtes Modell des zukünftigen Systems ausreicht (siehe die Steckdose oben, siehe Bild unten).

Realität und Modell, mal ganz einfach

Eine Möglichkeit, an den entscheidenden Stellen eine sehr gute Abbildung des zukünftigen Systemverhaltens zu erreichen, besteht darin, sich ganz explizit auf Modelle zu stützen. Wenn man eh ein Modell in den Köpfen der Beteiligten erzeugen muss, bietet es sich an, dieses gleich mittels einer für Alle gleichen Vorlage zu tun.

Diese Modell bestehend dabei üblicherweise nicht aus Pappe und Sperrholz, sondern es sind virtuelle Modelle, die in einer spezifischen Modellierungssprache beschrieben sind. Ein Beispiel für eine solche Modellierungssprache auf Systemebene ist die Systems Modeling Language (SysML), die als erweiterte Teilmenge von der Object Management Group spezifiziert wird.

In loser Folge möchte ich daher an dieser Stelle Ansätze zur Beschreibung von Systemen durch die SysML vorstellen. Im Vordergrund sollen dabei die Erfahrungen stehen, die ich in den letzten Jahren mit dieser Beschreibungssprache gesammelt habe. In einer Art Vermittlung von Best-Practices möchte ich gerne zeigen, wie sich bestimmte, immer wiederkehrende Aufgabenstellungen am einfachsten und elegantesten lösen lassen.


Literaturquellen:
[STA] Stachowiak, Herbert: Allgemeine Modelltheorie. Springer, Wien, 1973