Die alten Mythen des Software-Engineering leben noch (Teil 1)

Die CASE-Tools haben den Kern des Problems verfehlt

20.10.1989

Der vielzitierten Softwarekrise sind Gurus wie Hersteller bislang mit ständig neuen Methoden und Werkzeugen zu Leibe gerückt. Tom Gilb* bezeichnet die produkt- und methodenorientierten Denkansätze als "Mythen", die seiner Ansicht nach den Blick auf eine wirkliche Problemlösung verstellen.

Der erste dieser Mythen trägt den Namen "strukturierte Methoden" und war eines der wichtigsten Themen im Software-Engineering der letzten 20 Jahre. Den Grund dafür bildet sicherlich die Annahme, daß chaotische Informatik-Methoden zumindest zum Teil verantwortlich sind für eine fehlerhafte Kontrolle über die Ressourcen und die Qualität von Softwareprojekten. Diese Annahme ist auch durchaus richtig, vor allem auf den Ebenen der Kodierung, der logischen Strukturierung des Programms und des Datenbankaufbaus.

Man muß sich jedoch vor Augen halten, daß strukturierte Methoden unsere Probleme nicht gelöst haben. Allenfalls haben sie einen kleinen Beitrag zur Qualitätsverbesserung und Produktivität geleistet. Dieser ist allerdings nicht einmal überall nachzuvollziehen.

Ebenso fest etabliert wie die "strukturierten Methoden" hat sich der Mythos vom "Datenfluß". Es gibt eine ganze Reihe von Entwicklern, die auf die Erstellung von Flußdiagrammen setzen, meist computergestützt; sie gehen davon aus, daß dadurch das jeweilige Projekt besser verstanden wird und deshalb weniger Fehler bei der Automatisierung des betreffenden Vorganges gemacht werden.

Dies klingt vernünftig. Wir müssen sicherlich lernen, wie die Daten von einem Prozeß zum nächsten fließen. Und dies muß sicher auch dokumentiert werden. Soweit ich mich erinnern kann, haben wir auch immer mit Flußdiagrammen gearbeitet. Es besteht aber kein Grund, daraus die endgültige Lösung für das Software-Engineering zu machen.

Es gibt Organisationen, die viele Mann-Monate in die Ausarbeitung von Flußdiagrammen stecken, ohne zuvor Oberhaupt die genauen Projektvorgaben und Ziele auf einer einzigen Seite zusammengefaßt zu haben. Hier stimmt die Verhältnismäßigkeit nicht. Wie können wir den praktischen Wert solcher Flußdiagramme einschätzen, wenn die grundlegenden Ziele des Projektes noch nicht klar sind?

Gefährlich wird dieser Ansatz vor allem an vier Stellen:

- In größeren und großen Organisationen kann der Analytiker die Diagramme nur teilweise, anhand von Stichproben überprüfen. Dabei ist es möglich, daß die ausgewählten Beispiele nicht die gesamte Realität widerspiegeln:

- Nach einer gewissen Zeit kann sich der als Diagramm dargestellte Ablauf geändert haben und eine Aktualisierung erforderlich machen.

- Nur ein kleiner Teil der aufgezeichneten Angaben wird auch wirklich benötigt; dadurch wird Energie und Arbeit verschwendet.

- Der Zeit- und Energieaufwand bei der Analyse des Datenflusses kann die analytische Aufmerksamkeit von den eigentlichen Erfolgsfaktoren des Projektes ablenken.

Mein persönlicher Lösungsansatz besteht in einem vollständigen Verzicht auf die Darstellung des Datenflusses. Wenn ich etwas über ein System erfahren muß, dann sehe ich es mir lieber in der Praxis an.

Außerdem entwickle ich Systeme in kleinen Teilabschnitten, weshalb sich der Analyse-Aufwand auch auf diese kleinen Teilabschnitte beschränkt. Ich glaube nicht, daß ich von Anfang an bereits alle Details über das Gesamtsystem wissen muß, da ich das Gesamtsystem auf dieser Stufe sicher nicht komplett verändere. Wenn sich grundlegende Änderungen ergeben, dann nehmen die Anwender aktiv an der Analyse teil und bestimmen mit, welche Modifikationen notwendig sind.

Das Design meiner Systeme und Schnittstellen ist sehr flexibel ausgelegt. Ich rechne ständig mit Veränderungen. Meine Systeme sind daher so konzipiert, daß sie schnell den Änderungen angepaßt werden können. Zusätzlich hat der Anwender selbst die Kontrolle über die Verwendung der Schnittstellen, direkt oder indirekt.

