Stichworte wie Werkzeugsystem, Programmierumgebung, Produktionsumgebung und Software Engineering Environment werden in letzter Zeit nicht nur im Software Engineering diskutiert. Was diese Begriffe für die Praxis der computerunterstützten oder automatisierten Software-Produktion bedeuten können, wollen die Autoren in diesem Bericht untersuchen. Mit Betonung der Produktion von Anwendungs-Software sollen Entwicklungslinien aufgezeigt, Modelle, Methoden, Beschreibungsmittel und Werkzeuge kritisch vorgestellt werden. Im Schlußteil versuchen die Autoren, offene Probleme, aber auch praktische Lösungsansätze aufzuzeigen.

----------------

Die Autoren sind Mitarbeiter am Institut für Software-Technologie der Gesellschaft für Mathematik und Datenverarbeitung mbH Bonn, 5205 St. Augustin 1. Sie waren Mitorganisatoren des Symposium on Software Engineering Environments, Lahnstein 1980; die Proceedings des Symposiums erscheinen Ende 1980 bei North Holland.

--------------------

0.Einleitung

In den letzten 30 Jahren hat sich die Art und Weise der Herstellung von Programmen grundlegend verändert. Diese Veränderung hat auch unsere Sprache beeinflußt: Wir sprechen nicht mehr von Rechnerprogrammen, sondern von Software, und aus der Programmierung wurde Software Engineering. Aber kaum war das Wort Software geboren, ist auch der Begriff Software-Krise geprägt worden. Software Engineering - eine noch zu entwickelnde Ingenieurwissenschaft - sollte schon damals das Allheilmittel für diese Krise sein.

Hinter diesen Wortschöpfungen und Wortspielen steht die seit über zehn Jahren drängende Erkenntnis, daß der Bedarf an qualitativ guter Software nicht ausreichend gedeckt werden kann, und daß es zu viele schlechte Software-Produkte gibt. Fühlten sich anfangs nur Programmierer und Systemanalytiker von dieser mangelnden Software-Qualität betroffen, so ist zunehmend festzustellen, daß diese Mängel auch auf die Benutzer dieser Software und darüber hinaus oft auf viele mittelbar Betroffene wirken.

Auf dieser Grundlage wächst langsam eine Sichtweise, daß der Einsatz von Software organisatorische und soziale Auswirkungen hat, die schon bei der Entwicklung berücksichtigt werden müssen. Vor diesem Hintergrund sollte die Aufgabe des Software-Ingenieurs und der Einsatz von Software-Produktions-Umgebungen verstanden werden.

1. Die Entwicklung der Software-Produktion

Das Verständnis von Software-Produktion hat sich mit der Zeit verändert: Was zunächst nur ein Programmierproblem war, wurde mit zunehmenden Aufgaben der Datenverarbeitung zum Spezifikationsproblem zwischen Anforderung und (programm-) technischer Lösung und stellt heute ein umfassendes technisches, organisatorisches und soziales Problembündel des Einsatzfeldes dar.

Die Anfänge der Programmierung

Die ursprüngliche Programmieraufgabe bestand in der Übertragung eines mathematischen Algorithmus in eine für den Computer verständliche Sprache - zunächst wurden "harte" Maschinenbefehle, dann symbolische Codierungen in Assembler und schließlich problemorientierte Schreibweisen einer höheren Programmiersprache (zum Beispiel Fortran) verwendet.

Diese Art der Programmerstellung ermöglichte die Mehrfachverwendung einer Problemlösung und die Sammlung vieler Einzellösungen für einen ganzen Anwendungsbereich (Programmbibliotheken). Mit der Zeit wurden höhere Programmiersprachen aber so umfangreich in ihren Ausdrucksmöglichkeiten und so mächtig in ihren Fähigkeiten, daß sie von angelernten DV-Laien nur noch begrenzt eingesetzt werden konnten, DV-Spezialisten übernahmen die eigentliche Programmierung.

Die Programmier-Künstler

