Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

09.01.1981 - 

Software-Produktion:

Abschied vom Durchwursteln

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.

5. Methoden

Zahlreiche Methoden für die Software-Produktion sind vorhanden - auch in Software-Produktions-Umgebungen. Aber wie sie wirken, ist nicht eindeutig zu bestimmen. Software-Produktions-Umgebungen von "methodenneutral bis "völlig methodenabhängig" sind vorzufinden. Sind für die eigentlichen Produktionsphasen noch diverse Methoden vorhanden, so mangelt es an solchen für Planung und Organisation. Insbesondere die wichtiger werdende Benutzerbeteiligung ist methodisch nicht abgedeckt.

Es ist heute unstrittig, daß Software-Produktion methodisch erfolgen sollte, es ist allerdings heftig umstritten, welche Methode sich wofür eignet.

Da ist zunächst die Produktion: Konzepte zur Programmierung im großen wie Abstraktion, Information Hiding werden ebenso oft genannt wie Methoden und Verfahren von Michael Jackson und Structured design.

Für die Projektorganisation gibt es Methoden wie Adaptive Team, Chief Programmer Team oder teilautonome Gruppen.

Schließlich werden für die Benutzerbeteiligung Organisationskonzepte und -Modelle von Kubicek und aus dem skandinavischen Raum diskutiert.

Was wird davon in Software-Produktions-Umgebungen verwendet?

Die Bedeutung von Methoden ist in den Ansätzen verschieden:

In einem Werkzeugkasten wie UNIX/PWB spielen Methoden keine Rolle. AIDES dagegen wurde entwickelt, um eine spezielle Methode für die Entwurfsphase (Structured design) maschinell zu unterstützen. ISES geht noch weiter: Hier sollen Methoden durch das System implementiert werden, das heißt das System verhält sich einer Methode entsprechend.

Methoden für die technische Produktion

In der technischen Produktion werden bekannte Methoden für den Kern des Life Cycle angeboten:

- Implementierungskonzepte sind weitgehend verstanden und werden in der Praxis eingesetzt (dafür spricht zum Beispiel die Verbreitung von Columbus als Hilfe bei der Arbeit mit unzureichenden Implementierungssprachen). Auch die sonst in der Praxis verwendeten Entwurfsmethoden sind in Software-Produktions-Umgebungen zu finden: Da aber zu Entwurfskonzepten weder ausreichende Kenntnisse noch Erfahrungen vorliegen, werden sie eher experimentell eingesetzt (DREAM).

- Der Bereich der Problemanalyse ist dagegen weder theoretisch geklärt noch methodisch ausgearbeitet, von einem anwendungsspezifischen, aber vielversprechenden Ansatz (SREM/ RSL in SDS) einmal abgesehen.

- Methoden der Qualitätskontrolle, außerhalb von Software-Produktions-Umgebungen schon länger bekannt und diskutiert, kommen langsam auch hier zum Tragen; allerdings auch nur bezogen auf spezielle Aspekte (zum Beispiel Verifikation in HDM und GYPSY, Testmanager in SITOK).

Methoden für Planung und Organisation

Für Projektmanagement und Projektorganisation gibt es in Software-Produktions-Umgebungen noch relativ wenig Unterstützung (Ausnahmen: AIDES, SDEM); Methoden der Benutzerbeteiligung fehlen in Software-Produktions-Umgebungen bisher ganz.

Probleme

Diese Skizze zeigt schon die wesentlichen Probleme:

- Es gibt Methoden - aber nur für einzelne Aspekte und Phasen; diese sind isoliert voneinander, das heißt nicht aufeinander abgestimmt, so daß man sie nicht gemeinsam verwenden kann.

- Der Einfluß (oft auch die Wirkung) von Methoden bleibt im dunkeln: Wenn auch manches besser wird, weiß man nicht warum. Offen bleibt, ob der Einsatz einer speziellen Methode die Verbesserung bewirkt hat, oder ob eine andere Methode den gleichen oder einen besseren Erfolg erzielt hätte.

Wir meinen:

Das wahllose Hantieren mit Methoden kann nur dann überwunden werden, wenn gezielt Wirkungszusammenhänge von der Art untersucht werden:

