Für die Konzeption einer Dokumentation stellt sich die Frage, mit welchen Mitteln der Inhalt dem späteren Leser verständlich gemacht werden kann. Hier gibt es zwei Ansätze, die Papierdokumentation und die Hypertextdokumentation. In einem Abschnitt vergleiche ich diese beiden Ansätze zur Dokumentation. Danach folgt ein Abschnitt, der die Ansätze zeigt, mit denen eine Versionsverwaltung und Gruppenarbeit möglich ist.
Eine Dokumentation kann auf zwei verschiedenen Weisen aufgebaut werden. Viele Dokumentationen werden auf Papier gedruckt. Es besteht aber auch die Möglichkeit, die Dokumentation auf dem Computer abzulegen und zwischen den einzelnen Teilen der Dokumentation Verknüpfungen vorzunehmen, so daß ein Hypertext entsteht.
komplexere Dokumentstrukturen: Ein wesentlicher Vorteil der Hypertextdokumentation ist die einfache Navigation in der Dokumentation [Gsuck, 1995]. Durch die Links im Hypertext ist es möglich, mehr Zugriffsmöglichkeiten für den Benutzer zu schaffen. Bei einer Papierdokumentation ist meist nur ein Inhaltsverzeichnis und ein Stichwortverzeichnis vorhanden. In einem Hypertext ist es jedoch möglich, weitere Übersichten und Gliederungen aufzunehmen und so den Leser schnell an die gewünschte Information heranführen (Guided Tours). Außerdem läßt sich eine erweiterte Stichwortsuche intregieren. Durch das Verknüpfen von Teilen der Dokumentation mit Links kann der Leser auch schnell zu weitergehenden Informationen gelangen. Damit kann er den Inhalt der Dokumentation besser verstehen. In einer gedruckten Dokumentation sind die Querverbindungen zwischen den einzelnen Informationen nicht immer darstellbar.
Handhabung: Damit ein Leser schnell an alle Informationen gelangen kann, ist eine Trennung der Dokumentation einer gedruckten Software in kleinere Einheiten sinnvoll. So kann ein Teil das Glossar mit den Begriffserklärungen enthalten. Gerade bei großen Softwareprodukten ist dies sinnvoll, da die Dokumentation sehr umfangreich ist und sowieso in kleinere Einheiten unterteilt werden muß. Jedoch läßt sich dieses Verfahren nicht beliebig weit fortführen, da mehrbändige Dokumentationen meist den Leser abschrecken. Die zunehmende Komplexität der Software wird jedoch immer größere Dokumentationen erfordern. Die dann immer schwererer zu bewältigen sind, da die Anzahl der Bücher weiter zunimmt. Bei einer Hypertextdokumentation ist diese Aufteilung nicht nötig und trotzdem sind alle Informationen schnell verfügbar.
Verfügbarkeit: In Firmen kann eine Hypertextdokumentation auf einem Server abgelegt werden und damit steht sie allen Mitarbeitern zur Verfügung. Damit wird der benötigte Speicherplatz reduziert. Die Erreichbarkeit der Dokumentation über ein Intranet stellt sicher, daß alle Mitarbeiter, die die Dokumentation benötigen, diese auch erhalten. Bei einer gedruckten Dokumentation müssen mehrere Exemplare der Dokumentation in einer Firma vorhanden sein. Selbst dann ist nicht immer sichergestellt, daß alle Mitarbeiter auf die Dokumentation zugreifen können.
Kosten: Die Kosten für die Dokumentation sprechen für eine Hypertextdokumentation, wenn man davon ausgeht, daß die Computer schon zur Verfügung stehen. In diesem Fall ist zwar die Erstellung von der Dokumentation aufwendiger, weil diese Dokumentation besser strukturiert sein muß. Ohne diese Strukturierung wäre die Dokumentation schwer verständlich. Die Kosten für die Verteilung einer neuen Hypertextdokumentation sind jedoch niedriger als die Kosten für die Verteilung einer gedruckten Dokumentation. Bei einer Hypertextdokumentation brauchen nur die Dateien auf einem Server zur Verfügung gestellt werden. Eine gedruckte Dokumentation muß erst teuer gedruckt werden und danach an die Mitarbeiter weitergeleitet werden.
Aktualität: Eine Hypertextdokumentation ist außerdem leichter anpaßbar. Bei der Weiterentwicklung Software ist es nötig, die Dokumentation der Entwicklung anzupassen. Eine neue Hypertextdokumentation muß nur auf dem Server zur Verfügung gestellt werden. Insbesondere Änderungen, die bei kleineren Bugfixes entstehen, sind einfacher zu handhaben. Eine gedruckte Dokumentation muß immer neu gedruckt werden. Aus diesem Grund werden meist nur bei großen Änderungen (neue Versionen) neue Dokumentationen gedruckt. Bei Bugfixes wird allenfalls eine Liste von den Änderungen ausgegeben. Dies kann zu Konsistenzproblemen führen. Ebenfalls Inkonsistenz kann bei einem vollständigen Wechsel der Dokumentation auftreten, weil nicht alle Dokumentationen immer rechtzeitig ausgetauscht werden. Die Änderungen zwischen den einzelnen Versionen der Software können in einer Hypertextdokumentation festgehalten werden. In einer gedruckten Dokumentation ist dies nicht möglich, da der Dokumentationsumfang weiter zunehmen würde.
Strukturierung: Ein Leser kann durch die lineare Form einer gedruckten Dokumentation an ein bestimmtes Problem hingeführt werden. Gerade unerfahrene Leser können schneller ein Verständnis für die dokumentierte Software erhalten, wenn der Text aufeinander aufbaut. In einem Hypertext kann der Leser leicht durch das Benutzen von Links zu tiefergehenden Informationen gelangen. Diese sind für den Überblick aber meist ungeeignet und verwirren den Leser, wenn das Verständnis für die wesentlichen Teile der Software fehlt. Insbesondere kann der Leser soweit vom eigentlichen Thema weggeführt werden, daß er keinen Weg zurück zu den gewünschten Informationen findet. Diesen Zustand nennt man auch "lost in Hypertext" [Nielsen, 1993]. Dies kann nur durch eine gut durchdachte Benutzerführung vermieden werden, dazu gehören ein guter Bildschirmaufbau und eindeutige Links.
Anzahl der darstellbaren Informationen: Bei der Dokumentation in einem Hypertext stellt sich auch die Frage, wieviele Informationen gleichzeitig auf dem Bildschirm darstellbar sind. Meist ist es für das Verständnis eines Objektes innerhalb der Software günstig, erklärende Texte und Diagramme, die diese Objekte enthalten, gleichzeitig zu studieren. Selbst auf großen Bildschirmen lassen sich diese Informationen nicht gleichzeitig darstellen. Bei einer gedruckten Dokumentation können die Diagramme vom Text getrennt werden und so beide dem Leser gleichzeitig zugänglich gemacht werden. Dabei erhöht sich natürlich der Aufwand für die Suche nach den Informationen, denn der Leser muß einerseits das richtige Diagramm finden und andererseits in dem Text blättern um die gewünschten Informationen zu erhalten.
Sicherheit: Eine Dokumentation, die über ein Intranet verfügbar ist, stellt ein Sicherheitsproblem dar. In die dokumentierte Software wurde viel Entwicklungsaufwand gesteckt. Die Ergebnisse müssen vor unberechtigten Zugriffen geschützt werden, damit nicht Konkurrenten davon profitieren können. Ist nun die Dokumentation in einem Netz verfügbar, so kann der Zugriff schlecht kontrolliert werden und es lassen sich leicht Teile daraus kopieren. Bei einer gedruckten Dokumentation ist das heimliche Kopieren schwieriger, außerdem läßt sich leichter der Zugriff auf die Dokumentation beschränken. Es existieren ja nur einige Bücher und diese können leicht eingeschlossen werden.
Zusammenfassend läßt sich sagen, daß eine Hypertextdokumentation besser ist als eine gedruckte Dokumentation. Denn es überwiegen die Argumente für den Hypertext. Vor allem die komplexeren Dokumentenstrukturen sprechen für die Hypertextdokumentation. Dafür sprechen auch die Kosten. Viele Nachteile der Hypertextdokumentation gegenüber der gedruckten Dokumentation lassen sich beseitigen. So lassen sich die Sicherheitsprobleme durch Schutzmaßnahmen lösen oder durch eine gute Führung des Lesers kann die Einarbeitung erleichtert werden.
Die Entwicklung von Software ist sehr aufwendig, deshalb existieren mehrere Ansätze, die Entwicklung durch Computer zu unterstützen. Die meisten Werkzeuge helfen bei der Erstellung von die Diagrammen und Texten. Diese Werkzeuge unterstützen mehrere Phasen (Analyse, Design und Implementierung) in der Softwareentwicklung. Der Entwickler kann die Diagramme, die die Software beschreiben, in den Editoren der Werkzeuge zeichnen und die einzelnen Objekte in den Zeichnungen mit Texten beschreiben. Die Werkzeuge führen meist den Entwickler durch den Prozeß, d.h. es ist eine bestimmte Abfolge bei der Erstellung der Dokumente vorgegeben. Das Werkzeug verwaltet dann eine ToDo-Liste und weist den Entwickler auf fehlende oder nicht vollständige Dokumente hin. Einige der Werkzeuge bieten auch Hilfen beim Übergang zwischen den Phasen, z.B. kann das Werkzeug aus den Klassendiagrammen und zusätzlichen Informationen in C++ Dateien die Deklarationen der Klassen für die Implementierung erstellen, so daß der Programmierer diese Arbeit nicht tun braucht. Zusätzlich können Werkzeuge die Versionsverwaltung und zur Gruppenarbeit unterstützen.
Ein Softwareprodukt ändert sich im Laufe der Zeit. Dies geschieht, weil die Software ständig an neue Umgebungen (z.B. Betriebsysteme) angepaßt sein muß. Auch verlangen die Anwender ständig neue Funktionen bei bestehenden Softwareprodukten, so daß Änderungen in der Software unvermeidlich sind. Außerdem sind in der Software meistens Fehler, die korrigiert werden müssen. Dies geschieht zum Teil schon während der Entwicklung, da dort Betaversionen zum Testen erstellt werden. Damit diese Änderungen nicht zu weiteren Fehlern führen, ist es notwendig, die Änderungen festzuhalten. Dies geschieht mit Hilfe des Konfigurationsmanagements. Erreicht die zu erstellende Software einen gewissen Umfang, so kann ein softwaregestütztes Konfigurationsmanagement sinnvoll sein.
Ein Teilbereich im Konfigurationsmanagement ist die Versionsverwaltung. Die Versionsverwaltung verwaltet die einzelnen Komponenten der Software. Komponenten [Rammel et al., 1996] sind zum Beispiel die Klassen mit dem Programmtext, aber auch zusätzliche Daten wie Spezifikation, Testfälle, Dokumentation usw. Von jeder dieser Komponenten können unterschiedliche Versionen vorhanden sein. Neue Versionen können die alten Versionen ersetzen, zum Beispiel um Fehler zu korrigieren, in diesem Fall nennt man diese Version eine Revision. Die alten Revisionen sind dann nur noch zur Dokumentation und eventuell nötigen Rückschritten vorhanden. Versionen können aber auch als Varianten existieren. In diesem Fall werden die Komponenten parallel weiterentwickelt, z.B. kann jeder der Varianten einer Komponente ein unterschiedliches Rechnersystem unterstützen. Die Varianten werden dann natürlich alle weiter benötigt.
Abbildung 7: Versionsgraph [Schröder, 1994]
Durch die Kombination von Revisionen und Varianten entsteht ein Versionsgraph (Abbildung 7) für die jeweilige Komponente. Für Bezeichnungen der einzelnen Versionen gibt es unterschiedliche Möglichkeiten. In der Abbildung 7 ist eine Version durch eine Zahlenkombination gekennzeichnet. Eine Revisionsnummer in der Hauptentwicklungslinie besteht aus zwei Zahlen. Bei kleineren Änderungen zwischen zwei Revisionen wird die letzte Zahl inkrementiert (in der Abbildung z.B. 1.2 nach 1.3). Die Inkrementierung der ersten Zahl und das Zurücksetzen der letzten Zahl zeigt große Änderungen an (in der Abbildung z.B. 1.3 nach 2.0). Ein Abspalten von unterschiedlichen Varianten geschieht durch Anhängen von zwei Zahlen (in der Abbildung 1.3 nach 1.3.1.1). Die erste dieser Zahlen gibt die Nummer der Variante an. Die zweite Zahl beginnt bei 1 und dient zur Unterscheidung der unterschiedlichen Revisionen der Variante. So ist in der Abbildung die Variante 1.3.1.1 verändert worden und so ist die Version 1.3.1.2 entstanden. Diese Nummerierung ist sehr flexibel, so können auch mehrere Varianten von einer Version entstehen (1.3 nach 1.3.1.1 und 1.3.2.1) oder auch Varianten von Varianten entstehen (1.3.1.2 nach 1.3.1.2.1.1). Dabei können jedoch sehr lange Bezeichner entstehen, die dann schwer verständlich sind.
Abbildung 8:Vorwärts-Deltaspeicherung [Schröder, 1997]
Der Platzbedarf für die Speicherung aller Versionen einer Komponente ist sehr groß. So sind für die in der Abbildung 7 angeführte Komponente zehnmal fast identische Daten zu speichern. Da bei der Softwareentwicklung eine Vielzahl von Komponenten entstehen, muß der Speicherplatzbedarf reduziert werden. Dies geschieht mit Hilfe der Deltaspeicherung. Bei der Vorwärts-Deltaspeicherung, siehe Abbildung 8, werden nur die Änderungen zur vorherigen Version gespeichert. Für die Ausgabe einer bestimmten Version muß die Versionsverwaltung nun von einer vollständigen Version aus die gespeicherten Änderungen nachvollziehen. Dies ist sehr aufwendig, deshalb liegt meist nicht nur eine Version vollständig vor, sondern auch Versionen mit großen Änderungen liegen vollständig vor (die Revision 2.0 in der Abbildung). Damit muß die Versionsverwaltung nicht mehr so viele Schritte nachvollziehen. Die Vorwärts-Deltaspeicherung hat den Nachteil, daß die aktuelle Version, die am häufigsten benötigt wird, den größten Aufwand bei der Rekonstruktion benötigt. Aus diesem Grund gibt es auch die Rückwärts-Deltaspeicherung (Abbildung 9), dabei wird die aktuelle Version gespeichert und bei Bedarf die alten Versionen von der Versionsverwaltung mit Hilfe der Änderungsdaten rekonstruiert.
Abbildung 9:Rückwärts-Deltaspeicherung [Schröder, 1997]
Für Verzweigungen, die durch Varianten entstehen, gibt es bei der Rückwärts-Deltaspeicherung zwei Methoden. Es kann die jeweils letzte Revision der Varianten gespeichert sein, so daß von diesen Punkten die Versionsverwaltung die übrigen Punkte rekonstruieren kann. Bei der zweiten Möglichkeit liegt nur eine Version komplett vor und die Rekonstruktion erfolgt durch gemischte Deltaspeicherung. Dies ist, wie in Abbildung 10 dargestellt, eine Kombination aus Vorwärts- und Rückwärts-Deltaspeicherung.
Abbildung 10:Gemischte Deltaspeicherung [Schröder, 1997]
Ein vollständiges Programm besteht nun aus mehreren Komponenten. Diese Komponenten können in unterschiedlichen Versionen vorliegen. Eine Zusammenstellung von Versionen der Komponenten nennt man Konfiguration. Da die Versionen einer Komponente nicht mit allen Versionen der anderen Komponenten zusammenarbeiten kann, ist bei der Erstellung einer Konfiguration darauf achten, daß eine neue Konfiguration nur aus zueinander kompatiblen Versionen besteht. Die Komponenten sind zueinander inkompatibel, weil
Deshalb müssen die Entwickler zur Erstellung von neuen Konfigurationen die Beschränkungen beachten. Dabei kann ein Werkzeug sie unterstützen. Die Entwickler geben anhand von Regeln die Konfiguration vor. Die Entwickler können zum Beispiel eine konkrete Version angeben oder Regeln, wie "Verwende die aktuelle Version" oder "Verwende die Versionen des Autors X". In neueren Modellen können auch mehrere Komponenten zu logischen Einheiten zusammengefaßt werden, z.B. Klassen der Benutzeroberfläche (GUI), da diese meist gemeinsam geändert werden.
Abbildung 11:Systemmodell und Versionsauswahl [Rammel et al., 1996]
In einem Systemmodell sind die notwendigen Komponenten angegeben, die für die Erstellung einer Konfiguration nötig sind. Das Konfigurationswerkzeug fügt dann aus all diesen Informationen die neue Konfiguration zusammen, wie in Abbildung 11 dargestellt.
Die heute zu erstellende Software ist meist so
komplex, daß mehrere Personen an der Software arbeiten. Beim
V-Modell ist sogar vorgegeben, daß die Qualitätssicherung von
Personen durchgeführt wird, die nicht an der Entwicklung
beteiligt sind. Eine Aufteilung der Arbeit kann nach den
einzelnen Phasen in der Softwareentwicklung geschehen, so daß
unterschiedliche Personen für die Analyse, das Design, die
Implementierung und den Test zuständig sind. Bei sehr großen
Projekten müssen in den einzelnen Phasen mehrere Personen
arbeiten. Dies führt zu Problemen. Die einzelnen Mitarbeiter
müssen die Informationen über die Softwareentwicklung
austauschen. Außerdem arbeiten zum Teil mehrere Personen an
einem Dokument (z.B. zusammengehörige Klassendiagramme), so daß
es zu Inkonsistenzen kommen kann. Mit der Unterstützung von
Computern lassen sich die auftretenden Probleme verkleinern. Dies
nennt man computer supported co-operative work (CSCW).
Regelmäßige Besprechungen der Mitarbeiter sorgen für den
Informationsaustausch in einer Arbeitsgruppe, die ohne CSCW
arbeitet. Durch Computer können diese Besprechungen besser
vorbereitet werden. Einerseits gibt es Unterstützung bei der
Terminabsprache, andererseits kann ein Informationsaustausch mit
Hilfe des Computers die Besprechungen besser vorbereiten. Durch
einige Programme können die Besprechungen auch ersetzt werden,
indem die Besprechungen online per Computer ablaufen, so daß die
Kosten reduziert werden [Coleman, 1997] Mit entsprechenden
Werkzeugen auf dem Computer können alle Mitarbeitern auf alle
Informationen zugreifen. Die Mitarbeiter müssen ständig über
getroffene Entscheidungen anderer Mitarbeiter informiert sein, da
diese zum Teil ihre eigene Arbeit beeinflussen. Insbesondere wenn
neue Mitarbeiter hinzukommen, was aufgrund der langen
Entwicklungszeiten in großen Softwareprojekten leicht möglich
ist, müssen sich diese Mitarbeiter über die bisher gemachten
Arbeiten schnell und umfassend informieren. Dies kann durch
Bereitstellen aller Informationen auf dem Computer leicht
ermöglicht werden. Hier können die Informationen besser
strukturiert zur Verfügung stehen. HTML ist dafür besonders
geeignet [Woodcock, 1997]. Da mehrere Mitarbeiter an der
Entwicklung der Software arbeiten, kann es vorkommen, daß zwei
Mitarbeiter das gleiche Dokument verändern. So sind meist die
Klassendiagramme so umfangreich, daß mehrere Entwickler daran
arbeiten. Dies führt ohne Unterstützung des Computers zu
Problemen, so kann entweder die Konsistenz des Dokuments nicht
mehr gewährleistet werden oder aber das Dokument muß vorher in
fest definierte Teile unterteilt werden, wobei dann jeder
Mitarbeiter einen Teil bearbeitet. Meist ist eine solche strikte
Trennung aber nicht möglich. Mit Hilfe des Computers gibt es
hierfür zwei Lösungsansätze. Beim Bearbeiten eines Teils des
Dokumentes von einem Mitarbeiter setzt ein Programm
Zugangssperren, so daß die anderen Mitarbeiter diesen Teil nicht
bearbeiten können. Da die Teile sehr klein sein können, können
mehrere Mitarbeiter an einem Dokument arbeiten. Es ist aber auch
möglich, daß der Zugang für alle Mitarbeiter zu allen Teilen
immer möglich ist. Erst beim Speichern der Informationen
überprüft der Computer, ob die Änderungen im Widerspruch zu
gleichzeitig von einem anderen Mitarbeiter vorgenommenen
Änderungen stehen. In diesem Fall weist der Computer darauf hin
und die Mitarbeiter müssen eine Lösung finden [Woodcock, 1997].