Es bildete sich die "Kaste der Programmier-Künstler", mit der Folge, daß Programme zu sehr individualistischen Gebilden wurden. Programme, ja ganze Programmsysteme lebten und starben mit den zugehörigen Programmierern. Hier entstand der Bedarf nach einer personenunabhängigen Gestaltung von Software.

Die weiteren Stationen der Entwicklung sind schnell skizziert:

Komplexe Berechnungs- und Datenverwaltungsprobleme werden mit komplexen DV-Systemen gelöst; die notwendigen Hilfsmittel (Strukturierte Programmierung, Sprachen wie Cobol, Fortran, Algol, .etc.) werden von DV-Abteilungen eingesetzt. Diese Trennung von Fachabteilung (Anwender) und DV-Abteilung (Produzenten) führt zu Verständigungs- und Informationsproblemen. Entwurfs- und Spezifikationshilfen werden auf die jeweiligen Anforderungen ausgerichtet und sollen der Kommunikation zwischen den Abteilungen dienen.

Neue Probleme durch neue Aufgaben

Schließlich werden die Problemlösungen so umfangreich, daß innerhalb der DV-Abteilungen Entwicklerteams mit spezialisierten Funktionen und Kenntnissen eingesetzt werden müssen (wie Systemanalytiker, Systemprogrammierer, Anwendungsprogrammierer etc.) - interne Kommunikationsprobleme dieser Gruppen kommen hinzu; individuelle Werkzeuge einzelner Programmierer müssen zu umfassenderen Programmierumgebungen zusammengestellt werden. Die Organisation dieser Teams bereitet Probleme. Es zeigt sich, daß DV-Abteilungen nicht wie andere Fertigungsabteilungen, sondern eher wie Planungsabteilungen organisiert und geführt werden sollten. Auf der anderen Seite stellen Management und Anwender fest, daß die eingesetzten DV-Lösungen Auswirkungen auf die gesamte Organisation haben:

- DV-Lösungen führen oft zur völligen Reorganisation des Anwendungsbereichs, Akzeptanzprobleme und unbeabsichtigte Nebeneffekte stellen sich ein.

- Die Anforderungsanalyse und Beteiligungsmodelle für Benutzer und Betroffene erhalten wesentliches Gewicht.

Der norwegische DV-Experte und Mit-Entwickler von Simula 67, Kristen Nygaard, formuliert den Stand der Dinge heute so:

"Wir gehen davon aus, daß DV-Systeme als Teile von Organisationen betrachtet werden können, die mit der umliegenden Gesellschaft in Beziehungen stehen, und daß diese DV-Systeme schon im normalen Einsatz wichtige Aspekte des täglichen Lebens der betroffenen Menschen beeinflussen".

2. Was sind Software-Produktions-Umgebungen?

Software-Produktions-Umgebungen sollen Methoden, Beschreibungsmittel und Werkzeuge für die technische Produktion, die Planung und Organisation die Anwendengsvorbereitung und den Einsatz von Software umfassen. Die Entwicklung zu Software-Produktions-Umgebungen als Instrumente der technisierten Software-Produktion führt über Einzelwerkzeuge und Werkzeugsammlungen bis zu "Software Engineering Environments".

Die Kenntnisse über Software-Produktion sind nicht im gleichen Maße gewachsen wie die Anwendungsmöglichkeiten der Datenverarbeitung - auch dies ist eine Sicht der Software-Krise. Eine Lösung aus dieser Sicht kann daher lauten: Die Software-Produktion muß rationeller gestaltet und mit geeigneten Methoden und Konzepten unterstützt werden. Mit unserer Themenstellung haben wir die Hilfsmittel einer Software-Produktion ihre Methoden und Modelle und die Anwendung in Produktionsumgebungen in den Vordergrund gestellt.

Einzelne Methoden und Werkzeuge