Was will ich - welche Methode setze ich dazu ein. Die Auswahl abgestimmter Methoden sollte zu einer Verfahrenstechnik führen.

6. Beschreibungsmittel

Beschreibungsmittel sind Grundlage aller Aktivitäten des Software-Produktionsprozesses. In formalisierter oder formaler Form sind sie der maschinellen Bearbeitung zugänglich. Software-Produktions-Umgebungen verwenden vor allem sprachliche Beschreibungsmittel, aber auch grafische und tabellarische. Wie bei den Methoden liegt der Einsatzschwerpunkt im engeren Produktionsbereich. Eine durchgängige, auf alle Aspekte abgestimmte Konzeption von Beschreibungsmitteln fehlt.

Der technische Kern

Betrachten wir den technischen Aspekt bei Software-Produktions-Umgebungen, stellen wir fest:

- die Implementierung erscheint zumindest im Forschungs- und Entwicklungsbereich nicht mehr als Problem,

- der Entwurf wird zur Zeit stark betont: In der Praxis werden Methoden erprobt, eine Reihe neuer Konzepte ist in Entwicklung,

- Problemanalyse und Aufgabendefinition gelten als relativ offenes Gebiet; Ansätze wie SDS/SREM sind vielversprechend,

- Qualitätssicherung und -kontrolle werden zunehmend diskutiert; Konzepte für Test und Verifikation sind in der Erprobung,

- trotz wachsender Bedeutung verteilter Systeme sind kaum Ansätze für Parallelverarbeitung (Concurrency) zu finden (Ausnahmen: COSY, DREAM) .

Die Probleme von Software-Produktions-Umgebungen spiegeln den Stand des Software-Engineering: Wesentliche Aspekte und Zusammenhänge der Software-Produktion sind noch nicht verstanden. Erst recht fehlt eine Technologie der Software-Produktion, die für alle Probleme sagen könnte, welches Verfahren für welchen Zweck einzusetzen ist.

Neuorientierung in der Software-Produktion

Eine wichtige Voraussetzung für die Bewältigung der Software-Krise ist die richtige Einschätzung des Software Life Cycle. Der Versuch, bei den Entwicklungskosten zu sparen, bringt dann nur kurzfristigen und scheinbaren Erfolg, wenn man die späteren Reparatur-, Anpassungs- und Weiterentwicklungskosten ignoriert.

Der zunehmenden Einsicht der Bedeutung von Problem- und Anforderungsanalysen muß eine instrumentelle und organisatorische Umsetzung folgen. Weiterhelfen kann hier auch ein kritisch vergleichender Blick auf verwandte Technologien wie Computer aided management, Computer aided manufacturing, Computer aided design und die klassische Verfahrenstechnik.

Keine Allheilmittel in Sicht

Es gibt keine universell einsetzbare Software-Produktions-Umgebung, also keinen Ansatz, der Lösungen für alle Bereiche der Software-Produktion bereitstellen würde, und wir beweisen auch, daß eine solche Umgebung sinnvoll und mit vertretbarem Aufwand machbar ist.

Um so wichtiger werden Kriterien, die erlauben, die Eignung einer Produktions-Umgebung für einen bestimmten Zweck und für einen bestimmten Anwendungsbereich abzuschätzen.

Was ist in der Praxis zu tun?

- kurzfristig:

Trotz aller Unklarheiten läßt sich schon heute feststellen, daß methodische Software-Produktion dem intuitiven "Werkeln" überlegen ist. Daß dies zunehmend auch den Anwendern bewußt wird, zeigt eine demnächst erscheinende GMD-Studie (Abel et al, Einsatz von Methoden der Software-Produktion in der Bundesrepublik Deutschland, Oldenbourg). Bereits vorhandene oder erprobte Methoden und Hilfsmittel sollten sachund fachgerecht genutzt werden. Dabei sollten sich die Anwender nicht von einzelnen Systemen, Systemfunktionen oder Methoden blenden lassen: Ein Allheilmittel existiert nicht.

Eine längerfristige Strategie für die Entwicklung der DV-Abteilung sollte rechtzeitig erarbeitet werden.

- mittelfristig:

