Dokumentation in der Softwareentwicklung - Effizienter Einsatz von Entwicklerdokumentation

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

1 Einleitung
1.1 Problemstellung
1.2 Einordnung und Ziel der Arbeit
1.3 Vorgehensweise
1.4 Erläuterung verwendeter Begriffe

2 Entwicklerdokumentation
2.1 Gegenstände der Entwicklerdokumentation
2.2 Gründe für Entwicklerdokumentation
2.2.1 Wissenskonservierung
2.2.2 Wissenstransfer
2.2.3 Koordination
2.2.4 Kommunikation
2.2.5 Softwareerstellungs-Vertrag
2.2.6 Organisatorische Politik und Macht
2.2.7 Strukturierung der Implementierung
2.2.8 Durchdringung inhaltlicher Konzepte
2.2.9 Geforderte Qualitätsstandards
2.2.10 Dokumentationsvorgaben
2.3 Nachteile von Entwicklerdokumentation
2.3.1 Aktualität
2.3.2 Aktualisierungsaufwand
2.3.3 Verständlichkeit
2.3.4 Informationsfindung
2.3.5 Zusätzlicher Ressourcenbedarf
2.3.6 Motivationsproblem

3 Effizienzsteigerung des Einsatzes von Entwicklerdokumentation
3.1 Effizienz von Entwicklerdokumentation
3.2 Maßnahmen zur Effizienzsteigerung
3.2.1 Grundkonzepte und Qualitätsanforderungen
3.2.2 Quantitative Aspekte
3.2.3 Alternativen zu traditionellen Ansätzen der Dokumentation
3.3 Kritische Beleuchtung weiterer und genannter Vorschläge
3.3.1 Zeitpunkt von Dokumentation
3.3.2 Technische Hilfsmittel
3.3.3 Video- und Audioaufnahmen als Dokumentation
3.3.4 Kompletter Dokumentationsverzicht
3.3.5 Positive Aspekte von Redundanzen
3.3.6 Unnötigkeit richtiger und aktueller Dokumentation
3.3.7 Teamgröße und angemessene direkte Kommunikation
3.3.8 Öffentliche Präsentation und Prozessdokumentation

4 Einflussfaktoren auf Entwicklerdokumentation
4.1 Organisatorische Einflussfaktoren
4.1.1 Ablauforganisation
4.1.2 Aufbauorganisation
4.1.3 Umfang eines Projekts
4.1.4 Zeitraum der Erstellung eines Projektes
4.1.5 Fluktuation
4.1.6 Arbeitsteilung
4.1.7 Planung und Kontrolle
4.1.8 Entscheidungsdelegation
4.1.9 Vorauskoordination
4.1.10 Formalisierung
4.2 Softwarespezifische Einflussfaktoren
4.2.1 Art der Auslösung
4.2.2 Unklarheit der Entwicklungsaufgabe
4.2.3 Dynamik der Anforderungen
4.2.4 Neuartigkeit der Technologie
4.2.5 Intensität der Kunden-/Marktkommunikation
4.2.6 Sicherheitsanforderungen der Software
4.2.7 Lebensdauer von Entwicklerdokumentation und Software
4.2.8 Vorgehensmodelle
4.3 Weitere Einflussfaktoren
4.3.1 Verhalten der Mitarbeiter
4.3.2 Ausbildung und Wissen der Mitarbeiter
4.3.3 Technische Unterstützung der Entwicklung
4.3.4 Wirtschaftlicher Druck auf Software-Firmen

5 Schlussbetrachtung

6 Literaturverzeichnis

7 Anhang A: Literatur zu Formatierungsvorschlägen von Code und Kommentaren

Zusammenfassung

Dokumentation ist ein „Übel“ der Softwareentwicklung. Durch eine Effizienzsteigerung von Entwicklersoftware wird dazu beigetragen, den Erstellungsprozess von Software effizienter zu gestalten.

Entwicklerdokumentation wird für verschiedene Gegenstände der Softwareentwicklung angefertigt. Dazu zählen beispielsweise Anforderungen, Architekturen, Quellcode, Schnittstellen, Modelle und Testfälle. Es gibt einige Gründe, warum Entwicklerdoku-mentation erstellt werden sollte, beispielsweise Wissenstransfer, Wissenskonservierung, Kommunikation oder die Erstellung als Grundlage eines Vertrages. Entwicklerdoku-mentation bringt aber auch Probleme mit sich. Hier ist beispielsweise der Aktualisie-rungsaufwand, eine mangelnde Verständlichkeit und geringe Aktualität hervorzuheben.

Es sind seit einiger Zeit Maßnahmen bekannt, durch die die Effizienz einer Dokumenta-tion verbessert werden kann. Unter diese Maßnahmen fallen dokumentationsbezogene (z.B. integrierte Dokumentation, hohe Lesbarkeit), organisationsbezogene (z.B. die Ge-staltung der Teamgröße) und technikbezogene Konzepte zur Steigerung der Effizienz. Großen Einfluss auf die Effizienz einer Entwicklerdokumentation hat der angestrebte bzw. erstellte Umfang der schriftlichen Dokumentation. Diese kann einerseits durch

eine geschickte Bestimmung der zu dokumentierenden Gegenstände, andererseits durch die Festlegung angemessener Umfänge einzelner Dokumentationen erreicht werden. Entwicklerdokumentation kann aber auch auf alternativen Wegen effizienter gestaltet werden. In der Arbeit werden dazu sieben Maßnahmen vorgestellt. Darunter fallen beispielsweise ‚Pair Programming’, ‚direkte Kommunikation’, ‚kontinuierliche Integration’ und ‚öffentliche Präsentation’.

Alle vorgestellten Maßnahmen eigenen sich jedoch nicht immer alle für jedes Software-entwicklungsprojekt. Vielmehr werden diese von verschiedenen Faktoren, die in der Softwareentwicklung auftreten können, beeinflusst und teilweise sogar determiniert. Beispielsweise kann bei hoher Dynamik von Anforderungen verstärkt ‚direkte Kommu nikation’, ‚umfassende Partizipation’ und ‚öffentliche Präsentation’ zur Effizienzsteige-rung eingesetzt werden. Diese Maßnahmen decken dann die Gründe ab, aus denen schriftliche Dokumentation erstellt worden wäre. Eine determinierende Wirkung ist beispielsweise bei hohen Sicherheitsanforderungen an Software gegeben. In diesem Fall kann nicht ohne weiteres auf schriftliche Dokumentation verzichtet werden. Verschie-dene Faktoren können dabei Einflüsse auf (1) die Entwicklerdokumentation selber, auf (2) vorgestellt Maßnahmen zur Effizienzsteigerung der Dokumentation und auf (3) die Wirkung verschiedener Maßnahmen haben.

Zusammenfassend lässt sich feststellen, dass Entwicklerdokumentation effizienter ges-taltet werden kann. Man muss jedoch bei einer Gestaltung die Umwelt und Situation, in der die Softwareentwicklung und das Anwendungsgebiet der Software eingebettet sind, beachten.

Kai Oey

Diplomarbeit

im Fach Management der Softwareentwicklung

Dokumentation in der Softwareentwicklung

Effizienter Einsatz von Entwicklerdokumentation

Vorgelegt in der Diplomprüfung im Studiengang Wirtschaftsinformatik der Wirtschafts- und Sozialwissenschaftlichen Fakultät der Universität zu Köln.

Köln, im September 2002

Dokumentation ist nicht Teil der Lösung, sondern Teil des Problems.

Tom DeMarco ( „ Wien wartet auf Dich “ , S. 130)

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abb. 1-1: Schematische Darstellung der Vorgehensweise

Abb. 3-1: Effektivität von Kommunikationsalternativen

1 Einleitung

Dokumentation ist in der Softwareentwicklung ein geläufiges Stichwort. Sie ist Bestandteil jeder Software.¹ Zu den Aufgaben eines Programmierers gehört es Entwicklerdokumentation² zu erstellen.³ Sie „ (...) dient der Aufzeichnung von Informationen über die Prozesse und Produkte der Entwicklung.“⁴

Entwicklerdokumentation wird verschieden gehandhabt und bewertet. Einerseits wird sie in der Softwareentwicklung als absolut notwendig erachtet und sogar postuliert, je mehr in einem Softwareentwicklungsprojekt dokumentiert wird, desto „besser“ ist dies für ein Projekt.⁵ Diesem Verständnis liegen zum Beispiel Vorgehensmodelle, wie das CMM, das V-Modell oder auch die ISO 9000, zugrunde.⁶

