Der Stolz der Rocky Mountains sollte er werden, der neue internationale Flughafen von Denver (Colorado). Er bedeckt doppelt soviel Fläche wie Manhattan, ist zehnmal so breit wie der verkehrsreichste europäische Flugverkehrsknoten London-Heathrow und bietet drei Passagiermaschinen gleichzeitig Gelegenheit zum Landen – und das auch bei schlechtem Wetter (Bild 1 oben).

Noch eindrucksvoller ist das unterirdische Gepäcktransportsystem. Wie intelligente Loren verkehren 4000 unabhängige "Telecars" auf 35 Kilometern Stahlschienen zwischen Abfertigungsschaltern, Gates und Gepäckausgaben von 20 verschiedenen Fluglinien. Ein Zentralnervensystem aus rund 100 Computern, die untereinander und mit 5000 elektronischen Augen, 400 Funkempfängern und 56 Strichcode-Lesegeräten vernetzt sind, sorgt für die sichere und pünktliche Ankunft aller Koffer, Reisetaschen und Skiausrüstungen.

So war es jedenfalls geplant. Seit einem Jahr wird dieser Gulliver von Lilliputanern bewegungsunfähig gehalten: von Fehlern in der Software, die das automatische Verteilersystem steuern soll (Bild 1 unten). Vorgesehen war der Start für November vergangenen Jahres. Doch dann wurde die große Eröffnungsfeier auf Dezember verschoben, damit die Firma BAE Automated Systems die bösen Kobolde aus ihrem 193 Millionen Dollar teuren System verscheuchen konnte. Aus Dezember wurde März; aus März wurde Mai. Die Aktienkurse des Unternehmens stürzten auf lächerliche Werte, während die anfallenden Betriebskosten und Zinszahlungen täglich 1,1 Millionen Dollar vom Budget zehrten. Im Juni mußten die Flughafenplaner eingestehen, daß sie nicht voraussagen konnten, wann das Gepäcksystem zuverlässig genug sein werde, um endlich den Flugbetrieb zu ermöglichen.

Für erfahrene Software-Entwickler ist dieses Debakel eigentlich nur bemerkenswert, weil es unter den Augen der Öffentlichkeit stattfindet. Einschlägigen Studien zufolge kommen auf je sechs neu in Betrieb gehende große Programmkonvolute zwei andere, die abgebrochen werden.

Das durchschnittliche Entwicklungsprojekt überzieht seinen Planungsrahmen um 50 Prozent; bei ehrgeizigeren ist es meistens noch schlimmer. Und etwa drei Viertel aller komplexen Software-Systeme funktionieren am Ende nicht wie gedacht oder werden gar nicht erst eingesetzt (Bild 2).

Das ist der Stand der Technik in einem Gewerbe, das immerhin seit 50 Jahren betrieben und stetig fortentwickelt wird. Bereits nach den ersten 25 Jahren hatten die Schwierigkeiten, umfangreiche Produkte zu erstellen, so bedrohliche Ausmaße erreicht, daß der Wissenschaftsbeirat der NATO die Krise der Software ausrief und im Herbst 1968 rund 50 hochrangige Programmierer, Informatiker und Unternehmensvorstände zusammenrief, um nach Abhilfe zu suchen.

Die Experten sahen sich dazu zwar außerstande, aber immerhin gaben sie dem Ziel einen Namen: software engineering; es ist heute offiziell definiert als "die Anwendung eines systematischen, disziplinierten und quantifizierbaren Ansatzes für Entwicklung, Einsatz und Pflege von Software".

Ein Vierteljahrhundert später ist Software Engineering in diesem anspruchsvollen Sinne immer noch ein Wunschtraum. Der allergrößte Teil der Computerprogramme wird nach wie vor individuell gefertigt: Programmierer fügen den Code aus Rohmaterial elementarer Programmiersprachen zusammen, nach Verfahren, deren Effekte sie nicht messen und die sie nicht zuverlässig reproduzieren können.

"Wir sind auf dem Stand des Büchsenmacherhandwerks vor Eli Whitney", urteilt Brad J. Cox von der George-Mason-Universität in Fairfax (Virginia). Der amerikanische Ingenieur Whitney (1765 bis 1825) ist berühmt geworden dafür, daß er die Massenfertigung – zuerst von Musketen – aus austauschbaren Teilen in den USA einführte. "Vor der industriellen Revolution", so Cox, "ging es bei der Produktion von Gütern kaum um Austauschbarkeit, sondern um ein Maximum an nicht-spezialisierter Handwerkskunst. Wenn wir diese Software-Krise je überwinden wollen, dürfen die Programmierer nicht mehr jedesmal das Rad neu erfinden."

Das ist freilich Schwarzmalerei aus didaktischen Gründen. Bloße Intuition weicht tatsächlich allmählich der Analyse; Programmierer verwenden inzwischen häufiger quantitative Qualitätsmaße für ihre Produkte, um den Herstellungsprozeß zu verbessern. Wissenschaftler bieten dafür solidere mathematische Grundlagen, indem sie Programmentwürfe in algebraische Form umsetzen, was hilft, schwerwiegende Fehler zu vermeiden. Informatik-Professoren machen sich neuerdings Gedanken darüber, warum es ihnen bisher mißlang, genügend viele gediegen ausgebildete Fachleute heranzuziehen. Wohl am bedeutsamsten ist, daß die Industrie zunehmend Technologien und Marktstrukturen für Software aus austauschbaren, wiederverwendbaren Komponenten fordert.

