Software-Produktionsumgebungen sind keine Spielzeuge für "verrückte Programmier-Fetischisten". Vielmehr werden sie heute bereits in den unterschiedlichsten Bereichen eingesetzt, um Entwicklung und Nutzung von Software rationell zu gestalten (Teil 1).

Eine Software-Produktionsumgebung (SPU) ist ein computergestütztes Softwarelabor, in dem viele Software-Entwickler mit unterschiedlichen Aufgaben zusammenarbeiten, der Arbeitsprozeß (mehr oder weniger) durchgängig organisiert ist und Hilfsmittel (Konzepte, Methoden, Werkzeuge) verwendet werden, die auf die Bearbeitung einzelner (Teil-) Aufgaben zugeschnitten sind.

Neue Systeme ständig in der Pipeline

Heute werden viele Werkzeug-und Methodensysteme entwickelt, die die Software-Entwicklung unterstützen sollen. Man nennt sie Progranimierumgebungen, Werkbanken, Software-Entwicklungssysteme, Software Engineering Environments, Software Development Environments oder eben Software-Produktionsumgebungen.

Worin unterscheidet sich eine SPU von konventionellen Hilfsmitteln zum Beispiel Programmgeneratoren und Methodenbanken? Mit Programmgeneratoren werden aus Steueranweisungen und -parametern Programmsysteme erzeugt. Dabei werden Programmrahmen und Programmbibliotheken verwendet. Generatoren sind meist auf spezielle Probleme und Verfahren der kommerziellen Datenverarbeitung oder auf besondere Anwendungssprachen ausgerichtet. Als eine Erweiterung der Programmgeneratoren können die Methodenbanken angesehen werden. Mit ihnen wird ein Programmsystem aus vorgefertigten

Programmbausteinen (Methodenbausteinen) für spezielle Anwendungen zusammengesetzt.

Mit einer SPU wird, im Gegensatz zu Generatoren und Methodenbanken, sowohl die komplette Entwicklung einzelner Komponenten als auch deren Integration zu Software-Systemen in allen Entwicklungsschritten rationalisiert. Eine SPU soll auch die Produktprüfung unterstützen sowie die Entwicklung und die Kontrolle von System-Version und -Varianten automatisieren.

Wie unterscheidet sich nun eine SPU von den unter der Kontrolle eines Betriebssystems angewendeten Werkzeugen. Grundlegend für eine SPU ist die ausgewählte Software-Entwicklungsmethode und das Lebenszyklus-Modell. Sie bestimmen Aufbau und Anwendungsmöglichkeiten einer SPU. Struktur und Anwendung eines Betriebssystems sind dagegen durch die speziellen Eigenschaften der verwendeten Hardware (und ihrer Peripherie) bestimmt. Betriebssystem-gesteuerte Hilfsmittel erzwingen einen bestimmten Ablauf von Vorgängen.

Diese Ordnung auf Vorgängen kann der Ordnung von Vorgängen in der computergestützten Software-Entwicklung widersprechen. Letztere verlangt zudem nach anderen, in einem Betriebssystem nicht angebotenen Instrumenten. Auf diese können die Kontrollmechanismen eines Betriebssystems häufig nicht angewendet werden. Eine Verschmelzung von SPU und Betriebssystem wird jedoch möglich, wenn Teile des Betriebssystems auf die speziellen Aufgaben der System-Entwicklung zugeschnitten werden können.

Software-Krise als Vater der SPU

Als Antwort auf die Software-Krise wurde Ende der 60er Jahre die Disziplin Software-Technologie (Software-Engineering) eingeführt. Damals wurde Software-Produktion verstanden als das Entwerfen und Dokumentieren von Programmen. Beides sollte verbessert werden durch methodisches Vorgehen bei Strukturierung und Dokumentation von Programmen.

Inzwischen ist der Aufgabenbereich der Software-Produktion gewachsen: Anforderungsanalyse, Spezifikation von Problem und Software sowie Verifikation und Validation von Software werden heute ebenfalls als Entwicklungsaufgaben angesehen. Außerdem wird dem Management der Software-Produktion und der Organisation von Entwicklungsgruppen ein besonderes Gewicht beigemessen. Erkennbar ist heute bereits die Notwendigkeit, die Auswirkungen der Anwendung eines Systems schon während seiner Entwicklung zu beachten.

Der Einsatz eines Computersystems beeinflußt nicht nur die Arbeitsbedingungen des einzelnen Benutzers an seinem Arbeitsplatz, er kann unter Umständen die gesamte Organisation verändern, in der es verwendet wird. Betroffen sind aber nicht nur diejenigen, die mit einem Computersystem arbeiten müssen sondern auch diejenigen, für die zum Beispiel Dienstleistungen mit Computerhilfe erbracht werden.