Andererseits wird Entwicklerdokumentation in den Hintergrund gestellt, als hinderlich für ein erfolgreiches Softwareprojekt angesehen und soweit wie möglich reduziert.⁷ In der Praxis kann häufig beobachtet werden, dass Entwicklerdokumentation, selbst bei erfolgreichen Softwareentwicklungen, als lästig angesehen und vernachlässigt oder teilweise weggelassen wird.⁸ Von Dokumentationsvorgaben wird häufig abgewichen und erstellte Entwicklerdokumentation wird als mangelhaft bewertet.⁹

Entwicklerdokumentation hat sich jedoch für Beteiligte an einem Entwicklungsprojekt als hilfreiches Mittel zur Arbeitsunterstützung herausgestellt.¹⁰ Aus diesem Grund wird die Entwicklerdokumentation auch als ein „notwendiges Übel“¹¹ bezeichnet.

Es existieren verschiedene Ansätzen zur Softwareentwicklung, mit jeweils verschieden stark ausgeprägten Anweisungen und Gestaltungsvorgaben zur Erstellung von Entwicklerdokumentation.¹² Daraus lässt sich schließen, dass verschiedene Aspekte bei der Bestimmung eines effizienten Grades der eingesetzten Entwicklerdokumentation von Bedeutung sind. Deshalb lassen sich unterschiedliche Gestaltungsalternativen in Bezug auf die Erstellung von Entwicklerdokumentation finden.

Die Softwarebranche ist ein stark umkämpfter Markt. Um Wettbewerbsvorteile erreichen zu können ist es wichtig, die Softwareentwicklung so effizient wie möglich zu ges-talten und Software auf hohem qualitativem Niveau zu erstellen. Doch die eine „silber-ne Kugel“¹³, welche die Softwarekosten zur Erstellung qualitativ guter Software redu-ziert, ist nicht in Sicht.¹⁴ Aus diesem Grund kann sich nur in kleinen Schritten einer ef-fizienten Softwareentwicklung genähert werden.¹⁵ Entwicklerdokumentation ist ein ‚Ü-bel’ der Softwareentwicklung und deren Effizienzsteigerung einer der kleinen Schritte, die angegangen werden müssen, um Software effizienter zu erstellen.¹⁶

1.1 Problemstellung

In der Theorie ist die Bedeutung der Entwicklerdokumentation unter verschiedenen Ausprägungen von Softwareprojekten noch nicht vollständig erfasst und die Meinungen über den Umfang notwendiger Entwicklerdokumentation gehen auseinander. Erschwert wird die Situation durch einen schwierigen Effizienzvergleich aufgrund der Uneinheitlichkeit von Softwareprojekten sowie einer schwierigen Kosten-/Nutzenanalyse von Entwicklerdokumentation.¹⁷

Wie es für verschiedene Softwareprojekte nicht den einen ‚besten’ Prozess gibt,¹⁸ existiert für verschiedene Softwareprojekte, teilweise für verschiedene Module innerhalb eines Projektes, nicht die eine ‚beste’ Dokumentationsvorgehensweise. Vielmehr existieren in der Praxis verschiedenartige Ausprägungen von Dokumentationsvorgaben und Entwicklerdokumentationen.¹⁹

Die Frage nach der Effizienz der erstellten oder vorgeschlagenen Entwicklerdokumenta-tion wird in der Literatur nicht gestellt. Beispielsweise wird oft versucht, das Problem ineffizienter und auch oft ineffektiver Entwicklerdokumentation durch eine Technisie-rung, und somit einer effizienteren Verwaltung, zu beheben.²⁰ Ein Dokumentationsdefi-zit wird in der Literatur auch erkannt. So schreibt Gluchowski beispielsweise: „Zu be-klagen bleibt an dieser Stelle, dass viele Erkenntnisse, die während der Systemgestal-tung gewonnen werden, sich nur im implementierten System wiederspiegeln, nicht je-doch als dokumentiertes Wissen (...) vorliegen.“²¹ Im folgenden geht Gluchowski davon aus, dass möglichst alles dokumentiert werden sollte und versucht eine Referenzarchi-tektur für eine solche Entwicklerdokumentation herzuleiten. Die Effizienz der erstellten Entwicklerdokumentation betrachtet aber auch Gluchowski nicht.

1.2 Einordnung und Ziel der Arbeit

Die geringe theoretische Durchdringung im Bezug auf die Effizienz von Entwicklerdokumentation in Softwareentwicklungsprojekten soll als Anlass für die Arbeit genommen werden. Die Arbeit soll dazu beitragen, dieses Defizit zu verringern.

Ziel der Arbeit ist es, Maßnahmen aufzuzeigen, die zu einer Effizienzsteigerung der Entwicklerdokumentation führen und darzulegen, welchen Einflüssen Entwicklerdoku-mentation unterliegt. Vor dem Hintergrund der erläuterten Problematik verfolgt die Arbeit drei Unterziele. Erstens sollen Anforderungen an eine effiziente Dokumentation aufgezeigt werden. Zweitens wird hergeleitet, unter welchen Umständen und unter Zu-hilfenahme welcher Maßnahmen eine angemessene Entwicklerdokumentation erstellt werden kann. Drittens werden Einflussfaktoren mit ihrer Wirkung auf Entwicklerdoku-mentation vorgestellt. Die Diplomarbeit soll damit zum einen der Theorie die Grundla-ge zur Diskussion über Vorschläge zur Entwicklerdokumentation liefern und zum ande-ren der Praxis Hinweise zu einer effizienteren Entwicklerdokumentation geben.

Fokus der Arbeit ist die Art von Dokumentation, die den Entwicklern, während der (Weiter-)Entwicklung einer Software, Informationen liefert. Nicht betrachtet werden in der Arbeit alle Arten von Prozess-²² und Programmdokumentation²³, die Ausprägungen syntaktischer Gestaltung von Dokumentation²⁴, die physische Speicherung von Dokumentation²⁵ und Dokumentationsmanagement²⁶.

1.3 Vorgehensweise

Die Arbeit ist das Ergebnis eines Literaturstudiums. Im ersten Teil der Arbeit, den Kapiteln 2 und 3, wird der Fokus auf die Softwareentwicklung gelegt. Die Arbeit geht dabei im ersten Kapitel auf die Gegenstände, die Gründe für und die Nachteile von Entwicklerdokumentation ein. Als nächstes wird die Effizienz von Entwicklerdokumentation beleuchtet. Dazu wird in Kapitel 3 hinterfragt, was unter der Effizienz einer Entwicklerdokumentation verstanden werden kann und es werden Maßnahmen vorgestellt, die die Entwicklerdokumentation effizienter gestalten können.

Im nächsten Teil der Arbeit, dem Kapitel 4, wird die Umwelt, in der sich eine Software-entwicklung befinden kann, betrachtet. Dabei wird ein kontingenztheoretischer Ansatz²⁷ verfolgt. Da Softwareprojekte in unterschiedliche Umfelder eingebettet sind, lassen sich Faktoren finden, die zum ersten auf die Entwicklerdokumentation, zum zweiten auf die Maßnahmen zur Effizienzsteigerung der Entwicklerdokumentation und zum dritten auf die Wirkung dieser Maßnahmen Einfluss haben. Die Arbeit versucht abzuleiten, wie sich die Entwicklerdokumentation unter dem Einfluss erkannter Faktoren gestaltet²⁸ und welche Maßnahmen unter sinnvoll zur Effizienzsteigerung eingesetzt werden können.²⁹

In Abb. 1-1 ist das Vorgehen mit Hinweis auf das jeweilige Kapitel schematisch darge-stellt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1-1: Schematische Darstellung der Vorgehensweise

1.4 Erläuterung verwendeter Begriffe

In diesem Kapitel werden Begriffe erläutert, die für das Verständnis der Arbeit wichtig sind, unterschiedlich aufgefasst werden könnten und dadurch zu einem ungenauen Verständnis der Arbeit führen würden.

Klassisch ist Dokumentation das schriftliche Festhalten von Informationen zu einem be-stimmten Gegenstand sowie das resultierende Ergebnis dieses Vorgangs.³⁰ Dokumentation wird mit dem Ziel betrieben, relevante Informationen über den dokumentierten Gegenstand³¹ zu späteren Zeitpunkten verfügbar zu machen, um Aktionen auf oder mit dem dokumentierten Gegenstand ausführen zu können. Dieses Ziel kann jedoch auch durch nicht schriftliche Methoden erreicht werden.³² Aus diesem Grund werden in dieser Arbeit unter dem Begriff Dokumentation alle vorgestellten Möglichkeiten, die Ziele klassischer Dokumentation zu erreichen, zusammengefasst.³³