Allerdings braucht eine Innovation aus der Forschung derzeit typischerweise nicht weniger als 18 Jahre, bis sie zum Sortiment der Standard-Programmiertechniken gehört. In einer konzertierten Aktion könnte es jedoch zumindest in den USA Universitäten, Forschungsinstituten, Industrie und Regierung gelingen, die Software-Entwicklung noch in diesem Jahrzehnt auf das Niveau einer Ingenieursdisziplin zu hieven. Wenn nicht, wird der ungestüme Aufbruch der Gesellschaft in das Informationszeitalter ins Stocken geraten.

"Wir werden in den nächsten Jahren einen massiven Wandel [des Computereinsatzes] erleben, neben dem der Siegeszug des Personal Computers zur Bedeutungslosigkeit verblassen wird." So lautete die Abschlußerklärung von 22 führenden Softwareentwicklungsexperten aus Universitäten, Wirtschaft und Forschungsinstituten, die sich im April zur Erinnerung an die NATO-Tagung von 1968 und zu einer Analyse der Zukunft in Hedsor Park, einer Seminarstätte bei London, versammelt hatten. "Im Jahre 1968 wußten wir, was wir bauen wollten, aber konnten es nicht", sagte nachdenklich Cliff Jones von der Universität Manchester (England). "Heute stehen wir auf Treibsand."

Indem die Hardware-Ingenieure immer schnellere, billigere und kleinere Maschinen bereitstellen, untergraben sie rapide das Fundament der traditionellen Programmierpraxis. Mithin müssen die Programmentwickler Grundüberzeugungen wie die revidieren, daß es nun einmal hinzunehmen sei, wenn ihre Produkte durchweg fehlerhaft sind. Bei zahlreichen Anwendungen habe man gar keine Chance nachzubessern, erklärt Mary M. Shaw, Professorin an der Carnegie-Mellon-Universität: Sie müssen auf Anhieb funktionieren.

Dabei läßt der Sog des Marktes nie nach. "Der Umfang fest codierter Anweisungen in Konsumartikeln verdoppelt sich alle zwei Jahre", bemerkt Remi H. Bourgonjon, Direktor der Abteilung Software-Technologie am Philips-Forschungszentrum in Eindhoven (Niederlande). Nach seiner Abschätzung stecken in einem Fernseher derzeit schon bis zu 500, in einem Elektrorasierer 2 Kilobyte Software und in der Motorsteuerung eines neuen Autos von General Motors 30000 Programmzeilen.

Es ist indes bei allem Bemühen schwierig, einen komplizierten Satz von Befehlen gleich beim ersten Mal richtig zu schreiben. Das amerikanische Verteidigungsministerium etwa pflegt verständlicherweise die Zuverlässigkeit von Software, von der das Gelingen einer militärischen Aktion abhängt, mit sehr strengen – und teuren – Verfahren zu überprüfen. Auch der Satellit Clementine hatte, als er im Frühjahr in eine Mondumlaufbahn gebracht wurde, diesen Check bestanden; eine seiner Hauptaufgaben war der Test einer Zielerfassungs-Software, die für ein weltraumbasiertes Raketenabwehrsystem eingesetzt werden könnte. Aber bei dem Manöver, den Mond ins Visier zu nehmen, bewirkte ein Programmierfehler, daß die Steuerdüsen elf Minuten lang ununterbrochen in Betrieb blieben, bis aller Treibstoff verbraucht war und der Satellit orientierungslos heftig rotierte. Das geplante wissenschaftliche Projekt – ein Rendezvous mit dem Asteroiden Geographos – mußte aufgegeben werden.

Fehler in Echtzeitsystemen wie dem von Clementine sind deswegen schwer zu lokalisieren, weil sie oft nur unter ganz bestimmten Bedingungen auftreten (Spektrum der Wissenschaft, Januar 1993, Seite 64). "Es ist noch unklar, ob sich die gegenwärtigen Verfahren für das Erstellen sicherheitskritischer Software, zum Beispiel für Kernkraftwerke oder Automobile, weiterentwickeln und in höhere Größenordnungen übertragen lassen", warnte Gilles Kahn, wissenschaftlicher Direktor des französischen Forschungslabors INRIA, auf dem Treffen in Hedsor Park. "Ich glaube sogar, daß wir bei Echtzeitsystemen eine Art Schallmauer erreicht haben."

Auch die enorm zunehmende Nachfrage nach verteilten Systemen – Programmen, die kooperativ auf vielen miteinander vernetzten Rechnern ablaufen – zeigt die Grenzen der bisherigen Entwicklung auf. In der Hoffnung, sie wettbewerbsstrategisch einsetzen zu können, investiert die Wirtschaft dafür große Summen.

