Mit Bodo Frösch, Leiter Produktmanagement EDV bei der NCR GmbH, Augsburg, sprach Dieter Eckbauer

- NCR setzt im eigenen Haus Werkzeuge für interaktive Programmierung ein. Welche Erfahrungen haben Sie damit gemacht?

Lassen Sie mich zunächst die "interaktive Programmierung" von der "Dialogprogrammierung" trennen - und eine Begriffsdefinition finden. Unter "interaktiver Programmierung" verstehen wir eine Programmierung, bei der die eingegebene Ursprungszeile sofort im Dialog mit dem System auf ihre syntaktische Richtigkeit überprüft wird - im Gegensatz zur "Dialogprogrammierung", bei der die Erfassung und Korrektur, das

Ändern, das Einfügen im Ursprungsprogramm über Bildschirme erfolgt. Wir sind den zweiten Weg gegangen, den der Dialogprogrammierung, da wir der Auffassung sind, daß die Dialogprogrammierung mit einem daran anschließenden schnellen Compilationslauf ebenso effektiv ist wie die interaktive Programmierung.

- Welchen Vorteil hat denn die Dialogprogrammierung, wie Sie sie soeben skizziert haben?

Wir sind diesen Weg ganz bewußt gegangen, weil wir uns damit die Tür offenhalten, die Dialogprogrammierung für jede beliebige Programmiersprache auch auf kleineren Anlagen sofort implementieren zu können. Die Dialogprogrammierung ist sprachenunabhängig und damit flexibler - während die interaktive Programmierung jeweils die Entwicklung des entsprechenden interaktiven Compilers erfordert und damit zwangsläufig ein Zeitgap zwischen der Verfügbarkeit der Systeme und der Verfügbarkeit der entsprechenden Software entsteht. Auch bei der interaktiven Programmierung findet selbstverständlich ein Dialog mit dem System statt. Aber der wesentliche Unterschied zwischen interaktiver Programmierung und Dialogprogrammierung liegt darin, daß bei der interaktiven Programmierung die eingegebenen Ursprungszeilen zwar sofort auf Syntaktik, aber nicht auf Richtigkeit im Programmzusammenhang geprüft werden. Bei beiden Verfahren kann diese wesentlich wichtigere Prüfung erst durch nachfolgende Compilation erfolgen.

- Welche Zeitersparnis bringt der Dialog gegenüber der herkömmlichen Programmiermethoden - und bringt er auch bessere Programme?

Die Zeitersparnis liegt in erster Linie in der Verkürzung des Zeitraums zwischen dem Compilationsergebnis und der Korrektur. Dem Programmierer am Bildschirm ist die Programmänderung, die vor kurzer Zeit erst in dieses Programm eingebracht wurde, noch mehr gegenwärtig; sie wird nicht verdrängt durch den Vorgang des Ablochens und Prüfens im Rechenzentrum und das Warten auf die Compiler-Listen. Darin sehen wir den wichtigsten Vorteil. Die im Dialog erstellten Programme sind im allgemeinen durch die komfortablen Edit-Möglichkeiten übersichtlicher.

- Läßt sich der quantifizieren?

Wir sind der Auffassung, daß Dialogprogrammierung den Zeitraum bis zur sauberen Compilationsliste um mindestens einen Faktor 10 reduziert. Wobei hier noch der Vorteil hinzukommt, daß mehrere Benutzer gleichzeitig im Dialog ihre Programme korrigieren und erfassen können.

- Wir haben bisher - wie ich das sehe - über das reine Programming, über das Codieren, gesprochen. Ist mit der Verbesserung dieser Phase der Software-Entwicklung denn schon viel erreicht?

Sicherlich nicht, das ist der erste Schritt. Denn -die Korrektur allein im Programm beschleunigt die Gesamtentwicklung nicht ausreichend, sie erleichtert lediglich die Programmierung, weil die Korrektur im syntaktischen Zusammenhang mit der Umgebung, in die sie eingefügt wird, auf dem Bildschirm zu sehen ist - im Gegensatz zur Programmierung per Lochkarte, wo die Korrektur isoliert in einer Zeile erfaßt wird, ohne die Umgebung zu sehen.

- Setzt Dialogprogrammierung eine wesentlich höhere Qualifikation beim Programmierer voraus?

Nein, wir haben die Erfahrung gemacht, daß das Hilfsmittel "Dialogprogrammierung" nach einer Anlaufphase von drei bis fünf Arbeitstagen beherrscht wird und sich dann die zuvor erwähnten Vorteile zeigen.