In der Softwareentwicklung werden unter dem Begriff der Dokumentation im Allgemeinen Programmdokumentation³⁴, Prozessdokumentation und Entwicklerdokumentation subsummiert.³⁵

Unter der Programmdokumentation wird der Teil einer Softwaredokumentation verstanden, der die Installation, Bedienung und Administration einer Software erklärt und als Teilprodukt mit in das endgültige Softwareprodukt einfließt.³⁶

Die Prozessdokumentation besteht aus Informationen, die den Entwicklungsprozess der Software betreffen, diesen steuern und gestalten.³⁷ Die Prozessdokumentation kann beiBedienungsanleitungen, ein Beispiel von Dokumentation zur Informationssuche im Alltag sind Beipackzettel zu Arzneimitteln. spielsweise den Ressourceneinsatz zur Entwicklung, eine Meilensteinplanung, Versionsmanagement, Ablaufplanung und Konfigurationsmanagement umfassen.³⁸

Entwicklerdokumentation ist die Dokumentation, die den Entwicklern einer Software zur Unterstützung ihrer Tätigkeiten zur Verfügung steht und die zum großen Teil durch Entwickler erstellt wird.³⁹ Entwicklerdokumentation ist der Teil der Dokumentation, der sich beispielsweise auf den Quellcode oder auf die Architektur/Struktur der entwickel-ten Software bezieht.⁴⁰ Die Entwicklerdokumentation kann dabei einerseits eine deter-minierende⁴¹, andererseits eine deskriptive Funktion erfüllen.⁴² Determinierende Ent-wicklerdokumentation gibt Vorgaben für Programmierer, wie die Software umgesetzt werden soll.⁴³ Beispielsweise übernehmen Entwicklerdokumentationen eine determinie-rende Funktion, indem Modelle (Klassendiagramme, Datendiagramme), Architektur-oder Designpläne Vorgaben zur Erstellung der Software enthalten.⁴⁴ Deskriptive Ent-wicklerdokumentation ist Information, die sich auf Teile des Quellcodes bezieht, dar-legt, was die Aufgabe eines bestimmten Codeabschnitts ist, und detaillierter erklären kann, wie das Ziel im Code umgesetzt ist. Deskriptive Entwicklerdokumentation kann sich beispielsweise auf Module, Datenbankfelder, Funktionen⁴⁵ oder auch wenige Zei-len Quellcode beziehen.⁴⁶ Oft wird sie in direkter Nähe oder im dokumentierten Gegenstand der Software (beispielsweise bei Quellcode) festgehalten.⁴⁷ Entwicklerdokumentation mit erklärendem Charakter unterstützt somit die Softwareentwickler bei der Erstellung, Fehlerbeseitigung und Wartung einer Software.

Die Arbeit beschränkt sich auf die Betrachtung von Entwicklerdokumentation. Eine Ef-fizienzbetrachtung dieser ist für die Entwickler einer Software am interessantesten. An-forderungen an die Programmdokumentation sind gut erkannt und verstanden⁴⁸ und die Einbeziehung der Prozessdokumentation hätte den Umfang der Arbeit um Weiten über-schritten.⁴⁹ Da sich die Arbeit auf Entwicklerdokumentation bezieht, wird die Bezeich-nung ‚Dokumentation’ im Folgenden synonym zur ‚Entwicklerdokumentation’ verwen-det. Nur, wo es einer besseren Abgrenzung oder Verständlichkeit dient, wird explizit ‚Entwicklerdokumentation’ geschrieben.

Unter der Lebensdauer einer Dokumentation wird die Zeitspanne verstanden, in der eine Dokumentation aktiv, erstellend oder nachfragend, genutzt wird.⁵⁰

Einige Begriffe, die mit Bezug zu Dokumentation genannt werden, wie beispielsweise Lastenheft, Systemdefinition oder Grobkonzept, sind nur schwer einzugrenzen und werden unterschiedlich in der Literatur benutzt.⁵¹ Auf eine Eingrenzung der Begriffe wird hier verzichtet. Wichtig ist, dass die Inhalte eines Dokumentes abgegrenzt sind. Wie ein entsprechendes Dokument in einem Projekt genannt wird und ob verschiedene Gegenstände der Dokumentation darin zusammengefasst werden, sei jedem Projektteam überlassen.

2 Entwicklerdokumentation

Entwicklerdokumentation wird in verschiedenen Softwareentwicklungsprojekten und innerhalb eines solchen Projektes von verschiedenen Beteiligten unterschiedlich eingesetzt. Grundlagen zur Erstellung von Entwicklerdokumentation, also die Gegenstände, Gründe und Nachteil, werden in diesem Kapitel hinterfragt.

Zuerst werden verschiedene Gegenstände der Softwareentwicklung betrachtet, die do-kumentiert werden können und die dadurch auch ausschlaggebend für den Umfang ei-ner projektweiten Dokumentation sind. Hier stellt sich also die Frage, was dokumentiert werden kann (Kapitel 2.1). Des weiteren können sich unterschiedliche Dokumentati-onsvorgaben aus der unterschiedlichen Wichtigkeit von Gründen zur Dokumentation herleiten lassen. Es stellt sich folglich die Frage, welche Gründe es für Dokumentation gibt (Kapitel 2.2). Und im Anschluss wird untersuchte, welche Gründe gegen Dokumentation in der Softwareentwicklung sprechen können (Kapitel 2.3).

2.1 Gegenstände der Entwicklerdokumentation

Ein Entwickler, der ein Programm warten muss, das nicht von ihm selbst erstellt wurde, benötigt einen Großteil seiner Zeit, um dieses Programm zu verstehen.⁵² Zum Verstehen eines Programms ist eine effiziente Entwicklerdokumentation über verschiedene Gegenstände des Programms hilfreich.

Nach David gibt es eine Vielzahl von Gegenständen in der Softwareentwicklung deren Dokumentation notwendig ist:⁵³ beispielsweise Anforderungen, Analysen, Feinentwür-fe, User-Interfaces, Schnittstellen, Datenmodelle, Architekturen, Testfälle und Quellco-de.

Im Folgenden werden typische Gegenstände vorgestellt, die bei der Erstellung von Software vorhanden sein können und deren Dokumentation zu einem besseren Verständnis einer Software beitragen kann. Dabei werden die verschiedenen möglichen Gegenstände teilweise auf einem hohem Level zusammengefasst.

- Anforderungen

Anforderungen stellen den Grundbaustein einer Software dar.⁵⁴ Sie beschreiben, was eine Software leisten soll. Ohne die Anforderungen zumindest ansatzweise zu kennen, kann kein Programmierer Software erstellen.

- Spezifikationen

Spezifikationen sind detailliertere Ausformulierungen von Anforderungen und zur Koordination der Arbeit eines Programmierers notwendig. Aus diesem Grund wird häufig gefordert, Anforderungen und/oder Spezifikationen schriftlich zu dokumen-tieren.⁵⁵

- Architektur

Bei der hohen Komplexität heutiger Software ist eine stabile Architektur⁵⁶ ein guter Ausgangspunkt zur Erstellung von guter Software und bietet einen Überblick über verwendete fachliche und technische Konzepte. Allerdings ist die Architektur, gerade bei langlebiger Software, nicht statisch.⁵⁷

- Quellcode

Quellcode, bzw. Quellcode-Blöcke, wie beispielsweise Funktionen, Module oder Klassen sind die einzelnen Anweisungen, die Aktionen einer Software erzeugen. Quellcode ist in der Regel sehr umfangreich und komplex. Dokumentiert werden kann Quellcode beispielsweise durch Kommentare direkt im Programmtext.⁵⁸

- Schnittstellen

Zur Interaktion zwischen den einzelnen Komponenten einer Software werden klar definierte Schnittstellen benötigt.⁵⁹ Gerade durch moderne objektorientierte Pro-grammierparadigmen, bei der eine hohe Kapselung und Modularisierung in der Systementwicklung vorliegt, ist dies elementar. Schnittstellen müssen dokumentiert sein, damit jeder Programmierer weiß, wie ein Modul zu nutzen ist.⁶⁰

- Modelle und Analysen