Es gibt heute eine Menge von Werkzeugen und Methoden für Einzelaspekte. Der Computer wird immer mehr als Arbeitsinstrument für die Vorbereitung seiner eigenen Anwendung genutzt. Hilfsmittel wie Columbus (Siemens), SPF (IBM) oder PET (Softlab) sollen eine bessere Umgebung für den Programmierer schaffen. Parallel dazu wurden Methoden und Werkzeuge für einzelne Aufgaben wie Dokumentation (Byblos von Siemens und Siclos), Entwurf (Methode nach M. Jackson, Structured Design nach Constantine, auch bekannt als Composite design) und für Planung und Organisation (Orgware von ADV/ Orga) entwickelt; inzwischen gibt es auch Werkzeugsammlungen wie Sitok (Siemens Tool Konzept).

Ein Gesamt-Ansatz

Doch wenn wir die in der Einleitung genannten Probleme ernst nehmen, können Werkzeuge und Methoden für einzelne Aspekte und Phasen auf die Dauer keine ausreichende, das heißt vollständige Lösung der Probleme der Software-Produktion sein. Ein Ansatz ist notwendig, der die einzelnen Aspekte der Software-Produktion integriert: .

- Planung, Organisation und Durchführungskontrolle; dieser Aspekt beschäftigt sich mit Projektplänen und Projekten.

-Technische Produktion von der Problemdefinition über die Erstellung bis zur Änderung und Weiterentwicklung; hierzu gehören auch Qualitätssicherung und -kontrolle (des heißt Produktkontrolle durch Tests, Verifikation Structured walk through etc.)

-Anwendungsvorbereitung und Anwendung; hierzu gehört vor allem die frühzeitige Einbeziehung von Benutzern und Betroffenen in den Planungs- und Entwicklungsprozeß.

"Integrierter Ansatz" soll hier kein Schlagwort sein: Er muß auf einem jeweils einheitlichen Verständnis des Software-Produktionsprozesses und des Software-Produkts aufbauen und beides miteinander verbinden.

Software-Produktions-Umgebung

Einen solchen Ansatz nennen wir Software-Produktions-Umgebung in Anlehnung an den englischen Begriff " Software Engineering Environment"; dieser Begriff umfaßt mehr als " Programmierumgebung " .

Eine Produktions-Umgebung stellt Methoden und Hilfsmittel für drei Bereiche zur Verfügung:

- für die DV-Abteilung,

- für die Fachabteilung,

- Für das Management.

Wir meinen:

Probleme der Software-Produktion haben zu Anforderungen und Wunschvorstellungen für Software-Produktions-Umgebungen geführt. Doch bis heute ist kein System entwickelt, daß diesen Vorstellungen umfassend entspricht.

3. Wer entwickelt Software-Produktions Umgebungen?

Zu unterscheiden sind Software-Produktions-Umgebungen, die in der Industrie und solche, die im Wissenschaftsbereich entwickelt werden: Die einen sollen Produktionsengpässe und Wartungsprobleme beim Entwickler beseitigen, die anderen sind Forschungsinstrumente. In beiden Bereichen werden Software-Produktions-Umgebungen noch nicht für den Markt produziert. Staatliche und tarifrechtliche Regelungen können die Entwicklung beeinflussen.

Sowohl in der Industrie als auch an Universitäten und Forschungseinrichtungen werden Ansätze zu Produktions-Umgebungen entwickelt. Die angestrebten Ziele solcher Entwicklungen sind vielfältig: Rationalisierung (speziell Kostenreduzierung und Produktivitätssteigerung), Standardisierung und nicht zuletzt Verbesserung der Software-Qualität.

Entwicklungsimpulse in der Industrie

In der Industrie dienen die Entwicklungen von Produktions-Umgebungen der Bewältigung von konkreten Schwierigkeiten bei der Software Produktion. So wurde AIDES entwickelt, um Schwierigkeiten im Umgang mit "Structure charts" bei der Methode "Structured design" (nach Stevens, Myers und Constantine) zu verringern.

Auffällig ist, daß verschiedene Firmen unterschiedliche Probleme als besonders wichtig ansehen. Allgemein will man zur Zeit im eigenen Haus "kurieren" (und damit die eigenen Marktchancen verbessern) - aber nicht Software-Produktions-Umgebungen als Produkte verkaufen.

