In den vergangenen Jahren haben wir eine heftige Debatte über die Vor- und Nachteile verschiedener Programmiertechniken - darunter die normierte Programmierung, die Entscheidungstabellentechnik, die Modulare Programmierung und die Strukturierte Programmierung erlebt. Jetzt, nachdem man festgestellt hat, daß dies eigentlich ein Streit um des Kaisers Bart war, daß alle jener Techniken ihren Platz in dem breiten Feld der Programmierung haben, haben die Methodenpriester ein neues Tätigkeitsfeld gefunden, nämlich der Programm Design.
Auf dem diesjährigen CDI-Kongreß "STRUKTO 77" steht dieses Thema im Vordergrund, nicht zuletzt wegen dem Auftreten eines der Hauptkontrahenten in dieser neuen Runde - Michael Jackson. Natürlich hat Michael Jackson, Verfasser einer ausgetüftelten datenstrukturbezogenen Design Methode, uns etwas mitzuteilen, aber auch Larry Constantine und Ed Yourdon Advokaten einer vom Datenfluß ausgehenden Methode, sowie Doug Ross von Softech mit seiner funktionsorientierten SADT Methodik und Jean Dominique Warnier mit seiner auf der Datentransformation basierenden Modulentwurfsmethodik. Nicht weniger interessant ist der ablaufbezogene Ansatz von Harlan Mills oder die HIPO-Methodik von IBM. Alle diese Verfahren haben Vor- und Nachteile. Keiner kann einen Anspruch auf Ausschließlichkeit erheben. Jeder kann, wenn konsequent angewendet, zu einer Erhöhung der Softwarezuverlässigkeit führen. Dennoch fragt es sich, ob die Methodik allein genügt. Ich habe meine Zweifel.
In den letzten Jahren habe ich an einigen Software-Projekten mitgearbeitet, bei denen die neuesten Programmiertechniken und Designmethoden eingesetzt waren. Am Anfang war man immer sehr pedantisch und methodengläubig. Aber im Laufe der Zeit fielen die guten Absichten immer mehr dem Termindruck zum Opfer. Zum Schluß wurde wie eh und je gewurstelt. Dies hat mir zu denken gegeben. Was mich jedoch noch mehr stört, ist die Tatsache, daß ehrgeizige Projektleiter Programme freigeben, die noch lange nicht stabil sind, nur um Erfolg nach außen vorzutäuschen. Bis einer merkt, wie es mit der Software wirklich steht, hoffen sie, schon längst EDV-Leiter oder sonst irgendwo in den höheren Sphären der Organisationshierarchie zu sein.
Dieses Spiel der Software-Manager erinnert mich an meine früheren Tage als Zimmermann in den USA. Ich hatte mal einen Chef, der statt der vorgeschriebenen Stahlträger immer billigere Holzträger verwendete, um den Boden seiner Holzhäuser zu stützen. Da die Träger bedeckt wurden, konnte der Kunde es nicht merken, und bezahlen mußte er für Stahlträger. Inzwischen ist mein alter Chef Millionär geworden und wohnt irgendwo in Wyoming, wo er Politik betreibt. Ich frage mich oft, ob die Häuser, die wir damals gebaut haben, überhaupt noch stehen.
Ich sehe mich als Programmierer in einer ähnlichen Lage wie damals als Zimmermann: Gezwungen gegen Wissen und Gewissen zu schlampern. Und ich frage mich immer wieder, ob die alten Programme überhaupt noch laufen.
Alle Methoden und alle Programmiertechniken nutzen recht wenig, wenn der Chef ankommt und sagt, die Programme müssen bis Ende der Woche abgegeben werden, ob ausgetestet oder nicht. Der zynische Programmierer flickt sie irgendwie zusammen und präsentiert sie seinem Projektleiter der freudestrahlend damit zu seinem Vorgesetzten läuft. Der Inhalt jener Programmbibliotheken ist immerhin genauso unsichtbar für den Benutzer wie die Holzträger es für die Hausbewohner waren. Hauptsache ist, sie täuschen den nötigen Effekt vor. Jetzt möchte ich fragen, ob der Software-Projektleiter, der unausgetestete, unausgereifte Programme abgibt bzw. verkauft, nicht ein ebenso großer Gauner ist, wie der Bauunternehmer, der seine Kunden betrogen hat.
Deshalb meine ich, Methoden allein genügen nicht. Was wir brauchen, ist ein Statiker für Software, ein Software-Prüfer. Denn in Deutschland, mit seinen strengen Bauvorschriften, wäre das Täuschungsmanöver meines früheren Bauchefs nicht möglich gewesen. Es wird alles zu verschiedenen Phasen des Baus von einem Fachmann genau überprüft. Warum wohl? Weil man den Bauleitern mit Recht mißtraut. Und wie steht es mit der Software? Ist eine Software-Kontrolle nicht ebenso erforderlich? Ist Software, die unser Geld verwaltet, unseren Verkehr steuert, unsere Kranken überwacht, unsere Personalien speichert, nicht genauso wichtig wie irgend ein Einfamilienhaus? Was bedeuten schon Datensicherung und Datenschutz, wenn die Programme, die die Daten sichern bzw. schützen, voller Fehler stecken.
Methoden sind schön und gut. Es macht auch Spaß, über sie zu diskutieren. Aber Methoden allein können keine Qualität gewährleisten. Deshalb mein Plädoyer für eine Software-Qualitätskontrolle zu verschiedenen Zeitpunkten des Software-Entwicklungsprozesses; z. B. nach dem Systementwurf, nach der Programmspezifikation, nach der Kodierung und nach dem Modultest. Nur so können wir versichern, daß unsere Software wirklich das leistet, was wir von ihr erwarten. Nur so können wir vermeiden daß Projektleiter ihre quantitativen Ziele auf Kosten der Qualität erreichen. Nur so können wir feststellen, ob die Methoden, die wir anwenden, wirklich den erwünschten Erfolg bringen: ein funktionsgerechtes, effizientes, zuverlässiges und anpassungsfähiges Stück Software. Und schließlich können wir Software-Handwerker vielleicht besser schlafen.
Im übrigen verspreche ich mir als Programmierer mehr von den neuen Entwurfssprachen wie von den Entwurfsmethoden. Eine Methode ist meines Erachtens nach nur so gut wie die Werkzeuge, die sie unterstützen, und das "Ultimate Tool" ist in der Programmierung die Sprache. Eines Tages werden COBOL, FORTRAN und dergleichen endgültig von der Bühne verschwinden. PASCAL ist nur der Anfang. Es kommen auch noch ALPHARD und CLU. Für den kommerziellen Anwendungsprogrammierer, falls es noch welche gibt, wird es Sprachen wie SBA (System für Business Automation) geben. Für die Mehrzahl der kommerziellen Anwendungen sehe ich jedoch eine Datenbank Querysprache, wie z. B. SEQUEL von IBM oder IQL von Siemens, mit angeschlossenem Reportgenerator als das geeignete Werkzeug an. Man muß sich halt noch ein bißchen gedulden.
A propos für diejenigen, die immer noch glauben, ihr Heil in den Entwurfsmethoden zu finden, möchte ich folgende Lektüre empfehlen:
Constantine, Larry: Structured Design, Yourdon Press
Jackson, Michael: Principles of Program Design, Academic Press
Myers, G. J.: Reliable Software through Composite Design, Petrocelli/Charter McGowan/Kelly: Top-Down Structured Programming Techniques, Petrocelli/Charter
Warnier, Jean D.: Les procedures de traitment et leur données, l'Instruction Publique Yourdon, Ed.: Techniques of Program Structure and Design, Prentice Hall