Modelle, beispielsweise Objekt- und Prozessmodelle, stellen unterschiedliche Sich-ten oder Perspektiven eines Systems dar. Analysen betrachten ein System unter be-stimmten Aspekten und in unterschiedlichem Detaillierungsgrad. Beides sind eine Abstraktion bestimmter Bereiche des späteren Systems.⁶¹ Um zu einem Verständnis über ein Modell oder eine Analyse zu gelangen kann es sinnvoll sein, eine schriftli-che Dokumentation von Entwurfsentscheidungen und Designalternativen (die ver-worfen wurden) zu erstellen.⁶²

Dem Ansatz deskriptiver Dokumentation folgend,⁶³ können Modelle auch Dokumentation sein, wie beispielsweise Modelle von Datenbanken oder Architekturen. Sie entstehen dabei vor dem Implementieren einer Software⁶⁴ und sind zum Verständnis und der Implementierung einer Software notwendig.⁶⁵

- Testfälle

Testfälle beinhalten mindestens detaillierte Vorgehensanweisungen, was und wie ein Gegenstand getestet werden soll und welches Ergebnis erwartet wird. Testfälle sind notwendig,⁶⁶ da jedes Softwaresystem getestet werden muss.⁶⁷ In der Regel gibt es eine sehr große Menge von Testfällen, da sichergestellt werden soll, dass mög-lichst viele Anwendungsszenarien auch wirklich funktionieren.⁶⁸ Um den Überblick über die Testfälle nicht zu verlieren, sollten diese dokumentiert werden.

- Richtlinien & Styleguides

Richtlinien und Styleguides, beispielsweise Standards, Konventionen, Muster, Checklisten oder Vorlagen,⁶⁹ müssen selber wenig dokumentiert werden, stellen jedoch eine schriftliche Dokumentation von zu nutzenden Formulierungen und Formatierungen, etwa von Variablennamen, Schleifen und Blöcken, in Projekten dar. Richtlinien und Styleguides können durchaus Projekt-/Produktübergreifend (z.B. unternehmenseinheitlich) gültig sein.

2.2 Gründe für Entwicklerdokumentation

In der geläufigen Literatur werden zwei Argumente, die für Entwicklerdokumentationen sprechen, immer wieder hervorgehoben.⁷⁰ Zum einen wird betont, dass die Einarbeitung neu zum Projekt stoßender Mitarbeiter in kürzerer Zeit und unter weniger Entwick-lungskosten geschieht. Unter diesem Aspekt wird Dokumentation zur Konservierung von Wissen, um es zu einem späteren Zeitpunkt verfügbar zu haben, genutzt. Zum ande-ren wird argumentiert, dass bei fehlender Dokumentation die Gefahr besteht, Anforde-rungen wegen fehlendem Hintergrundwissens aus fachlicher und technischer Sicht falsch zu implementieren. Der Transfer von Wissen, um nicht von falschen Annahmen auszugehen, wird hier unterstützt.

Diese beiden sind jedoch nicht die einzigen Gründe, aus denen Entwicklerdokumentati-on erstellt werden soll. Im Folgenden sind diese und weitere Gründe für Entwicklerdo-kumentation, die in heutigen Softwareentwicklungsprojekten bestehen können, erläu-tert.

2.2.1 Wissenskonservierung

Schriftliche Dokumentation dient der Konservierung von Informationen und Wissen und soll so dem Risiko des Informations- und Wissensverlusts durch Fluktuation⁷¹, Vergessen⁷² oder Stellenwechsel⁷³ vorbeugen. Schriftliche Dokumentation soll auch dafür sorgen, dass bei einem eventuell notwendigen Re-Engineering oder bei Wartungsarbeiten relevante Informationen vorliegen.⁷⁴ Eine bessere Dokumentationsqualität kann spätere Änderungen vereinfachen.⁷⁵ Dies resultiert daraus, dass spezifisches Implementierungswissen des Programmierers, der einen bestimmten Quellcode erstellt hat, nachlesbar ist und sich eine Erweiterung und Wartung durch andere Programmierer leichter gestalten kann.⁷⁶ David behauptet sogar, dass „eine gute Dokumentation (...) Voraussetzung für eine generelle Austauschbarkeit von Personal“⁷⁷ ist.

In der Softwareentwicklung gibt es zwei Gründe, bei denen eine zuverlässige Dokumentation zur Informationskonservierung wirklich notwendig ist. Zum einen betrifft dies die Generierung von Testfällen.⁷⁸ Zum anderen den Fall, dass klare und eindeutige Vorgaben bezüglich Spezifikationen und zu entwickelnder Features bestehen.⁷⁹

2.2.2 Wissenstransfer

Wissensaufbau über den zu lösenden Problembereich und über die programmierte Software ist eine wichtige Aufgabe eines Programmierers.⁸⁰ Der Satz „Wissen ist besser als Vermutung“⁸¹ trifft in der Softwareentwicklung, durch den hohen Grad der Komplexität und Interdependenz einzelner Softwareteile, in besonderem Maße zu.

Das Ziel von Dokumentation ist es, implizites Wissen⁸² eines Individuums in explizites Wissen der Organisation („Externalization“⁸³ ) zu transformieren,⁸⁴ um zu einem späteren Zeitpunkt das so erzeugte explizite Wissen der Organisation wieder in implizites Wissen eines Individuums („Internalization“⁸⁵ ) zu transformieren.⁸⁶

Schriftliche Dokumentation ist somit ein Vermittler zwischen Informationserzeuger und Informationsbenutzer.⁸⁷ Sie ist ein hilfreiches Instrument, das zum Wissenstransfer genutzt werden kann.⁸⁸

2.2.3 Koordination

Softwareentwicklung ist ein komplexer Prozess und bedarf der Koordination⁸⁹.⁹⁰ Dies trifft vor allem bei hoher Prozess- und Wissenskomplexität⁹¹ und bei umfangreichen Projekten zu.⁹² Dokumentation zur Koordination ist demnach primär zur Prozesssteue-rung und -kontrolle wichtig. Da sich Entwicklungsaufgaben aber beispielsweise anhand der Komponenten, Spezifikationen, Modellen oder der Architektur einer Software auf-teilen lassen,⁹³ kann Entwicklerdokumentation als Basis zur Koordination von Entwick-lungsaufgaben genutzt werden.

Eine Koordination mit den Projektauftraggebern ist zur Abstimmung des Arbeitsauftrages immer notwendig und kann beispielsweise über Spezifikationen, Schnittstellendefinitionen zu externen Komponenten oder Modelle erreicht werden.⁹⁴

2.2.4 Kommunikation

Schriftliche Dokumentation kann als Kommunikationsersatz oder -ergänzung (direkter Kommunikation) während der Softwareentwicklung genutzt werden.⁹⁵ Genutzt werden kann dies beispielsweise bei Softwareentwicklungsteams, die örtlich weit auseinander liegen oder bei denen Verständigungsschwierigkeiten bestehen.⁹⁶ In der Softwareent-wicklung wird oft behauptet, dass es wichtig ist, projektweite direkte Kommunikation zu verringern, da direkte Kommunikation zu geringerer Produktivität führt.⁹⁷ Dies führ-te im Laufe der Zeit zu einer Substitution direkter Kommunikation durch schriftliche Dokumentation. Heutzutage wird direkte Kommunikation und Zusammenarbeit wieder vermehrt als nützlich eingestuft.⁹⁸ Brooks ging 1975 schon explizit darauf ein, dass di-rekte Kommunikation erst dann schädlich für ein Projekt werden könnte, wenn zu viele Personen beteiligt sind.⁹⁹

2.2.5 Softwareerstellungs-Vertrag

Bei der Erstellung einer Individualsoftware, die einem Softwareherstellungs-Vertrag¹⁰⁰ unterliegt, ist eine Dokumentation oft schon implizit im Vertrag gegeben, da der Vertrag schriftliche Vereinbarung (Aufträge) über Eigenschaften des zu entwickelnden Systems enthält.¹⁰¹ Eine fachliche Dokumentation ist dann unerlässlich, wenn Vorgaben bezüglich Spezifikationen und zu entwickelnder Features bestehen.¹⁰²

Ein besonderer Fall der Forderung nach umfassender Entwicklerdokumentation kann dann gegeben sein, wenn ein Auftraggeber die Entwicklung einer Software outgesourced hat, und den extern entwickelten Code verstehen (z.B. aus Sicherheitsgründen) oder erweitern/modifizieren will.¹⁰³

2.2.6 Organisatorische Politik und Macht

