Die Dokumentation begleitet das Projekt von der ersten Stunde bis zum endgültigen Abschluss.
So ist z.B. bereits bei der Vorstudie zu kontrollieren, ob die gewählte Lösungsvariante tatsächlich mit den Projektzielen vereinbar ist. Anhand eines Beispieles aus der Praxis soll demonstriert werden, warum die laufende Dokumentation schon bei der Vorstudie so wichtig ist.
Bei der Vorstudie wird sehr viel Zeit mit dem Abwägen der einzelnen Lösungsvarianten oder von Teilbereichen daraus verbracht. Dabei treten zahlreiche Argumente für oder gegen einen Vorschlag auf.
Werden die Argumente, warum man sich für eine bestimmte Variante und nicht für andere Vorschläge entschieden hat, nicht ausreichend begründet und dokumentiert, so läuft man Gefahr, dass nach einiger Zeit (u.U. von anderen Personen) wieder über dasselbe Problem nachgedacht wird, und dass dabei einige wesentliche Argumente von damals in Vergessenheit geraten sind.
Jede Besprechung sollte systematisch protokolliert und geordnet - am besten in einer Datenbank - gespeichert werden. Mittels Stichwörtern, Teilnehmern oder Datum sollte auf das jeweilige Protokoll zugegriffen werden können.
Ein wesentlicher Punkt ist die Dokumentation der Programme selbst. Zunächst sind die Funktionen aller verwendeten Module zu beschreiben. Die Verwendung bzw. der gegenseitige Aufruf sollte u.U. grafisch dargestellt werden.
Der Programmcode selbst sollte mit ausreichenden Kommentaren versehen werden. Was als ausreichend zu bezeichnen ist, hängt von der gewählten Programmiersprache und dem jeweiligen Problem ab. In einer Richtlinie der IBM kann bis zu einem Verhältnis von 1 : 25 (ein Befehl mit 25 Wörtern Kommentar) gehen.
Eine gute Dokumentation erleichtert die Wartung der Software wesentlich und macht einen Personalwechsel nicht zur mittleren Katastrophe!
Jeder Softwareentwickler - besonders Entwicklungsgruppen - müssen eigen Richtlinien darüber aufstellen, wie Programme aufgebaut, Variablen und Felder benannt und wie die Benutzeroberfläche zu gestalten ist. Diese Richtlinien sind zu dokumentieren!
Wenn man allerdings das Rad nicht neu erfinden möchte, kann man sich an bestehenden Richtlinien orientieren. Beispielsweise hat Microsoft einen "style guide for applications" herausgegeben.
Viele Anwender sind beruhigt, wenn Sie zu der Software umfangreiche Handbücher erhalten. M. E. können diese allerdings durch ein gut aufgebautes Hilfesystem ersetzt werden. Wichtig ist jedoch für die Anwender, die spezifische Benutzung der Software zu dokumentieren. Dies geschieht meist in der Form eines Organisationshandbuches, in dem beispielsweise die Verwendung aller Schlüsselbegriffe, Merkmale und anderer Kennzeichen festgelegt ist.
|