In Übereinstimmung mit dem wachsenden Aufgabenbereich des Software-Engineering werden neue und komplexere Instrumente entwickelt, die nicht nur den einzelnen Software-Entwickler unterstützen, sondern auch die Planung und Organisation großer Software-Projekte. Angesichts dieser Geschichte ist es verständlich, daß die früheren Programmierwerkzeuge zu Programmier-Umgebungen erweitert wurden (einschließlich Sprachprozessoren und speziell zugeschnittene Editoren), denen heute Software-Produktionsumgebungen folgen.

Eine SPU stellt Beschreibungsmittel und Werkzeuge für alle Aufgaben der Software-Entwicklung und für alle Entwicklungsstadien des Software-Produktes von der Anforderungsanalyse bis zur Wartung und Weiterentwicklung zur Verfügung. Sie bietet Methoden und Konzepte sowohl für die Entwicklung des Produktes als auch für die Organisation des Entwicklungsprozesses. Eine SPU basiert auf einem Modell des Produktes und einem Modell der Entwicklung.

Die Rolle von Methoden ist in den Produktionsumgebungen unterschiedlich. Es gibt methodenabhängige Produktionsumgebungen die ganz bestimmte Methoden unterstützen. Ein Beispiel ist "proMod" (GEI), das ein Methodenbündel bereitstellt: Für die Anforderungsanalyse und -definition wird Structured Analysis unterstützt, für den System-Entwurf "Modular Design", für den Programmentwurf "Pseudocode" und für die Implementierung "Structured Programming". Es gibt andere Umgebungen, die vollständig methodenunabhängig sind: In einem Werkzeugkasten wie "PWB-Unix" wird die Anwendung der Werkzeuge nicht durch Methoden festgelegt. Man kann auch sagen, solche Systeme sind offen für viele Methoden.

Anwender entscheidet zwischen zwei Varianten

Beide Ansätze haben ihre Berechtigung. Beim methodenabhängigen Ansatz ist zu berücksichtigen, daß es nicht immer möglich sein wird, Anwendern die Verwendung bestimmter Methoden vorzuschreiben. Auf der anderen Seite kann dieser Ansatz eine optimale Unterstützung anbieten, die bei einem methodenunabhängigen Ansatz unter Umständen nicht möglich ist. Ein Entscheidung für den einen oder den anderen Ansatz ist nur bei Berücksichtigung der speziellen Einsatzbedingungen (sinnvoll) möglich.

Bei den Aufgaben der Software-Entwicklung lassen sich folgende Bereiche unterscheiden:

- Software-Entwicklung und -prüfung, das heißt Entwicklung und Prüfung aller Dokumente, die zum Produkt gehören wie Entwurfsbeschreibung, Programme und Benutzerhandbücher.

- Managementaufgaben, das heißt Planung, Steuerung und Kontrolle aller Aufgaben der Software-Entwicklung und -prüfung.

- Software-Konfiguration, das heißt Planung und Kontrolle aller Produktteile in allen Versionen und Varianten.

Ein wichtiger Bestandteil aller drei Aufgabengebiete ist die Oualitätssicherung aller Entwicklungsergebnisse.

Für die Benutzbarkeit und damit die Akzeptanz einer SPU ist die Benutzeroberfläche entscheidend.

Ein wichtiges Feld für die Unterstützung durch den Computer ist das der Informationsverwaltung und der Dokumentation

Ein weiterer wesentlicher Aspekt bei der Betrachtung einer SPU ist ihre Basismaschine, das heißt die Software und Hardware, auf der sie aufsetzt.

Methoden und Werkzeuge für die technische Software-Entwicklung findet man in jeder SPU. Auch in den methodenunabhängigen. Dort sind sie unter Umständen nicht direkt sichtbar. Es ist heute zwar unstrittig, daß Software methodisch entwickelt werden sollte, es ist allerdings heftig umstritten, welche Methode sich für welche Aufgabe besonders eignet.

Zahlreiche Methoden für die Software-Entwicklung sind vorhanden, auch in SW-Produktionsumgebungen. Aber wie sie wirken, ist nicht eindeutig zu bestimmen. Ebenfalls unstrittig ist, daß die Software-Entwicklung durch Werkzeuge erheblich erleichtert werden kann. Es gibt folglich zahlreiche Tools für einzelne Aufgaben der Software-Entwicklung. Diese Werkzeuge passen aber nur in den wenigsten Fällen zueinander.

Heute kann man bei der Entwicklung von Programmen nur sehr selten sofort mit der Programmierung beginnen. Die Aufgaben, die gelöst werden sollen, sind meist so umfangreich und schwierig, daß man sich vorher sehr genau überlegen muß, was die Aufgabe ist und was das System leisten soll, das als Lösung dieser Aufgabe zu entwickeln ist.

Die Analyse und Definition der Aufgabe sind anwendungsorientierte Probleme. Es muß geprüft werden,

wofür und warum ein Rechner eingesetzt werden soll. Dies ist eine Aufgabe der Fachabteilung. Anforderungen werden aufgelistet; es wird aber noch keine Lösung vorgeschlagen