Bei der Entwicklung von Software sind mehrere Interessensgruppen beteiligt,¹⁰⁴ die verschiedene Gründe und Anforderungen an Dokumentation haben können.¹⁰⁵ Die In-teressensgruppen, z.B. Programmierer, Nutzer und Projektverantwortliche, lassen sich vereinfachend in zwei Gruppen aufteilen: diejenigen, die die Software benutzen und diejenigen, die Einfluss auf die Softwareerstellung haben. Diese Arbeit beschränkt sich hier auf Interessensgruppen, die auf die Entwicklung direkt Einfluss nehmen können.

So kann beispielsweise das Management oder ein Projektleiter Dokumente fordern um das Gefühl der Kontrolle zu haben,¹⁰⁶ die Unternehmensleitung fordert durch Dokumen-tation eine „Perfektionierung des Managements“¹⁰⁷. Beteiligte Personen können Doku-mente zur Daseinsbegründung anfordern bzw. erstellen.¹⁰⁸ Dokumente können auch zur Befriedigung des Bedürfnis, etwas ‚abhaken’ zu können, verlangt werden.¹⁰⁹ Beispiels-weise kann ein Projektleiter detaillierte Anforderungs- und Architekturdokumentation fordern um seinen Arbeitsinhalt, das Managen der Entwicklung, explizit bestätigt zu se-hen und um die daraus resultierenden Arbeiten genehmigen zu können.

2.2.7 Strukturierung der Implementierung

Da Software komplex¹¹⁰ und die Erstellung von Software ein kreativer Prozess ist,¹¹¹ wird Dokumentation von Programmierern zur Erhöhung der Übersichtlichkeit und der Verständlichkeit des Quellcodes genutzt.

Schon vor dem Schreiben der ersten Zeile Quellcode kann durch Dokumentation (Inline-Kommentare) eine Verdeutlichung und Strukturierung der nächsten Arbeitsschritte erreicht werden.¹¹² Beispielsweise kann eine Aufstellung der nächsten Implementierungsaufgaben, ein Entwurf benötigter Funktionalitäten oder einfach eine knappe Übersicht über den Ablauf der weiteren Befehle aufgeschrieben werden.¹¹³

Eine solche Strukturierung dient auch der Erkennung von Problemen, die in der Imple-mentierung auftreten können und über die man sich durch das Aufschreiben rechtzeitig und umfassend Gedanken macht.¹¹⁴ Dies bietet den Vorteil, dass ‚frisch’ an ein Problem herangegangen wird und nicht, durch eine zu frühe Entscheidung auf einen Lösungs-weg, spätere Probleme selber erzeugt und Alternativen übersehen werden.¹¹⁵

2.2.8 Durchdringung inhaltlicher Konzepte

Wenn Entwickler Software erstellen, erweitern, wiederverwenden oder von Fehlern bereinigen sollen, ist die Durchdringung inhaltlicher Konzepte und Wissen über interne Abläufe einer Software, die übersichtlich und verständlich durch Modelle und Pläne gegeben werden können, Voraussetzung.¹¹⁶ Gerade in den heutzutage vielfach verwendeten objektorientierten Vorgehensweisen ist die Durchdringung modellierter inhaltlicher Konzepte zum Verständnis des objektorientierten Systems eine fundamentale Voraussetzung, um ein System korrekt implementieren zu können.¹¹⁷

Die Erstellung von Dokumentation kann auch helfen Fehler aufzudecken. Denn „(...) beim Schreiben werden Lücken offensichtlich“¹¹⁸, die vorher nicht aufgefallen sind oder die nicht bedacht wurden. Die Praktik des Extreme Programming, dass vor der Implementierung eines Codestückes zuerst die Testfälle dieses Abschnittes erstellt werden sollen,¹¹⁹ zielt beispielsweise darauf ab.

2.2.9 Geforderte Qualitätsstandards

Sobald von einer Software eine hohe Zuverlässigkeit und Sicherheit erwartet wird, kann man beobachten, dass Dokumentation detaillierter und umfangreicher erstellt wird. Dies liegt zum großen Teil an einer Ursache-Wirkungs-Beziehung, der die Software dann un-terliegt.¹²⁰ Die Ursache der hohen Qualitätsanforderung hat zwei Wirkungen. Erstens wird erschöpfend getestet und die Tests werden festgehalten. Zweitens strebt man an, Systeme leicht wartbar zu gestalten (nach weit verbreiteter Meinung also viel zu doku-mentieren), um bei Fehlfunktionen schnell und richtig eingreifen zu können.

2.2.10 Dokumentationsvorgaben

In einem Softwareentwicklungsprojekt kann es verschiedene Gründe für Dokumentati-onsvorgaben geben. Das jeweils angewendete Vorgehensmodell bzw. Softwareentwick-lungsmethode, nach dem eine Software entwickelt wird, kann bestimmte Elemente der Entwicklerdokumentation verlangen.¹²¹ Einige Modelle unterliegen beispielsweise einer inkrementellen oder evolutionären Vorgehensweise, bei denen davon ausgegangen wird, dass zu einem späteren Zeitpunkt eine Wartung der Software notwendig wird. Dann ist eine fachliche Dokumentation, z.B. Daten- oder Objektmodelle, unerlässlich.¹²² Auch können CASE-Tools die Erzeugung verschiedener Dokumente im Entwicklungsprozess vorschreiben.

2.3 Nachteile von Entwicklerdokumentation

Softwareentwicklung bedarf schon seit jeher die Abstimmung zueinander im Gegensatz und teilweise interdependenter stehender Ziele.¹²³ Ein Ziel, die Qualität der Software, kann durch Dokumentation verbessert werden.¹²⁴ Auf die anderen Ziele, Entwicklungs-kosten und -dauer, hat Entwicklerdokumentation allerdings einen negativen Einfluss.

Die Nutzung von Dokumentation in der Softwareentwicklung beinhaltet also ein gewis-ses Risiko,¹²⁵ das auf wenige Gründe zurückgeführt werden kann. Alle Nachteile der Erstellung einer Entwicklerdokumentation können im Endeffekt auf die zwei negativ korrelierenden Ziele verdichtet werden: zum einen auf einen Kostenaspekt (‚Dokumen-tation ist zu teuer’) und zum anderen auf einen Zeiteffekt (‚Dokumentation ist zu zeit-aufwändig’).¹²⁶ Diese vereinfachende Darstellung ist in der Betrachtung dieser Arbeit allerdings wenig hilfreich. Vielmehr wird im Folgenden darauf eingegangen, warum Dokumentation zu viel kosten bzw. zu hohen Zeitaufwand erzeugen, und welche sonstigen Nachteile Dokumentation noch mit sich bringen kann.

2.3.1 Aktualität

Während der Entwicklung einer Software unterliegen die verschiedenen Gegenstände der Dokumentation, insbesondere Quellcode, Schnittstellen, Architektur und Modelle, verschieden stark ausgeprägten Änderungen.¹²⁷ Auch Anforderungen und Spezifikatio-nen ändern sich in unklaren Softwareentwicklungsprojekten häufig,¹²⁸ und jede Soft-ware unterliegt nach der Fertigstellung ständig dem Druck, neuen Bedürfnissen angepasst werden zu müssen.¹²⁹ Durch Änderungen an Gegenständen der Dokumentation müsste auch die Dokumentation des Gegenstandes so geändert werden, dass sie der ak-tuellen Situation des dokumentierten Gegenstandes entspricht.¹³⁰ In der Praxis wird die Dokumentation einerseits jedoch oft nicht aktualisiert,¹³¹ andererseits kann eine schrift-liche Dokumentation nicht alle Feinheiten, wie eine Software funktioniert, erklären.¹³² Aus diesen Gründen findet sich in der Literatur sogar, häufig zusammen mit der Aussa-ge veraltete Dokumentation sei ‚gefährlich’, der Tipp: „Never trust documentation“¹³³.

2.3.2 Aktualisierungsaufwand

Wie oben gezeigt ändert sich Dokumentation stetig, oder sollte sich zumindest stetig ändern.¹³⁴ Durch die entstehende Notwendigkeit zur Aktualisierung von Dokumentation kann ein hoher Zeitaufwand entstehen, der in der Praxis kaum investiert wird.¹³⁵ Dies liegt zum großen Teil daran, dass Softwareprojekte unter einem stark ausgeprägten Termindruck zu leiden haben, und ein zusätzlicher Aufwand für vermeintlich überflüs-sige Aktivitäten, die nur die Projektlaufzeit erhöhen würde, zuerst gestrichen wird.¹³⁶ Daher kommt auch die Annahme, dass eine schnellere Realisierung von Software-Strukturen u.a. durch Dokumentationserleichterungen erreicht werden kann.¹³⁷ Auch kann sich der Fall ergeben, dass Termine nicht eingehalten werden können, da bei der Projektplanung der Aufwand für notwendige Dokumentation nicht berücksichtigt wur-de.¹³⁸

