Der vielzitierten Softwarekrise sind Guras 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.

Gerald M. Weinberg zeigte mir einmal zwei rund zehn Jahre alte Korrekturfahnen für sein Manuskript "Die Psychologie der Computer-Programmierung", das später ein Bestseller wurde. Dort ging es um die Frage: "Was hat Programmieren mit Menschen zu tun?"

In der modernen Management-Literatur ist die Antwort klar. Produktivität, Planbarkeit und Qualität sind Funktionen von Menschen. Wie motiviert und schult man aber die Mitarbeiter und gibt ihnen die nötige Energie? Dies hat wenig mit den neuesten Technologien zu tun. Der IBM-Wissenschaftler Horst Reraus, Software-Entwicklungsleiter der Santa Teresa Labs, kam in seinen historischen Produktivitätsstudien zum selben Schluß.

Die Vertriebsleute für neue Technologien werden Ihnen dies allerdings nicht erzählen; es könnte den Markt für ihre Werkzeuge ruinieren. Normalerweise lügen diese Leute nicht; es ist auch keineswegs so, daß sie nur die halbe Wahrheit sagen Wahrscheinlicher ist, daß sie die Tatsachen einfach nicht kennen - wie die meisten von uns.

Manche Leute fühlen sich von dem Gedanken angezogen, daß der Computer genau das tut, was wir ihm befehlen. In diesem Zusammenhang unterscheidet sich der Computer sehr von uns Menschen. Gilb´s erstes Gesetz über die Zuverlässigkeit von Computern lautet: "Computer sind unzuverlässig, Menschen sind es noch mehr." Wir gehen nicht gerne mit Menschen um. Es ist schon schwer genug, seine Eltern, seine Frau oder seine Kinder zu verstehen!

Die Büchse der Pandora im Software-Management

Die Lösung liegt in dieser und in anderen Branchen auf der Hand. Wenn Sie Menschen organisieren, motivieren und leiten können (indem Sie möglicherweise eine Umgebung des selbstverantwortlichen Managements schaffen), dann werden Sie die Technologie beherrschen. Bei der größten und erfolgreichsten Company der Computerindustrie bei IBM nämlich, ist man sich durchaus der Tatsache bewußt, daß der Mensch (sowohl der Angestellte als auch der Kunde) und die Art und Weise, wie man mit ihm umgeht, Schlüsselfaktoren für den Erfolg sind.

Wir haben es versäumt, die Leute im erfolgreichen Umgang mit Software zu schulen. Wir haben sie nicht in dieser Richtung motiviert. Wir haben ihnen nicht einmal die dafür geeignete Art von Werkzeugen gezeigt. Und wir haben sie nicht dementsprechend organisiert. Solange wir das nicht tun, sind wir zum Mißerfolg verdammt.

Wir hängen an Methodologien. Und unsere Methoden müssen unbedingt strukturiert sein, obwohl noch niemand bewiesen hat, daß diese besser sind als unstrukturierte. Wir haben es einfach akzeptiert. im Vertrauen darauf, daß strukturiert besser sei als - ja, als was? Als das Chaos? Neue Veröffentlichungen wie "Thriving on Chaos" von Tom Peters oder "Chaos: Making a New Science" von James Gleick haben uns an dieser Prämisse zweifeln lassen.

Es ist nichts Schlechtes daran, eine Methode zu haben. "Struktur" ist sicherlich auch in Ordnung. Aber ich gehe davon aus, daß wir gefährliche Methoden und allzu statische Strukturen haben. Unsere aktuellen Methoden weisen in der Regel größere Unzulänglichkeiten auf:

- Sie eignen sich nicht unmittelbar für die Problembereiche Qualität und Kosten; dazu fehlt ihnen ein Quantifizierungsinstrument. Sie orientieren sich vielmehr an Funktion und Struktur.

- Sie basieren auf dem statischen Wasserfall-Lebenszyklus, der hoffnungslos ungeeignet ist für die großen neuen Technologien und für die chaotischen Umgebungen, die unsere schwierigsten Projekte charakterisieren.

- Es fehlt ihnen die Grundlage eines Design-Engineering-Modells. Statt dessen basieren sie auf einem Handwerker-Modell, das der Denkweise eines Programmierers entspricht.

