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

Es gibt eine ganze Reihe von Standards und Richtlinien für die Erstellung von Software. Diese beziehen sich zumeist auf den Entwurf und das Design von Softwaresystemen.

Software erstellen heißt aber auch, und das hat der erste Teil dieser Serie gezeigt, die Entwicklungsschritte und -ergebnisse zu dokumentieren. Auch zu diesem Thema wurden Standards, Normen und Richtlinien erarbeitet.

Standards sind Regeln, die ein beispieIhaftes, musterhaftes Vorgehen beschreiben, nach denen eine bestimmte Tätigkeit vereinheitlicht durchgeführt werden kann. Dokumentationsstandards sind also Regeln, nach denen Softwaredokumentation erstellt werden kann. Es gibt Standards für

-Entwicklungsdokumentation,

- Anwenderdokumentation,

- Benutzerdokumentation,

- Vertriebsdokumentation.

Solche Standards sind aus vielfältiger Projekterfahrung gewachsen, sie sind das Ergebnis praktischer Arbeit, das heißt empirisch entstanden. In den Software-Entwicklungsabteilungen großer EDV-Hersteller und in großen Softwarehäusern werden solche Standards erarbeitet. Es handelt sich also zunächst um internes Know-how, das jedoch auch Außenstehenden zum Teil zugänglich ist. Dokumentationsstandards beinhalten

- Vorgehensweise

- Art und Inhalt

- Methodik

beim Erstellen von Softwaredokumentation.

Sie sind nicht zu verwechseln mit EDV-gestützten Dokumentationssystemen, wie sie von Herstellern und Softwarehäusern auch angeboten werden. Für den Softwareentwickler, der nicht beim Hersteller oder im Softwarehaus tätig ist, heißt das, daß er sich häufig seine Standards selbst erarbeiten muß, wozu Richtlinien ein erster Schritt sein können.

Es gibt auch Standards für Teilbereiche der Softwaredokumentation:

- Standards zur Beschreibung von Daten oder Dateien hierzu gibt es einheitliche Formulare;

- Standardinhaltsverzeichnisse für - Pflichtenheft oder Leistungsbeschreibung.

Der Softwareentwickler kennt Methoden und Standards für den Entwurf und das Design von Programmen; etwa die Methoden HIPO oder Strukturierte Programmierung. Diese Methoden unterstützen nicht nur den Entwurf, sondern auch die Dokumentation eben dieses Entwurfs.

So betrachtet, stehen dem Softwareentwickler eine ganze Reihe von Standards zur Verfügung, die er für seine praktische Arbeit verwenden kann.

Zusätzlich gibt es Dokumentationsnormen. Eine Norm ist eine verbindliche Regel. Sie wird erarbeitet und herausgegeben vom Deutschen Institut für Normung und ist allgemein als DIN-Norm bekannt. Normen werden auf nationaler Ebene herausgegeben. Für das Gebiet Softwaredokumentation gibt es folgende Normen:

- DIN 66001 Symbole für Datenflußpläne

- DIN 66230 Programmdokumentation

- DIN 66231 Programmentwicklungsdokumentation

- DIN 66232 Datei-, Datensatz- und Datenfelddokumentation.

Neben deutschen Normen gibt es amerikanische und schwedische Normen. Normen sollten, wie man das aus anderen technischen Bereich kennt, eigentlich allgemeinverbindlich sein, weil sonst der Sinn einer Norm nicht erfüllt ist. Die Herausgabe vor allem der Norm 66230 hat seinerzeit bei Herstellern und Anwendern einen Sturm der Entrüstung ausgelöst, der zu einer Überarbeitung dieser Norm führte. Auch heute noch sind diese Normen vielfach nicht anwendbar, wie die Dokumentationspraxis zeigt, weil sie nicht die eigentliche Dokumentationsprobleme treffen, und weil die Anwendungen, deren Entwicklung dokumentiert werden soll, sehr speziell sind. Die Normen sind einfach um Jahre zu spät gekommen.

Wenn von Standards und Normen die Rede ist, müssen auch Dokumentationsrichtlinien erwähnt werden. Richtlinien beschreiben ein für einen Teilbereich verbindliches Vorgehen. So gibt es

- projektspezifische

- anwendungsspezifische

- kundenspezifische

Dokumentationsrichtlinien, die so lange gültig sind, wie das Projekt dauert, die Anwendung realisiert ist, für einen bestimmten Kunden gearbeitet wird. Richtlinien sind also im Gegensatz zu Standards in einem kleineren Bereich verbindlich. Richtlinien können sich an Standards und Normen orientieren.

Dem Softwareentwickler stellt sich jetzt die Frage: Woher weiß er, welche Standards es gibt; wie kommt er an diese Standards und wie kann er sie erlernen?

So banal und selbstverständlich es klingen mag, oft genügt es, sich bei den Kollegen in der eigenen Abteilung oder einer anderen Abteilung zu erkundigen. Leider wird hier sehr häufig aus Prestigegründen ein ernsthafter Erfahrungsaustausch gescheut! Darüber hinaus kann man sich in der Fachliteratur informieren oder bei Fachtagungen Neues kennenlernen. Auch Institutionen wie die GMD (Gesellschaft für Mathematik und Datenverarbeitung) und die Gl (Gesellschaft für Informatik) können hier Auskünfte geben. Des weiteren sei verwiesen auf den ISIS-Report und die zahlreichen Veröffentlichungen realisierter EDV-Systeme.

Wie kann ein Softwareentwickler schließlich solche Standards, Richtlinien und Normen erlernen und in seine Arbeit integrieren? Dazu gibt es folgende Möglichkeiten:

- Selbststudium

- in einer Arbeitsgruppe, zum Beispiel mit anderen Kollegen oder Abteilungen

- während der praktischen Projektarbeit

- in Kursen (es gibt Spezialkurse für Dokumentationsmethodik!)

Alle diese Aktivitäten bedeuten natürlich Zeit und Aufwand, die der Entwickler während seiner täglichen Arbeit vielleicht gar nicht hat. Die Erfahrung zeigt aber, daß man sich mit der Einsicht in die Notwendigkeit, mit gutem Willen mit der richtigen Motivation seinen Kollegen und Vorgesetzten gegenüber Spielraum verschaffen kann. Wichtiger noch als das Erlernen einer neuen Methode ist ihre praktische Erprobung in einem Projekt. Denn nur die eigene praktische Erfahrung lehrt, Vor- und Nachteile zu erkennen. Dabei ist es zunächst gleich welche

Dokumentationsstandards oder -richtlinien man umsetzen will. Wichtig ist, daß ein guter Ansatz konsequent durchgehalten wird, und daß man am Ende der Erprobung eine Art Bilanz zieht: Wie konnte mit der Methode gearbeitet werden, welchen Mehraufwand gab es, welche Vorteile im Ergebnis sind aufgetreten, welche Lernerfolge sind zu verzeichnen. Der Erfolg sollte nicht nur an einem ersten Projekt gemessen werden, denn jedes Projekt "läuft" anders.