Entwicklungsimpulse im Wissenschaftsbereich

Im Forschungs- und Entwicklungs-Bereich dienen Software-Produktions-Umgebungen vorrangig als Forschungsvehikel. An ihnen soll eine wissenschaftliche Hypothese erprobt werden. Dementsprechend sind diese Ansätze auf die speziellen Forschungsrichtungen abgestimmt (zum Beispiel COSY auf Sprachdefinitionen mit Hilfe von Petri-Netzen) und haben meist Experimentalcharakter. Doch auch im akademischen Bereich verstärkt sich die Einsicht, daß nur eine Kooperation mit den Anwendern weiterführt, und so finden zunehmend Ansätze aus diesem Bereich ihren Weg in die Praxis (siehe CDL2-Labor).

Für beide Bereiche gilt, daß Mehrfach-Installationen oder Vertrieb von Produktions-Umgebungen selten sind (Ausnahme: zum Beispiel PWB/ UNIX).

Standards und Richtlinien

Durch die Festlegung von Produktions- und Qualitätsstandards kann auch der Staat großen Einfluß auf die Entwicklung von Software-Produktions-Umgebungen ausüben. Dies ist in der Bundesrepublik zwar noch nicht abzusehen, aber in den USA haben beispielsweise die MUST-(Nasa project on Multi-purpose User-Oriented Software Technology) und die APSE-Richtlinien (ADA Programming Support Environments) wesentliche Auswirkungen. Wir wollen an dieser Stelle ausdrücklich auf die Bedeutung von APSE auch für den nicht-militärischen Bereich hinweisen. Eine ähnliche Entwicklung wie bei Cobol ist durchaus wahrscheinlich.

In diesem Zusammenhang sollten auch Rahmenabkommen über die Einführung neuer Technologieanwendungen gesehen werden, wie sie beispielsweise 1975 von den Dachverbänden der norwegischen Tarifpartner abgeschlossen wurden. Laut einer aktuellen Infratest-Studie werden ähnliche Rahmenabkommen von den Tarifparteien für die Bundesrepublik innerhalb der nächsten Jahre erwartet.

Wir meinen:

In der Bundesrepublik sind verglichen mit den USA oder Japan kaum Aktivitäten zur Entwicklung einer umfassenden Software-Produktions-Umgebung festzustellen. Was sich auf dem Markt für Mikrocomputer und dem Automobilmarkt abspielt, kann bald auch auf dem software-Markt Realität sein.

4. Modelle der Software-Produktion

Der Software-Produktionsprozeß wird im allgemeinen in Life Cycle Modellen abgebildet, die die Software-Produktion als Aufeinanderfolge von Produkt-Entwicklungsphasen beschreiben. Life Cycle Modelle unterscheiden sich in Detaillierungsgrad und in der Phasenzuordnung einzelner Aufgaben. Vorhandene Life Cycle Modelle sind nicht geeignet, alle relevanten Aspekte des Software-Produktionsprozesses gemeinsam abzubilden: Sie modellieren den Produktionsaspekt, ignorieren aber das Zusammenspiel von Produktion, Planung und Organisation untereinander und mit der Anwendungsvorbereitung und Anwendung.

Wir haben umrissen, daß Basis für eine Software-Produktions-Umgebung einerseits Konzepte (oder Prinzipien) und Methoden und andererseits Hilfsmittel, nämlich Beschreibungsmittel und (technische) Werkzeuge sind. Um den Zusammenhang zwischen beiden herzustellen, braucht man ein Software-Produktionsmodell.

Einfachste Life Cycle Modelle sind von der Art:

Problemanalyse

Systementwurf

Implementierung

Installation

Diese Phaseneinteilung ist fast in allen Software-Produktions-Umgebungen explizit oder implizit vorzufinden. In der Regel werden darunter zeitlich nacheinander abzuleistende Aufgaben verstanden, obwohl dieses "Fließband"-Verständnis von Software-Produktion den tatsächlichen Gegebenheiten nicht gerecht wird.