Zwar sehen die Ziele zunächst täuschend einfach aus: Es geht lediglich darum, veraltete Großrechner-Software für Netzwerke umzuschreiben beziehungsweise existierende Programme untereinander oder mit neuen Systemen zu verbinden, so daß man verstreute Daten austauschen kann und Zugang zu den jeweils besten Benutzerschnittstellen gewinnt. Im Fachjargon wird das oft als Systemintegration bezeichnet. Aber Brian Randell, ein Informatiker an der Universität von Newcastle upon Tyne (England) weiß ein besseres Wort dafür: "Bei der britischen Luftwaffe sagte man ,to graunch', wenn es darum ging, etwas zusammenzuwürgen, also mit roher Gewalt passend machen."

Das ist ein riskantes Geschäft; denn obwohl Software auf den ersten Blick ein sehr gefügiges Material zu sein scheint, sind die meisten Programme spröde logische Gebilde, die nur Daten und Aufgaben der richtigen Art tolerieren. Wie handgemachte Musketen können zwei Befehlssätze durchaus ähnliche Funktionen erfüllen und dabei doch völlig unterschiedlich aufgebaut sein. Entsprechend schwer ist es, Software zu modifizieren und zu reparieren; und ein Versuch, zwei solcher Systeme übereinzubringen, kann bald in graunching übergehen.

Die kalifornische Kraftfahrtbehörde (Department of Motor Vehicles, DMV) beschloß 1987, bis 1993 ihr Kraftfahrzeug- und ihr Führerscheinregister zu vereinigen, damit die Bürger die dort übliche Erneuerung der Papiere mit einem Gang erledigen könnten – eine scheinbar einfache Aufgabe. Doch als das DMV im vergangenen Dezember feststellte, daß die geschätzten Kosten sich mehr als versechsfacht hatten und der freundliche Service gleichwohl frühestens 1998 zu leisten sei, brach es das Projekt ab. Die verlorene Investition betrug 44,3 Millionen Dollar.

Manchmal resultieren die schlimmsten Fehlschläge gerade aus Erfolgen. In den siebziger Jahren entwickelte American Airlines SABRE, ein genial konzipiertes, zwei Milliarden Dollar teures System zur Flugreservierung, das in der Reisebranche zu einem festen Bestandteil der Infrastruktur wurde. In der Absicht, auch in diesem Jahrzehnt mit einem eigenen, noch kundenfreundlicheren Dienstleistungsangebot den Markt zu dominieren, versuchte das Unternehmen, seine Flugbuchung mit den Hotel- und Mietwagen-Reservierungssystemen von Marriot, Hilton und Budget zu koppeln. Das Projekt endete 1992 in einer Flut von Schadenersatzprozessen. American Airlines mußte 165 Millionen Dollar als Verlust abschreiben.

Das sind keine Einzelfälle. Im Juni dieses Jahres veröffentlichte ein Beratungsgremium der IBM das Ergebnis einer Umfrage bei 24 führenden Unternehmen, die große verteilte Systeme entwickelt hatten: Davon kosteten 55 Prozent mehr als erwartet, 68 Prozent kamen den nicht termingerecht in Gang, und 88 Prozent mußten zu wesentlichen Teilen neu konzipiert werden.

Der Bericht machte keine Angaben zu einer besonders kritischen Frage: Wie zuverlässig waren die schließlich implementierten Programme? Oftmals brechen Systeme zusammen, weil ihre Schöpfer das Unerwartete nicht erwartet hatten. Netzwerke vergrößern die Probleme noch mehr. "Verteilte Systeme können aus einer großen Anzahl miteinander verbundener Fehlerquellen bestehen, von denen viele vor der Vereinigung nicht identifiziert worden waren", erklärt Randell.

Die Komplexität nimmt aber stetig zu. Die Rechenleistung der Hardware pro Mark verdoppelt sich etwa alle 18 Monate. In der Folge "wachsen die Software-Systeme um eine Größenordnung in zehn Jahren – in manchen Branchen schon in fünf Jahren", resümiert Bill Curtis, ein Berater des Instituts für Software Engineering an der Carnegie-Mellon-Universität in Pittsburgh (Pennsylvania). Um mit der Nachfrage Schritt zu halten, müßten die Programmierer ihren Arbeitsstil ändern: "Mit Zimmerleuten", spöttelt er, "kann man keinen Wolkenkratzer bauen."


Notruf

Wenn ein System so komplex wird, daß kein einzelner Manager es mehr in seiner Gesamtheit verstehen kann, bricht der traditionelle Entwicklungsprozeß zusammen. Die amerikanische Luftfahrtbehörde (Federal Aviation Administration, FAA) hat diese Erfahrung bei dem schon zehn Jahre währenden Versuch gemacht, ihr zunehmend veraltendes Flugsicherungssystem zu ersetzen.

Dem neuen "Advanced Automation System" (AAS) stellen sich alle großen Probleme der Datenverarbeitung der neunziger Jahre. Das Programm besteht aus mehr als einer Million Zeilen und ist auf Hunderte von Rechnern mit moderner, hochentwickelter Hardware verteilt. Es muß zu jedem Zeitpunkt binnen Sekunden auf unvorhersagbare Ereignisse reagieren – und schon ein winziger Fehler kann Menschenleben gefährden.

