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.

Es sieht ganz so aus, als gäbe es keinen geraden Weg zu all den Antworten, die wir gerne hätten. Das gilt für die wissenschaftliche Forschung, das Ingenieurwesen, das Management und sicher auch für die Politik.

Ein signifikantes Beispiele für den Versuch, diese Tatsache zu übergehen. ist das sogenannte Wasserfall-Modell. Modelle zur Kostenkalkulation machen den selben Feiner. Wissen wir Programmierer eigentlich, daß Programme nicht einfach geschrieben werden, sondern sich in einem iterativen Prozeß entwickeln? Oder ist unser Kopf einfach mit Stroh vollgestopft?

Vielleicht liegt das Problem in unserem Bildungssystem. Wir lernen Regeln und Formeln; aber wir lernen zu wenig dar über, wie man mit den wirklich schwierigen neuen Problemen umgeht.

Unsere Probleme sind nicht nur schwierig, sondern eigentlich unlösbar. Das heißt, wenn wir endlich eine Lösung gefunden haben, dann haben wir geschummelt. Die Endanwender ändern nämlich nach Belieben die Spielregeln. Tatsächlich müssen wir davon ausgehen, daß Anwender und Kunden systematisch ihre Software-Anforderungen ändern, bevor wir am Ziel angelangt sind.

Das könnte natürlich daran liegen, daß wir notorisch langsam sind. Aber es liegt auch daran, daß sich die Welt um Anwender und Kunden herum sehr schnell ändert, und also auch die Anwender keine andere Wahl haben als ihre Anforderungen an unsere Systeme ständig zu aktualisieren.

Rasche Anpassung an Anwenderwünsche tut not

Bei der Methode der schrittweisen Annäherung (Iteration) gibt es vier kritische Punkte:

- die Frequenz der Iteration; hier sollte die Norm lauten: wöchentlich oder monatlich, nicht jährlich oder gar nur alle paar Jahre,

- der Inhalt der Iteration; die Frage ist: Hat der Kunde etwas wirklich Sinnvolles erhalten oder haben Sie einfach einen Haufen Papier und Bürokratie, aber keine Hilfe geliefert?

- die Anpassungsfähigkeit der jeweils folgenden Iteration; hier lautet die Frage: Können Sie sofort und unmittelbar auf Feedbacks von Kunden reagieren, oder sind Sie bereits für das nächste Jahr mit den nächsten zwölf Schritten ausgelastet, unabhängig von benutzerseitigen Anforderungen?

- Die Relevanz, die die gelieferten Iterationen des Entwicklungs-Prozesses besitzen; Sie müssen straffe Richtlinien darüber haben, welche wichtigen Dinge zuerst erledigt werden müssen. Viele Software-Ingenieure verbringen jedoch - aufgrund fehlender Richtlinien und Kontrolle - Jahre mit dem Erledigen weniger wichtiger Dinge für ihr Unternehmen. Das ist ein Management Problem. Software-Ingenieure haben keinerlei ethische Standards, die sie dazu bringen könnten, sich den Kopf über die Gesundheit ihrer Kunden zu zerbrechen.

Es ist uns noch nicht gelungen, die Veränderung unseres Arbeitsprozesses vom Wasserfall zu den iterativen Zyklen zu institutionalisieren. Um das Problem aufzufangen, haben wir den Fehler gemacht, Industrie- und Militär-Standards zu übernehmen, die unsere schlechte Angewohnheit nur noch tiefer verwurzelt haben. Aber das ist nichts Neues; schließlich bringen die Menschen sinnlose Gesetze immer mit den besten Absichten durch, siehe zum Beispiel die Prohibition!

Die Fähigkeit, etwas in Zahlen auszudrücken, ist ein grundsätzlicher Test für das Wissen. Wie bereits erwähnt, sind Software-Ingenieure besonders schwach darin, ihre Wissenschaft in Form von Zahlen auszudrücken; sie haben eher literarische als wissenschaftliche Ansätze (von bedeutenden Ausnahmen einmal abgesehen).