Unterschiedlich sind dagegen die Auffassungen über Qualitätssicherung:

In manchen Life Cycle Modellen ist nur eine besondere Phase für Test vorgesehen, in anderen wird die Produktkontrolle als begleitende Aufgabe angesehen.

Ebenso gibt es Auffassungsunterschiede über Wartung: Sie wird als letzte eigenständige Phase beschrieben oder als Wiedereintrittspunkt in frühere Phasen des Life Cycle.

Erweiterte Life Cycle Modelle

Dieses einfache Modell von Entwicklungsphasen läßt sich weiter ausbauen: Zum einen kann eine detailliertere Phaseneinteilung gewählt werden; zum anderen kann die Beschreibung von Phasen um die Beschreibung von Ergebnissen (Dokumenten) oder von Entscheidungspunkten (zum Beispiel Entscheidung Go oder No-go) ergänzt werden, die dann auch zur Steuerung des Projektablaufs dienen können (wie bei SDEM).

Ein erweitertes Life Cycle Modell könnte so aussehen:

Phase Voraussetzung/

Ergebnis

Probleme

Problemanalyse

Anforderungskatalog

Entwurf

Programmspezifikationen

Codierung

Programme

Test

geprüftes Programmsystem

Installation/Abnahme

Anwendungssystem

Nutzung

Protokolle

Wartung

modifiziertes System

Bedeutung für Software-Produktions-Umgebungen

Die Bedeutung von Life Cycle- Modellen innerhalb existierender Software-Produktions-Umgebungen ist unterschiedlich:

- Eine Werkzeugsammlung wie PWB/UNIX ist unabhängig von einem Life Cycle Modell; hier dient das Modell allenfalls zur Erläuterung der Einsatzmöglichkeiten eines Werkzeugs.

- In anderen Ansätzen dient das Modell zur Standardisierung, das heißt als Vorschlag für eine Vorgehensweise.

- Ein Life Cycle Modell kann aber auch als Grundlage für Managementaufgaben verwendet werden, das heißt zur Steuerung und Kontrolle des Software-Entwicklungsprozesses.

Dies geschieht in SDEM/SDSS, SWB und ARGUS.

Was leisten diese Modelle, und was leisten sie nicht ?

Die existierenden Life Cycle Modelle sind als Modelle für die praktische Software-Produktion unzureichend, da immer nur Teilaspekte dargestellt werden.

Hervorstechend ist der Zwang zur Sequentialisierung von Aktivitäten. Hierdurch werden gleichzeitige oder sich wiederholende Aktivitäten in den verschiedenen Dimensionen von technischer Produktion, Planung und Organisation sowie DV-Anwendung zwangsweise in einer Reihenfolge dargestellt. Die bekannten Modelle sind konzeptionell eigentlich nur geeignet, die technische Produktion zu beschreiben, nicht aber das Zusammenwirken der verschiedenen Dimensionen.

Wir finden problematisch, daß Entwurfsentscheidungen nicht explizit festgehalten werden: Sie werden implizit in der Produktbeschreibung dokumentiert - hier sind aber die Alternativen nicht sichtbar. Da nicht beschrieben wird, wann eine Entscheidung unter welchen Alternativen getroffen wurde und von wem, kann man auch notwendige (und ständig vorkommende) Revisionen einer Entscheidung nicht im Modell abbilden- was zu unnötigem Arbeitsaufwand bei späteren Änderungen führt.

Wir meinen:

Die Einführung von Software-Systemen hat immer soziale und organisatorische Auswirkungen. Wenn diese nicht in einem Software-Produktionsmodell darstellbar sind, werden sie unkontrollierbar und unvorhersehbar ablaufen. Solange wesentliche Aspekte wie Planung und Organisation sowie Benutzerbeteiligung nicht im Modell erfaßt sind, wird die Software-Produktion krisenhaft bleiben.

Wird fortgesetzt