Programmierer schöpfen anscheinend grundsätzlich jeden Speicher restlos aus:

Devise: Quantifizieren und Qualität sichern

30.04.1981

1968 versammelten sich in Garmisch Experten aus allen DV-Bereichen zu einer NATO-Tagung mit dem bewußt provokativen Titel "Software-Engineering". Man war sich einig, daß etwas unternommen werden müsse gegen die offenkundige "Software-Krise" (auch ein Schlagwort aus jenen Tagen). Mit dem neuen Begriff Software-Engineering - Engineering bedeutet bekanntlich "Planung, Entwurf, Konstruktion und Management von technischen Produkten" - wollten die Veranstalter das Augenmerk auf die unzulänglichen Herstellungspraktiken für das technische Produkt Software lenken.

Vieles ist durch Garmisch initiiert worden: regelmäßige internationale Konferenzen (die fünfte dieser Folge fand kürzlich in San Diego statt), Fachzeitschriften, Bücher und Arbeitskreise (beispielsweise IEEE on Software-Engineering, Special Interest Group of the ACM). Zahlreiche Methoden und Techniken wurden in den folgenden Jahren veröffentlicht, manche mit den Verheißungen eines Allheilmittels angepriesen.

Ein paar Beispiele: "Strukturierte Programmierung reduziert die Kosten um mindestens 30 Prozent", "Programmierautomaten machen binnen kurzem die Programmierer arbeitslos", "Detaillierte Standards ausreichend für das Software-Management". Die Problemlisten und Fragen-Kataloge von Garmisch haben jedoch kaum etwas von ihrer Aktualität eingebüßt. Die großen Erwartungen der frühen 70er Jahre wurden enttäuscht; der für den Praktiker sichtbare Fortschritt war relativ gering. Warum?

Software ist ein sehr junges Arbeitsgebiet, das sich ungeheuer schnell ausweitet. Relativ wenigen Erfahrungsträgern stehen (zu?) viele Software-Neulinge gegenüber. Manche der Alteingesessenen meinen, ihre Position beruhe einzig auf ihrem Wissen um die traditionellen Entwicklungspraktiken; Neuem stehen sie somit recht zurückhaltend bis ablehnend gegenüber.

Hasen oft zu alt - Neulinge oft zu grün

Es fehlt an Ausbildungsmöglichkeiten. Wo kann man Software-Technologie studieren? Wo läßt sich das gesicherte Basiswissen über Software nachschlagen, lassen sich die Regeln der Kunst nachlesen? Hochschulen konzentrieren sich auf den Software-Wissenschaftler, Informatiker genannt. Veranstalter von öffentlichen Seminaren dagegen reduzieren Software-Engineering auf Software-Management und das wiederum auf die Einführung von Entwicklungsphasen.

Ein weiterer wesentlicher Punkt ist die grundsätzliche Unterschätzung der Komplexität von Software. Wie sagte doch Weizenbaum: "Der Programmierer ist ein Schöpfer von Welten, deren alleiniger Gesetzgeber er ist. In Form von Programmen kann er ein Universum von prinzipielI unbegrenzter Komplexität erschaffen."

Software kennt keine physikalischen Schranken. Es scheint keine scharfen, durch Naturgesetze definierten Grenzlinien zu geben. Die Entwicklungsmethoden der frühen Jahre setzten zudem erst beim Codieren ein; die fundamentalen und damit teueren Fehler werden jedoch bekanntlich viel früher, meist schon bei der Definition der Anforderungen gemacht.

Schließlich sei noch der zwangsweise langsame Technologietransfer erwähnt. Die meisten Methoden wurden im Stadium "prinzipielle Lösunggefunden" veröffentlicht. Von da an ist es noch ein weiter Weg bis zur ersten Laborerprobung. Der Praktiker interessiert sich für eine Methode aber erst, wenn nach einem erfolgreichen Projekteinsatz Erfahrungen vorliegen, die auf seine Verhältnis übertragbar sind.

Die Diskrepanz zwischen den Verheißungen und dem tatsächlichen Fortschritt in der Vergangenheit sollte allzu große Erwartungen für morgen dämpfen. Doch nun zu den vor uns liegenden Jahren. Vor welchen Herausforderungen stehen die Software-Entwickler? Welche Lösungsansätze bietet der derzeitige Stand des Software-Engineering?

Da ist zunächst die Mikroelektronik mit stetem Preisverfall und immer mächtigeren Bauelementen. Dies lockert sicherlich die harten Speicherplatzbegrenzungen und andere Hardware-Zwänge. Aber nur ein wenig! Programmierer schöpfen anscheinend grundsätzlich jeden Speicher restlos aus. Mehr und mehr Software wird in integrierte Schaltkreise "eingefroren".

Aus Software- wird Systems-Engineering