Um eines der größten Mißverständnisse der Softwarebranche handelt es sich beim "Wasserfall-Modell". Es geht um das Prinzip der schrittweisen Annäherung in der Entwicklung. Die meisten Umsetzungen dieses Modells haben jedoch systematisch den Prozeß der Annäherung ausgelassen und einfach vorausgesetzt, daß Software-Entwicklung in einer geraden Linie von den theoretischen Anforderungen über ein theoretisches Design bis hin zu Kodierung und Test durchgeführt werden könne.

Die Warnschilder wurden übersehen

Ich glaube, daß Menschen mit einer Programmierermentalität so fasziniert von der Aufgabe waren, formale Anforderungen auszuarbeiten und ein theoretisches Design vorzuschlagen, daß die Warnschilder übersehen wurden. Mangels einer weitergehenden Erfahrung wurde die eigentliche Botschaft nicht verstanden.

Langsam wacht die Branche aus diesem Dämmerschlaf auf; aber der Mythos wird nur schwer auszurotten sein. Wir vergiften unsere Studenten und Mitarbeiter nicht nur mit überholten Ideen. Diese Ideen waren für unsere Art Arbeit niemals richtig!

Die schrittweise Entwicklung ist ein Modell der Ablaufsteuerung. Dies ist wichtig in der heutigen Welt, in der Risiken kontrolliert werden müssen und Unsicherheitsfaktoren, Komplexität, große Dimensionen sowie Veränderungen die Norm sind. Was wir brauchen, ist ein neues Paradigma für die Steuerung komplexen Systeme. Die Tatsache, daß das evolutionäre Modell allgemein für die Entwicklung von umfassenden Systemen und Prozessen gilt - und nicht nur für Computerprogramme - macht die Situation für uns nur noch interessanter.

Eines der größten Probleme in der heutigen Kultur des Software-Engineering ist, daß immer noch versucht wird, Probleme im engen Rahmen des algorithmischen Musters zu lösen, anstatt aus der Sicht des Gesamtsystems zu arbeiten, wie es heute für den Erfolg unverzichtbar erscheint. Das statische Wasserfall-Modell ohne Feedbacks und Anpassungen eignet sich nur für Software-Projekte, die so klar und deutlich sind, daß man für die Entwicklung eigentlich keinen Software-Ingenieur braucht; solche Programme kann man direkt fertig kaufen.

Was ist für DV-Fachleute normaler als die Verwendung des Computers als Werkzeug? Oder anders gefragt: Sieht für einen kleinen jungen mit einem Hammer in der Hand nicht die ganze Welt aus wie ein Nagel? Ich bin davon überzeugt, daß wir Computer für viele Dinge im Software-Engineering einsetzen können und müssen. "CASE-Werkzeuge" als den großen Durchbruch im Software-Engineering zu feiern, ist allerdings nicht gerechtfertigt und wird es auch niemals sein.

Ich zweifle nicht daran, daß CASE-Werkzeuge die Produktivität und Qualität einiger Aufgaben in gewissem Maße verbessern. Aber es gibt mehr Behauptungen als überzeugende Untersuchungen, die diese Behauptungen unterstützen.

Meiner Ansicht nach liegt das eigentliche Problem darin, daß diese Werkzeuge hauptsächlich für die Programmierung und die Programmstruktur oder den Datenbankaufbau ausgelegt sind. Für den größten Teil des Software-Engineering (im

Gegensatz zum Programmieren), im Managementbereich und im Design der Qualitäts- und Ressourcen-Kontrolle sind die CASE-Tools jedoch ungeeignet.

Die meisten Werkzeuge befinden sich auf verschiedenen Ebenen der Beschreibung von logischen Strukturen oder der Verknüpfung von Daten. Keines davon ist für den direkten Einsatz in so zentralen Bereichen des Software-Engineering wie Zeitplan, Zuverlässigkeit, Verwendbarkeit, Verfügbarkeit und Portabilität einsetzbar - trotz allen Geredes, daß diese Probleme mit CASE-Werkzeugen gelöst werden könnten.

Das jeweilige Tool spielt eine untergeordnete Rolle

Solche Werkzeuge eignen sich sehr gut für Universitätsprojekte. Und man kann damit hervorragend vermarktbare Produkte herstellen. Diese Tatsache allein garantiert uns, daß sich jemand findet, der diese Werkzeuge lauthals lobt, ungeachtet dessen, ob es sich nun um wirklich geeignete Werkzeuge handelt oder nicht.

Leider brauchen wir zum Geldausgeben etwas Vorzeigbares - auch wenn unsere wichtigsten Werkzeuge Menschen und Know-how sind. Wir haben die Bedeutung von Softwarewerkzeugen wohl übertrieben, weil man aus ihnen eher verwertbare Produkte herstellen kann als aus dem Know-how das wir tatsächlich für ein erfolgreiches Software-Engineering brauchen.

