Die Situation mangelhaft dokumentierter Software in der Praxis; das Unbehagen, Dokumentation schreiben zu müssen; das Problem, mit nicht dokumentierter Software arbeiten zu müssen; Die Unmöglichkeit, nicht dokumentierte Software modifizieren, ändern oder anpassen zu müssen.

*Erika Baumann ist freiberufliche DV-Beraterin in München

Teil 2

Beim Anwender unterscheidet man zwei Personengruppen, die sich mit der Software befassen:

- die Fachabteilungen als eigentliche Endbenutzer;

- das Rechenzentrum, die Defacto-Bediener.

Diese Einteilung trifft zumindest in der Mehrheit für kommerzielle Softwareanwendungen zu.

Mit der wachsenden Anzahl installierter Kleincomputersysteme verschieben sich diese Grenzen.

Ausgehend von der Tatsache, daß Software aus bestimmten Gründen mangelhaft dokumentiert wird, ergeben sich für Anwender und Bediener weitreichende Probleme, wenn sie mit schlecht oder gar nicht dokumentierter Software arbeiten müssen.

Für den Anwender bedeutet das: Er lernt das Softwaresystem nicht als Ganzes kennen, sondern nur Teile davon, nämlich überwiegend die Dateneingabe- und die Datenausgabeseite.

Er stellt bestimmte Daten für eine Verarbeitung durch den Computer zur Verfügung und erhält bestimmte Daten zurück - in der Regel handelt es sich um diverse Auswertungen.

Die fachlichen Abläufe, die funktionalen Zusammenhänge, die hinter einer EDV-Verarbeitung stecken, bleiben dem Anwender verschlossen, weil ihm hierzu keine Dokumentationen ausgehändigt werden. Wenn er nicht selber die Aufgabenstellung für die Softwareentwickler formuliert und die Realisierungsarbeiten verfolgt, kann er den Ablauf nicht nachvollziehen.

Das hat zur Folge, daß Anwender oft, wenn ein System einmal aus bestimmten Gründen nicht die gewünschten Ergebnisse bringt, mißtrauisch gegen das ganze Verfahren werden!

Und für neue Mitarbeiter auf seiten des Anwenders ist es fast unmöglich, sich in die fachliche Lösung eines ihnen bekannten Problems und dessen DV-technische Realisierung einzuarbeiten, wenn als einzige "Dokumentation " Kommentarzeilen zwischen den Statements und unvollständige Beschreibungen im Programmvorspann existieren.

Der Anwender fühlt sich ohne ausreichende Dokumentation sehr alleine gelassen, hat er sich doch für seine fachlichen Aufgabenstellung durch eine EDV-Lösung eine wirkliche Dienstleistung erhofft!

Schlecht dokumentierte Anwendersoftware führt auch dazu, daß der Anwender das System gar nicht in seinem vollen Funktionsumfang nutzen kann.

Auch der Bediener, sei er nun Mitarbeiter im Rechenzentrum oder in der Fachabteilung unter den eigentlichen Anwendern, hat Schwierigkeiten, mit einem mangelhaft dokumentierten System zu hantieren.

Es ist in der Praxis immer wieder zu beobachten, daß Bedienungsanleitungen nicht brauchbar sind.

Der Bediener benötigt zum Beispiel folgende Unterlagen

- Installationsanleitung

- Bedienungshandbuch

- Nachschlagwerk für System- und Fehlermeldungen.

Die Bedienungsabläufe müssen

- einheitlich

- vollständig

- der Reihenfolge entsprechend

beschrieben sein. Der Normalablauf muß getrennt von Sonder- und Fehlerfällen erläutert werden. Es müssen die Voraussetzungen genannt werden, die erfüllt sein müssen, um ein System oder Programm starten zu können.

Die Nennung einer Fehlermeldung, oder gar nur einer Fehlernummer, nützt nichts; es müssen die Maßnahmen genannt werden, die im Fehlerfall zu ergreifen sind. Das gilt insbesondere bei "Abstürzen", wenn es gilt

- eventuelle Fehlerursachen zu finden

- eine Verarbeitung wieder aufzusetzen

- eine Dialogverarbeitung sicherzustellen

- im Doppelrechnerbetrieb auf einen anderen Rechner "umzuschalten"

- Datensicherung zu betreiben

- Daten wiederherzustellen

etc.

Eine Folge der mangelhaften Dokumentationen für Anwender und Bediener ist, daß sie

- ein System "ausprobieren" müssen

- sich ihre Dokumentationen basierend auf eigenen Erfahrungen selbst schreiben

- ein EDV-System gar nicht effektiv nutzen können

- auf "eingeschworenes" Personal nicht mehr verzichten können (Urlaub, Krankheit).

Aber nicht nur für den Anwender/Bediener bringt schlecht dokumentierte Software Schwierigkeiten. Auch der Softwareentwickler wird (wieder) damit konfrontiert, wenn eine bestehende Software

- geändert

- modifiziert

- angepaßt

werden muß.

Änderungen sind auch bei einem noch so guten Softwarekonzept unvermeidlich, denn es gibt immer

- Änderungen aufgrund fachlicher Gegebenheiten

- Modifikationen aufgrund organisatorischer Veränderungen

- Anpassungen aufgrund äußerer Umstände zum Beispiel Anpassung an gesetzlicher Verordnungen.

Aber mangelhaft dokumentierte Software kann nicht sinnvoll geändert werden, da bleiben Änderungen Zufall! Änderungen aber sollen

- sicher

- gezielt

- kontrollierbar

- abgestimmt

vorgenommen werden, sonst gibt es Überraschungen, und zwar meist nicht beim Testen, sondern in späteren Produktivläufen.

Unerläßlich ist auch, daß eine vorgenommene Änderung selbst dokumentiert wird, und zwar nicht isoliert, sondern im Zusammenhang des gesamten Systems.

Verhängnisvoll kann die Änderung von

- Programmschnittstellen

- Datendefinitionen

- Parametern

- Ablaufstrukturen

sein, wenn nicht wirklich vollständige Dokumentationen vorliegen und diese die Basis für eine notwendige Änderung sind. Die tägliche Praxis liefert hierzu vielfältige Beispiele, sodaß hier auf deren Nennung verzichtet werden kann.

Aus dem hier Gesagten ergibt sich die uneingeschränkte Notwendigkeit, Software ausreichend zu dokumentieren. Prinzipien, Methoden und Verfahren hierzu gibt es, sie sind ebenso lehrbar und lernbar wie zum Beispiel die Methoden der Softwaretechnologie und der Softwareplanung.

Wird fortgesetzt