Eigene Erfahrungen und externes Know-how im Umgang mit Methoden und Hilfsmitteln sollten ausgewertet sein. Im Hause Vorhandenes sollte so mit (externen) Neuentwicklungen verbunden werden, daß ein vereinheitlichtes Instrumentarium zur Unterstützung der Software-Produktion entsteht. Die Entscheidung über die längerfristige Anschaffung einer Software-Produktionsumgebung sollte getroffen werden.

Beschreibungsmittel spiegeln die Vorstellung über das zu beschreibende Objekt und sind Grundlage für sämtliche Aktivitäten der Software-Produktion: für die Konstruktion, für die Analyse und Kontrolle sowie für die Dokumentation.

Für die Software-Entwicklung ist relevant, welche Ausdrucksmöglichkeiten ein Beschreibungsmittel bietet, ob der Produzent das zu beschreibende Objekt oder den Prozeß nach seiner Vorstellung beschreiben kann (wer je versucht hat, Textverarbeitung mit Fortran zu "beschreiben", hat dies erfahren).

Eng damit verbunden ist der Aspekt der Dokumentation, dessen Relevanz für größere, langlebige Software kaum zu unterschätzen ist. Oft sind Dokumentationen so mangelhaft, daß sie für die Benutzer kaum verständlich sind.

In beiden Fällen geht es um die Angemessenheit und Verständlichkeit für den Menschen, das heißt um den kognitiven Aspekt. Für die maschinelle Bearbeitung ist die formatierte, vor allem die formale Darstellung von Objekten (wie Software oder Entwicklungsprozesse) von Bedeutung.

Formen von Beschreibungsmitteln

Man muß daher unterscheiden zwischen informellen Beschreibungen (zum Beispiel in natürlicher Sprache), formatierten Darstellungen (beispielsweise in Formularen und Tabellen) und formalisierten Repräsentationen (in formalen Spezifikations- und Programmiersprachen).

Im Prozeß der Software-Produktion durchläuft die Beschreibung des Produkts verschiedene Formalisierungs und Detaillierungsstufen. So wird ein Beschreibungsmittel, das der Verständigung zwischen Anwendern und Entwicklern dient, anders aussehen als ein Beschreibungsmittel, das dem Entwickler helfen soll, ein Programm zu verifizieren. Können im ersten Fall die natürliche Sprache oder Tabellendarstellungen ausreichen, wäre im zweiten eine formale Spezifikation auf mathematischer Basis notwendig. Daher ist Verständlichkeit immer relativ, immer im Kontext zu sehen.

Wir wollen an dieser Stelle allerdings nicht das Vorurteil bestärken, daß informelle Darstellungen allgemein verständlich, formale Darstellungen aber nur für den Spezialisten seien. Denn einerseits können informelle Beschreibungen durch ihre Unverbindlichkeit und "Unschärfe" zu Mißverständnissen und Interpretationsschwierigkeiten führen, andererseits zeigt das Computer aided design, daß selbst komplexe Systembeschreibungen durch formale grafische Repräsentation verständlich gehandhabt werden können.

Was wird in Software-Produktions-Umgebungen verwendet?

- Wir finden im wesentlichen linguistische Mittel (von natürlichen Sprachen bis zu formalen).

- Grafische Mittel werden heute verstärkt in den Anfangsphasen (speziell für den Entwurf) verwendet. Das ist verständlich, da grafische Mittel besonders gut geeignet sind, Zusammenhänge anschaulich darzustellen.

- Auch Tabellen und Formulare finden Anwendung.

- Für die technische Produktion werden neben den üblichen Programmiersprachen (für die Implementierung) Spezifikationsmittel für Moduln und Modulbeziehungen angeboten (für den Entwurf). Beschreibungsmittel für die Problemanalyse sind selten (RSL in SDS).

- Wie zu erwarten, sind in existierenden Software-Produktions-Umgebungen fast keine speziellen Beschreibungsmittel für Managementaufgaben und Benutzerbeteiligung vorzufinden.

Wir meinen:

Es gibt zwar viele Beschreibungsmittel für einzelne Aspekte und Phasen, aber sie sind unabhängig voneinander. Doch aus unzusammenhängenden Beschreibungsmitteln kann keine zusammenhängende Systemdarstellung resultieren. Wenn ein (Software-) System aber mehr ist als die Summe seiner Teile, wird eine Systemdarstellung, die nur Aspekte erfaßt, kaum zu brauchbaren Systemen führen.