- Sie orientieren sich an statischen Produktmodellen und mißachten die Tatsache, daß unsere Arbeit ein Prozeß ist, der sich aus der Vergangenheit bis in dic Zukunft hinzieht.

- Die Qualitätskontrolle stützt sich auf Checks und Tests statt auf Design, Ablaufkontrolle und Inspektion.

Es gibt in unserer Zunft einige Ausnahmen hiervon, wie Nutzen und Realisierbarkeit anderer Modelle beweisen. Aber diese anderen Modelle sind noch weitgehend unbekannt oder noch nicht anerkannt. Tatsächlich scheint es so, als käme echte Motivation nicht aus der Annahme bekannter Technologien, sondern aus dem Schwung, etwas Neues und Persönliches zu kreieren.

Wir müssen uns eine Reihe von Werkzeugen anschaffen, mit denen wir permanent unseren realen Status im Verhältnis zu unseren Zielen und unseren kritischen Faktoren sichtbar machen können. Konkret brauchen wir dazu:

- multidimensionale Metriken zur Spezifikation und Messung der Grenzen von Erfolg und Mißerfolg,

- ständige, kleine, iterative und komplette Zyklen anwenderorientierter Produktion - als Norm, nicht als Ausnahme,

- leistungsstarke, allgemeine und unmittelbare Kontrolltechniken für Design und Spezifikation, um menschliche Fehler dann zu beheben, wenn sie entstehen und nicht Jahre später in den Testphasen,

- eine kontinuierliche Kausalanalyse der Ablaufprobleme und der Veränderungsmechanismen (wie Inspektion und statistische Ablaufkontrolle), da mit wir in einen ständigen Prozeß der Verbesserung eintreten, bevor die nächsten Arbeitsstufen beginnen, sowie

- klare Mechanismen der Qualitätskontrolle in kleineren Ablaufabschnitten wie IBMs Mustermodell "Entry Task Validation Exit".

Wir suchen noch nach einem Software-Äquivalent für den kontinuierlichen Fluß, für Kanban und für statistische Ablaufkontrolle, für Herstellungstechniken, die die zur Zeit im Abschwung befindliche amerikanische Industrie zwingen, sich aufzusetzen und nachzudenken - oder unterzugehen.

Bislang haben wir uns zum einen an den funktionalen Anforderungen orientiert (welche Eingaben, Algorithmen und Ausgaben ein neues System benötigt), zum anderen an den Techniken (den richtigen Methoden, Strukturen, Standards und Sprachen für ein gutes System - was immer das ist ). Und wir haben Schlüsselwörter für unsere Branche geprägt: Benutzerfreundlichkeit, Portabilität, Produktivität, Anpassungsfähigkeit, Modularität, Sicherheit und einfache Wartung in der täglichen Arbeit. Außerdem haben wir uns Mühe gegeben die mit diesen Begriffen zusammenhängenden Techniken zu verwenden.

Aber wir haben diese Ausdrücke nur selten definiert und in meßbaren Zusammenhängen verwendet, wie es eigentlich von jeder Wissenschaft, vom Management, in der Medizin oder in anderen Technikbereichen erwartet wird. Ein ganzer Berufszweig, von dem die Welt annimmt, daß er mit Zahlen gefüllt sei, ist eigentlich "zahlenschwach" (ill-numerate), um hier einmal einen Begriff zu prägen.

Praxis der SW-Entwicklung hat sich kaum geändert

Läßt man die gebräuchlichen Spezifikationen von Zugriffszeit in Millisekunden oder Speicherplatz in Megabyte außer acht, so benutzen wir noch nicht einmal das einfache Werkzeug der Zahl für alles, was in unserem Bereich wichtig ist. Die Tatsache, daß es in der Literatur bereits geeignete Metriken für Software gibt, hat kaum etwas an der tatsächlichen Praxis der Softwarentwicklung geändert. Das erfahre ich immer wieder in meiner Beratertätigkeit. Es scheint, als berührten die existierenden Metrik-ldeen uns nicht, weil wir unmotiviert und schlecht geführt sind.

Allerdings sind wir uns unserer technologischen Sünde nicht bewußt. Wir machen den Fehler, unserem Nachwuchs keine Meßmethoden beizubringen. Und auf diese Weise lehren wir ihn auch nicht, wie man rationell denkt, wie man komplexe und sich ändernde Technologien einschätzt, kurz: wie man mit der Zukunft umgeht.