Alle stimmen offensichtlich darin überein, daß der Softwarebereich verstärkt zahlenmäßig dokumentiert werden muß. Ein Problem scheint es vielmehr zu sein, das tatsächlich zu bewerkstelligen. Dabei gibt es eigentlich kein Wissensmanko in den Printmedien. Wir haben unsere Erkenntnisse nur noch nicht angewandt.

Warum eigentlich nicht? Ich glaube, die Ursache liegt einfach in einem Mangel an Motivation. Wir sind lange auf einer Welle der expandierenden und populären Technologie geritten. Wir konnten lange die Benutzer-Anforderungen an Qualität und Preis-/Leistungs-Verhältnis ignorieren, da das tolle neue Werkzeug, für das wir Software machen, von beidem soviel zu bieten hatte, unabhängig davon, wie schlecht wir es programmierten oder wie teuer es wurde.

Diese Einstellung ähnelt der Arroganz, die die US-amerikanische Industrie in den Jahrzehnten nach dem Krieg an den Tag legte. Diese Industrie wurde schnell von den Japanern, die wir natürlich unterschätzt hatten, in die richtigen Dimensionen verwiesen. Werden wir einige unterschätzte östliche oder europäische Länder brauchen um die US amerikanischen Software-Ingenieure, heute die arroganten Führer auf dem Weltmarkt, zu zwingen, ihre Methoden zu modernisieren? Ich glaube ja. Und es würde mich nicht wundern, wenn unsere hochverehrten Mitbewerber von der fernöstlichen Insel uns einmal mehr eine Lektion in Bescheidenheit lehren wunden.

Für die Spezifikation von Software-Attributen erachte ich folgendes Schema als sinnvoll:

- Wir brauchen eindeutig benannte Markierungen, um Nachverfolgbarkeit und Möglichkeit zu Querverweisen in der Spezifikation zu gewährleisten; Markierungen können auf allen Ebenen der Spezifikation verwendet werden, wo direkte Referenzen nötig sind.

- Außerdem muß eine eindeutige und dokumentierte Maßeinheit definiert werden. Auf diese Weise erhalten alle Zahlen eine Bedeutung. Es gibt praktisch keine allgemein und international akzeptierten Standards, Software zu messen. Dieselben Wörter werden überall verschieden interpretiert. Die einzige allgemeingültige Lösung ist, die gemeinte Maßeinheit schriftlich präzise zu beschreiben. Wörter wie "Einsetzbarkeit" oder "Portabilität" haben keine Bedeutung, solange sie nicht durch eine Maßeinheit und einen zugehörigen Wert definiert sind. Nichtsdestoweniger halten wir uns normalerweise nicht daran.

Die Anforderungsprofile sind in der Regel unklar

- Der Parameter "Test" definiert einen (oder mehrere) anwendbare Überprüfungen oder Meßvorgänge. Damit können wir herausfinden, wo wir uns gerade in der Entwicklung und Anwendung befinden. Die Wahl der Maßeinheit hängt von der benötigten Genauigkeit und Zuverlässigkeit ab, aber auch von den verwendeten Ressourcen und Meßinstrumenten sowie von der Frage, ob diese für Messungen verwendet oder modifiziert werden können.

- Sinnvoll sind einer oder mehrere Referenzpunkte in aktuellen oder vergleichbaren Systemen. Hier finden wir den Ausgangspunkt für die aktuelle Technologie.

- Nicht um eine Anforderung im eigentlichen Sinn handelt es sich bei der Definition des am höchsten angesiedelten Ziels. Diese Festlegung stellt eine Informationen dar, an der wir messen können, wie realistisch die tatsächlichen Forderungen ("plan", "worst") sind.

