Auch der Programmierplatz soll so menschengerecht wie möglich gestaltet werden. Um eine Überforderung des geistig tätigen Mitarbeiters durch Doppelbelastungen aus parallel zu bearbeitenden Projekten einerseits und alternativ- unproduktive Wartezeiten zu vermeiden sollte dem konventionellen ein interaktiver Entwicklungsplatz vorgezogen werden. Erhöhte Qualität und Quantität des Produktes Software werden die anfänglichen Investitionskosten für geeignetes Programmierwerkzeug schnell amortisieren. Die größere Befriedigung des Mitarbeiters in seiner Arbeit ist ein nicht zu unterschätzender Nebeneffekt.

Daß und warum die Eingabe und Änderung von Programm-Quelltexten über Bildschirme unmittelbar in die rechnergestützte Datenhaltung sinnvoller, ist als traditionelle Datenerfassungs-Verfahren braucht hier wohl nicht mehr ausführlich erläutert zu werden: Viele Unternehmen kennen die Vorteile der Online-Bildschirm-Erfassung ja schon sei es beim Programmierer selbst, in den Fachabteilungen oder auch im Textverarbeitungs-Sekretariat. Im wesentlichen wird jedoch dabei das Codierblatt nur durch einen Bildschirm ersetzt und meist wird die Ersterfassung - vor allem wenn es um Programme geht von einer Datentypistin erledigt.

Der wesentliche Vorteil des Bildschirmes besteht darin daß Tippfehler schnell und unproblematisch korrigiert werden können und die Daten direkt in den entsprechenden Bibliotheken gespeichert werden also auf Arbeitsvorbereitung und Operating verzichtet werden kann. Eingabefehler werden vom Programmierer später selbst korrigiert wie auch die weitere Bearbeitung dann meist durch ihn selbst erfolgt.

Ein auffallender Mangel dabei ist jedoch häufig die Zeitdauer zwischen der Übergabe der Codierblätter an die Datentypistin und dem Erhalt eines Programm-Ausdrucks sowie benötigter Ausgabelisten wie Übersetzungsprotokolle, Testergebnisse und ähnliches aus dem Rechenzentrum. Diese Zeit beträgt in der Regel einige Stunden und kann bei Überlastung des Erfassungspersonals, des Test- und Entwicklungsrechners oder des Rechenzentrums bis auf Tage anwachsen.

Im folgenden soll zuerst auf die Konsequenzen dieser Wartezeiten für die Programmierproduktivität und -qualität eingegangen werden. Anschließend werden deren Ursachen und die Möglichkeit ihrer Beseitigung sowie zusätzliche Vorteile, die sich durch einen dedizierten Software-Entwicklungs-Rechner für die Arbeit der Programmierer ergeben, erläutert.

Die Arbeitsweise des Programmierers

Programmieren ist eine Tätigkeit, die sehr hohe Konzentration und intensive Einarbeitung in das jeweils bearbeitete Problem erfordert. Auch eine gute Programmiertechnik ("strukturierte Programmierung") kann nicht vermeiden, daß Fernzusammenhänge zwischen verschiedenen Programmteilen auftreten. Diese müssen dem Programmierer jederzeit bewußt sein, da ihre Nichtbeachtung die entscheidenden - und oft am schwersten aufzudeckenden - Fehlerursachen in Programmen sind.

