Es ist allgemein bekannt, daß jede Datenverarbeitungsanlage nur das tut, war ihr ein eingegebenes Programm vorschreibt. Verantwortlich für richtige Ergebnisse, für übersichtlich gestaltete Ausdrucke - oder auch für das oft beklagte Gegenteil davon sind also, abgesehen von Funktionsfehlern der Anlagen, immer die Programme oder richtiger diejenigen, die die Aufgaben eines Programms definieren oder es hergestellt und geprüft haben. Die Programme sind daher von ganz entscheidender Bedeutung für die Brauchbarkeit der Datenverarbeitung für den Menschen. In den Anfängen der elektronischen Datenverarbeitung war das Herstellen der Programme noch ein maschinennahes Problem. Die Maschinen waren noch relativ langsam, die Speicher klein, und man konnte daher trotz der oftmals wenig benutzerfreundlichen Maschinenanweisungen die noch relativ kurzen Programme noch ohne große Mühe schreiben, verbessern und zum fehlerlosen Ablaufen bringen. Mit den ungeheuren Fortschritten, die die Datenverarbeitungstechnik seither gemacht hat, und mit dem daraus abgeleiteten enormen Anwachsen des Programmbedarfs haben sich die Probleme und Methoden der Software-Entwicklung entscheidend geändert. Dr. Gerhard Bretschneider, Siemens AG, München, verdeutlicht in diesem Beitrag die heutige Situation und zeigt gründliche Lösungen, mit denen die Software die von der Hardware gebotenen Möglichkeiten der Datenverarbeitung voll ausschöpfen kann.

Seit einer Reihe von Jahren besteht die Situation, daß das Herstellen von Programmen - oder der Software, wie man zusammenfassend sagt - in aller Welt der Engpaß der Datenverarbeitung ist. Zwar hat man auch auf dem Gebiet der Software-Entwicklung Fortschritte erzielt, zum Beispiel durch Entwicklung und Einführung umfangreicherer und für dem Menschen verständlicherer "höherer Programmsprachen" sowie durch verbesserte Programmiermethoden; aber das konnte nicht verhindern daß die Software-Technologie im Vergleich zur Hardware-Technologie eine geringere Weiterentwicklung erfahren hat. Die Entwicklung der Software-Technologie hat einen derart hohen Nachholbedarf, daß die Software heute den größeren Teil der gesamten Datenverarbeitungsaufwendungen bei Herstellern und Anwendern benötigt (Bild 1.)

Erschwerend kommt hinzu, daß trotz der hohen Aufwendungen - verbreitet Kritik an der Leistungs- und Modifikationsfähigkeit der Software geübt wird. Das geht so weit, daß die Software - entgegen ihrem Namen - vielfach als härter, das heißt schwerer änderbar, angesehen wird als selbst die Hardware. Diese Situation erfordert, daß der Software und ihrer Herstellung besondere Aufmerksamkeit gewidmet wird. Inzwischen hat man allgemein erkannt, daß "Software-Entwurf und -Programmierung" eine "komplexe technische Tätigkeit" ist, die "effektiv gesteuert werden muß". Es wurden auch schon merkliche Verbesserungen erzielt; ein entscheidender Durchbruch allerdings, das heißt der Übergang zu einem allseits befriedigenden Zustand auf diesem Gebiet, an dem alle - Anwende wie Hersteller gleichermaßen - interessiert sind, konnte bisher jedoch nicht erreicht werden.

Die Problematik der Software-Herstellung möge ein exemplarisch gewähltes Beispiel der Programmentwicklung - hier aus dem Gebiet der Anwenderprogrammierung (Bild 2) - verdeutlichen: Ein Auftraggeber möchte einen bestimmten Vorgang - ein "Problem" - mit Hilfe einer Datenverarbeitungsanlage gelöst sehen. Er sucht sich dazu einen Fachmann, bei einer komplizierten Aufgabe - die wir hier voraussetzen wollen -, ein Team, das seine Vorstellungen in ein realisierbares Konzept umsetzen soll. Die Aufgabenstellung für ein derartiges DV-Verfahren wird von den Anwendern zusammen mit Organisationsfachleuten in Form eines Grobkonzeptes festgelegt. Das setzt einen intensiven gegenseitigem Abstimmprozeß voraus. Hierfür müssen genügend Zeit und Aufwand eingeplant werden, denn Unklarheiten, die in dieser Phase verbleiben, können bei der Realisierung zu unpassenden Lösungen führen. Das Ergebnis wird als Grobkonzept so exakt wie möglich schriftlich festgehalten. Dadurch werden die Vorstellungen der Organisationsfachleute über die Wünsche des Auftraggebers oder auch dessen Vorstellungen deutlich und nachträgliche Verschiebungen rekonstruierbar.