7. Werkzeuge

Werkzeuge bilden den technischen Kern einer Software-Produktions-Umgebung. Sie unterstützen sowohl die Produktbearbeitung als auch die Steuerung des Produktionsprozesses. Generell haben Produktions-Umgebungen einen Minimalsatz an Werkzeugen rund um eine Sprache. Weiterhin lassen sich zwei Ausrichtungen unterscheiden: auf Beschreibungsmittel oder auf Informationsverwaltung. Die eingesetzten Werkzeuge sind kaum aufeinander abgestimmt, noch decken sie alle Aspekte des Life Cycle ab.

Werkzeuge stellen die eigentliche " Computerunterstützung" bei der Software-Produktion dar. Sie sind eng verbunden mit Beschreibungsmitteln: Einerseits regeln Beschreibungsmittel den Umgang mit Werkzeugen, zum anderen bearbeiten Werkzeuge ihrerseits wieder Beschreibungen. Für die Software-Produktion gibt es eine kaum überschaubare Zahl von Werkzeugen, doch für eine Software-Produktions-Umgebung ist entscheidend, daß die Werkzeuge für verschiedene Aspekte und Phasen zueinander passen.

Was wird an Werkzeugen in Software-Produktions-Umgebungen angeboten?

Wie zu erwarten, ist der technische Teil von Software-Produktions-Umgebungen relativ stark ausgeprägt. Jede Umgebung besitzt zumindest einen Prozessor für eine Programmiersprache und eine Programmierunterstützung im engen Sinne aus Editor, Binder, Lader und Laufzeitsystem. Diesen Satz könnte man als das "kleine Handwerkszeug" einer Produktions-Umgebung bezeichnen.

Doch schon hier werden verschiedene Auffassungen über die Abstimmung der Werkzeuge untereinander und mit den Sprachmitteln deutlich:

Beispielsweise bei den Editoren - die einen (wie bei PWB/UNIX) arbeiten mit beliebigen Zeichenketten, die anderen "kennen" ihre Programmiersprache und können daher beispielsweise Variablen, Befehle, Datenblöcke und Strukturen der Programmiersprache bei der Bearbeitung unterscheiden (wie das CDL2-Labor).

So flexibel ein universeller Editor ist, so umständlich kann die Arbeit damit in einer bestimmten Programmiersprache sein.

"Zusatzausstattung"

Neben dem "kleinen Handwerkszeug" gibt es weitere Werkzeuge, die sich im wesentlichen um zwei Schwerpunkte gruppieren. Die meisten Systeme lassen sich einem der beiden Schwerpunkte zuordnen:

Schwerpunkt Beschreibungsmittel:

- zusätzliche, meist grafische Beschreibungsmittel,

- Beschreibungsmittel für andere als die Programmierphase, also für Modulbeziehungen, Problembeschreibungen etc.,

- Beschreibungsmittel für Planung, Organisation und Nutzung.

Schwerpunkt Informationsverarbeitung:

- Verwalten und Fortschreiben von Informationen wird besonders bei großen und langlebigen Software-Systemen zum Problem. Da hier der Computer eine besondere Stärke hat, ist nicht verwunderlich, daß besonders die Software-Produktions-Umgebungen im industriellen Bereich Datenbanken besitzen.

Probleme

Die offenen Probleme liegen generell bei der mangelnden Abstimmung der Werkzeuge. Auch im einzelnen bleiben Lücken:

- wirklich abgestimmte Werkzeuge für die Produktkontrolle,

- Planungs- und Organisationswerkzeuge,

- Unterstützung der Wartung.

- Unterstützung der Benutzerbeteiligung.

Wir meinen:

Bisher verteilen sich die heterogenen Werkzeuge der Software-Produktion auf verschiedene "Werkzeugkisten". Die Entwicklung wird von diesem "Handwerkzeug" zu "Produktionsmaschinen" führen, mit denen Routinetätigkeiten automatisiert werden können. Damit eröffnen sich Möglichkeiten zu erhöhter Kreativität und zum Denken und Planen von alternativen Lösungen in der Software-Produktion.

8. Offene Probleme