Wissenschaftler wie Horst Remus von den Santa Teresa Labs der IBM haben jedoch in praktischen Untersuchungen herausgefunden, daß Produktivität, Qualität und Rentabilität (das wahre Ziel jeder Ingenieurs-Zunft) nicht - oder nur in unbedeutendem Ausmaß - von den Werkzeugen herkommen, sondern von der Organisation der Arbeitsabläufe sowie von den richtigen und motivierten Mitarbeitern.

Ich habe die Erfahrung gemacht, daß dem jeweilige Werkzeug weniger als ein Prozent an Bedeutung zukommt im Vergleich mit der Suche und dem Erarbeiten unseres Weges in Richtung meßbarer Qualitätsziele und Ressourcen-Nutzung. Vom Praktischen Standpunkt des Ingenieurs aus würden Papier und Bleistift ausreichen.

Der Computer eignet sich lediglich besser für den Satz und die graphische Darstellung; er ist ein hochstilisierter "Konzept Prozessor". Aber der Computer steht dem Ablauf nicht kritisch gegenüber.

Das Hauptproblem ist die Frage, was wir machen, und nicht die Frage, mit welchem Werkzeug wir es machen. Wir sind völlig mit Detail-Arbeit überlastet. Also wissen wir zuwenig über die wichtigsten Abläufe im Software-Engineering. Damit meine ich beispielsweise

- die Identifikation aller kritischen Entwicklungsstufen und ihre Kontrolle,

- statistische Qualitäts-Kontrollen aller Design-Unterlagen,

- einen kontrollierten Annäherungsprozeß, innerhalb dessen wir unsere Ideen testen und falsche Konzeptionen rechtzeitig korrigieren können,

- wechselnde Kontrollen für alle Anforderungen und Design-Elemente - natürlich mit einem guten Werkzeug (die meisten Design-Ideen werden immer noch nicht festgehalten und systematisch nachverfolgt)

- sowie

- die Ausbildung von Design-Ingenieuren, die aktiv in Richtung mathematischer Qualitätsziele und Ressourcen-Nutzung planen können, von Ingenieuren, also die innerhalb eines Kostenrahmens arbeiten können und dies auch tun.

Wir sind nicht einmal soweit gekommen, solche Ingenieure auszubilden. Die meisten unserer Software-Ingenieure sind in Wirklichkeit Software-Handwerker.

Unsere "Ingenieure" sind normalerweise außerstande zu sagen, auf welche Weise man zentrale Konzepte wie Verwendbarkeit, Wartungsfreundlichkeit und Portabilität mathematisch ausdrucken kann. Keine Universität lehrt diese Sprache. Dem würde entsprechen, wenn Ingenieure der Elektrotechnik keine Ahnung hätten, wie man Leistung, Strom und Impedanz mathematisch ausdrückt!

Es fehlt eine Sprache für die tatsächlichen Probleme

Für die meisten Software- Menschen ("Ingenieur" ist - wie oben erläutert - eine Krone, die sie sich selbst aufsetzen, ohne sie im eigentlichen Sinn des Wortes verdient zu haben) bedeutet die Programmiersprache das Zentrum des Universums. Die Fürsprecher der jeweiligen Sprachen unterstreichen stets deren hervorragende Leistungsmerkmale - ohne sie je zu messen. Negative Nebeneffekte übergehen sie dabei vollständig. Besonders in der Computer-Szene wuchs die Zahl der Vertriebsleute, nicht aber die der Wissenschaftler.

Unter dem Gesichtspunkt der Einsparung menschlichen Arbeitsaufwandes helfen die Sprachen nur scheinbar. Die Unmengen an Programmierer, die heute noch daran arbeiten, ein Reservierungssystem für Luftfahrtlinien wie dem amerikanischen Sabre in Assembler zu programmieren, gehören zu einer geringer werdenden Minderheit.

Von Anfang an gab es "portable" Sprachen. Wir haben es nur versäumt, unsere Hardware und Compiler anzupassen. Mein PC versteht heute sicher Cobol, Fortran und PL/1, aber ich habe nicht die Software dafür. Ich kenne auch niemanden, der sich für diese Sprachen interessiert (obwohl es sicherlich einige gibt).

Die nächste Software-Generation soll uns immer vor den Verrücktheiten der Vergangenheit retten. Leider tut sie es nie. Wir hoffen weiter. Die nächste Generation bringt uns in der Regel neue Inkompatibilitäten, Wartungs- und Schulungsprobleme.

Und dies wird solange der Fall sein, wie der Mensch von einer gemeinsamen Sprache träumt (Latein, Französisch, Deutsch, Englisch, Esperanto, Musik, Kunst). Die Geschichte des Menschen beweist, daß wir uns nicht auf einen Standard einigen werden.