Für die Verwirklichung dieses technologischen Traums wandte sich die Luftfahrtbehörde an die Federal Systems Company von IBM, eine führende Software-Entwicklungsfirma, die inzwischen den Besitzer gewechselt hat. Die Vertreter der FAA erwarteten (verlangten aber nicht ausdrücklich), daß IBM Kosten und Dauer des Projekts mit den besten verfügbaren Verfahren abschätzen sowie die Anforderungen und das geplante Systemdesign durchmustern würde, um frühzeitig Mängel festzustellen, die man dann noch in wenigen Stunden statt Tagen beheben könnte. Vorsichtshalber kalkulierte die FAA mit einem Preis von etwa 500 Dollar pro Zeile Computerprogramm, dem Fünffachen des Durchschnittssatzes für ein wohlgeführtes Entwicklungsprojekt.

Nach einem Bericht externer Prüfer vom Mai dieses Jahres aber hatte die Firma "Kostenschätzung und Projektüberwachung mit ungeeigneten Daten betrieben, inkonsistent angewendet und die Ergebnisse regelmäßig ignoriert." Für die Luftfahrtbehörde wurde das ziemlich teuer – 700 bis 900 Dollar pro Programmzeile. Einen plausiblen Grund für diesen exorbitanten Preis hat die FAA selber in einem internen Bericht festgehalten: "Im Durchschnitt muß jede entwickelte Programmzeile einmal neu geschrieben werden."

Alarmiert durch die explodierenden Kosten und durch Testergebnisse, denen zufolge das halbfertige System unzuverlässig arbeitet, beschloß FAA-Chef David R. Hinson im Juni dieses Jahres, die Entwicklung zweier der vier Hauptkomponenten von AAS abzubrechen und einen dritten Teil im Umfang zu reduzieren. Die 144 Millionen Dollar, die für diese gescheiterten Programme ausgegeben wurden, sind aber eine Kleinigkeit im Vergleich zu den 1,4 Milliarden Dollar Kosten für den vierten und zentralen Teil: neue Workstation-Software für die Fluglotsen.

Aber auch diese Projektkomponente hat den Zeitplan um mehr als fünf Jahre und den Kostenrahmen um mehr als eine Milliarde Dollar überschritten. Experten der Carnegie-Mellon-Universität und des Massachusetts Institute of Technology in Cambridge sollen nun ein Urteil darüber abgeben, ob das Projekt überhaupt noch zu retten ist.

Solche Debakel würden zur Regel, wenn das Programmieren sich nicht zu einer Ingenieursdisziplin entwickelte, die fest in Mathematik und Naturwissenschaft verwurzelt ist. Immerhin geht der Trend in diese Richtung, nachdem in den letzten zehn Jahren wesentliche Fortschritte wenigstens dabei erzielt wurden, das Chaos eines Entwicklungsprozesses, die Fehlerhäufigkeit und die Stagnation der Arbeitsproduktivität konsistent und quantitativ zu bestimmen. Der nächste Schritt – die Suche nach praktikablen, reproduzierbaren Lösungen dieser Probleme – wird schon vorbereitet.


Lohn der Mühe

So publizierte das Software Engineering Institute 1991 sein Capability Maturity Model (CMM, etwa: Kompetenz-Reife-Modell). "Es bietet Aussicht auf hervorragende Qualität in Software Engineering und Management", schwärmt David Zubrow, Leiter eines Projekts über empirische Methoden an dieser vom Militär finanzierten Denkfabrik. CMM hat zumindest viele Programmierer davon überzeugt, daß sie ihren Arbeitsprozeß bewerten müssen – eine Grundvoraussetzung für jede industrielle Ingenieursdisziplin.

Mit Hilfe von Interviews, Fragebögen und dem CMM als Maßstab läßt sich beurteilen, inwieweit ein Programmierer-Team fähig ist, Software zu erstellen, die zuverlässig die Anforderungen des Kunden erfüllt. Das CMM verwendet eine Notenskala von 1 ("chaotisch") bis 5 ("vorbildlich"). Bis heute wurden 261 Organisationen evaluiert.

"Die große Mehrheit – etwa 75 Prozent – hängt immer noch auf Stufe 1", berichtet Curtis. "Sie verwenden keinen formalen Prozeß, verfolgen nicht kritisch, was sie tun, und haben keine Möglichkeit festzustellen, ob sie noch auf dem richtigen Weg sind." Von den verbleibenden erreichen 24 Prozent Stufe 2 oder 3.

Nur zwei Elitegruppen erzielten die höchste CMM-Note 5: das indische Programmiererteam des US-Konzerns Motorola in Bangalore und das Team von Loral (früher IBM) für die Bord-Software des Space Shuttle, das inzwischen sogar zuverlässig voraussagen kann, wie viele Fehler in der jeweils neuesten Version noch auftauchen dürften. Das ist ein bemerkenswerter Fortschritt; denn laut Capers Jones, dem Vorsitzenden von Software Productivity Research, protokollieren 90 Prozent der amerikanischen Programmierer nicht einmal, wie viele Fehler sie gefunden haben – und nur wenige unter denen, die es tun, finden seiner Einschätzung nach mehr als ein Drittel aller vorhandenen.