Software-Produktion muß als soziotechnischer Prozeß verstanden werden: Produktion, Planung und Organisation, Benutzerbeteiligung sind die drei Dimensionen, die mit wechselnder Bedeutung, den ganzen Prozeß erfassen. Neben einen fehlenden Gesamtansatz für Software-Produktions-Umgebungen stellen erkannte Lücken und fehlende Bewertungskriterien für Konzepte, Methoden und Werkzeuge offene Probleme dar.

Generell:

Einen Gesamtansatz, der sowohl Lösungen für die technische Produktion als auch für Projekt-Manegement and -Organisation und Beteiligung der Benutzer (soweit sinnvoll) umfaßt, gibt es bisher nicht. Allerdings decken einzelne Systeme bereits einen relativ großen Problembereich ab (SDS, CADES etc.).

Doch selbst im meistbearbeiteten Bereich der technischen Produktion fehlt nicht nur ein Ansatz, der alle Aktivitäten (von Problemanalyse bis zu Wartung und Qualitätskontrolle) umfaßt, es gibt noch erhebliche Lücken bei Problemanalyse, Transformation von Spezifikation in Implementierung und Qualitätskontrolle, ja sogar beim Entwurf. Diese Aspekte sind immer noch nicht im vollen Umfang verstanden .

Im einzelnen:

Software-Produktion als schrittweiser (und interaktiver) Prozeß ist nicht modellierbar. Entsprechende Modelle der Software-Produktion sollten die Entscheidungsräume der verschiedenen am Produktionsprozeß beteiligten Instanzen mit ihren verschiedenen Sichtweisen in Abhängigkeit vom Produktzustand darstellen können. Damit müßten sowohl die Struktur des Software-Produkts als auch der Prozeß seiner Entwicklung abbildbar sein.

Die vorhandenen Konzepte sind zu erweitern um eine Sicht, die Software-Produktion als sozio-technischen Prozeß versteht. In diesem Prozeß sollten dann auch Planung und Durchführung zusammengeführt werden.

Die bereitgestellten Beschreibungsmittel sollten eine ständige Beobachtung des Produktionsprozesses ermöglichen; sie sollten unter anderem umfassen:

- Entwicklungsstand, lnkonsistenzen, Vollständigkeit und Plausibilität von Systembeschreibungen,

- visuelle Unterstützung,

- Überwachung, Dokumentation und Koordination des Entwicklungsprozesses.

Völlig unklar scheint, ob herkömmliche Datenbanken geeignet sind, die speziellen Datenstrukturen und Informationsanforderungen eines Software-Produktionsprozesses zu bearbeiten.

Eine Lücke ist auch bei Werkzeugen zur Produktion interaktiver Software und zur interaktiven Produktkontrolle zu schließen.

Wir meinen:

Solange Auswirkungen von Methoden und Instrumenten nicht systematisch erkannt sind und Maßstäbe für Software-Qualität fehlen, können auch keine befriedigenden Kriterien für die Auswahl und Zusammenstellung der Bestandteile von Software-Produktions- Umgebungen erarbeitet werden. Zwar können für diese Probleme noch keine Patentlösungen angeboten werden, aber inzwischen lassen sich schon die richtigen Fragen stellen, für die jetzt Antworten gesucht werden müssen.

9. Zusammenfassung und Schlußbemerkungen

Die erkannten Mängel heutiger Software-Produktions-Umgebungen können leichter behoben werden, wenn Wirkungsfaktoren ermittelt sind. Eine Universallösung ist nicht zu erwarten. Kurzfristig sind bereits jetzt Zwischenlösungen sinnvoll. Eine neue Sicht der Software-Produktion und -Nutzung wird heutige Produktionsformen entscheidend verändern. Neuentwicklungen von Software-Produktions-Umgebungen müssen mit Blick auf vergleichbare Produktionstechniken erfolgen.

Stand der Entwicklung

Heutige Entwicklungsansätze decken nur einzelne Aspekte der Software-Produktion ab und sind meist auf die technische Produktion beschränkt. Selbst bei Systemen wie SDEM/SDSS, die wesentlich für Managementaufgaben entwickelt wurden, beschränkt sich die Unterstützung auf die Bereitstellung eines Life Cycle Modells und von Handbüchern.