Diese Software-Chips stellen extreme Anforderungen an Korrektheit und Zuverlässigkeit der Programme. Ein ROM kann man nicht patchen; ein häufiges Auswechseln verbietet sich allein schon aus Kostengründen. Hier müßten eigentlich die großen Fortschritte auf den Gebieten des Konstruierens von fehlerfreien Programmen und des Korrektheitsbeweises voll zum Tragen kommen.

Die Mikroelektronik macht die bislang eindeutige und scharfe Trennlinie zwischen Hard- und Software zur Grauzone. Die optimale Verteilung der Funktionen auf Hard- und Software zwingt die Entwickler zum Blick über den Zaun; Software-Engineenng weitet sich im Richtung Systems-Engineering. Die billige Hardware ermöglicht einer breiten Bevölkerungsschicht die Benutzung von programmgesteuerten Geräten. Eine laiengerechte Mensch-Maschine-Schnittstelle wird zu einem wichtigen Verkaufsargument. Mit ihren zahlreichen neuen Erkenntnissen leistet hier die Benutzerforschung Hilfestellung.

Diese Einfachheit nach außen erkauft man sich jedoch mit einer erhöhten Komplexität der darunter liegenden Software. Somit bleibt der Ruf nach Methoden, Techniken und Werkzeugen, um die offensichtlich stetig zunehmende Komplexität zu beherrschen!

Die zweite große Herausforderung ist der Mangel an Programmierern. Laut Business Week fehlen in den USA derzeit 50 000 Software-Fachleute, bis 1990 sollen es gar 1,5 Millionen werden. Die beste Abhilfe wäre ein praxisnah lehrbares und lernbares Software-Engineering als theoretisch fundiertes und allgemein anerkanntes Fundament. Die ACM veröffentlichte kürzlich einen Vorschlag für eine Art Aufbaustudium.

Mathematik auch für den Praktiker

Er enthält auch Vorlesungen über Betriebswirtschaft, Psychologie, Benutzerforschung, technische Dokumentation, Kommunikationstechniken, Datenschutz und Ergonomie. Ein Studiengang "lnformatik für Ingenieure" könnte die erprobten Grundprinzipien des Software-Engineerings ebenso enthalten wie ballastfrei formulierte Erkenntnisse der theoretischen Informatik - auch der Praktiker wird sich an mathematische Formulierungen gewöhnen müssen.

Die vermutlich größte Herausforderung sind die lawinenartig anschwellenden Kosten für die Entwicklung, insbesondere für die Wartung von Software. Wer Kosten in den Griff bekommen will, darf sich nicht mit qualitativen Aussagen zufriedengeben. Er muß versuchen, Software zu quantifizieren. Vielversprechende Schätzverfahren (beispielsweise die von L. H. Putnam) befinden sich auf dem Weg zum breiten Einsatz; das Interesse der Fachwelt beginnt derzeit sich auf die Quantifizierung von Software-Merkmalen zu konzentrieren.

Ein zweiter Ansatz liegt in einer Qualitätssicherung ähnlich wie bei herkömmlichen Produkten. Dort zählt der Markenname, also eine Firma. Programme sind immer noch weitgehend durch ihren Entwickler, also durch eine Person, qualifiziert.

Verfahren zur Unterstützung eindeutiger und überprüfbarer Anforderungsspezifikationen wollen das Kostenübel an seiner Wurzel anpacken, dort wo die Fehler üblicherweise gemacht werden, aber auch noch schnell und billig zu korrigieren sind. Schließlich sollte man die Software-Werkstatt nicht vergessen. Wie früher die Kinder des Schusters barfuß herumliefen, so arbeiten heute viele Programmierer mit unzulänglicher Rechnerunterstützung.

Der Arbeitsplatz eines Programmierers wird teuer! Isolierte kleine Abteilungen oder Kleinstfirmen werden es schwer haben, im Geschäft zu bleiben. Die Alternative heißt Software "von der Stange" oder "Maßkonfektion". Nach Business Week steigt in den USA der Umsatz von Standardpaketen jährlich um 32 Prozent.

Wohin geht also das Software-Engineering? Die Software dringt immer weiter zum Laien vor, eine wachsende Zahl von Produkten ist ohne komplexe Programme unverkäuflich. Kurzum, die Gesellschaft wird in mehrfacher Hinsicht Software-abhängig.

Damit steigt natürlich auch die Bedeutung von "Methoden, Techniken und Werkzeugen für die ingenieurmäßige Entwicklung und Wartung von qualitativ hochwertiger Software nach wirtschaftlichen Gesichtspunkten". Ob die derzeit erkennbaren Ansätze ausreichen, die Software-Problematik wenigstens zu entschärfen, bleibt abzuwarten. Der Blick in die Vergangenheit sollte skeptisch stimmen.

*Dr. Ernst J. Feicht ist Abteilungsleiter im Unternehmensbereich Kommunikationstechnik der Siemens AG; er hält Seminare über methodische Software-Entwicklung bei der GES, Allensbach.