- Die herkömmliche Programmierung hatte den Vorteil, daß die Abläufe chronologisch erfaßt und Änderungen protokolliert wurden. Wie sieht es denn hier bei der Bildschirmprogrammierung aus? Besteht nicht ein gewisses Risiko im Sinne des Datenschutzes, daß sich Eingriffe ins Programm nicht mehr kontrollieren lassen?

Sie haben recht, wenn Sie sagen, es handelt sich hier um ein mögliches Risiko im Sinne des Datenschutzes. Aber wir haben verschiedene Maßnahmen in unserer Dialogprogrammierung, die dieses Risiko absolut minimieren. Stellvertretend steht hier der Kennwortschutz für bestimmte Anwendungen - daß also Programme nicht von jedem Bildschirm aus geändert werden können. Der zweite Schritt, das Dokumentieren der Änderung, wird bewerkstelligt, indem wir vor dem Compilationslauf altes und neues Ursprungsprogramm miteinander abgleichen und einen entsprechenden Print-Out liefern, so daß die endgültige Korrektur, wie sie in den Compiler hineingegangen ist, schwarz auf weiß dokumentiert ist.

- Wenn Dialog eine Zeitersparnis bringt, werden dann nicht Programmierer zum Teil überflüssig?

Wir sehen eher den umgekehrten Trend, daß die Programmieraufgaben in unserem Hause derart steigen, daß wir diese Probleme nur mit diesen Tools lösen können - also in keinem Fall Reduzierung der Arbeitsplätze. Wir können bei weitem nicht alle Aufgaben angehen, die wir uns vorgenommen haben.

- Wie weit ist dieses Instrument beim Anwender bereits im Einsatz?

Wir gehen bei unseren kleineren Systemen den Weg, daß wir dem Kunden Paketlösungen anbieten, er also relativ wenig Eigencodierung hat und damit von der Dialogprogrammierung, das heißt von der interaktiven Erstellung von Programmen, keinen Gebrauch macht - oder nur wenig, um seine speziellen spezifischen Wünsche in die vorhandenen Pakete hineinzuprogrammieren oder um entsprechende Steuerungen für das Betriebssystem zu katalogisieren. Bei größeren Systemen sehen wir den Trend dahin gehen, daß nach wie vor noch genügend Eigenprogrammierung unserer Kunden offenbleiben wird, um dieses Tool einzusetzen.

- Sie befinden sich dabei erst am Anfang?

Wir haben die Dialogprogrammierung bereits zusammen mit unserer 1976 freigegebenen Criterion-Serie der Öffentlichkeit vorgestellt und in den folgenden Software-Releases schrittweise ausgebaut. Das ist also für uns kein Anfang, sondern eine Fortentwicklung.

- Die Frage bezog sich darauf, wie viele Ihrer Kunden bereits im Dialog programmieren?

Hier würde ich sagen, daß wir bei größeren Systemen erst am Anfang dieser Dialogprogrammierung stehen - obwohl die Tools für unsere Anlagen schon seit Jahren verfügbar sind. Wir können aber einen rapiden Meinungsumschwung und die verstärkte Hinwendung zu diesen Tools - nicht zuletzt durch die verschiedenen Publikationen - beobachten.

- Nun legt der Bildschirm als solcher gewisse Zwänge auf. Wie reagiert der Programmierer darauf?

Wir haben die Erfahrung machen können daß er durch Dialogprogrammierung eine gewisse Motivation erhielt, einfach dadurch, daß er auf seine Jobs, auf die ersten Ergebnisse, nicht mehr so lange warten mußte, wie das im Closed-Shop-Rechenzentrum der Fall sein kann.

- Nun ist gelegentlich der Einwand zu hören, Dialogprogrammierung belaste den Zentralrechner, weil ja jeder Programmierer über den Bildschirm in die Anlage reingeht.

Die Belastung durch Dialogprogrammierung liegt in erster Linie in der ständigen Verfügbarkeit der entsprechenden Programme im System und weniger in einem Verbrauch von CPU-Leistung. Deshalb haben wir Dialagprogrammierung schon bei unseren kleinen Systemen 8100 bis 8400 implementiert und führen dies bei den Großsystemen der 8500- und 8600-Reihe durch Leistungserweiterungen fort: Vor zwei Jahren hat Ihre COMPUTERWOCHE bereits eine entsprechende Übersicht veröffentlicht.

- Das hat aber erst die neue Hardware-Technologie ermöglicht.

Das ist richtig. Je größer der Speicher, desto komfortabler kann die Dialogprogrammierung agieren - ohne zu große CPU-Belastung. Aufgrund der gemachten positiven Erfahrungen können wir uns heute eine Programmentwicklung ohne unsere Dialog-Tools nicht mehr vorstellen.