[...]

---

¹ Vgl. Boehm u.a. /Characteristics/ S. 2.1-2.2; Ambler /Agile Modeling/ S. 4

² Vgl. zur Abgrenzung Kapitel 1.4

³ Vgl. Komarnicki /Programmiermethodik/ S. 136

⁴ Stelzer /Möglichkeiten/ S. 104

⁵ Vgl. Borchert /Entwicklung/ S. 6-8; Visconti, Cook /Evolution/; Stelzer /Möglichkeiten/ S. 212-214; Block geht zwar nicht explizit davon aus, ihr Artikel Block /Life Cycle/ lässt dies aber vermuten

⁶ Vgl. Stelzer /Möglichkeiten/ S. 8-9; David /Relevanz/ S. 71; In der Praxis werden die Dokumentations- anforderungen der Vorgehensmodelle oft als Problem bezeichnet, vgl. Stelzer /Möglichkeiten/ S. 280

⁷ Vgl. Boehm /Agile Methods/ S. 66; Poppendieck /Lean Programming/ S. 3-4; Ambler /Agile Modeling/ S. 17

⁸ Vgl. David /Relevanz/ S. 18; Andersen u.a. /Systems Developement/ S. 159; Powell, French, Knight /Software Documentation/ S. 201; Brooks /Mythos/ S. 153; Wong /Incomplete Documentation/ S. 68

⁹ Vgl. Deifel u.a. /Praxis/ S. 31; Borchart /Entwicklung/ S. 6; Didrich, Klein /Aragmatic Approach/ S. 1; Visconti, Cook /Evolution/ S. 223; David /Relevanz/ S. 15-19

¹⁰ Vgl. Zokaites /Code/ S. 1-2 ; Cockburn /Development/ S. 176-177; Tempel /Re-Engineering/ S. 223

¹¹ Vgl. Komarnicki /Programmiermethodik/ S. 136; Ambler /Agile Modeling/ S. 144; Brooks und Naur nennen Dokumentation eine „Last“ (“a burden”), vgl. Brooks /Mythos/ S. 153; Naur /Computing/ S. 352

¹² Boehm u.a. unterstellen der Softwareentwicklung z.B. einen linearen Prozess, dessen Phasen durch ei- ne strenge Dokumentation abgeschlossen wird, vgl. Boehm u.a. /Characteristics/ 2.1-2.9, wohinge- gen dem Extreme Programming teilweise unterstellt wird, es verbiete Dokumentation außerhalb von Quellcode, vgl. Paulk /Extreme Programming/ S. 22

¹³ Brooks /Silver Bullet/ S. 10

¹⁴ Vgl. Brooks /Silver Bullet/ S. 10

¹⁵ Vgl. Yourdon /Programmierkunst/ S. 30

¹⁶ Vgl. Smith, Thomas, Tilley /Documentation/ S. 235; David /Relevanz/ S. 1

¹⁷ Vgl. David /Relevanz/ S. 18; Boehm /Agile Methods/ S. 68

¹⁸ Vgl. Oestereich u.a. /Objektorientierung/ S. 18

¹⁹ Vgl. Ambler /Agile Modeling/ S. 166-167

²⁰ Vgl. beispielsweise Powell, French, Knight /Software Documentation/; Zeihsel, Wittern /Dokumentation/ S. 28-30 oder David /Relevanz/

²¹ Gluchowski /Informationssysteme/ S. 1

²² Vgl. zur Abgrenzung und zu Literaturquellen zur Prozessdokumentation Kapitel 1.4

²³ Vgl. zur Abgrenzung und zu Literaturquellen zu Programmdokumentation Kapitel 1.4

²⁴ Zur Syntax verschiedener Dokumente bzw. Modellnotationen vgl. beispielsweise Balzert /Lehrbuch/, Rumbaugh u.a. /Modellieren/, Ferstl, Sinz /Grundlagen/ oder Raasch /Systementwicklung/; vgl. zu allgemeiner Dokumentationssyntax Rupietta /Benutzerdokumentation/

²⁵ Zu Vorschlägen der physischen Speicherung/Ablage von Dokumenten vgl. beispielsweise Gluchowski /Informationssysteme/; Zeihsel /Produktweiterentwicklung/ S. 23-26

²⁶ zum Dokumentationsmanagement in Projekten vgl. Madauss /Projektmanagement/ S. 319-328

²⁷ Vgl. Kieser, Kubicek /Organisation/ S. 45-47; Schreyögg /Organisation/ S. 326-327

²⁸ Es werden demnach deterministische Eigenschaften von Einflussfaktoren auf Entwicklerdokumentati- on aufgezeigt.

²⁹ Dieser Teil der Arbeit basiert auf rein theoretischen Überlegungen und baut in Ihren Gestaltungsalter- nativen auf Kapitel 3 auf. Eine empirische Arbeit, die Einflussfaktoren auf Entwicklerdokumentati- on systematisch untersucht, konnte nicht gefunden werden.

³⁰ Vgl. Rupietta /Benutzerdokumentation/ S. 15-16; Gaus /Dokumentationslehre/ S. 1-2; Klassische Do- kumentationen zu alltäglichen Gegenständen und zur Unterstützung einer Aktion sind beispielsweise

³¹ Der zu dokumentierende Gegenstand kann ein Produkt oder ein Prozess der Softwareentwicklung sein, vgl. Stelzer /Möglichkeiten/ S. 104

³² Vgl. Kapitel 3.2.3

³³ Beispielsweise zählen darunter direkte Kommunikation, umfassende Partizipation, öffentliche Präsen- tation und die (klassische) schriftliche Dokumentation, vgl. für weitere Alternativen Kapitel 3.2. Mit dieser Ansicht wird Kieser und Kubicek gefolgt, die eine synonyme Sichtweise auf Weisungen und Programme vertreten: „Persönliche Weisungen können ebenso mündlich wie schriftlich erteilt wer- den, und Programme können gleichermaßen in Handbüchern wie im Bewusstsein der Organisati- onsmitglieder ‚festgeschrieben’ sein“, Kieser, Kubicek /Organisation/ S. 104

³⁴ Manchmal auch Benutzerdokumentation, (Benutzer-)Handbuch oder Produktdokumentation genannt, vgl. Jamin /Lexikon/ S. 109; Chroust /Modelle/ S. 189; Stelzer /Möglichkeiten/ S. 101, 302

³⁵ Vgl. Oestereich u.a. /Objektorientierung/ S. 213; Savolainen /Perspectives/ S. 111-112; Dumke, Foltin /Softwareentwicklungskomplexität/ S. 84; Krause /Software-Erstellungsvertrag/ S. 5-6; David /Relevanz/ S. 61-62; Stahlknecht, Hasenkamp /Wirtschaftsinformatik/ S. 323-324; Die Benennung der einzelnen Dokumentationsarten ist teilweise unterschiedlich, läuft jedoch semantisch immer auf einer der bzw. die genannten Dokumentationsarten hinaus.

³⁶ Vgl. Balzert /Entwicklung/ S. 49; Sommerville /Software/ S. 230; Rupietta /Benutzerdokumentation/S. 15-16; Dumke /Software Engineering/ S. 102; David /Relevanz/ S. 63-64; zur Vertiefung eignet sich Rupietta /Benutzerdokumentation/; eine Norm findet sich beispielsweise in DIN /DIN 66230/; eine kurze Zusammenfassung findet sich in David /Relevanz/ S. 93-105

³⁷ Vgl. David /Relevanz/ S. 64-65; weiterführend Lehner u.a. /Organisationslehre/ S. 511-522; Dumke /Software Engineering/ S. 183-207; Koreimann /Softwareentwicklung/ S. 249-351; Hopkins, Jernow /Software Development Process/; für spezielle Dokumentation zur Projektkontrolle (die im Kontext dieser Arbeit der Prozessdokumentation entspricht) vgl. Madauss /Projektmanagement/ S. 177-247;

³⁸ Vgl. Lehner u.a. /Organisationslehre/ S. 518; David /Relevanz/ S. 106-115; oder allgemein Vorge- hensmodelle zur Softwareentwicklung.