Tom Peterson, Leiter des Shuttle-Software-Projekts, schreibt den Erfolg seiner Gruppe der Strategie zu, "daß wir nicht nur einen Fehler korrigieren, sondern auch die Lücke im Testprozeß suchen, durch die er unentdeckt schlüpfen konnte". Zwar läßt sich Perfektion lediglich annähern. Der erste Start einer Raumfähre beispielsweise wurde 1981 abgebrochen und um zwei Tage verschoben, weil ein Programmfehler verhinderte, daß sich die fünf Bordcomputer korrekt synchronisierten; und ein anderer Schwachpunkt, diesmal im Rendezvous-Programm, gefährdete 1992 die Bergungsaktion für den Satelliten Intelsat-6. Aber eine Reihe führender Software-Unternehmen ist mittlerweile überzeugt, daß sich quantitative Qualitätskontrolle längerfristig auszahlt.

Die Geräte-Abteilung der US-Firma Raytheon etwa rief 1988 zu einer internen "Software Engineering Initiative" auf, nachdem sie beim CMM-Test durchgefallen war, investierte eine Million Dollar jährlich in die Verbesserung rigoroser Kontroll- und Testrichtlinien und in die entsprechende Schulung ihrer 400 Programmierer. Innerhalb von drei Jahren verbesserte sich die Abteilung um zwei Noten. Im Juni dieses Jahres waren die meisten Projekte – darunter komplexe Radar- und Flugleitsysteme – vor dem vereinbarten Termin abgeschlossen und blieben unter den kalkulierten Kosten. Die Produktivität hat sich mehr als verdoppelt. Die Analyse der eingesparten Überarbeitungskosten ergab eine Rendite von 7,80 Dollar für jeden in die Initiative investierten (Bild 4).

Beeindruckt durch solche Erfolge verlangt die amerikanische Luftwaffe jetzt, daß alle ihre Software-Entwickler bis 1998 die Note 3 erreichen. Auch die NASA soll eine ähnliche Politik in Erwägung ziehen.


Mathematische Nachbildung

Selbst der beste Entwurf kann schiefgehen, und Fehler werden sich einschleichen, solange Menschen Programme schreiben. Katastrophal wirken sich jedoch in der Regel nicht diejenigen aus, die frühzeitig entdeckt und ausgemerzt werden, sondern jene, die schon im Konzept stecken und unentdeckt bis ins Endprodukt geraten.

Die Hersteller von Software für den Massengebrauch, denen es nicht darum geht, einen einzelnen Kunden zufriedenzustellen, können sich Korrekturen auf archaische und rabiate Weise erlauben: Sie geben das mangelhafte Produkt erst einmal als sogenannte Beta-Version frei, damit experimentierfreudige Benutzer die Schwachstellen aufspüren. Charles Simonyi, ein Chefentwickler bei Microsoft, hat bekannt, daß 20000 Freiwillige die neue Version des Betriebssystems Windows beta-testen. Das ist für ein unsystematisches Verfahren zwar bemerkenswert wirksam, aber teuer und bestenfalls für PC-Programme geeignet, die weniger als 10 Prozent des amerikanischen Software-Marktes mit einem Volumen von 92,8 Milliarden Dollar ausmachen.

Die Forschung konzentriert sich deshalb auf Strategien, Unzulänglichkeiten frühzeitig zu entdecken oder von vornherein zu vermeiden. Ein Grundprinzip: Man rechne damit, daß sich die Aufgabe, die das System lösen soll, im Verlauf der Entwicklung immer wieder wandelt. Die Planer des Flughafens von Denver schoben Änderungswünsche zu Kosten von 20 Millionen Dollar nach, lange nachdem die Arbeiten am Entwurf des Gepäcktransportsystems begonnen hatten. In ähnlicher Weise revidierten die Verantwortlichen der FAA ihren Auftrag für das neue Flugsicherungssystem.

Einige Entwickler sind denn auch der Überzeugung, Software müsse eher wachsen und reifen als konstruiert werden. Sie entwerfen daher zunächst ein Prototyp-Programm aus standardisierten Komponenten, an dem – wie am Modell eines Architekten – Mißverständnisse zwischen Kunde und Auftragnehmer ausgeräumt werden können, ehe das logische Fundament gegossen wird.

Weil aber Prototypen nur das äußerliche Verhalten eines Systems imitieren, lassen sich damit kaum Inkonsistenzen in dem verschachtelten Gebilde selbst aufdecken. "Fehler in großen Software-Konvoluten sind größtenteils Unterlassungen", bemerkt Laszlo A. Belady, Direktor des Forschungslabors von Mitsubishi Electric. Und Modelle helfen überhaupt nichts mehr bei der Fehlersuche, sobald der Entwurf einmal in Code umgesetzt wird.