- "Worst" heißt der gerade noch akzeptierbare Fall. Ergebnisse, die unterhalb dieser Ebene liegen, führen zu der Definition eines Mißerfolges für das Gesamtsystem, unabhängig davon, wie gut andere Attribute sein mögen.

- "Plan" heißt die Ebene, ab der das Ergebnis eine Qualität ist, die einem technologischen Erfolg entspricht. Für eine Ressource - zum Beispiel ein Budget - ist dies die geplante und akzeptierbare Ebene.

Spezifizieren Sie alle kritischen Erfolgsfaktoren für alle Ihre Software Projekte unter Verwendung einer so spezifischen Sprache? Oder (und in diesem Fall gehören Sie einer Mehrheit an) erlauben Sie nach wie vor die Verwendung von nicht definierten, ungenauen Wörtern, um ihre kritischen Objekte zu beschreiben? Wenn dem so ist, dann ist keine Kontrolle möglich, und das Software-Engineering liegt in der Hand von Whizz-Kid-Superprogrammierern. Viel Glück! Sie werden es brauchen können.

Übrigens: Selbst wenn Sie alles korrekt spezifizieren, dann ist das Finden geeigneter Lösungen immer noch keine leichte Aufgabe. Das Problem ist mit der Spezifikation von Attributen nicht gelöst, sondern erst definiert.

Zur Notion der Kontrolle über mehrere Dimensionen fehlen meiner Ansicht nach Kommentare in der Literatur, speziell in der Literatur über Software-Engineering. Das gilt besonders für Einheiten, mit denen der Status eines geplanten Designs hinsichtlich aller kritischen und meßbaren Anforderungen gleichzeitig eingeschätzt werden kann.

Das überrascht kaum, weil die meisten Menschen, wie bereits erwähnt, nach wie vor mit meßbaren Notionen der Software-Qualität zu kämpfen haben. Wenn man es aber als normal ansieht, daß Kosten Nutzen Anforderungen vollständig definiert werden, dann wird auch der Bedarf nach einem Werkzeug für die Evaluation der Fortschritte im Design in Richtung aller Anforderungen klar.

Software-Anforderungen quantifizierbar machen

Entscheidenden Input bekam ich allerdings durch die Arbeit von Barry Boehm, der 1974 eine "Requirements Properties Matrix" vorstellte, mit deren Hilfe die Beziehung zwischen Design Lösungen und Anforderungen erfaßt werden kann. Dabei handelt es sich um eine nicht-numerische Beziehungstabelle.

Diese Tabelle habe ich später in eine quantifizierte Form gebracht (sowohl im Hinblick auf Anforderungen wie auf die Qualität der technologischen Lösungen). Ich bezeichne die neue Tabelle mit dem Begriff "Wirkungseinschätzung". Erst kürzlich ging mir auf, daß es sich dabei lediglich um ein Werkzeug für einen Überblick handelt.

Wichtig sind folgende Punkte: Sie müssen die Anforderungen quantifizieren, mit denen Sie Ihr Design in Übereinstimmung bringen wollen. Quantifizieren müssen Sie auch den Beitrag, den Ihr Design in bezug auf die Anforderungen bringt. Außerdem müssen Sie ein formales Verhältnis gegenüber den Beweisen haben, mit denen Sie Ihre Einschätzung untermauern wollen.

Im Software-Engineering und den meisten Büchern zu diesem Thema werden diese Notionen nicht genutzt. Ich kann hierbei keine Ausnahme nennen, was sicherlich an meiner Unkenntnis in diesem Zusammenhang liegt. Um ein Arbeitsmittel zu finden das in Kürze das Design darstellen kann, haben wir seit kurzem die Religion des Protyps angenommen.

Entwürfe bedürfen einer Wirkungs-Einschätzung

