LÜNEBURG - Methodenbausteine, Normungsgrundsätze für die Dialogprogrammierung und ein Datenbankentwurfs-Konzept waren die Hauptthemen der diesjährigen Konferenz des Orgware-Benutzerrings (OBR) in Lüneburg (CW-Nr. 27 vom 4. Juli 1980). Der OBR - nach Meinung von Manfred Wagner, Prokurist der Wilhelmshavener ADV/Orga GmbH, "effizienter als jeder andere User-Klub, ob er nun Scout oder anders heißt" - bot den ADV/ Orga-Kunden und -Gästen auch die Möglichkeit, sich über DV-Konzeptionen und -Realisierungen bei Anwendern zu informieren.

Ein wesentliches Ziel der Arbeit im Orgware-Benutzerring und seinen Arbeitskreisen sei es, erklärte Gunther Lüth, Bereichsleiter Methoden bei ADV/Orga, an der Lösung der Akzeptanz-Probleme neuer Methoden mitzuwirken, wie sie beim Anwender vor Ort immer wieder auftreten. Ehe in den Arbeitskreisen einheitliche Auffassungen zu den vielen schwierigen Einzelfragen dieses Themengebietes zu erreichen seien, komme es - und dies könne niemanden wundern häufig dazu, daß die "Fetzen fliegen"; er selbst, meinte Lüth, werte des durchaus als Qualitätsmerkmal.

Methodenintegration statt -konfrontation

Lüth vertrat vor den Konferenzteilnehmern die Auffassung, es könne den Orgware-Benutzern wie auch dem Hause ADV/Orga nur um eines gehen: Um Methodenintegration statt Methodenkonfrontation. Es spiele nämlich keine entscheidende Rolle, ob der Orgware-Benutzer gleichzeitig auch Anwender etwa von Jackson, HIPO, Delta oder der Structured Analysis and Design Technique (SADT) sei. Zurückhaltender formulierte es Siegried Heinze, Bereichsleiter Systementwicklung beim Großversandhaus Quelle: Nach seinen Beobachtungen "erlaubt Orgware weitgehend die Verwendung bereits eingesetzter Tools, Packages etc.". Heinze sagte aber auch, Orgware 4 sei für ihn das beste Vorgehensmodell für die Projektentwicklung. ADV/Orga offeriert Orgware 4 als ein Arbeitssystem zur Planung und Implementierung von Informationssystemen .

ADV-Methodenberater Uwe Haun berichtete dem Plenum, der Unterarbeitskreis Wartung habe im zurückliegenden Jahr einen Baustein zur Systemwartung auf der Basis von Orgware 4 erarbeitet, der nun fertig beschrieben vorliege. Haun erläuterte, die eigentlichen Probleme der Maintenance lägen in ihrer Vorbereitung, sehr viel weniger in der Durchführung.

Wartung richtig planen

Um der Gefahr einer durch unsystematische Wartung verursachten Software-"Aushöhlung" - so Haun - vorzubeugen, sei eine spezielle Checkliste entstanden, ferner eine Sammlung von Standard-Wartungsfällen. Immer aber bleibe noch zusätzlich eine Anpassung der Orgware 4-orientierten Systemwartung an firmenspezifische Gegebenheiten vorzunehmen, unterstrich Haun, wobei er eine zehn Tage dauernde Anpassungsberatung durch ADV/Orga als Erfahrungssatz angab.

Der Unterarbeitskreis DB/DC sei, nachdem er im vergangenen Jahr das entsprechende Konzept geliefert habe, in diesem Jahr nun mit den konkreten Vorgehensmodellen Orgware 4-Anwender bei der Entwicklung eines logischen Datenbank-Designs sowie eines Kommunikationsverfahrens fertig geworden, teilte ADV-Methodenberater Karl Anton Dreibholz mit. "Das Ergebnis ist gut", meinte Dreibholz und präsentierte den Zuhörern für den DB-Teil und den DC-Teil je eine "Untercheckliste". Die Liste für den DB-Baustein enthält die drei Hauptarbeitsschritte:

-Erarbeiten Datenkataloge (darunter das Definieren der Datenelemente)

-Definieren logische Segmente (darunter das Ableiten von Objekten)

-Bilden logischer Strukturen (darunter als Abschlußmaßnahmen das Übergeben der Dokumentation für das Konzipieren physischer Strukturen) .

DB/DC-Modulbaustein

Die vier Hauptarbeitsschritte der Untercheckliste DC-Baustein tragen die Bezeichnungen

-Festlegen Kommunikationsablauf

-Festlegen logische Transaktionen

-Überprüfen Realisierungsmöglichkeit.

Dreibholz wies darauf hin, daß die Anwender den neuen DB/DC-Baustein durch Modulaustausch in ihr Orgware 4-System integrieren können.

Zum Thema "Normierung und Dialogprogrammierung" berichtete Wolfgang Pätzold, Mitgeschäftsführer der ADV/Orga, die Wilhelmshavener hätten - ursprünglich für den internen Gebrauch - ein Handbuch entwickelt mit dem das Chaos, das aus den zunehmenden Dialog-Anwendungen einerseits und den fehlenden Standards andererseits zu entstehen drohe, abgewendet werden könne. Pätzold rechnete vor, auf 100 Beschäftigte komme in der Bundesrepublik derzeit zwar nur ein Terminal, in den USA aber bereits eins auf 48 und in absehbarer Zeit sogar eins auf zehn Beschäftigte.