Wenn ein System absolut korrekt sein muß, sagt Martin Thomas, Chef der britischen Softwarefirma Praxis, kann man allein mit mathematischen Analysen sein Verhalten vorhersagen. Nur greifen die Techniken, mit denen sich Phänomene in der realen Welt beschreiben lassen, nicht in dem synthetischen binären Universum eines Computerprogramms; hier regiert die diskrete, weitaus weniger ausgereiftes Mathematik. Aber mit den – relativ unhandlichen – Hilfsmitteln der Mengenlehre und des Prädikatenkalküls hat man Verfahren entwickelt, Anforderungen und Programme in die Sprache der Mathematik zu übersetzen, so daß man sie mit formalen Methoden zu analysieren vermag.

Die Firma Praxis hat das kürzlich bei einem Projekt für ein Flugleitsystem der britischen Zivilluftfahrtbehörde getan. Obwohl es wesentlich kleiner ist als das der FAA, war ein ähnliches Entwurfsproblem zu lösen: ein Reservesystem in jedem Moment auf demselben Stand wie das Hauptsystem zu halten, damit es bei dessen Versagen auf der Stelle einspringen kann. "Die größte Schwierigkeit bestand darin sicherzustellen, daß Nachrichten, die über ein doppelt ausgelegtes Netz laufen, in der richtigen Reihenfolge eintreffen", erläuterte Anthony Hall, ein Chefberater bei Praxis. Der Versuch zu beweisen, daß das Programm dies leisten würde, schlug fehl. Also wurde der Entwurf überarbeitet und korrigiert. Das System konnte daraufhin fristgerecht fertiggestellt werden und ging im Oktober 1983 in Betrieb.

Praxis benutzte formale Beschreibungen nur für die heikelsten Teile dieser Software, während andere Firmen im gesamtem Entwicklungsprozeß mathematische Strenge walten lassen. So setzt die GEC Alsthom in Paris eine Methode namens "B" für ein 350 Millionen Dollar teures Projekt ein, das die Weichen- und Geschwindigkeitssteuerung für die 6000 elektrischen Züge im Eisenbahnnetz Frankreichs auf den neuesten Stand bringen soll. Durch schnellere Verbindungen und dichtere Zugfolgen will die französische Eisenbahn sich Ausgaben in Milliardenhöhe für einen Ausbau des Streckennetzes ersparen.

Fraglos ist Sicherheit dabei eine zentrale Forderung. Deshalb formulierten die GEC-Entwickler den gesamten Systementwurf wie auch das endgültige Programm in einer formalen Beschreibung, um dann mit mathematischen Methoden deren Konsistenz nachzuweisen. "Funktionstests sind jedoch immer noch nötig", erklärte Fernando Mejia, Chef der Abteilung für formale Software-Entwicklung bei GEC: Erstens machen Programmierer gelegentlich auch Fehler bei den Beweisen; und zweitens können formale Methoden lediglich garantieren, daß die Software den formalisierten Anforderungen genügt, aber nicht, daß sie den Überraschungen der realen Welt gewachsen ist.

Ted Ralston, Direktor der strategischen Planungsabteilung von Odyssey Research Associates in Ithaca (New York), rechnet mit noch anderen menschlichen Schwächen. Das Überprüfen seitenlanger algebraischer Umformungen, räumt er ein, könne erheblich öder sein als selbst die Inspektion von Computerprogrammen. Um der Gefahr von Unaufmerksamkeit zu begegnen und die Mitarbeiter zu entlasten, versucht seine Firma wie etliche weitere nun, formale Methoden zu automatisieren. GEC Alsthom arbeitet mit der ebenfalls französischen Firma Digilog zusammen, um Programmierwerkzeuge für die "B"-Methode marktfähig zu machen; die Beta-Version des Systems wird von sieben Unternehmen und Institutionen getestet, unter anderen von dem Luft- und Raumfahrtkonzern Aérospatiale und der französischen Atomenergiebehörde sowie dem Verteidigungsministerium.

In den USA experimentiert zudem ein wachsender Kreis von Firmen mit dem sogenanten clean-room approach. Dabei versucht man, formale Beschreibungen, Korrektheitsbeweise und statistische Qualitätskontrollen mit einem evolutionären Ansatz für die Software-Entwicklung zu vereinen. Wie bei den namensgebenden Reinlufträumen der Mikrochip-Fertigung soll das Befolgen strenger Vorschriften gewährleisten, daß das Produkt schon beim ersten Einsatz perfekt arbeitet. Die Programmierer bauen ein System Funktion um Funktion auf und unterwerfen jede neue Komponente einer formalen Prüfung, bevor sie in die Gesamtarchitektur integriert wird.