Bei der Festlegung der zu entwickelnden Lösung geht man schrittweise vor:

- Die "Was-Beschreibung" (System-Spezifikation) definiert die Daten, die das System verarbeiten soll, die Funktionen, die es zur Verfügung stellen soll, und wie diese Funktionen zu verwenden sind. Neben diesen anwendungsorientierten (externen) Funktionen und Datenstrukturen werden auch die dafür notwendigen internen DV-Funktionen und -Datenstrukturen festgelegt.

Die System-Spezifikation ist entscheidend dafür, ob das System später vom Benutzer akzeptiert wird, und welche Schwierigkeiten in diesem Zusammenhang bei der Systemnutzung auftreten. Auf der Basis der Spezifikationen einigen sich Nutzer beziehungsweise Auftraggeber und Entwickler über das System. Deshalb muß die Spezifikation des Systems und seiner Leistungen für beide Seiten verständlich und nicht beliebig interpretierbar sein. Da grafische Darstellungen verständlich und hinreichend präzise sein können, spielen grafische Methoden und Werkzeuge hier eine besonders wichtige Rolle.

- Die "Wie-Beschreibung" (System-Entwurf und -Implementierung) besteht aus

- Beschreibung des Systemaufbaus,

- Beschreibung der Systemteile und

- Realisierung dieser Teile.

Die beiden ersten Schritte werden als System-Entwurf bezeichnet. Der System-Entwurf ist besonders wichtig, da er darüber entscheidet, welche Schwierigkeiten man später beim Test, beim Debugging, bei der Wartung und bei der Weiterentwicklung haben wird. Schlagworte sind Modularisierung, Abstraktion und Information-hiding.

Der letzte Schritt, die Implementierung, erscheint zumindest im Forschungs- und Entwicklungsbereich nicht mehr als Problem; sie wird am besten verstanden. Schlagworte sind Pseudocode, Strukturierte Programmierung und Stepwise-refinement.

Die Definition der Aufgabe durch die Fachabteilung wird in einer SPU nicht speziell unterstützt. Da ähnliche Strukturen behandelt werden wie bei der System-Spezifikation, könnten die gleichen Hilfsmittel verwendet werden, zum Beispiel Grafik und Entscheidungstabellen. Eine SPU sollte insbesondere graphische Mittel zur Verfügung stellen.

Bei der System-Spezifikation gibt es verschiedene Ansätze, um festzulegen, was das zu entwickelnde System leisten soll: Von natürlich sprachlichen Texten über Grafiken und Tabellen bis zu relationalen Darstellungen und sogenannten formalen Spezifikationen wie axiomatische und algebraische Spezifikationen. Die meisten dieser Ansätze sind in den existierenden Produktionsumgebungen zu finden.

Grafische Mittel findet man zum Beispiel in "proMod." Das Modell des zu entwickelnden Software-Systems wird nach der Methode "Structured Analysis" beschrieben durch ein Datenfluß-Diagramm (Data Flow Diagramm, DFD), ein Datenlexikon (Data-Dictionary, DD) und sogenannte Kurzinfos (Transformation Description, TD). Eine solche Beschreibung ist für Fachabteilung und Entwicklungsabteilung verständlich.

Der wohl bekannteste Ansatz für relationale System-Spezifikationen ist PSL/PSA (Problem Specification Language/Problem Statement Analyzer) von Teichroew. Obwohl der Name vermuten läßt, daß PSL/PSA ein Hilfsmittel für die Beschreibung des Problems beziehungsweise der Aufgabe ist, wird es meist für die Systemspezifikation verwendet. Mit der Sprache PSL wird das System beschrieben als Menge von (benannten) Objekten, die bestimmte Eigenschaften haben und miteinander in

Beziehung stehen können. Das Werkzeugsystem PSA prüft die Beschreibung, generiert beziehungsweise ändert die Einträge in der Datenbank, prüft deren Konsistenz und erzeugt Berichte aus der Beschreibung in der Datenbank.

Formale Spezifikationen gibt es für die Beschreibung sowohl sequentieller Systeme als auch nicht-sequentieller Systeme. Bei den formalen Spezifikationen sequentieller Systeme kann man zwei Ansätze unterscheiden:

- prozedurale Abstraktion, das heißt input-output specifications und operational spezifications

- Datenabstraktion, das heißt axiomatic specifications und abstract model specifications.

Die Spezifikation nicht-sequentieller Systeme kann man aufteilen in

- state variable specifications nach Ovicki,

- event expression specifications und

- path expression specifications nach Habermann.

*Hans-Ludwig Hausen ist wissenschaftlicher Mitarbeiter am Institut für Systemtechnik der GMD Gesellschaft für Mathematik und Datenverarbeitung mbH, Sankt Augustin.

Interface zur Basismaschinen

Heute werden viele Software-Produktionsumgebunden auf einem Betriebs auf