Mit Ausnahme vereinzelter Entwicklungen vor allem in den skandinavischen Ländern wird die Einbeziehung der Benutzer und Betroffenen völlig vernachlässigt.

- Iangfristig:

Wir gehen davon aus, daß in etwa zehn Jahren eine Software-Produktion ohne Software-Produktions-Umgebung wirtschaftlich und bezogen auf die Qualität der Software nicht mehr vertretbar ist. Daher wird sich in diesem Zeitraum die Frage stellen, ob die Software-Produktion im eigenen Haus auf dieses Niveau gehoben werden kann, oder ob dann auf Software-lmport zurückgegriffen werden soll. Die Einführung einer Produktions-Umgebung wird hohen organisatorischen Aufwand und hohe Investitionen auch im Personalbereich erfordern, was schon heute in der Planung berücksichtigt werden muß.

Facit

Der Einsatz von Software-Produktions-Umgebungen wird die heutigen eher experimentellen, handwerklichen Produktionsformen stark verändern. Dabei wird es von forschungspolitischen Ausrichtungen und Entscheidungen mit volkswirtschaftlicher Tragweite abhängen, ob Software-Produktion sich zur "Fließbandarbeit" entwickelt oder ob die Automatisierung von Routinearbeiten Potentiale für menschengerechtere Systeme und Arbeitsplätze schafft. Die Dequalifizierung von DV-Arbeitsplätzen wird jedenfalls nicht durch scheinbare "Sachzwänge" zu erklären sein.

Software-Produktions-Umgebungen werden hohen Investitionsaufwand erfordern, dadurch geht ein Teil der heutigen Flexibilität verloren, und die Produktionstechnik wird längerfristig festgelegt. Wenn dies rechtzeitig berücksichtigt wird, werden Anpassung an die Umwelt und Flexibilität im Einsatz Kennzeichen künftiger Software-Produktions-Umgebungen sein. Eine standardisierte Software-Produktion wird aber zu einer besseren Beherrschung der Technik führen, so daß eine einheitliche Produktions-Technik das heute noch verbreitete Verfahren des "Durchwurstelns" (muddling through) ablösen wird.

Die Software-Produktion wird in vielen Aspekten der modernen Fertigungstechnik gleichen: Modulare, standardisierte Grundelemente werden von verschiedenen Spezialisten auf die Bedürfnisse der Anwender zugeschnitten werden. Die Software-Benutzung wird neben der Systembedienung auch die Anpassung der Systemeigenschaften an die Bedürfnisse des jeweiligen Arbeitsplatzes umfassen.

ICAS-Kurzbeschreibung

Systemeigner:

System Development Laboratory

HITACHI, Ltd.; Kawasaki, 215 Japan

Referenz:

Miura, T.: Kawasaki, J.

System Development Laboratory HITACHI, Ltd.

Laboratory Report October 1980

Abstract:

ICAS ist eine Sammlung von Werkzeugen und Methoden zur Software-produktion. Das System erlaubt die Verwendung von Standard-Spezifikationen und Standard-Modulen.

ISES-Kurzbeschreibung

Systemeigner:

Bell-Northern Research

Ottawa, Ontario, Canada

Referenz:

Pearson, D.J.

ISES - A System for the Formal Capture of Informal Design

Paper presented to IFIP TC10+

Abstract:

ISES ist ein "life-cycle software engineering system" zur Unterstützung von unterschiedlichen Entwurfsverfahren. Es bietet eine einheitliche Benutzerschnittstelle und operiert auf einer zentralen Datenbank.

PDS-Kurzbeschreibung

Systemeigner:

Center for Research in Computing Technology

Harvard University

Cambridge, MA, USA

Referenz:

Cheatham Jr., T.E.

An Overview of the Harvard Program Development System

Proc. Symposion on Software Engineering Environments

Lahnstein, June 16-20, 1980, North Holland Publishing Comp.

Abstract:

PDS ist eine Kollektion von sprachorientierten Entwicklungs-Instrumenten mit besonderer Betonung der Systemvalidation. Es ist das (vorläufige) Endprodukt einer Serie von Programmiersystemen zur Unterstützung der Programmierung in der Sprache EL1.

Plasma-Kurzbeschreibung

Systemeigner:

Triumph-Adler Gruppe