Langsam wachsende statt stur nach einem ursprünglichem Konzept verfertigte Software verlangt ein gänzlich neues Vorgehen beim Testen. Herkömmlicherweise läßt der Entwickler sein Programm versuchsweise so ablaufen, wie es seiner Vorstellung nach benutzt werden soll – unter Bedingungen also, die oft nur entfernte Ähnlichkeit mit den Anforderungen der Praxis haben. Dagegen versucht der Programmierer beim Reinraum-Prozeß, jeder Folge von Aktionen, die ein Benutzer – ob richtig oder falsch – durchführen kann, eine Wahrscheinlichkeit zuzuweisen. Mit Hilfe dieser statistischen Daten konstruiert man Testfälle derart, daß die gebräuchlichsten Aktionsfolgen auch eingehender geprüft werden. Dann läßt man das Programm jeden Testfall durchlaufen und stoppt, wann ein Fehler auftritt. Diese Zeitspannen werden dann in guter Ingenieursmanier in ein Modell übernommen, das daraus die Zuverlässigkeit des Programms berechnet.

Die ersten Anwender melden ermutigende Ergebnisse. Der schwedische Telekommunikationskonzern Ericsson verwendete Reinraum-Prozesse bei der Entwicklung eines Betriebssystems für seine Telephonvermittlungsrechner. Die Fehlerhäufigkeit reduzierte sich nach Angaben der Firma auf einen pro 1000 Programmzeilen; der industrielle Mittelwert liegt 25mal so hoch. Zudem schaffte das Team 70 Prozent mehr Zeilen pro Zeiteinheit als früher und erledigte die Tests doppelt so schnell.


Unsicherheiten

Ob solche Trends bereits in generellen Fortschritt umschlagen ist in der Branche umstritten. Für die USA konstatiert David A. Fisher vom National Institute of Standards and Technologie (NIST), der bundesstaatlichen Normungsbehörde, daß inflationsbereinigt "die Wertschöpfung pro Programmierer in der Industrie seit 20 Jahren bei 40000 Dollar" liege. An Code, besagt hingegen eine kürzlich veröffentlichte Studie, produziere der durchschnittliche amerikanische Programmierer gegenwärtig doppelt soviel wie 1970.

Pro und Kontra sind schwerlich glaubwürdig zu belegen, denn weniger als 10 Prozent der amerikanischen Firmen wenden regelmäßig Leistungskontrollen an. Die Industrie hat dafür auch gar kein brauchbares Standardmaß, weil es immense Unterschiede in der Komplexität der Programmiersprachen und Probleme gibt. Ein schlichter Vergleich des Zeilen-Outputs eines japanischen und eines deutschen Programmierers, von denen der eine ein simples Sortierprogramm in C und der andere ein Flugsicherungssystem in Ada schreibt, würde nicht mehr besagen, als vergliche man ihre Gehälter, ohne von Yen in Mark umzurechnen. Außerdem überdecken individuelle Unterschiede die wesentlich geringeren Effekte der technischen und organisatorischen Innovation.

Nach 25 Jahren voller Enttäuschungen mit vorgeblichen Durchbrüchen, die nur für den Einzelfall galten oder sich nicht für größere Aufgaben adaptieren ließen, räumen viele Forscher ein, daß es so etwas wie experimentelle Informatik braucht, um allgemeingültige Ergebnisse von Zufallstreffern zu trennen. Bislang gibt es nur wenige Beispiele dafür. Wohl am erfolgreichsten ist das 1976 gegründete Software Engineering Laboratory, ein Konsortium des Goddard-Raumflugzentrums der NASA, der Computer Sciences Corporation und der Universität von Maryland in College Park. Dort haben fortgeschrittene Studenten und Programmierer der NASA an mehr als 100 Projekten zusammengearbeitet – freilich mit Blick auf unmittelbaren Praxisnutzen: Bei den meisten ging es um die Entwicklung von Bodenkontroll-Software für Satelliten.


Puzzles

Wenn schon nicht Räder als solche – Rädchen müssen immer wieder erfunden werden. Zwar kann man Software-Teile, wenn sie geeignet standardisiert sind, durchaus in unterschiedlichsten Kontexten wiederverwenden; seit Jahrzehnten benutzen Programmierer Bibliotheken von Unterprogrammen, um nicht immer wieder denselben Code neu schreiben zu müssen.

Aber diese Komponenten versagen mitunter, wenn sie von einer anderen Programmiersprache aus auf einem anderen Rechner oder unter einem anderen Betriebssystem aufgerufen werden. "Es ist doch tragisch, daß man die exzellente Implementierung eines Sortier-Algorithmus aus den sechziger Jahren wieder neu schreiben muß, nur weil die Hardware inzwischen veraltet ist", bemerkt Simonyi von Microsoft.

Probleme gibt es ebenfalls mit hochspezialisierten Teillösungen. Ehe Fisher im letzten Jahr zu NIST ging, war er Geschäftsführer der von ihm gegründeten Firma Incremental Systems. "Wir waren Weltspitze in drei der Technologien, die in einen Compiler eingehen, aber nicht so überragend bei den restlichen sieben", bekennt er. "Leider mußten wir feststellen, daß es keinen Markt für Compiler-Komponenten gibt."

Nun, bei der Normungsbehörde, versucht er etwas in dieser Richtung zu bewegen. Im April kündigte das NIST ein neues Technologieprogramm an, das die Etablierung eines Marktes für komponenten-basierte Software fördern soll. Als Leiter des Programms hat Fisher 150 Millionen Dollar für Entwicklungsarbeiten zu vergeben.