³⁹ Vgl. Brodbeck /SE-Projekte/ S. 58-59; David /Relevanz/ S. 43-44, 86-89; Stahlknecht, Hasenkamp /Wirtschaftsinformatik/ S. 324

⁴⁰ Vgl. Ambler /Agile Modeling/ S. 143; Dumke /Software Engineering/ S. 3-4

⁴¹ Teilweise auch ‚spezifizierend’ genannt, vgl. David /Relevanz/ S. 61-63

⁴² Vgl. Ambler /Agile Modeling/ S. 143-144; Krause /Software-Erstellungsvertrag/ S. 6; Oestereich u.a. nennen dies externe bzw. interne Sicht der Dokumentation, vgl. Oestereich u.a. /Objektorientierung/

S. 219-220; David /Relevanz/ S. 62-63

⁴³ Vgl. David /Relevanz/ S. 74-75; Ambler /Agile Modeling/ S. 9; Boehm nennt den determinierenden Einsatz von Dokumentation „Vorabdokumentation“ und erstellt diese, „um (...) Ziele und Pläne für künftige Tätigkeiten der Softwareentwicklung zu definieren (...)“, vgl. Boehm /Software- Produktion/ S. 37-38; Müller nennt determinierende Dokumentation explizit „Projektvorgaben“, vgl. Müller /Software-Engineering/ S. 49

⁴⁴ Vgl. Cockburn /Development/ S. 127-129

⁴⁵ Der Ausdruck Funktion wird anstelle der in der OO üblichen Bezeichnung Methode verwendet, um den Charakter des Quellcodes hervorzuheben und eine Abgrenzung zu möglichen Methodendoku- mentationen verschiedener Prozessmodelle anzudeuten.

⁴⁶ Vgl. Oestereich /Objektorientierung/ S. 219

⁴⁷ Häufig, insbesondere bei Quellcode, wird dann einfach nur von ‚Kommentaren’ geredet, vgl. Kernig- han, Plauger /Elements/ S. 117-128

⁴⁸ Vgl. beispielsweise DIN /DIN 66230/, Gray, London /Programm-Dokumentation/ oder Rupietta /Benutzerdokumentation/

⁴⁹ Um einen Eindruck zu bekommen muss man nur die umfangreiche Literatur mit Bezug auf Prozess- modelle der Softwareentwicklung betrachten. Alleine Literatur zu den Themen CMM oder XP ist schon sehr umfangreich.

⁵⁰ D.h. selbst wenn Dokumentation sogar gänzlich unkorrekt ist, aber noch genutzt wird ist sie noch nicht am Ende der Lebensdauer angekommen. Einige Autoren würden die Bezeichnung ‚Ende des Le- benszyklus einer Dokumentation’ verwenden. Hier wird jedoch die Meinung vertreten, dass es kei- nen typischen Lebenszyklus (wie beispielsweise Erstellen, Nutzen, Warten) einer Software gibt. Hier wird vielmehr die Meinung vertreten, dass Entwicklerdokumentation einer ständigen und gleichzeitigen Erstellung, Nutzung und Wartung unterliegt. Der Begriff ‚Lebensdauer’ ist also präg- nanter, als der Begriff ‚Lebenszyklus’.

⁵¹ Vgl. David /Relevanz/ S. 74

⁵² Vgl. Kuhlmann /Qualitätsmodell/ S. 119; Gray, London /Programm-Dokumentation/ S. 12; Tempel geht von mehr als 50% aus, vgl. Tempel /Re-Engineering/ S. 218-219

⁵³ Vgl. Zum folgenden Absatz David /Relevanz/ 73-92; Für eine weit detailliertere und umfangreicherer Zusammenstellung vgl. Gray, London /Programm-Dokumentation/

⁵⁴ Vgl. Brooks /Mythos/ S. 54-55

⁵⁵ Vgl. DeMarco /Projektmanagement/ S. 65-66; Brooks /Mythos/ S. 54-55

⁵⁶ Vgl. weiterführend Bass, Clements, Kazman /Architecture/ insb. Kapitel 2 “What Is Software Archi- tecture?” oder für eine umfassende Definitionssammlung o.V. /Software Architecture/

⁵⁷ Vgl. Kazman /Scenario/ S. 6

⁵⁸ Vgl. Ambler /Agile Modeling/ S. 143

⁵⁹ Vgl. Oestereich u.a. /Objektorientierung/ S. 23

⁶⁰ Vgl. Yourdon /Programmierkunst/. S. 186; Ein praxisnahes Negativ-Beispiel hierzu ist der Absturz ei- ner Ariane 5 Trägerrakete am 4.Juni 1996, der durch einen fehlerhaften Prozeduraufruf zustande kam. Vgl. dazu Gleick /Bug/; Lions /Ariane 5/

⁶¹ Vgl. Borchart /Entwicklung/ S. 6; Tempel /Re-Engineering/ S. 220

⁶² Vgl. Oestereich u.a. /Objektorientierung/ S. 220

⁶³ Vgl. Kapitel 1.4

⁶⁴ Modelle stellen dann determinierende Dokumentation dar, vgl. Kapitel 1.4

⁶⁵ Vgl. Ambler /Agile Modeling/ S. 143-144

⁶⁶ Vgl. Beck /Extreme Programming/ S. 45

⁶⁷ Vgl. Sommerville /Software/ S. 9-10

⁶⁸ Natürlich sollte angestrebt sein, dass alle Szenarien funktionieren.

⁶⁹ Vgl. Oestereich u.a. /Objektorientierung/ S. 100

⁷⁰ Vgl. zum folgenden Absatz David /Relevanz/ S. 18-19

⁷¹ Vgl. Yonda /Employees/ S. 1; Oestereich u.a. /Objektorientierung/ S. 90-91; Funke u.a. /Softwareentwicklung/ S. 22; McConnell /Less/ S. 2; Cockburn /Development/ S. 36-37; Locke- mann u.a. /Systemanalyse/ zitiert nach David /Relevanz/ S. 17; Das Problem wird dadurch noch verschärft, da Fluktuation in der Softwarebranche, dem Saratoga Institute nach, höher ist, als in anderen Branchen, zitiert nach Müller /Erfolgsfaktoren/ S. 383

⁷² Vgl. Lockemann u.a. /Systemanalyse/ zitiert nach David /Relevanz/ S. 17; Boehm /Agile Methods/ S. 66

⁷³ Vgl. Poole, Huisman /Extreme Programming/ S. 43

⁷⁴ Vgl. Tempel /Re-Engineering/ S. 215; David /Relevanz/ S. 19; Nietsch /Softwareentwicklung/ S. 92-94

⁷⁵ Vgl. Dumke /Software Engineering/ S. 99

⁷⁶ Vgl. Borchert /Entwicklung/ S. 7; Gray, London /Programm-Dokumentation/ S. 11-13; Cockburn /Development/ S. 97-99

⁷⁷ David /Relevanz/ S. 19

⁷⁸ Vgl. Oestereich u.a. /Objektorientierung/ S. 220

⁷⁹ Vgl. David /Relevanz/ S.14

⁸⁰ Vgl. Mellis /Software/ S. 14; Naur /Computing/ S. 38; Naur argumentiert sogar, dass das wichtigste Ziel, noch vor der Erstellung von Quellcode, Dokumentation oder Spezifikationen, die ‚Bildung ei- ner Theorie’ über die Software ist, und dass das Wissen eines Programmierers, dass der Dokumenta- tion übersteigen sollte. (S. 41-42) Dies lässt sich allerdings auch leicht dadurch erklären, dass Ent- wicklerdokumentation nicht jedes Detail einer Software enthalten sollte.

⁸¹ Oestereich /Objektorientierung/ S. 93

⁸² Vgl. Zeihsel /Produktweiterentwicklung/ S. 20; nach Nonaka und Takeuchi ‚tacit’, vgl. Nonaka, Ta- keuchi /Company/ S. 62-64

⁸³ Vgl. Nonaka, Takeuchi /Company/ S. 64-67

⁸⁴ Vgl. Zeihsel, Wittern /Dokumentation/ S. 26; Nonaka, Takeuchi /Company/ S. 85-86

⁸⁵ Vgl. Nonaka, Takeuchi /Company/ S. 69-70

⁸⁶ Vgl. Nonaka, Takeuchi /Company/ S. 14, 69-70

⁸⁷ Vgl. Gaus /Dokumentationslehre/ S. 7-8

