Dokumentation ist ein Wort, das bei jedem Mitarbeiter Zwang assoziiert. Obwohl niemand die Notwendigkeit einer aktuellen Dokumentation bestreitet. ist in den wenigsten Fällen eine Dokumentation auf dem letzten Stand. Die Ursache liegt offensichtlich an der Wartung, da jede Änderung innerhalb einer Anwendung einen mehr oder weniger großen Einfluß auf die Dokumentation hat. Daraus entsteht der Zwang, neben erforderlichen Wartungsarbeiten, die immer so rasch wie möglich und neben anderen Tätigkeiten durchgeführt werden sollen, den weit höheren Aufwand der Dokamentationsaktualisierung zu betreiben.

Die zu erhebende Forderung ist daher, eine Methode zu finden, die den Dokumentationsaufwand minimiert und möglichst maschinell die Aktualisierung durchführt. Diese hinlänglich bekannten Tatsachen führen zur Betrachtung komplexer Dokumentationsmethoden, die auf den ersten Blick bestechend wirken. Denn der Dokumentationszwang wird an die Stelle verlegt, an der der Projektauftrag entsteht.

Durch Vervollständigen der Analyse entsteht die Programmstruktur; durch deren Vervollständigen die Programme und deren Dokumentation. Im ganzen eine perfekte Dokumentation von der Planung bis zum Programm.

Allerdings - jede Norm ist nur dann gut, wenn sie komplett durchgezogen wird.

Probleme der Organisation sind zu klären

Bei näherer Betrachtung solch komplexer Methoden stellen sich wert- und prioritätsfrei Fragen (die keinen Anspruch auf Vollständigkeit erheben) aus dem Bereich der Betriebs- und DV-Organisation.

So aus der Betriebsorganisation:

- Fügt sich die Methode in die betriebsspezifische Struktur ein?

- Sind Abteilungsschnittstellen und Kompetenzen berührt?

- Ist bei den Mitarbeitern Lernbereitschaft vorhanden?

- Kann der höhere Arbeitsaufwand in den Fachabteilungen bewältigt werden?

- Werden alle Fachabteilungen mitziehen?

und aus dem Bereich der EDV-Organisation:

- Sind die laufenden Anwendungen einzubinden?

- Sind Werkzeuge für die Nachdokumentation vorhanden?

- Ist ein neues Data-Dictionary anzulegen?

- Sind die Programmstrukturen kompatibel?

- Ist die Flexibilität bei Wartungen groß genug?

- Ist die Möglichkeit der RZ-Dokumentation gegeben?

- Ist der Schulungsaufwand vertretbar?

- Ist genügend Manpower zur Einführung vorhanden?

Der Aufwand aber um eine perfekte maschinelle Dokumentation zu erhalten, scheint in vielen Fällen zu groß, wobei die Flexibilität und Wartungsfreudigkeit hoch zu bewerten ist.

Trotzdem scheint die Forderung nach Minimierung des Dokumentationsaufwands und rascher Reaktion bei Wartungsarbeiten nicht gegeben. Denn der Änderungsantrag des Endbenutzers, der meist auf ein Planungsversäumnis zurückzuführen ist, hat mehr Wartungsstufen zu durchlaufen als bisher. Auch der Dokumentationszwang wird nicht verringert, sondern verlagert und unter Umständen erhöht.

Methoden entwickeln Eigenleben

Die Anforderungen an eine Dokumentationsmethode lassen sich nicht verallgemeinern, da sie von den betriebsspezifischen Gegebenheiten geprägt werden.

Warum überhaupt eine neue Methode? In den meisten Fällen doch nur deshalb, weil die bisherige Methode im Laufe der Zeit ein Eigenleben entwickelt hat und von den Mitarbeiten unterschiedlich gehandhabt wird.

Eine Lösungsmöglichkeit wäre eine gemeinsame Untersuchung und Entwicklung von verbesserten Normen und Checklisten aus der gewohnten Umgebung, die dann auch der Betriebsstruktur entsprechen. Das Festlegen der statistischen Dokumentationsteile (zum Beispiel Benutzerhandbuch, Programmbeschreibungen, RZ-Dokumentation) und Feststellen der neuralgischen Punkte gehören hierzu.

Denn weder bei standardisierten noch bei gewachsenen Methoden ist das große Problem neue Projekte zu dokumentieren, sondern das Nachdokumentieren von laufenden Änderungen.

Das Benutzerhandbuch kann durch entsprechend formulierte Änderungsanträge, die doch letztlich vom Benutzer kommen, einem Änderungsdienst unterworfen werden.

Langwierige Übergabeprozeduren

Für die Programmdokumentation sind Werkzeuge zu beschaffen oder zu erstellen, die die Möglichkeit bieten, mit geringem Dokumentationsaufwand innerhalb des Programms Änderungsprotokolle und Programmdokumentationen aus dem Quellencode zu erstellen.

Der oft gering geachtete und dennoch größte Aufwand an Dokumentation und deren Wartung entsteht im Rechenzentrum (RZ-Handbuch Schneidepläne, Listenverteiler, Sicherungspläne, Durchführungsrhythmen und vieles andere mehr). Durch diese Anforderungen sind die Übergabeprozeduren an das Rechenzentrum oft sehr langwierig und aufwendig, da neben der Job-Control, die Arbeitsanweisungen und die RZ-Dokumentation zu warten sind.

Dennoch wird vom Rechenzentrum (RZ), zur Gewährleistung der jeweils korrekten Anwendungsdurchführung, ein hohes Maß an Flexibilität und rasche Durchführung gefordert. Mit diesen kaum zu vereinbarenden Anforderungen haben wir uns eingehend beschäftigt und festgestellt, daß fast alle für das RZ erforderlichen Informationen in der Job-Control enthalten sind.

Die daraus entstehende Dokumentationsmethode arbeitet folgendermaßen:

Durch einfache, oft kaum erforderliche Formatierung und Aufnahme einiger zusätzlicher Anweisungen, entsteht aus der eigenen Job-Control eine Informationsdatei, die flexibel und up-to-date ist. Durch entsprechende Auswertungen und Cross-Referenzen (Bildschirm/Drucker) entstehen aktuelle Dokumentationen und Informationen, von denen mancher RZ-Leiter "träumt". Hiermit wird auch im Rechenzentrum die Forderung nach geringem manuellem Dokumentationsaufwand erfüllt. Die erforderlichen Grenzen zwischen der Perfektion und der Flexibilität einer Dokumentationsmethode werden trotz allem immer nur betriebsspezifisch zu betrachten sein.

*Herbert Bock ist Bereichsleiter Systementwicklung DOS-VSE der Apollo GmbH, Neuss.