Szerkesztő:Szabo Tamas/invarianten

Kopie eines Artikes von Ernst Denert 1998 zu CEBIT, original kann ich nicht finden.

Informatik im Wandel - ein Kontrapunkt: Invarianten des Software-Engineering Von: Prof. Dr. Ernst Denert

Daß sich die Informationstechnik rasant ändert und entwickelt, ist evident. Der Wandel ist in einigen Bereichen von einem atemberaubenden Tempo; die Entwicklung der Chips, deren Leistungsfähigkeit sich jedes Jahr verdoppelt, ist ein spektakuläres Beispiel dafür, die Software auf dem PC-Markt ein anderes. Prognosen sind deshalb ein Lieblingsthema der Presse unserer Branche und ihrer Leitartikler. Gerne spekulieren sie, wie Client/Server-Systeme die zentralen Mainframes niedermachen, daß Java die Programmiersprache der Zukunft wird oder wie E-Commerce die Welt der Wirtschaft auf den Kopf stellt. Nie reflektieren sie allerdings, was aus ihren Vorhersagen von gestern, vor einem oder vor fünf Jahren geworden ist - es wäre wohl zu blamabel und würde auch niemanden interessieren.

Es wäre ein lehrreiches Experiment, einmal im Jahr aufzuschreiben, wohin die Informatik sich in zwei, in fünf und in zehn Jahren entwickelt haben wird, und zugleich nachzuschauen, was aus den Prognosen vergangener Jahre geworden ist - ein gutes Training für das Urteilsvermögen, vor allem aber eine große Ernüchterung über die eigene Fähigkeit, in die Zukunft zu blicken. Wem dieses Experiment zu langwierig ist, kann es ja ersatzweise mit einer ehrlichen Selbstbefragung versuchen: Was hätte ich 1980 über den Stand der Technik 1985 bzw. 1990 gedacht und 1985 über 1990/95 usw.?

Meinen Vermutungen über die Veränderungen in der Zukunft würde ich nicht trauen, und deshalb widerstehe ich dem Ansinnen des Herausgebers dieses Blattes, solche anzustellen. Statt dessen biete ich zur Abwechslung einmal eine Betrachtung darüber an, was sich nicht ändert bzw. nicht ändern sollte, entweder weil es resistent ist, ewige Gültigkeit besitzt oder bewahrenswert ist. Dabei will ich mich auf das Gebiet beschränken, von dem ich etwas zu verstehen glaube: Software-Engineering. Im folgenden geht es also um Unveränderliches oder, wie ich es nennen will, "Invarianten des Software-Engineering".

Softwaresysteme leben lang.

Das kann doch nicht wahr sein, wird der geneigte Leser denken, in Zeiten, in denen Geschäftsprozesse und Informationstechnologie sich so rasch ändern, kann auch den Softwaresystemen kein langes Leben beschieden sein. Doch, es gibt viele Anwendungen, die älter als 20 Jahre, ja, es gibt Code, der älter ist als die Programmierer, die ihn warten. Wir haben keinen Grund anzunehmen, daß die Systeme, die wir heute bauen, weniger lange leben, im Gegenteil, sie kosten einen derart hohen Aufwand und sind so komplex, daß es noch schwerer wird, sie abzulösen als diejenigen, die heute alt sind. Langlebende Software muß langlebig gebaut werden , d.h. modular, gut strukturiert und dokumentiert. In Amerika ist die Auffassung verbreitet, das gehe und lohne sich nicht wegen der sich rasch ändernden Anforderungen - tun die das in ihrem Kern wirklich? -, und deshalb ist Rapid Application Development (RAD) dort in vieler Munde. Nachhaltig auch in der Praxis? Ich halte es für einen Irrweg, denn Softwaresysteme leben lang.

Software ist und bleibt unsichtbar.

Das ist der tiefe Grund für die vielen Schwierigkeiten der Software-Entwicklung. Anders als etwa beim Bau eines Hauses, bei dem auch der Laie den Stand der Dinge auf einen Blick erkennt, mangelt es der Software an Anschaulichkeit. Ihre Qualität ist schwer zu beurteilen, ebenso ihr Fertigstellungsgrad während der Entwicklung, und das macht auch ihre Planung so schwierig. Deshalb müssen wir uns viel Mühe geben mit den Methoden der Software-Entwicklung und den Darstellungen der Artefakte, die wir schaffen - sie müssen präzise und anschaulich zugleich sein.

Projektplanung greift immer zu kurz.

Es dauert immer länger und kostet mehr als gehofft, gedacht, gewünscht, geplant. Es ist eben schwer, sich vorzustellen, daß ein Softwaresystem einmal so groß und komplex wird, und zudem - meint mancher - ist es doch so einfach, etwas zu programmieren. Man sollte beim Planen nicht naiv sein und tut gut daran, ordentlich Reserven vorzusehen.

Modularität tut not.

