Das Thema Software-Dokumentation scheint von untergeordneter Bedeutung zu sein – das suggeriert zumindest eine Recherche in den Standardwerken der modernen Entwurfslehre [Booch, 1991; Coad et al., 1991; Jacobson, 1992; Rumbaugh et al., 1993], wo dieses Thema höchstens ergänzend erwähnt wird. Auch aktuelle Software-Produktionswerkzeuge (z.B. objectiF, Rational Rose, Paradigm Plus) bieten bislang keine ausreichende Unterstützung an. Vor allem fehlt einerseits die Beschreibung einer Methode mit der Integration in ein Vorgehensmodell und andererseits eine integrierte und konsistente Werkzeugunterstützung. Auch in der Ingenieurausbildung an den Hochschulen findet das Thema "Technische Dokumentation" weiterhin keine große Beachtung. Zusammenfassend läßt sich so nur die Abwesenheit einer Dokumentationskultur attestieren und es ist daher nicht erstaunlich, daß der einzelne Software-Ingenieur keinen großen Antrieb hat, Arbeitsergebnisse zu dokumentieren. Das Management gibt aufgrund kurzfristiger Zielsetzungen auch nur allzu gerne anderen Tätigkeiten den Vorrang und übersieht dabei die längerfristige Entwicklung: das über Jahre aufgebaute Firmenkapital verbleibt in den Köpfen der Entwickler; die Einarbeitung neuer Mitarbeiter wird mit zunehmenden Projektgrößen immer aufwendiger. Auch hier ist die Crux: die Folgen kurzfristigen Handelns wirken sich langfristig aus.
Fragt man bei Unternehmen aus der Software-Branche nach, ergibt sich ein differenzierteres Bild: Der Status quo ist unbefriedigend; der Dokumentation wird eine wachsende Bedeutung zugeschrieben; die grundlegenden Probleme sind weiterhin ungelöst. Gerade in Zeiten der Abkehr vom Wasserfallmodell [Pagel et al., 1994] und der Hinwendung zu einem iterativen Vorgehensmodell, der zunehmenden Verwendung objektorientierter Entwicklungsmethoden und der Veränderung von der klassischen Software-Erstellung hin zur industriell geprägten Komponentenproduktion, bedarf es neuer Antworten auf alte Fragen. Schließlich: Mit der Einführung objektorientierter Konzepte ist die Erwartung an eine höhere Effizienz verbunden: der lang gehegte Wunsch, aus einer ständig wachsenden Sammlung von Software-Bausteinen die passenden auszuwählen und so die Konstruktion neuer Software mit jedem Entwicklungsschritt einfacher, billiger und schneller zu gestalten – eine Vorbedingung effektiver Wiederverwendung [Zendler et al., 1995] ist die geeignete Dokumentation dieser Artefakte.
In der anwendungsorientierten Forschung, das zeigte die diesjährige ECOOP (European Conference on Object-Oriented Programming), auf der auch wir vertreten waren [Odenthal&Quibeldey-Cirkel, 1997], wird das Thema Software-Dokumentation unter neuer Sichtweise wieder aufgegriffen. Bemerkenswert ist, daß Firmen zuvorderst mit dabei sind – beispielsweise Daimler Benz [Meusel et al., 1997] und Siemens [Buschmann et al., 1997].
Entwurfsmuster [Gamma et al., 1995] sind das derzeit wohl meist diskutierte Thema unter Informatikern. Dabei sind die Muster nur insoweit etwas Neues, als das sie bereits vorhandenes Wissen strukturieren und kommunizierbar machen.
Woher diese Euphorie? Wir meinen, sie ist ein Zeichen für das bestehende Defizit im Bereich des ingenieurmäßigen Vorgehens bei der Durchführung von Software-Projekten. Vergleicht man die typische Arbeitssituation eines Software-Ingenieurs mit der eines Architekten, so ist letzterer mit einer vollständig durch Verordnungen (als Beispiel sei die VOB – Verdingungsordnung für Bauleistungen [VOB, 1979], genannt) und Normen reglementierten aber gleichsam auch vorstrukturierten Arbeitsrealität konfrontiert; der Software-Ingenieur arbeitet hingegen weitestgehend künstlerisch: das Arbeitsergebnis hängt allein von der Kreativität des Entwerfers ab; eine Überprüfung und Qualitätskontrolle ist nur schwer möglich. Die Bewegung der Entwurfsmuster hat zum Ziel, den Prozeß des Entwerfens im positiven Sinne zu reglementieren: Entwurfswissen wird analog eines Handbuchs, wie es z.B. die VOB für den Architekten darstellt, niedergeschrieben, der Entwerfer kann sich an diesem Expertenwissen orientieren und auf einem höheren Niveau entwerfen; nicht zuletzt werden Entwürfe durch die Strukturierung mit Mustern leichter verständlich. An dieser Stelle setzt unser Vorhaben an.
Bislang werden Entwurfsmuster einerseits deskriptiv zur Weitergabe von verallgemeinertem Entwurfswissen sowie generisch zur Produktion von objektorientierten Software-Entwürfen eingesetzt. Wir verwenden die Mustergliederung zur Strukturierung der Dokumente und den Musterinhalt als Vorbild für die Dokumentation. Die Folge ist eine wesentlich einfachere Integration der Dokumentation in einen musterbasierten Entwurfsprozeß: Die Qualität der Dokumente steigt, der Entwicklungsprozeß wird besser nachvollziehbar.
Geplante Forschungsziele (Forschungshypothesen):
Geplantes Ergebnis: Eine praxiserprobte Methode samt prototypischer Werkzeugumgebung, die in zwei Bereichen eingesetzt werden kann:
Basierend auf Erfahrungen und ausgehend von der geleisteten Arbeit soll in drei zusammenhängenden Bereichen fortgefahren werden:
Punkt eins dieser Aufstellung ist zum gegenwärtigen Zeitpunkt ausreichend bearbeitet. Ausgehend von dem in [Blachnik, 1997] realisierten Prototyp wird im nächsten Schritt (2) eine vollständige Werkzeugumgebung zur Erstellung musterbasierter Software-Dokumentation konfiguriert. Diese Umgebung implementiert die Methode und soll dann praktisch eingesetzt werden (3). Die Erfahrungen aus dieser Validierung fließen dann in die Weiterentwicklung der Methode (1) und der Werkzeugumgebung (2) ein. In diesem Schritt soll dann die Dokumentationsumgebung in eine vollständige Software-Entwicklungsumgebung integriert werden.
Um die Ideensammlung für das Projekt zu strukturieren ist ein "Problem-Puzzle" eingerichtet. Dort werden die wesentlichen Fragen formuliert, der Kontext dargestellt und mögliche Lösungsansätze beschrieben.