Dass die kommunikative Beherrschung der Komplexität großer Softwaresysteme ein schwerwiegendes Problem darstellt,
wurde mir erstmals bewusst, als mich mein Studienfreund Dietrich Klugmann mit der Software bekannt machte, die
von der Firma Siemens anlässlich der Olympiade 1972 in München entwickelt worden war. Mit der Entwicklung dieser
Software waren ungefähr 150 Projektmitarbeiter über einen Zeitraum von fast drei Jahren beschäftigt. In dieser
Software steckte also ein Aufwand von etwas mehr als 400 Personenjahren, und der Papierstapel mit dem ausgedruckten
Programmcode hatte eine Höhe von ca. 2 Metern. Da brauchte man nicht viel Phantasie, um sich die folgenden drei Fragen zu stellen:
(1) Anhand welcher Dokumente können die Teilaufgaben abgegrenzt werden, falls das zu erstellende System nur mit
hochgradiger Arbeitsteilung realisiert werden kann?
(2) Anhand welcher Lehrunterlagen können diejenigen Personen geschult werden, die im Laufe des Projekts neu in die
Entwicklermannschaft aufgenommen werden sollen?
(3) Wie können sich Personen, die nicht an der Planung und Realisierung der ursprünglichen Software beteiligt waren, später
das Wissen verschaffen, welches sie benötigen, um Fehler in der Software zu korrigieren oder um die Software um neue Funktionen
zu erweitern?
Wenn es nicht um Software, sondern um Gebäude oder Maschinen ginge, ließen sich diese drei Fragen leicht
beantworten, denn dann gäbe es Pläne, die vor Beginn der Systemrealisierung erstellt wurden und an denen sich die Realisierer
orientierten. Es war mir klar, dass auch im Softwarewesen entsprechende Pläne benötigt werden, wobei aber damals noch niemand
eine Vorstellung davon hatte, wie solche Pläne aussehen könnten. Heute sind Softwaresysteme im Einsatz, deren Programmcode,
würde man ihn ausdrucken, einen Papierstapel ergäbe, der die Höhe des Eiffelturms erreicht. Solche Systeme kommunikativ zu
beherrschen, ist ohne den Einsatz geeigneter grafischer Pläne völlig unmöglich.
1.1.2 Das sekundäre Problem
Das sekundäre Problem besteht im Desinteresse der akademischen Informatik am primären Problem.
Wenn man einem Ingenieur, der mit der Welt der Softwareentwicklung nicht vertraut ist, das oben beschriebene primäre Problem
schildert, kann er es zuerst gar nicht glauben, dass die kommunikative Beherrschung der Komplexität großer Softwaresysteme
mittels leicht lesbarer genormter grafischer Pläne in der Informatikausbildung im Jahre 2016 immer noch keine zentrale Rolle spielt.
Bei meinem Bemühen, das primäre Problem zu lösen, war ich verständlicherweise auch immer auf der Suche nach Verbündeten
in der akademischen Informatik. Diese jahrelange Suche blieb aber leider erfolglos, und deshalb fragte ich mich nach den Gründen
für das Desinteresse der Informatiker an meinem Thema. Inzwischen glaube ich, drei Ursachen für dieses Desinteresse entdeckt
zu haben.
(1) Der Stolz der Programmierer auf ihr laufendes Programm
Der Einstieg in das Programmieren erfordert keine überdurchschnittliche Begabung, so dass sehr viele Anfänger schon recht
früh ihre ersten Erfolgserlebnisse haben können. Und diese Erfolgserlebnisse können süchtig machen, denn man erlebt
sich nun als jemand, der dem Computer seinen Willen aufzwingen kann. In meinen Vorlesungen über das Programmieren habe ich es
immer wieder erlebt, dass mich die Studenten drängten, meine in ihrer Sicht langweiligen einführenden Erklärungen
abzukürzen und ihnen endlich beizubringen, ihr erstes Programm zu schreiben. Bei vielen Programmierern verfestigt sich schon
sehr früh die Einschätzung, dass es nur darauf ankomme, das Programm "zum Laufen zu bringen", und dass jeglicher zusätzliche
Aufwand ein unnötiger Ballast sei. In dieser Haltung werden sie auch noch durch den Beifall von Außenstehenden bestärkt,
von denen sie wie Zauberer im Zirkus bestaunt werden.
(2) Das an Formalismen orientierte Wissenschaftsverständnis der Informatikprofessoren
In der Entstehungszeit der akademischen Informatik war das Fassungsvermögen der Computerspeicher noch so beschränkt, dass
höchstens so viel Software eingebracht werden konnte, wie ein einziger Programmierer in einem halben Jahr entwickeln konnte.
Deshalb gab es damals noch kein "Komplexitätsbeherrschungsproblem." Die damaligen Probleme im Zusammenhang mit der
Programmentwicklung waren ausschließlich mathematisch-logische Probleme. Deshalb war es ganz selbstverständlich, dass
die akademische Informatik von Mathematikern aus der Taufe gehoben wurde und dass diese die Lehrinhalte und Forschungsthemen der
neuen Disziplin festlegten. So ist es auch nicht verwunderlich, dass das wissenschaftliche Vorgehen gegen das Komplexitätsbeherrschungsproblem
in der Suche nach geeigneten Formalismen und Automatismen besteht und die Erfahrung der klassischen Ingenieure
mit leicht lesbaren genormten grafischen Plänen nicht herangezogen wird. Ein renommierter Informatikprofessor sagte mir einmal,
meine Arbeiten gehörten in den Bereich der Managementmethoden und hätten mit der wissenschaftlichen Informatik nichts zu tun.
In diesem Zusammenhang wird auch immer wieder darauf hingewiesen, dass es doch inzwischen die genormten Begriffs- und Symbolwelten UML
(Unified Modeling Language) und SysML (System Modeling Language) gebe, für deren Anwendung eine reiche Palette an unterstützenden Tools
zur Verfügung stünden. Und diese toolunterstützten Methoden würden das hier vorgestellte FMC entbehrlich machen. Es ist hier nicht der Raum
für die zwingenden Argumente, die ich gegen diese Behauptung anführen kann. Denn dazu müsste ich ausführlich auf die
Inhalte von UML und SysML eingehen, was den Umfang dieser Darstellung sprengen würde.
(3) Die fehlende natürliche Sichtbarkeit der geplanten Strukturen
Im Bauwesen und im Maschinenbau geht es bei den zu planenden Systemen um Gebilde, die eine natürliche Sichtbarkeit haben,
so dass auf den grafischen Plänen nur das dargestellt werden muss - in leicht abstrahierter und symbolisierter Form -, was man
später bei der Betrachtung des realisierten Systems sehen wird. Dies gilt im Softwarewesen jedoch nicht, denn
da ist das Einzige später Sichtbare der lesbare Programmcode. Die grafischen Pläne müssen hier das verständliche
Gedankengebäude zeigen, welches bei den Planungsüberlegungen in den Köpfen der Systemarchitekten entstand. Selbst auf
die Gefahr hin, als überheblich zu gelten, behaupte ich, dass nur ein recht kleiner Anteil aller im Softwarebereich Tätigen
die nötige Abstraktionsfähigkeit und das ebenso nötige didaktische Geschick besitzt, die hier geforderten grafischen
Pläne in ausreichender Qualität zu gestalten. Ich bin sogar überzeugt, dass auch viele der in der Informatik Lehrenden
die für die Planerstellung nötigen Fähigkeiten nicht besitzen.
Gibt es eine positive Perspektive?
Die beschriebenen drei Sachverhalte legen die Frage nahe, ob denn die kommunikative Beherrschung der Komplexität großer
Softwaresysteme mittels leicht lesbarer genormter grafischer Pläne überhaupt eine Chance hat, eines Tages zur
Selbstverständlichkeit im Softwarewesen zu werden. Ich sehe durchaus gute Gründe dafür, die Hoffnung noch nicht
aufzugeben. So ist insbesondere die Tatsache, dass nur wenige Fachleute die Fähigkeit haben, brauchbare grafische Pläne zu
gestalten, kein ernsthafter Hinderungsgrund, denn die wenigen, die das können, reichen zur Deckung des Bedarfs völlig
aus. Alle anderen in der Softwarebranche brauchen ja keine Pläne zu zeichnen, sondern müssen sie nur lesen können,
und das gelingt fast jedem.
Meine optimistische Meinung bezüglich der Perspektiven von FMC beruht auch auf meinen Erfahrungen mit Führungskräften in
der Softwareindustrie. Ich hatte oft die Gelegenheit, solchen Führungskräften das Konzept von FMC vorzustellen, und meistens
haben diese das Konzept mühelos verstanden und sahen den Nutzen sofort ein. Manche von ihnen haben anschließend die Möglichkeiten
ausgelotet, FMC in ihrem Unternehmen einzuführen. Sie mussten aber bald erkennen, dass sie den passiven Widerstand ihrer
Untergebenen nicht überwinden konnten. Diese Untergebenen wollen verständlicherweise die Vorteile, die ihnen aus der
Intransparenz ihres Tuns erwachsen, nicht widerstandslos aufgeben. Und sie wissen sehr wohl, dass sie für das Unternehmen nicht
ersetzbar sind, so dass ihre Vorgesetzten sie nicht zwingen können, FMC einzusetzen.
Ich vermute zwar, dass es tatsächlich unmöglich ist, die Situation heute schon positiv zu verändern. Ich bin aber
überzeugt, dass die Probleme, die aus der kommunikativ nicht beherrschten Komplexität großer Softwaresysteme
erwachsen, immer offenkundiger und teurer werden, so dass die Verantwortlichen in der Softwareindustrie eines Tages nach den
Schuldigen suchen werden. Und diese werden sie in der akademischen Informatik bei denen finden, die für die Lehrinhalte
verantwortlich sind. Diese werden sich dann nicht mehr länger dagegen sträuben können, der kommunikativen
Beherrschung der Komplexität großer Softwaresysteme mittels leicht lesbarer genormter grafischer Pläne das angemessene
Gewicht in den Lehrplänen einzuräumen.
zum Seitenanfang