Als "Ansätze, die wir gefunden haben", zählte Pätzold auf: Bildaufbau normen, dialogspezifische Funktionen automatisieren, Dialogsteuerung automatisieren, Dialogverarbeitung normen, Richtlinien und Standards vorschreiben (verbindende Tools), schließlich die Unabhängigkeit von DC-Monitoren- und DB-Systeme-Herstellern. Alle nach diesen Normen erstellten Transaktionen, versicherte Pätzold, seien herstellerneutral. Als DC-Sprache habe man die KDCS-Schnittstellennorm gewählt.

Programmierzeit nur noch ein Zehntel

Über die Ergebnisse des Dialogprogrammierungs-Workshops berichtete ADV-Methodenberater Adalbert Fritz. Nach seiner Darstellung soll und kann das ADV/Orga-Konzept serienmäßige, normierte, bedienerfreundliche, DB/DC-unabhängige, keine DC- Kenntnisse erfordernde und mit bis zu 90prozentiger Arbeitsersparnis zu er stellende Dialogprogramme gewährleisten. Zu den Merkmalen des Konzepts gehören die "Normierten Bilder" - hier ist bei der Änderung von Feldinhalten stets auch die bisherige Eintragung auf dem Bildschirm sichtbar - und ein "Rahmenprogramm" (siehe Grafik), in das der Benutzer zu einem gewissen Teil auch individuelle Benutzerdaten und Moduln einzubringen hat.

Im Urteil der Konferenzteilnehmer kommt die normierte Dialogprogrammmierung gut weg wegen ihrer - in dieser Reihenfolge - Wartungsfreundlichkeit, Zeitersparnis, automatischen Unterstützung der Einhaltung von Richtlinien und der (oben erwähnten) Normierten Bilder. Als Problempunkt hingegen betrachten die DV-Leute - ebenfalls in dieser Reihenfolge - die Schnittstelle zu schon vorhandenen Systemen, die notwendig werdende Anpassung an des jeweilige Anwenderumfeld und die Programmiersprache (derzeit steht nur Cobol zur Verfügung).

Dennoch: "Die Jackson Strukturierte Programmierung hilft Ihnen dabei nicht; und auch die Normierte Programmierung hat beim Dialog ihre Grenzen", redete Gunther Lüth den Zuhörern ins Gewissen und trug so vermutlich mit dazu bei, daß die Normierung der Dialogprogrammierung zum Abschluß der Konferenz mit in das OBR-Arbeitsprogramm für das kommende Jahr aufgenommen wurde.

CSD einstweilen noch nicht standardisiert

Anwenderberichte zum Thema "Computerunterstützte Systementwicklung und Dokumentation" (CSD) gaben Siegfried Heinze, Wolfgang Hinze von der Datev eG und Karl F. Grüter von der Colonia Versicherung. Ein Workshop über "die Methodenbank als Schlüssel zur CSD", geleitet von ADV-Methodenberater Helmut Gomolzig, arbeitete unter anderem heraus, daß CSD ohne die Beachtung der Orgware 4-Vorgehensmodelle unmöglich sei, daß das Methodenproblem hauptsächlich ein Managementproblem ist und daß - vor allem wegen der individuell unterschiedlichen Softwaregegebenheiten - augenblicklich nur firmenspezifische CSD-Lösungen realisierbar sind. Erster Methodenbank-Anwender in praxi wird ab Februar 1981 Quelle sein.

Die Methodenbank, meinte Gunther Lüth, illusionslos, ist "kein sehr marktfähiges Produkt, doch stellte er keinen Zusammenhang her zwischen dieser Aussage und der Tatsache, daß ADV/Orga beim zuständigen Bundesminister CSD zur Förderung eingereicht hat. Die CSD-Workshop-Teilnehmer hatten sich auch über die Vorzüge sowie die Akzeptanz- und Realisierungsschwierigkeiten einer Methodenbank Gedanken gemacht und stellten sie dem Plenum zur Abstimmung. Ergebnisse:

Erwartete Vorteile

Qualitätssicherung und -steigerung

(37 Stimmpunkte)

Verbesserung der Dokumentation

(31 Stimmpunkte)

bessere Systemwartungsmöglichkeiten

(20 Stimmpunkte)

Steigerung der Normierung des Vorgehens

(18 Stimmpunkte)

Insgesamt wurden 192 Punkte verteilt.

Erwartete Akzeptanzprobleme

Einführungsaufwand

(49 Stimmpunkte)

das Management überzeugen

(35 Stimmpunkte)

Angst vor Kontrollierbarkeit

(34 Stimmpunkte)

schwierige Handhabung

(26 Stimmpunkte)

Insgesamt wurden 187 Punkte verteilt.

Erwartete Realisierungschwierigkeiten

hoher Entwicklungsaufwand

(60 Stimmpunkte)

Nachweis der Wirtschaftlichkeit

(38 Stimmpunkte)

höhere Priorität von Anwendungsprojekten

(37 Stimmpunkte)

unzureichende Personalkapazität

(32 Stimmpunkte)

Insgesamt wurden 206 Punkte verteilt.

Die "Methodik des Datenbank-Designs aus nutzerorientierter Sicht" war ein weiterer Themenkreis, der in Lüneburg behandelt wurde. Der betreffende Vortrag von ADV-Methodenberater Heinz Münzenberger zeitweise assistierte ihm Karl Anton Dreibholz - geriet fast zu einer Gastvorlesung. Denn der in Friedrich A. Meyers Softwarefabrik erarbeitete Entwurf ist vom Orgware-System (und auch vom neu vorgestellten DB/ DC-Baustein) völlig unabhängig und war die zuhörenden Orgware-Benutzer daher nur indirekt "verwertbar". Entwickelt wurde das Konzept aufgrund eines Auftrags des Koblenzer Bundesamts für Wehrtechnik und Beschaffung, einem Nicht-Orgwareanwender. CW wird auf diese Entwurfsmethodik in der nächsten Ausgabe gesondert eingehen.