Wir bringen den jungen Leuten nur unsere begrenzte, von Mythen behaftete Methodologie bei und schicken sie aus das technologische Schlachtfeld - zum Scheitern verurteilt wie unbewaffnete Kinder. Das Problem ist, daß wir selbst noch nicht so alt und noch nicht bereit zum Rückzug sind, so daß dieses Problem mindestens in genauso großem Maße unseres ist wie das unseres Nachwuchses.

Niemand erhält "Datenbank-Flexibilität", indem er die echte und Codd-zertifizierte relationale Datenbank einsetzt; diese Flexibilität läßt sich jedoch erzielen, indem die vielen verschiedenen Elemente, die zusammen unseren praktischen Begriff von Anpassungsfähigkeit formen, identifiziert werden. Für jedes dieser Elemente müssen die Meßkriterien und die Grenzwerte zwischen Erfolg und Mißerfolg definiert werden - und zwar für alle verschiedenen Systemkomponenten und für den bereits planbaren Zeitraum in der Zukunft.

Die "Anwenderfreundlichkeit" läßt sich auch nicht dadurch erreichen, daß man sich eine Macintosh-Benutzerschnittstelle (oder gar ein Hypercard-Interface) ins Haus holt. Das mag eine gewaltige technologische Veränderung bedeuten, wenn Sie bereits an Schlimmeres gewöhnt sind. Aber sobald Sie auf dieser Ebene angelangt sind, gehen die Anforderungen darüber hinaus.

Das komplette Design der Macintosh-Software ist wesentlich reicher und subtiler als eine oberflächliche Schnittstelle vermitteln oder ein Benutzerhandbuch ausdrücken kann. Nach vielen Jahren bin ich immer noch täglich entzückt, wenn ich ein neues unbekanntes Leistungsmerkmal im Design finde, das mein Leben als Anwender einfacher macht. (Meine letzte Entdeckung war, daß die Suche-und-Ersetze-Funktion die Groß- oder Kleinschreibung des Suchbegriffes beachtet und das Ersetzen entsprechend durchführt).

Wann haben Sie zuletzt quantitativ die Verwendbarkeit für ein Projekt spezifiziert, in das Menschen als Anwender involviert waren? Sagen Sie nichts, Sie sind bereits verurteilt!

Die Definition von Verwendbarkeit gehorcht vier bis acht größeren Kriterien (Eingabe-Anforderungen, Leichtigkeit des Erlernens, Produktivität, Fehlerquote, subjektive Meinung). Diese Definition kann allerdings auch andere Dimensionen für jede Systemkomponente haben; das hängt vom jeweiligen Anwendertyp ab. Sie brauchen jeweils eine 8x8x8-Matrix, um die Kriterien für fehlerhaftes Design eines Softwaresystems zu definieren (worst case) und um die Grenzwerte des Erfolges zu spezifizieren (planned level).

Die Technologie für Mensch-Maschine-Schnittstellen hat zur Zeit Hochkonjunktur. Sie ist natürlich viel umfangreicher als jede Benutzeroberfläche, und die Praktiker und Wissenschaftler auf diesem Gebiet gehören sicherlich zu den zahlenorientiertesten Vertretern unserer Branche.

Schlacht um die Portabilität

Daneben tobt derzeit die Schlacht um die Portabilität, wobei Standard-Schnittstellen, Unix oder Ada im Brennpunkt stehen. Aber auch für dieses Konzept haben wir bisher keinerlei Meßsysteme verwendet:, um die Technologie zu beschreiben. (Was heißt hier eigentlich Computer-Wissenschaft?) "Wie die Schlacht steht, weiß ich nicht; denn ich habe bislang keinerlei Zahlen über den Hergang." So lautet die frei erfundene Klage eines kurz vor der Niederlage stehenden Feldherren.

Wir verfügen nicht nur über zuwenig Meßmethoden für Software-Qualitätskriterien in kritischen Bereichen; wir haben es zusätzlich versäumt, das Wissen darüber zu vermitteln, wie man mit solchen Methoden als einer Reihe von simultanen Anforderungen umgeht. Es ist nur natürlich, daß wir kein multidimensionales Werkzeug anbieten können, wenn wir noch nicht einmal daran gewöhnt sind, mit eindimensionalen Problemen umzugehen.