Anschließend haben die Organisationsfachleute eine Leistungsbeschreibung auszuarbeiten, die vor dem Übergang zur nächsten Stufe nochmals mit dem Auftraggeber abgestimmt und schriftlich fixiert werden sollte. Dabei muß gesichert werden, daß alle Beteiligten - also auch der Auftraggeber - verstehen, was das zu realisierende DV-Verfahren später leisten wird und was nicht. Auf der Basis der Leistungsbeschreibung sind ein "Realisierungsentwurf" und ein "Feinkonzept" auszuarbeiten, die bereits die datentechnische Realisierung berücksichtigen müssen jedoch noch nicht die Umsetzung in Programmanweisungen.

Vor dem Beginn des eigentlichen Schreibens der Programmanweisungen - der Implementierung - ist es von Vorteil, zur nochmaligen Konzeptüberprüfung eine Systemsimulation zwischenzuschalten. In dieser Phase kann dem Auftraggeber die Funktion des zu realisierenden Systems modellhaft vorgeführt und durch ihn erprobt werden. Das ist vor allem bei Programmsystemen, die für den Auftraggeber größere organisatorische Veränderungen bringen, sehr zu empfehlen.

Erst jetzt ist das Feinkonzept in Programmanweisungen umzusetzen. Aus Gründen der Übertragbarkeit muß man zuerst die allgemeinere "Implementierungsstruktur" entwickeln und sie erst dann in die speziellen Maschinenanweisungen umwandeln. Dazu ist es erforderlich, das Team der Organisationsfachleute und Programmierspezialisten zu erweitern und die gesamte Arbeit in überschaubare Teilaufgaben zu trennen und an Programmiergruppen zu verteilen.

Für die Implementierung selbst gibt es bereits eine ganze Reihe sehr nützlicher Hilfsmittel, auf die später noch eingegangen wird. Ein besonderes Problem ist jedoch das Zusammenfügen der getrennt entwickelten Programmteile. Je sorgfältiger der Entwurf des zu entwickelten Programmsystems war und je exakter er beschrieben wurde, um so weniger Probleme ergeben sich später beim Zusammenfügen dieser Programmteile.

Betrachtet man den Vorgang des Entwickelns eines neuen Programmsystems noch einmal im Zusammenhang, so erkennt man, daß es mehrere Ebenen unerläßlicher Verständigung zwischen den verschiedenen Gruppen der Beteiligten gibt:

- Auftraggeber - Organisationsfachleute auf der Beschreibungsebene (fachliches Grobkonzept);

- Organisationsfachleute untereinander beim Entwickeln des Feinkonzepts. Mit Erläuterungen muß dieses Konzept auch dem Auftraggeber verständlich gemacht werden können;

- Organisationsfachleute - Programmiergruppen und Programmiergruppen untereinander;

- Programmierer - Datenverarbeitungsanlage.

Zum Bearbeiten des Programmsystems in all diesen Verständigungsebenen sowie zur Weitergabe der Informationen von einer Ebene an die folgenden bedarf es von Stufe zu Stufe mehr ins Detail gehender Unterlagen (Bild 2). Diese Unterlagen müssen, beim fachlichen Grobkonzept beginnend, einen zunächst schnell ansteigenden Abstraktionsgrad haben, der in Computernähe langsam wieder abfällt. Hierfür sind auf jeder Ebene speziell angepaßte Darstellungsformen, besonders auf der Entwurfsebene in Form "grafischer Pläne", unerläßlich. Das lehrt auch ein Vergleich mit den schon viel weiterentwickelten Entwicklungsverfahren in anderen Bereichen, zum Beispiel in der Gerätetechnik. Demzufolge verspricht der bei der Software-Entwicklung gemachte Versuch, durch Anwendung "höherer Programmiersprachen" - Sprachen, die zugleich dem Menschen und der Maschine verständlich sind - die Informationsaufbereitung für DV-Verfahren mit einem einzigen Verständigungsmittel erreichen zu wollen, wenig Erfolg.