Diese Forderung gilt sowohl bei der Programm-Neuentwicklung als auch bei der Wartung und Weiterentwicklung - bei Aufgaben der zweiten Art sogar eher noch stärker, da das zu wartende Programm von dem daran arbeitenden Programmierer überhaupt nicht oder schon vor längerer Zeit entwickelt wurde und er deshalb die wichtigen Fernzusammenhänge entweder erst mühsam aufdecken oder sich wieder ins Bewußtsein rufen muß (dies ist übrigens der Grund für die hohe Fehleranfälligkeit und der um Größenordnung geringeren Produktivität bei Wartungsarbeiten gegenüber der Programm-Neuentwicklung.

Deshalb ist es wünschenswert, daß ein Programmierer Aufgaben nicht parallel bearbeitet. Zwingen ihn widrige Arbeitsumstände - lange Wartezeiten auf benötigte Listen, Testresulate - dazu, häufig zwischen verschiedenen Arbeiten zu wechseln, so erforert dies eine geistige Umstellung, für die auch ein sehr "beweglicher" Mensch eine nennenswerte Zeit braucht: Er ist erst nach einem Zeitraum von vielleicht ein bis zwei Stunden wieder "voll da", in dem Sinne daß er das gesamte, von der vorhergehenden Aufgabe "zurückgedrängte" Wissen, das aktuelle Problem reaktiviert hat. Liegen die erzwungenen Unterbrechungszeiten nun ebenfalls in der Größenordnung von einigen Stunden, so arbeitet der Programmierer fast dauernd mit wesentlich gesenkter Leistungsfähigkeit. Es erhebt sich dann die Frage, ob es überhaupt sinnvoll ist, Aufgaben parallel bearbeiten zu lassen, oder ob die Wartezeiten

nicht von vornherein als Leerzeiten betrachtet werden sollen.

Persönlichkeitsstruktur berücksichtigen

Dafür gibt es durchaus erwähgenswerte Gründe:

o Die geminderte Leistungsfähigkeit während der Umstellungszeit senkt nicht nur die Produktivität, sondern auch die Qualität der Arbeit. Sei es durch nicht vollständiges Überblicken der Fernzusammenhänge, durch mangelnde Konzentration, durch "Verwechseln" wesentlicher Parameter der gleichzeitig zu bearbeitenden Aufgaben oder durch sonstige Gründe- Programmierer wird in der geistigen Umstellungsphase mehr Fehler machen als normal, und diese können mit ihren Behebungs- und Folgekosten den ohnehin nur geringen, durch "Ausnutzen" der Wartezeiten, erreichten Produktivitätsgewinn leicht überkompensieren.

o Jeder Manager weiß, wie anstrengend und streßerzeugend häufige Unterbrechungen und Umstellungen bei geistig anspruchsvollen Arbeiten sind. Die hohe Streß-Stabilität, die einer der wichtigsten Qualifikationen für Managementfunktionen ist, kann aber nicht von jedem Mitarbeiter gefordert werden; anderfalls sind je nach seiner Persönlichkeitsstruktur leistungshemmende Reaktionen wie Fahrigkeit bei der Arbeit, Unzufriedenheit, Angst vor Versagen, Verweigerung, Aggressivität oder - letztlich - Lösung des Arbeitsverhältnisses zu befürchten.

Häufig wird deshalb Parallelarbeit an mehreren Aufgaben selbst bei Leerzeiten bewußt vemieden, sei es aus grundsätzlichen Erwägungen des DV-Managements oder des Projektleiters oder als stillschweigende Duldung eines entsprechenden Verhaltens der einzelnen Programmierer. So wird häufig der Programmierer mit nur einer Aufgabe betraut, so daß zumindest für eine grobe Abschätzung Wartezeiten als Verlustzeiten zu werten sind.

Es ist deshalb zu beachten, daß ein Programmierer nach Abgabe seiner Codierblätter bis zum Erhalt der Listen oft nur mit Schwierigkeiten sinnvoll am Projekt weiterarbeiten kann. Seine Projektarbeit wird in diesen Wartezeiten möglicherweise nur in mehr oder weniger wichtigen Diskussionen, Aufräum- oder Verwaltungstätigkeiten oder "unbewußtem" Nachdenken bestehen.

Akzeptiert man, daß die derzeit entstehenden Wartezeiten zu Produktivitäts- und vielleicht Qualitätseinbußen führen, so erhebt sich die Frage, ob mit der gegenwärtigen technischen Realisierung der Host-Bildschirm-Schnittstelle eine bessere Organisation der Arbeit möglich wäre, welche die Wartezeiten vermindert oder- optimal - beseitigt. Dies scheint nicht der Fall zu sein. Die Wartezeiten entstehen fast ausschließlich durch zwei hintereinander geschaltete Engpässe, nämlich

(1) die Erfassung der vom Programmierer auf Codierblätter geschriebenen Programm-Quelltexte oder Änderungen durch eine Datentypistin oder auch durch ihn selbst

(2) die Verweilzeiten im Entwicklungsrechner, in seiner Drucker-Warteschlange und für die Druckausgabe ihre manuelle Bearbeitung und die Verteilung der Drucklisten.

Daß der unter (2) zusammengefaßte Anteil systemimmanent und nur durch eine technische Verfahrensänderung - wie der Verwendung eines dedizierten Software-Entwicklungs-Rechners beseitigt werden kann, ist unmittelbar einsichtig. Dagegen muß der Erfassungaufwand (1) kurz diskutiert werden. Wäre es grundsätzlich möglich, mit der gegenwärtigen Bildschirm-Schnittstelle die Programmierer ihre Texterfassung unmittelbar, ohne Zwischenschaltung der Datentypistin, durchführen zu lassen?

Dies muß verneint werden, weil wie jeder auch nur flüchtig mit Programmierung und Wartung Vertraute weiß, die Erstellung oder Korrektur eines Programmes nicht sequentiell "heruntergeschrieben" werden kann. Sie erfordert vielmehr ein häufiges Vor- und Zurückgehen im gesamten Text mit zahlreichen, oft iterativen Korrekturen, Einschüben und Streichungen. Deshalb muß der Programmierer nicht nur den gesamten, von ihm bereits erstellten Text "vor sich haben" - in Form von Listen, Codierblättern oder, besser, genau in der jeweils zuletzt erreichten Fassung auf dem interaktiven Bildschirm. Er muß auch in der Lage sein, die zu bearbeitende Stelle frei auszusuchen und zu wechseln.

Die traditionellen Pragrammiersysteme bieten jedoch keinen, echten" freizügigen Bildschirmdialog sondern im Grunde nur eine sequentielle "Schreibmaschinen "-Schnitttstelle, welche durch die Benutzung von Video-Terminals lediglich etwas benutzerfreundlicher gemacht wurde (schnellere Eingabe und Rückmeldung, weniger Geräuschbelastung).

Damit ist sie als direktes Eingabemedium für den Programmierer nicht verwendbar, und auf die Zwischenschaltung der Datentypistin kann derzeit nicht verzichtet werden.

Vorteile einer Dialogschnittstelle

Die Eliminierung der oben aufgeführten Wartezeiten ist vermutlich der größte und sicher am besten zu quantifizierende Vorteil am Produktions- und Qualitätszuwachs, den eine Umstellung der Programmierung auf eine Schnittstelle wie sie ein Software-Entwicklungs-Rechner wie Pet bietet verursacht. Zusätzlich sollte jedoch auch noch auf einige weitere der durch ein solches System gebotenen "echten" Bildschirm-Dialogprogrammierung eingegangen werden.

Der Programmtext ist nicht die einzige von einem Programmier benötigte und bearbeitete lnformation braucht während seiner Arbeit noch weitere Dokumente und Daten wie etwa

o Vorgaben und Aufträge,

o Spezifikation und Dokumentation

o andere Programmtexte (zum Herauskopieren von Codeabschnitten

o Notizen,

o Meldungen (beispielsweise über geänderte Konventionen Schnittstellen und Systemmerkmale),

o Verzeichnisse vereinbarter Namen,

o Makros, JCL-Rümpfe und ähnliche Textbausteine.

Ein solches System erlaubt ihm, alle zu gegebenem Zeitpunkt benötigten Texte und Datenbestände über Bildschirm auf Tastendruck ohne merkliche Verzögerung einsehen und bearbeiten zu können.

Je nach Entwicklungssystem ist es dem Programmierer möglich, auch auf Hostleistungen wie interaktives Debugging zuzugreifen. Auf diese Weise kann er seine Arbeitskapazität auf die eigentliche Aufgabe der Programmentwicklung konzentrieren, da Zeitaufwand und intellektueller Einsatz für Randaufgaben durch den Rechner möglichst gering gehalten wird.

*Karl-Heinz Herrmann ist Prokurist der Softlab GmbH und im Bereich Produktvertrieb und Marketing tätig.