Die größte Aufgabe besteht darin, die Abhängigkeit der Programme von speziellen Computern und anderen Programmen aufzubrechen. Etliche aussichtsreiche Ansätze werden bereits verfolgt, so solche für eine einheitliche Sprache zur Beschreibung von Software-Komponenten, für Programme, die eine so formulierte Komponente an jede gewünschte Umgebung anpassen, und für Komponenten mit zahlreichen Eigenschaften, die der Benutzer nach Bedarf an- oder ausschalten kann.

Nach Fishers Vorstellung sollte ein Programmierer "im wesentlichen nur niederschreiben, wie etwas zu tun ist, anstatt es tatsächlich zu tun": Er sollte also ein Rezept produzieren, das jeder Computer umsetzen kann. "Wenn man dann zwei Komponenten zusammenfügen will, ruft man das Rezept auf und läßt zusammenpassende Versionen von beiden erzeugen, indem noch geeignete Elemente zu den Schnittstellen hinzugefügt werden. Das Ganze würde automatisiert ablaufen."

Ungeduldige Hoffnungen auf solch eine industrielle Revolution in der Software-Branche dämpft Fisher indes gleich selber: "In fünf oder sieben Jahren wird es bestenfalls vereinzelte Beispiele dieser Technologie geben – und auch das kann noch schiefgehen".

Brad Cox beschäftigte sich bereits mit Schwierigkeiten des künftigen Marktes. Bevor er seine Professur an der George-Mason-Universität versah, betrieb er eine Firma, die elementare Programmbausteine entwickelte. Aber wie Fisher kam er nicht auf seine Kosten – aus zwei Gründen: Die individuelle Anpassung der Komponenten für jeden Kunden war zu zeitaufwendig (eben dieses Hindernis hofft das NIST mit dem neuen Technologieprogramm zu überwinden), und die Käufer wollten nur einmal für eine Komponente bezahlen, sie jedoch beliebig oft kopieren. Dafür meint wiederum Cox die Lösung zu kennen.

Er stellt sich den Vertrieb von Software aller Art über Netzwerke vor, die nicht nur Produzenten und Endbenutzer verbinden, sondern außerdem Abrechnungsagenturen einschließen, die bei jedem Einsatz einer Komponente Tantiemen erheben. "Es ist wie ein Kreditkartensystem: ein großer Krake mit Armen, die in jeden PC hineinreichen."

Cox führt als weiteren bewährten Beispielsfall die Verwaltung und Vergütung musikalischer Urheberrechte an. Gleichwohl ist er sich im klaren darüber, daß das automatische Kassieren bei jeder Bewegung auf den avisierten Daten-Autobahnen eine radikale kulturelle Umwälzung wäre, und hat sich auf jahrelange geduldige Überzeugungsarbeit eingestellt. Als Plattform dient ihm die Coalition for Electronic Markets, deren Präsident er ist.

All diese Entwicklungen – industrielle Prozeßkontrolle, verbesserte technische Hilfsmittel und austauschbare Komponenten - werden freilich nur hinreichend qualifizierte Programmierer ins Werk setzen können, die zudem ein völlig neues Berufsverständnis entwickeln. "In vielen Branchen werden Menschen professionell Programme schreiben, aber sie lediglich als Werkzeuge verstehen", erwartet der Mitsubishi-Forschungsdirektor Belady, und das Auditorium in Hedsor Park pflichtet bei. "Ihre Arbeit werden sie als die Tätigkeit eines Architekten, Verkehrsplaners oder Filmproduzenten einschätzen."

Eine der entscheidenden Fragen ist, wie sich diese neue Expertenkaste rekrutieren soll. Auch in den pragmatischen Vereinigten Staaten bieten gegenwärtig erst 28 Universitäten Hauptstudiengänge für Software-Ingenieure an; vor fünf Jahren waren es sogar nur zehn. Und selbst Akademiker stimmen mit einem Praktiker wie Capers Jones darin überein, daß die Informatik-Lehrpläne im allgemeinen noch unzureichend auf die Anforderungen der Industrie eingestellt seien: "Grundlegende Dinge", so kritisiert er, "etwa wie man die Inspektion eines Programmcodes anlegt, ein Benutzerhandbuch erstellt und alte Software frischhält, werden nicht gelehrt". Die vielbeschworene Softeware-Revolution, so scheint es, wird eine langwierige Evolution.

Literaturhinweise

- Encyclopedia of Software Engineering. Herausgegeben von John J. Marciniak. John Wiley & Sons, 1994.

– Software 2000: A View of the Future. Herausgegeben von Brian Randell, Gill Ringland und Bill Wulf. ICL und die Kommission der Europäischen Gemeinschaften, 1994.

– Formal Methods: A Virtual Library. Von Jonathan Bowen. Hypertext-Dokument im World Wide Web, zu beziehen als http:/www.comlab.ox.ac.uk/archive/formal-methods.html.


Aus: Spektrum der Wissenschaft 12 / 1994, Seite 56
© Spektrum der Wissenschaft Verlagsgesellschaft mbH