⁸⁸ Vgl. Ambler /Agile Modeling/ S. 164; Naur /Computing/ S. 38

⁸⁹ Vgl. Kieser, Kubicek /Organisation/ S. 104-105

⁹⁰ Vgl. David /Relevanz/ S. 18; Hoch u.a. /Secrets/ S. 96; Dumke, Foltin /Softwareentwicklungskom- plexität/ S. 85

⁹¹ Vgl. Zeihsel /Produktweiterentwicklung/ S. 19-22

⁹² Vgl. Powell, French, Knight /Software Documentation/ S. 201

⁹³ Vgl. Mellis u.a. /Software/ S. 28-29

⁹⁴ Vgl. Funke u.a. /Softwareentwicklung/ S. 129; Ambler /Agile Modeling/ S. 9, 70-71

⁹⁵ Vgl. Gaus /Dokumentationslehre/ S. 22; Gray, London /Programm-Dokumentation/ S. 10; Gray und London argumentieren, dass ein ursprünglicher Gedanke ohne Dokumentation mehr und mehr ent- stellt wird, so das der umgesetzte Gedanke kaum noch Ähnlichkeit mit dem ursprünglichen hat.

⁹⁶ Vgl. Cockburn /Development/ S. 13 i.V.m. S. 97

⁹⁷ Vgl. Balzert /Entwicklung/ S. 461-466; Sommerville /Software/ S. 295; Brooks /Mythos/ S. 11-22; Schnupp, Floyd /Software/ S. 209-212

⁹⁸ Vgl. Pasch /Software-Entwurf/ S. 15-16; David /Relevanz/ S. 19-22; Ambler /Agile Modeling/ S. 84- 85; Cockburn /Development/ S. 148-149, 153-156; Brodbeck /Kommunikation/ S. 11-13; Stelzer /Möglichkeiten/ S. 148-149

⁹⁹ Vgl. Brooks /Mythos/ S. 16-17; Dies wäre auch ein Grund, warum man sagt, dass Extreme Program- ming nur erfolgreich eingesetzt werden kann, wenn die Teamgröße 20 Personen nicht überschreitet, vgl. Beck /Extreme Programming/ S. 157, und warum bei Microsoft, wo stark auf Kommunikation gesetzt wird, auch kleine Entwicklungsteams vorherrschen, vgl. Cusumano, Selby /Microsoft/ S. 56 i.V.m. 83

¹⁰⁰ Für weiterführende Informationen zu Software-Erstellungsverträgen siehe Krause /Software- Erstellungsvertrag/ oder Wagen /Softwareherstellungsvertrag/

¹⁰¹ Vgl. Lockemann /Systemanalyse/ zitiert nach David /Relevanz/ S. 17 ¹⁰² Vgl. David /Relevanz/ S.14

¹⁰³ Vgl. Deifel u.a. /Praxis/ S. 33; Beck /Extreme Programming/ S. 156

¹⁰⁴ Vgl. Oestereich u.a. /Objektorientierung/ S. 213; Bächle /Qualitätsmanagement/ S. 77-81

¹⁰⁵ Vgl. Powell, French, Knight /Software Documentation/ S. 201; Ambler /Documentation/ S. 1

¹⁰⁶ Vgl. Ambler /Agile Modeling/ S. 144-145; Cockburn /Development/ S. 168; Beck /Extreme Pro- gramming/ S. 156

¹⁰⁷ Madauss /Projektmanagement/ S. 21

¹⁰⁸ Vgl. Ambler /Agile Modeling/ S. 146-147

¹⁰⁹ Vgl. Lockemann /Systemanalyse/ zitiert nach David /Relevanz/ S. 17

¹¹⁰ Vgl. David /Relevanz/ S. 18; Hoch u.a. /Secrets/ S. 96; Dumke, Foltin /Softwareentwicklungskom- plexität/ S. 85; Otto /Komplexitätseffekt/ S. 27; Brooks /Silver Bullet/ S. 11

¹¹¹ Vgl. beispielsweise Sommerville /Software/ S. 284; Grams /Denkfallen/ S. 111; Tempel /Re- Engineering/ S. 220; Madauss /Projektmanagement/ S. 21-22; Brooks /Silver Bullet/ S. 18

¹¹² Vgl. Brooks /Mythos/ S. 155; Dijkstra stellt dazu zwei Beispiele vor, in denen er seine ‚Kommentare’ allerdings wieder löscht, Dijkstra /Notes/ S. 27-39, 50-63

¹¹³ Vg. Funke u.a. /Softwareentwicklung/ S. 119-120; Ambler /Agile Modeling/ S. 9-10

¹¹⁴ Vgl. Ambler /Agile Modeling/ S. 145-146

¹¹⁵ Vgl. Leeds, Weinberg /Computer/ S. 282

¹¹⁶ Vgl. Koschke, Plödereder /Programmverstehen/ S. 159

¹¹⁷ Vgl. Kuhlmann /Qualitätsmodell/ S. 116

¹¹⁸ Brooks /Mythos/ S. 96

¹¹⁹ Vgl. Beck /Extreme Programming/ S. 115

¹²⁰ Vgl. zum restlichen Absatz Boehm /Software-Produktion/ S. 497-502, Boehm argumentiert, dass bei hoher geforderter Sicherheitsrate, vorab genauere Spezifikationen und Modelle erstellt werden müs- sen, und dass von Auftraggebern solcher Software (z.B. Militärs, Fahrzeughersteller) umfangreiche- re Dokumentations-Anforderungen bestehen. Madauss deutet darauf hin, dass gerade Systeme mit hohen Sicherheits- und Zuverlässigkeits-Anforderungen äußerst komplexe Systeme sind. Madauss zieht in seinem Buch immer wieder Vergleiche zur Raumfahrt und kommt so auch zu dem Schluss, dass „das Einfrieren der jeweiligen Basisdokumentation (Anforderungen, Spezifikationen u.Ä., Anm. d. Autors) (...) den erfolgreichen Abschluss vorausgehender Überprüfungen voraus(-setzt)“, und erst dann die Entwicklung folgen sollte, vgl. Madauss /Projektmanagement/ S. 153

¹²¹ Vgl. beispielsweise Chroust /Modelle/ S. 187-188; Oestereich /Objektorientierung/ S. 21

¹²² Vgl. David /Relevanz/ S.14

¹²³ Vgl. Boehm /Software-Produktion/ S. 16-18

¹²⁴ Vgl. Kapitel 2.2.9

¹²⁵ Vgl. Lehner u.a. /Organisationslehre/ S. 257-260

¹²⁶ In allgemeiner Literatur zu Betriebwirtschaftslehre und Produktion wird angeführt, das Zeit in der in- dustriellen Produktion durch Kosten (Investitionen) substituiert werden kann. In der Softwareindust- rie jedoch kann ein Zeitmangel nicht ohne weiteres durch einen höheren Ressourceneinsatz, was ei- ner Substitution des Zeitmangels in einen Kostennachteil entspricht, wettgemacht werden, vgl. Brooks /Mythos/ S. 19-22.

¹²⁷ Vgl. Oestereich u.a. /Objektorientierung/ S. 22; Ameneyro u.a. /System/ S. 29-30; Naur /Computing/ S. 42

¹²⁸ Vgl. Cusumano, Yoffie /Software Development/ S. 61, 64; Cusumano, Selby /Microsoft/ S. 221-224

¹²⁹ Vgl. Brooks /Silver Bullet/ S. 12; Weltz, Ortmann /Softwareprojekt/ S. 16

¹³⁰ Vgl. Nietsch /Softwareentwicklung/ S. 37

¹³¹ Vgl. Deifel u.a. /Praxis/ S. 31; Rugaber /Domain Knowledge/ S. 144

¹³² Vgl. Cusumano, Selby /Microsoft/ S. 117

¹³³ Ambler /Agile Modeling/ S. 166

¹³⁴ Vgl. Zöllner /Systementwicklung/ S.94-95

¹³⁵ Vgl. Funke u.a. /Softwareentwicklung/ S. 32; Cusumano, Selby /Microsoft/ S. 117-118; Boehm kommt 1981 zu dem Schluss, dass ein Programmierer ca. 60% des Arbeitsaufwandes für Dokumentation aufgewendet muss, vgl. Boehm /Software-Produktion/ S. 502

¹³⁶ Vgl. David /Relevanz/ S. 19

¹³⁷ Vgl. Koreimann /Softwareentwicklung/ S. 224

¹³⁸ Vgl. Funke u.a. /Softwareentwicklung/ S. 22