Eine Konsequenz daraus ist die Verwendung grafischer Darstellungsformen, denn die verbale Beschreibung in natürlicher Sprache ist nicht präzis genug und eignet sich nur schlecht zum Beschreiben netzförmiger Abhängigkeiten - wie sie bei Programmsystemen die Regel sind.

Verbesserte Software-Entwicklung

Bei der Entwicklung von Hilfsmitteln für den geschilderten Programmentwicklungsprozeß konzentrierte man sich zunächst allgemein auf die Datenverarbeitungsanlage, also auf Programmierhilfen. Dabei war man - über die Jahre gesehen -auch recht erfolgreich.

Angefangen hat man mit den Programmiersprachen, das heißt den Anweisungen an die Datenverarbeitungsanlage, selbst. Ausgehend von den sehr schwerfälligen Maschinensprachen, entwickelte man zunächst symbolische Maschinensprachen, wie Assembler, dann "höhere, ablauforientierte Sprachen" (Cobol, Fortran, Algol, Basic, PL/1 und viele andere). Ihre Benutzungshäufigkeit ist jedoch heute noch geringer als die von Assembler. Zwar wird die Anwendung der höheren Sprachen in Zukunft auf Kosten der Assembler weiter zunehmen, aber das Entwicklungstempo auf diesem Gebiet hat sich in letzter Zeit doch deutlich verlangsamt. Aufgrund der gemachten Fortschritte gelten die Programmiersprachen nicht mehr als entscheidender Engpaß der Software-Entwicklung.

Das nächste Gebiet, dem man sich Ende der sechziger Jahre - als man erstmals von "Software-Engineering" sprach - zuzuwenden begann, war die Entwicklung der "Tools". Diese sollten die Programmierung über die Programmiersprachen hinaus unterstützen, also Hilfe bei der Manipulation der zu entwickelnden Programme, ihrer Darstellung, ihrer Dokumentation und der Auskunft über Programme sein. Dies ließ sich alles mit Unterstützung der Datenverarbeitungsanlagen durch speziell für diese Zwecke entwickelte Programme verwirklichen. Die Siemens AG bietet heute einen umfangreichen, ausgereiften und aufeinander abgestimmten Satz solcher "Tools" an, der die Programmierung bedeutend erleichtert und verbessert sowie den Aufwand verringert. Diese Tools werden weiterentwickelt und noch leistungsfähiger gemacht.

Seit zwei, drei Jahren wird jedoch deutlich, nicht zuletzt durch die schon erreichten Fortschritte bei der Programmierung, daß es erforderlich ist, den Software-Entwicklungsprozeß als Ganzes, also auch in den vorgelagerten Stufen, durch entsprechende Hilfen zu unterstützen, wenn man eine durchgreifende Verbesserung der Entwicklung von DV-Verfahren erreichen will.

So hat eine Analyse in den USA ergeben, daß mindestens 50 Prozent aller Software-Fehler, die bei der Endprüfung oder erst bei der Anwendung eines Programms auftreten, auf Fehler und Schwächen bei der Planung des DV-Verfahrens zurückzuführen sind. Dazu kommt noch, daß derartige Fehler meist besonders schwerwiegend sind und vielfach tiefgreifende nachträgliche Änderungen des entsprechenden Programms erfordern. Dadurch werden sie oft auch noch die Ursache zu weiteren Fehlern.

Grafische Darstellungsformen

Was kann hier Abhilfe schaffen? Es wurde schon darauf hingewiesen, daß eine klar abgegrenzte, in Phasen unterteilte Entwicklung und eine exakte Darstellungsform der Ergebnisse in einer den Phasen jeweils angepaßten Form unerläßlich sind. Es wurde weiter darauf hingewiesen, daß die natürliche Sprache zur exakten Beschreibung komplizierter Sachverhalte nicht ausreicht. Leider gibt es bisher keine allgemein eingeführten Verfahren, mit denen in der Software auftretende Abhängigkeiten - übersichtlich und exakt zugleich - zu erfassen sind. Doch gibt es eine Reihe von Vorschlägen und vielversprechenden Ansätzen.