Wenn ein Prototyp von einer Person an einem Tag erstellt werden könnte und uns Informationen über alle wichtigen Punkte - über Leistung, Portabilität, Verfügbarkeit, Zuverlässigkeit, Wartungsfreundlichkeit Sicherheit und Kosten - liefern könnte, so wäre das zwar schön, ein Prototyp wäre das aber nicht.

Im besten Fall erhalten wir einige Einblicke: und es erfordert nicht soviel Aufwand, wie das ganze Ding zu bauen.

Ich bin darauf gekommen, die Tabelle zur Wirkungseinschätzung zu benutzen, wenn ich eine sofortige Auswertung von Design-Ideen benötige. Das aus erhalte ich mehr Informationen als von einem Prototyp - und das bei geringeren Kosten. Gern gebe ich zu, daß ein Prototyp unter Umständen bessere Information über spezielle Attribute liefern kann - allerdings zu weitaus höheren Kosten. Was noch wichtiger ist: Die Wirkungseinschätzung zwingt die Designer dazu, ihre Vermutungen untereinander in numerischer Form auszutauschen.

Um realistische Feedbacks zu erhalten, ohne gleich das ganze System zu bauen, verlasse ich mich auf eine frühe schrittweise Auslieferung. Dabei erziele ich viele der wirtschaftlichen Vorteile des Prototypings und zusätzlich den Vorteil, daß ich echte Reaktionen und verwendbare Informationen erhalte.

Die schrittweise Auslieferung gibt uns auch mehr zuverlässige Informationen über die Wirkung verschiedener komplexer Technologien durch eine Interaktion zwischen Technologie und Mensch. Während der schrittweisen Abläufe vorgenommene Messungen ermöglichen uns eine weitaus genauere Einsicht in die benötigten und erreichbaren Qualitätsebenen, die Effizienz der Design-Ideen und die realen Kosten der Realisierung von Anwender-Anforderungen als das Prototyping.

Ich baue auch Prototypen schrittweise und simuliere tatsächlich bestehende Systeme auf die gleiche Art. Prototyping muß als Bereich mit schrittweisen Notionen in die Abläufe integriert werden. Die Existenz von Prototyping Werkzeugen ohne ein Verständnis einer schrittweisen Alternative (die keine solchen Werkzeuge erfordert), hat die breite Auswahl, der die Software-Ingenieure ausgesetzt sind, nicht gerade einfacher gemacht

Wir kämpfen noch damit, einfache Notionen der statistischen Ablaufkontrolle und der Inspektion aus dem Jahre 1920 zu lernen. Und dieser Kampf wird noch einige Jahre dauern. Reifere Ingenieure, wie bei AT&T, haben eine Möglichkeit gefunden, Qualität und Kosten zu kontrollieren: Statt einfach Programmfehler zu bekämpfen, wird das System so ausgelegt, daß es keine Fehler hat oder Fehler automatisch behebt.

Qualität muß im voraus spezifiziert werden

Das bedeutet, daß Sie eine spezifizierte Ebene der Zuverlässigkeit anvisieren und das System dann so entwickeln, daß es diesen Anforderungen entspricht. Sie können jedes der Attribute festlegen (aus dem Kosten oder dem Qualitätsbereich) und dann in diese Richtung entwickeln oder auch - mit größeren Schwierigkeiten verbunden - gleich nach mehreren Kriterien entwickeln. Allerdings wird in unserer Branche allgemein davon ausgegangen, daß jeder Versuch der Entwicklung nach mehr als einem Kriterium gleichzeitig Fehler begünstigt.

Solange alle Software-Ingenieure gleich inkompetent sind, gut bezahlt und sehr gesucht, stellt sich die Frage, welche Motivation sie für Änderungen oder Verbesserungen haben könnten. Trotzdem werden diese Änderungen stattfinden, wenn auch vielleicht quälend langsam.