Unser Problem ist nicht die algorithmische Sprache. Unser Problem ist, daß wir keine Sprache für Software-Engineering entwickelt haben, die unsere echten Probleme beschreibt und bearbeitet.

Wie viele "Software-Ingenieure" kennen die Meßkriterien für so dringende Probleme wie Verwendbarkeit, Portabilität und Wartungsfreundlichkeit? Wie viele Bücher oder Kurse lehren das Wissen über diese fundamentalen Konzepte? Und wie viele Kurse und Bücher über Software-Engineering lehren die Fähigkeit, ein Software-System so aufzubauen, daß eines oder mehrere der oben erwähnten Qualitäts-Kriterien erfüllt werden? Dabei rede ich eigentlich nur von der Entwicklungsleistung, die von jedem Architekten oder Hardware-Ingenieur erwartet wird.

Wir verfügen über mehrere hundert Mutanten von Programmiersprachen - ein echter Turmbau zu Babel. Somit können wir garantiert nicht kommunizieren, außer in kleinen Gruppen, die denselben Dialekt verstehen. Gibt es also ein Komplott der Götter, uns zu teilen und zu beherrschen? Oder gibt es nur eine Reihe von persönlichen und marktbezogenen Interessen, die wir nicht im Griff haben? Vielleicht handelt es sich bei dieser Vielzahl auch um natürliche "Der-Stärksteüberlebt"-Mechanismen, die weiterbestehen, auch wenn sich unsere Anforderungen und Umgebungen ändern.

Wo aber gibt es die eine Sprache, mit der wir über unsere wirklichen Probleme kommunizieren können, die uns hilft, Pläne und Designs zu entwerfen, mit denen diese Probleme gelöst werden können? - Diese Sprache ist keine Sprache algorithmischer Logik. Es ist eine Sprache, in der Probleme spezifiziert und gelöst werden. Um sie zu finden, müssen wir uns an der Architektur und der Technik orientieren und nicht an der Linguistik.

Kurz, der Mythos, daß eine neue Programmiersprache (oder eine neue Datenbank oder ein neuer Standard) unsere Probleme löst, ist weitgehend falsch. In Wahrheit werden unsere Probleme klarer definiert und eher beseitigt, wenn wir über eine Sprache zur Problemlösung verfügen. Wir haben seit 30 Jahren unter der Laterne gesucht, da es dort heller war. Aber nun sollten wir auch einmal die dunkleren Teile unserer Straße ausleuchten.

Einen Mythos der Softwareentwicklung stellen auch die sogenannten Schätzmethoden dar. Sicher müssen wir Zeit, Geld und personelle Kapazitäten, vielleicht auch benötigte Hardware-Ressourcen, richtig einschätzen. Denn diese Ressourcen stehen nicht unbegrenzt zur Verfügung, außerdem neigen wir dazu, mehr zu versuchen, als Zeitplan und Budget uns erlauben.

Die neueste Masche, von der wir in den letzten zwei oder drei Jahrzehnten schon verschiedene Variationen erlebt haben, ist die Verwendung von Formeln, in die Parameter eingetragen werden, um Größe und Komplexität eines Projektes zu spezifizieren. Das funktioniert jedoch höchstens dann, wenn wir die Software-Qualität senken, sobald das Budget verbraucht ist. Aber damit hängen wir einer Illusion nach.

Möglicherweise funktioniert das in vorhersehbaren Brot-und-Butter-Entwicklungen. Es muß aber auch in groß angelegten, hochkomplexen neuen Technologien funktionieren. Dort stützten sich jedoch alle Modelle auf Daten, die vor Jahren in anderen Projekten gesammelt wurden und deren Parameter nicht genau bekannt sind. Wer kann schon mit einer Genauigkeit von vier Stellen hinter dem Komma sagen, welche Verfügbarkeit diese Projekte hatten?

Diesem Mythos suchen wir verzweifelt Gültigkeit zu verschaffen. Wir haben begonnen, auf PCs Modelle zu erstellend und einem fehlerhaften Konzept zu Glaubwürdigkeit und Marktwert zu verhelfen. Und was ist die Alternative? Niemand, der seine Ressourcen kontrolliert, verwendet die Kristallkugel-Methode. Vielmehr wird er anhand eines Kostenrahmens entwickeln; das ist eine alte Ingenieurs-Tradition. Außerdem arbeitet er mit einer schrittweisen Ablaufkontrolle, um rechtzeitig die reellen Kosten zu überblicken und zuverlässige Forecasts aufzustellen. Dadurch können die Entwickler entweder Design oder Anforderungen modifizieren um nah an der Realität zu bleiben - wie überraschend die Wirklichkeit hinterher auch sein mag. (wird fortgesetzt)