Von Dr. Gerhard Bretschneider

Mit der sich immer schneller in alle Lebensbereiche ausbreitenden Anwendung der Datenverarbeitung wächst auch die Bedeutung der Programmierung solcher Anlagen. Dabei werden immer komplexere Probleme in Angriff genommen. Deren Umsetzung in Datenverarbeitungsabläufe erfordert das Zusammenwirken vieler Menschen. Nach Fertigstellung der entsprechenden Programmsysteme müssen diese über viele Jahre von einer sich verändernden Mannschaft gepflegt und weiterentwickelt werden. Solche Aufgaben können - wie Vorbilder aus anderen Tätigkeitsgebieten zeigen - nur bei sorgfältiger Planung und übersichtlicher Systembeschreibung befriedigend bewältigt werden.

Das Programmieren als Tätigkeit wird bereits in fast unübersehbar vielen Büchern beschrieben. Dabei wird auch die Verwendung sogenannter höherer Programmiersprachen und die Verbesserung der Programmiermethodik eingehend behandelt. Dagegen gibt es insgesamt sehr wenig und in deutscher Sprache fast nichts daß sich mit dem Entwurf großer Programmiersysteme methodisch und konkret auseinandersetzt.

1. Überlegungen zum Systementwurf allgemein

1.1 Die Bedeutung der Analyse- und Konzeptionsphase

Problemanalyse und Entwurf der Gesamtkonzeption sind die entscheidenden Phasen der Entwicklung von Anwendungssystemen der Datenverarbeitung. Fehler oder Versäumnisse, die in diesem Abschnitt der Entwicklung gemacht werden, führen zu inadäquaten Lösungen, zu späterer nachträglicher Umkonzipierung, zu tiefgreifenden Reparaturen und damit zu Vergeudung von Geld, Zeit und Nervenkraft der Beteiligten. Um so erstaunlicher ist es, daß diesen Phasen der Entwicklung von Programmsystemen meist nicht der notwendige Aufwand und die erforderliche Sorgfalt gewidmet werden. Statt dessen wird nach mehr oder weniger oberflächlichem Studium der Anforderungen sogleich an die Bearbeitung von untergeordneten Teilaufgaben herangegangen. Oder um es im Fachjargon zu sagen: "Es wird gleich drauflos programmiert."

Warum ist das so? Ein wesentlicher Grund ist, daß die genannten Phasen - Problemanalyse und Konzeptionsentwurf - nicht nur die wichtigsten, sondern in vieler Hinsicht auch die schwierigsten des Entwicklungsprozesses sind. Schwierig sind sie nicht nur, weil der Entwickler die häufig erst unausgereift vorhandenen Vorstellungen des oder der Auftraggeber auf einem vielfach neuen Gebiet präzisieren und zu einem vernünftigen Konzept entwickeln muß. Dabei muß er ohne vorgefaßte Vorstellungen an das Studium der Bedürfnisse herangehen. Bei großen Vorhaben muß er dazu noch die meist widerstreitenden Vorstellungen mehrerer Interessentengruppen in Einklang bringen.

Schwierig sind diese Phasen aber auch darüber hinaus, weil es nötig ist die in einem Dialog mit den Auftraggebern schließlich erarbeitete Konzeption diesen so transparent machen zu können, daß sie ermessen können was die realisierte Lösung später leisten wird.

Schwierig sind diese Phasen schließlich deshalb, weil die erarbeitete Konzeption so detailliert und außerdem so unmißverständlich festgehalten werden muß, daß sie die Basis für eine anschließende weitgehend systemfehlerfreie Realisierung, das heißt, für die Detailentwürfe der mitarbeitenden Gruppen, bilden muß.

Alle diese Einflüsse zusammengenommen, dazu das Fehlen oder die Unkenntnis geeigneter Verfahren, die in übersichtlicher, verständlicher und dabei eindeutiger Weise die Entwicklung in diesen Phasen unterstützen, machen deren Schwierigkeiten aus.

Auch darf nicht außer acht gelassen werden, daß sowohl auf der Seite der Programmentwickler wie auch auf Seiten der Auftraggeber die Einsicht in die Notwendigkeit dieser Phasen und damit der durch sie entstehenden Kosten vielfach noch nicht vorhanden ist. Dabei könnte ein Seitenblick auf andere Tätigkeitsfelder, bei denen ebenfalls verschiedene Gruppen, also Auftraggeber, Entwurfsplaner und Ausführende, zusammenwirken müssen - wie etwa beim Bau eines Hochhauses - leicht lehren, daß ohne zuvor erarbeitete Baupläne ein solches Bauwerk vernünftigerweise nicht gebaut werden kann. Gleiches gilt auch für die Konstruktion von Autos, Flugzeugen sowie für Maschinen und Anlagen aller Art.

Dabei ist die Kommunikation in den genannten Fachgebieten sogar noch dadurch erleichtert, daß die Beteiligten - Auftraggeber wie Auftragnehmer - prinzipiell wissen, wie ein Hochhaus, ein Auto, ein Flugzeug beschaffen ist und was man bei der Konstruktion erwarten kann und was nicht.

Dagegen ist die gemeinsame Basis der Verständigung bei Programmsystemen zunächst meist nicht vorhanden. Sie kann vermutlich sogar langfristig durch folgende Voraussetzungen geschaffen werden:

- ein ausgereiftes Verfahren zur Verständigung über die abstrakten Eigenschaften von Software-Systemen wird benutzt

- sowohl Auftraggeber wie auch Auftragnehmer sind bereit, sich dieses Verfahrens auch zu bedienen (das heißt, es zu lernen und auch anzuwenden) .

Die Entwicklung von Programmsystemen stellt prinzipiell die gleichen Probleme wie die Entwicklung materieller Güter, nur mit dem Unterschied, daß die dabei entstehenden Gebilde nur auf dem Papier stehen, also wie man im Laborjargon sagt "Software" sind. An Kompliziertheit stehen sie realen "Maschinen", "Anlagen" und dergleichen aber nicht nach, ja sie übertreffen diese sogar oftmals.

Programmsysteme müssen daher ebenfalls abgestimmt entworfen werden, damit sie später auf Datenverarbeitungsanlagen in vorgegebener Weise ablaufen.

Gelingt es, nach einer sorgsamen Problemanalyse, einen fundierten, mit dem Auftraggeber oder Anwender abgestimmten Systementwurf zu machen und zweifelsfrei und lückenlos festzuhalten, dann ist eine solide Basis für die folgenden Realisierungsstufen gewonnen. Gleichgültig wie kompliziert diese noch sind, wird das System am Ende die von ihm erwartete Funktion erfüllen. Dagegen können noch so gute und vorbildliche Realisierungsmethoden Schwächen und Fehler des Entwurfs nie mehr ausgleichen.

1.2 Das Kommunikationsproblem

Jedes komplexere Vorhaben, an dessen Realisierung mehrere Menschen beteiligt sind, ist im wesentlichen ein Kommunikationsproblem. Das gilt, wie diskutiert, auch für die Erstellung von Programmsystemen und sogar in erhöhtem Maß, weil diese Produkte weitgehend unanschaulich und abstrakt sind. Damit kann eine optische Kontrolle der Zwischenergebnisse, wie sie etwa bei realen Anlagen üblich ist, nicht erfolgen.

Sehen wir uns diesen Kommunikationsprozeß für die Entwicklung eines

Programmsystems genauer an. Da gibt es zunächst die Kommunikation zwischen dem Auftraggeber, dem späteren Anwender, und dem Systementwerfer. Deren Vorstellungswelt inbezug auf die gestellte Aufgabe deckt sich zu Beginn nur teilweise. Dies sei in Bild 1 angedeutet.

So kennt der Auftraggeber die Umwelt, in der das zu verwirklichende Programmsystem später eingesetzt werden soll, im allgemeinen aus langjähriger Erfahrung. Diese Kenntnis ist aber vielfach unbewußt. Er ist daher meist nicht in der Lage, die daraus abzuleitenden Forderungen lückenlos von sich aus anzugeben. Es geht ihm etwa wie den meisten Deutschen, wenn sie die grammatischen Gesetze ihrer Muttersprache nennen sollen. Statt dessen wartet der Auftraggeber meist mit einer Unzahl häufig irrelevanter Detailinformationen auf. Auf der anderen Seite hat er oft nur geringe oder falsche Vorstellungen von den Möglichkeiten und Grenzen der Datenverarbeitung. In der dazu komplementären Lage befindet sich der Systementwerfer zu Beginn. Er muß in mühsamer Kleinarbeit erreichen, die für das zu entwerfende System relevanten Informationen aus der Menge des ihm Mitgeteilten herauszufiltern durch direkte Befragung zu beschaffen und vor allem zu lernen, mit den Augen der späteren Anwender zu sehen und das zu entwerfende System dann aus diesem Blickwinkel zu entwickeln. Den Systementwurf muß er im späteren Verlauf dem Auftraggeber wieder vorlegen und erschöpfend und unmißverständlich erläutern können, damit etwa noch offene Anforderungen rechtzeitig erkannt werden können.

Betrachten wir nun diese diskutierte Kommunikation in Hinsicht auf die benötigten methodischen Hilfsmittel. Es ist sicher, daß der Systemanalytiker Aufzeichnungen über den Konzeptentwurf machen muß. Diese Aufzeichnungen dürfen, von Ausnahmen abgesehen, nicht rein verbaler Art sein also nicht nur aus Einzelforderungen im Sinne eines Lastenheftes bestehen, denn derartige Unterlagen unterstützen den Systementwickler weder beim Entwurfsprozeß genügend noch lassen sie eine Prüfung auf Informationslücken im System zu. Rein verbale Beschreibungen reichen nicht aus, den Auftraggeber erschöpfend und verständlich über den Systementwurf zu informieren. Schließlich reicht ein solches nur verbales Lastenheft wegen seiner stets vorhandenen Lückenhaftigkeit auch nicht als Basis für die spätere Systemrealisierung aus. Als methodische Hilfsmittel zur Unterstützung der Kommunikation in diesem Abschnitt kommt nur ein Verfahren in Frage, das "Pläne" des fraglichen Systems zu entwickeln gestattet. Dies geschieht somit in voller Analogie zur Systementwicklung auch auf anderen technischen Gebieten. Die Anforderungen der Programmentwicklung an ein für sie geeignetes Verfahren werden später erörtert.

Wird fortgesetzt