Seit 40 Jahren beklage ich, daß wir so wenig Fortschritte gemacht haben. Aber vielleicht werden sich die Fortschritte mit einem schärferen Mitbewerb auf dem Markt beschleunigen. Denn Software wird zum entscheidenden Element auf diesem Markt. In diese Richtung geht die Entwicklung nun einmal. Dieses Papier will auf einige sinnvolle Ansätze hinweisen für den Fall daß, Sie eines Tages zu denen gehören sollten, die einem schärferen Mitbewerb ausgesetzt sind. Heben sie es gut auf. Sie könnten es noch vor Ihrer Pensionierung brauchen!

Vielleicht ist Ihre Reaktion ja auch positiv nach dem Motto: Der Bedarf ist da, ich bin bereit. Nur muß ich noch mein kulturelles Umfeld davon überzeugen. Schön, willkommen bei der Revolution. Lassen Sie mich Ihnen noch einige praktische Ratschläge zu der Frage geben: "Wie kann ich das nächste Mal mein Softwareprojekt besser managen?"

1. Probieren Sie alles selbst.

2. Überzeugen Sie durch Resultate und nicht durch mehr oder weniger rationale Argumente.

3. Arbeiten Sie immer in Richtung auf klar meßbare Ziele.

4. Gehen Sie schrittweise vor.

5. Verwenden Sie die statistische Ablaufkontrolle in bezug auf alle Produkte: Der Name hierfür ist Fagan´s Inspection.

6. Entwickeln Sie in Richtung Ihrer Kosten- und Qualitätsziele: schlagen Sie sich nicht dorthin durch.

7. Fangen Sie Fehler frühzeitig ab. Korrigieren Sie sie ebenso früh - vor allem im Design und in den Anforderungen.

8. Konzentrieren Sie sich auf Menschen, Motivationen und Unternehmen und nicht auf Werkzeuge, Strukturen, Methoden und Programmiersprachen

9. Kontrollieren Sie alle kritischen Faktoren und nicht nur einige.

10. Wenn diese Ratschläge nicht helfen, dann haben Sie nicht verstanden, was ich Ihnen vermitteln wollte. Versuchen Sie es noch einmal. Haben Sie Geduld. Auch ich befinde mich in einem ständigen Lernprozeß. Das hier ist eine Revolution! Und nicht alle Revolutionen sind unblutig.

Vergewissern Sie sich außerdem, daß über die Meßmethoden aller kritischen Erfolgsfaktoren Übereinstimmung herrscht. Wechseln Sie unbedingt sofort zur schrittweisen Methode. Überprüfen Sie Anforderungen und Design von oben nach unten. Verwenden Sie aktuelle Daten, um die Ablaufe zu verbessern. Und lassen Sie Ihre Mitarbeiter ihre eigenen Abläufe verbessern.

*Tom Gilb, arbeitet als internationaler Software-Berater in London und Oslo.

Eine Ankündigung jagt die andere

Möglicherweise ist das, was IBM vom Datenbankmarkt übrig läßt, noch nicht so endgültig verteilt, wie Oracle-President Larry Ellison das gern hätte. Der kalifornische Software-Anbieter reagierte jedenfalls auffallend nervös, als Sybase die vierte Version seines "SQL Server" vorstellte: Ungeachtet der Tatsache, daß die vor anderthalb Jahren angekündigte Version 6.0, so hartnäckige Branchen-Gerüchte, immer noch eine ganze Reihe von Bugs aufweist, stellte Oracle jetzt eine Version 7 in Aussicht, die enthalten soll, was Sybase schon für sein Release 4.0 reklamiert, nämlich referentielle Integrität und Two-Phase-Commit-Protocol. Nichtsdestoweniger hat Oracle dem Konkurrenten Essentielles voraus; Seine Verkäufer gehen bei den Entscheidern der Großunternehmen ein und aus. Ganz böse Zugen behaupten allerdings, diese Klientel hätte ihre Erwartungshaltung an IBM geschult, will sagen, sie sei schon froh, wenn ein Produkt zunächst nur halbwegs funktioniere.