Alvin Toffler identifiziert in "Third Wave" unser Manko bei der Bewältigung mehrerer gleichzeitiger Gefahren (kritische Erfolgsfaktoren) als Hauptursache dafür, daß wir solche Schwierigkeiten beim Beherrschen sich ändernder Technologien in einer sich ändernden Welt haben. Dieses gilt auch für das Software-Engineering.

Projekte werden unkontrollierbar bleiben

Systeme scheitern aufgrund mangelnder Qualität, fehlender Profite und Ressourcenknappheit. Diese Fehlerquellen sind Attribute und keine Funktionen. Unsere Projekte und Produkte werden nicht vorhersehbar und auf der Risikoseite unkontrollierbar bleiben, solange wir uns nicht für diese einfache Tatsache sensibilisieren und unsere Arbeit so organisieren, daß sie nicht nur für Funktionen, sondern auch für kritische Attribute strukturiert ist.

Wir müssen unsere Suche nach kurzfristigen und naheliegenden Ursachen für die heutigen Probleme wohl abbrechen. Vielmehr müssen wir uns auf allgemeinere Ursachen für die Probleme von heute und morgen konzentrieren. Die Konstante heißt Veränderung.

Die Methoden des Software-Engineering der Zukunft müssen folgende Charakteristika aufweisen:

- multidimensionale Auslegung, also die Fähigkeit, gleichzeitig mit mehreren kritischen Faktoren umgehen zu können,

- schrittweise Entwicklung, also die Fähigkeit, mit ständig weiterentwickelen Systemen ganz natürlich umzugehen,

- Anpassungsfähigkeit an sich ändernde kunden- und anwenderseitige Bedürfnisse und Umstände,

- Rationalität, also die Fähigkeit, systematisch rationale Entscheidungen über Technologien zu treffen (im Gegensatz zu emotionalen, von existierenden Mythen verursachten und Marketing-orientierten Entscheidungen, die heute an der Tagesordnung sind),

- Vorherrschaft der Ablaufkontrolle mit genauen Messungen über das Produkt wie auch den Entwicklungsprozeß selbst, wobei ständig auf eine verbesserte Kontrolle zu achten ist,

- schwerpunktmäßige Schulung in der Einschätzung von Problem- und Aufgabenstellungen (im Gegensatz zur bisher verfochtenen Methode, jeweils das nach Ansicht der Lehrer, Vertriebsleute und Autoren "Beste" zu vermitteln).

Mit Hilfe dieser Strategien können wir besser mit einer sich ändernden und unvorhersehbaren Zukunft umgehen. Und dies ist die einzig sichere Zukunft, die wir haben.

Software weist eine Parallele zur Medizin auf: Je früher Sie einer Krankheit vorbeugen, sie entdecken oder behandeln, desto besser.

Die treffendste Antwort des vergangenen Jahrzehnts auf die Frage nach der Software-Qualitätskontrolle besagt, daß eine frühzeitige Fehlerdiagnose und -behebung eine clevere Technologie ist. Die meisten Fehler treten in den Phasen des Design und der Spezifikationen auf. Keine noch so große Anzahl an höheren Programmiersprachen kann dieses Problem lösen! Und kein noch so intensives Programmtesten im Vergleich mit den Spezifikationen bringt irgend etwas außer der Gewißheit, daß der Fehler im System bleibt.

Wir müssen also lernen, zu welchem frühestmöglichen Zeitpunkt Probleme in der Praxis auftreten; dazu brauchen wir Erkennungs-Mechanismen. Außerdem müssen wir gewährleisten, daß sich die früh erkannten Probleme sofort auf das Produkt auswirken und die Fehlerquellen in der sie produzierenden Organisation dauerhaft behoben werden.

Wir haben die schlechte Angewohnheit, Probleme solange aufzuschieben, bis der Druck, sie zu beheben, von außen kommt Verantwortliches Management im Software-Engineering findet und löst seine eigenen Probleme, wie es auch in jedem anderen verantwortlichen Berufszweig erwartet wird. (wird fortgesetzt)