Wie soll man sonst 100.000e und Millionen Zeilen Code beherrschen, strukturieren, verstehen, ändern, verwalten, warten? Dennoch wird Modularität im (ver)öffentlich(t)en Bewußtsein nicht besonders hoch gehandelt. In den vielen technologischen Modeerscheinungen, mit denen wir überschwemmt werden, spielt sie jedenfalls keine Rolle. Manche davon sind geradezu kontra Modularität - ich denke etwa an 4G-Sprachen und Rapid Application Development. Es gibt eine Ausnahme: Objektorientierung ist derzeit sehr "in", allerdings gar nicht neu, sondern schon vor 30 Jahren erfunden. Dies ist eine hervorragende Methode zur Modularisierung im Kleinen, insbesondere wenn sie ergänzt wird durch eine klare Vorstellung von Softwarearchitektur im Großen.

"Goto considered harmful" befand Dijkstra, ebenfalls vor 30 Jahren, und erfand die Strukturierte Programmierung als Mittel gegen Spaghetti-Code. Dieser ganz alte Hut ist und bleibt immer gut im Dienste der Modularität im Kleinen.

Spezifikation und Konstruktion sind sauber zu trennen.

Spezifikation meint das "Was", die fachlichen Anforderungen an ein System, und Konstruktion das "Wie" seiner technischen Realisierung. Diese beiden Aspekte muß man streng auseinderhalten, im Entwicklungsprozeß und vor allem in den dabei entstehenden Dokumenten. Statt erst zu planen und dann zu realisieren wird häufig jedoch gleich drauflosprogrammiert - manche Tools verführen regelrecht dazu - und ein Prototyp zum "Typ" gemacht.

Eine besondere Spielart dieses Phänomens ist das unseriöse Verhalten von Auftraggebern und -nehmern, die (große) Festpreise für unklare Aufgaben verlangen bzw. anbieten.

Wir haben immer die falsche Programmiersprache.

Die Programmiersprache ist das bei weitem wichtigste Werkzeug des Software-Ingenieurs. Die Informatik hat gute Programmiersprachen entwickelt - Algol68, Pascal, Modula, Ada, Eiffel, um nur einige wichtige zu nennen -, in der wirtschaftlichen Praxis haben wir aber immer nur die schlechten Optionen: In den 60/70er Jahren hatten wir zwischen Cobol und PL/1 zu wählen - wer sich für das vermeintlich modernere PL/1 entschied, ist heute arm dran, und wie geht´s den vielen Cobol-Shops, die nicht davon loskommen? -, in den 80/90ern konnte man auf C bzw. C++ umsteigen, in gewisser Weise ähnlich Cobol: schlecht, aber weit verbreitet.Smalltalk, eine gute objektorientierte Sprache, war vor zwei, drei Jahren "in" und ist jetzt wieder ziemlich "out", also auch keine gute Option mehr. Java gibt endlich einmal Anlaß zu Hoffnung, es ist eine gute Sprache. Es fragt sich nur, ob sie sich durchsetzen kann, oder ob sie im "Krieg" Microsoft gegen Sun zerrieben wird. Mit den Programmiersprachen werden wir wohl ein ewiges Dilemma haben!

Testen zeigt Fehler auf, nicht Korrektheit.

"Testen zeigt nur die Anwesenheit von Fehlern auf, niemals deren Abwesenheit" (Dijkstra), d.h. wir wissen nie, ob eine Software korrekt ist, und umgekehrt bedeutet es, daß sie (praktisch) immer fehlerhaft ist. Und dennoch kommt das Testen immer zu kurz, denn den Letzten beißen die Hunde. Am Anfang eines Projekts läßt man sich eventuell Zeit für den Entwurf, ohne Codieren geht es sowieso nicht, aber das Testen bleibt häufig auf der Strecke. Noch so ein ewiges Dilemma!

Performance ist immer ein Problem.

Wieso denn? Die Hardware wird doch immer schneller, alle zwei Jahre verdoppelt sich ihre Leistungsfähigkeit bei gleichem Preis. Die Software frißt die Hardware auf! Das ist wie mit neuen Straßen: Sie ziehen den Verkehr an und sind gleich wieder verstopft. Das heißt, der Software-Ingenieur muß sehr auf Performance achten, im Design, beim Programmieren, beim Tuning. Naivität - die Hardware wird´s schon richten - rächt sich!

Menschen machen Projekte.

Das ist die wichtigste Invariante. Nicht Methoden und Tools, nicht Technologien und Verfahren, nein, Menschen machen Software. Auf ihre Fähigkeit und Zähigkeit, ihre Intelligenz und Erfindungsgabe, ihr Engagement und ihren Teamgeist kommt es vor allen Dingen an.

Ich hoffe, der Leser kann nun verstehen, warum ich sage, es lohnt sich nicht nur über den Wandel in der Informatik, sondern auch darüber nachzudenken, was invariant bleibt, weil es entweder unabänderlich ist oder bewahrt werden sollte. Oft eröffnet das tiefere Einsichten in den Stand unseres Fachs als Spekulationen über die Zukunft.