Nürnberg

Referenz:

Balzert. H.; Weber, D.

PLASMA/D - Eine Sprache für den Systementwurf

Proc. Softwareengineering, -entwurf und -spezifikation

GC-ACM. TU Berlin, 15.09.80

Abstract:

Plasma ist ein sprachorientiertes Software-Entwicklungssystem mit einer zentralen Software-Datenbank und einer Methodenbank für die verschiedenen Aktivitäten in der Software-Produktion.

SDS-Kurzbeschreibung

Systemeigner:

BMDATC

Ballistic Missile Defense Advanced Technology Center

Huntsville, AL, USA

Referenz:

Davis, C.G.; Vick, C.R.

The Software Development System: Status and Evolution

IEEE COMPSAC 78

Abstract:

SDS ist ein vollständiges Instrumentarium zur Entwicklung von Software für Prozeß-Datenverarbeitung im Militärwesen.

CADES-Kurzbeschreibung

Systemeigner:

ICL, UK

Referenz:

Pratten, G. D.; Snowdon, R.A.

CADES - Support for the Development of Complex Software

Proc. European Computing Conference on Software Engineering

1976. Online, Uxbridge, England

Abstract:

Das System CADES dient der computergestützten Software-Produktion und verwendet die "structural modelling method". Im Zentrum des Systems steht eine Datenbank, die auch zur Systemgenerierung verwendet werden kann

COSY-Kurzbeschreibung

Systemeigner:

Computing Laboratory

University of Newcastle upon Tyne

England

Referenz:

Lauer, P.E.; et. al.

On the Design and Certification of Asynchronous Systems

University of Newcastle upon Tyne, Computing Laboratory

Final Report, Period 1976-1977, 1978

Abstract:

Die Programmierumgebung COSY ist gedacht für die Entwicklung paralleler Systeme basierend auf der Sprache COSY. In dieser Sprache werden parallele Systeme durch path-expressions beschrieben.

DREAM-Kurzbeschreibung

Systemeigner:

Cray, Laboratories Inc.

Boulder, Colorado, USA

Referenz:

Riddle, W.E. et. al.

DREAM - A Software Design Aid System

Proc. 3rd Jerusalem Conference on Information Technology

Jerusalem, August 1978, North Holland Publishing Comp.

Abstract:

DREAM ist ein Entwurf-orientiertes System für interaktive Software-Entwicklung. Es hat eine zentrale Software-Datenbank. Besonders stark ausgearbeitet sind die Hilfsmittel für die Entscheidungsfindung und -kontrolle.

EPOS-Kurzbeschreibung

Systemeigner:

Institut für Regelungstechnik und Prozeßautomatisierung

Universität Stuttgart

Stuttgart

Referenz:

Biewald, J. et. al.

EPOS - A specification and design technique for computer controlled realtime automation systems

Proc. 4th ICSE. München, Sept. 1979, IEEE Long Beach, CA, USA

Abstract:

EPOS ist ein rechnergestütztes Hilfsmittel für "Automatisierungsingenieure zur problemlosen Untersetzung von Softwarespezifikationen für Prozeßautomatisierung in Programme".

GANDALF-Kurzbeschreibung

Systemeigner:

Department of Computer Science

Carnegie-Mellon University

Pittsburgh, PA, USA

Referenz:

Habermann, A.N.

The Gandalf Research Project

Carnegie-Mellon University, Department of Computer Science

Research Review 1979-1979, 1980, Pittsburgh, PA, USA

Abstract:

GANDALF ist der Versuch, eine Produktions-Umgebung für die Entwicklung von ADA-Software zu schaffen. Insbesondere soll ein Labor für die Überprüfung von ADA- und APSE-Konzepten bereitgestellt werden.

GYPSY-Kurzbeschreibung

Systemeigner:

Institute for Computer Science and Computer Application

Certifiable Minicomputer Project, University of Texas at Austin

Austin, Texas, USA

Referenz:

Good, D.I. et. al.

A Report on the Development of GYPSY

Report ICSCA-CMP-13, Univ. of Texas at Austin, Austin, Texas 78712

Abstract:

Entwurf und schrittweise Verifikation von Minicomputer-Software für Kommunikationssysteme sollen mit GYPSY unterstützt werden.