Vorgeschlagen wurden einerseits Beschreibungen in Form abstrakter Sprachen und andererseits in grafischer Form. Abstrakte Sprachen haben mit den natürlichen Sprachen den Nachteil gemein, daß sie Abhängigkeitsbeziehungen im wesentlichen nur linear, gewissermaßen eindimensional, darstellen können und damit notwendigerweise unanschaulicher sein müssen als flächenhafte, grafische Darstellungen. Grafische Darstellungen - in anderen Gebieten der Technik als Pläne bezeichnet - sind für den Menschen verständlicher.

Als Beispiel für ein modernes grafisches Darstellungsverfahren, das sich für den Software-Entwurf besonders eignet, sei das Verfahren der Petri-Netze erwähnt (Bild 3). Ursprünglich aus rein wissenschaftlichem Interesse entwickelt, haben Petri-Netze für den Software-Entwurf in den letzten Jahren international Beachtung gefunden. Petri-Netze haben zwei unterschiedliche Typen von Knoten, "Zustände" und "Aktionen", und Kanten als gerichtete Verbindung von Knoten der einen Art zu Knoten der anderen Art. Erste Erfahrungen mit Petri-Netzen bei der Entwicklung von DV-Verfahren und deren übersichtliche Programmierung und Beschreibung sind sehr vielversprechend. Die von den Gesichtspunkten der Programmimplementierung unabhängigen Beschreibungen gestatten nicht nur ein statisches, sondern - was wichtig ist - durch Verschieben von "Marken" im Netz auch ein dynamisches Prüfen des Programmentwurfs. Petri-Netze gelten somit als gute Basis für ein allgemeines computerunterstütztes Entwurfsverfahren.

Ein weiteres Beispiel neuerer grafischer Verfahren ist mehr analytischer Art, also auf bereits vorhandene Programme anzuwenden. Mit ihm kann deren interne Vernetzungsstruktur - ausgehend von vorhandenen Programmen nachträglich automatisch transparent gemacht werden (Bild 4). Dabei läßt sich für ein ausgewähltes Programm die Verflechtung seiner Bausteine untereinander darstellen. Dieses Verfahren ist von besonderem Wert für unzureichend dokumentiertet, ältere Programme. Es kann daher bei der schwierigen Aufgabe, dem Aufarbeiten und Modernisieren des riesigen Bestandes an derartigen Programmen, eine entscheidende Hilfe sein.

Daneben gibt es noch eine Reihe weiterer brauchbarer Ansätze für Verfahren zur Unterstützung von Information und Dokumentation innerhalb und zwischen den zu Beginn erwähnten Verständigungsebenen. Einige dieser Ansätze - deren Erörterung hier zu weit führen würde - lassen sich in Zukunft sicher zu brauchbaren Hilfsmitteln des Programmentwurfs entwickeln.

Zukünftige Aufgaben

Vielleicht erscheint die Erwähnung solcher spezieller Darstellungsverfahren in dem hier gewählten großen Rahmen auf den ersten Blick unangemessen. Der adäquaten Beschreibung der in Programmsystemen bestehenden Abhängigkeiten und damit der Entwicklung geeigneter Methoden kommt jedoch eine ganz zentrale Bedeutung dafür zu, ob die Software-Entwicklung überschaubar und vernünftig gesteuert abläuft. Der menschliche Geist braucht offenbar solche Hilfen, um sich in der unübersichtlichen Vielfalt von Abhängigkeiten, der er hier wie auch auf anderen Gebieten begegnet, zurechtzufinden und zu verständigen. So waren auch auf vielen anderen, technisch-wissenschaftlichen Wissensgebieten entscheidende Fortschritte erst nach der Entwicklung adäquater und übersichtlicher Darstellungsformen möglich und häufig sogar deren direkte Folge (Bild 5). Es kann daher damit gerechnet werden, daß dadurch auch bei der Software eine ähnliche Entwicklung eintreten wird.

*Dr. Gerhard Bretschneider ist Leiter der Anwendersoftware-Entwicklung der Siemens AG, München