REPORT | SOFTWAREENTWICKLUNG 
Über das erfolgreiche Dokumentieren 
Papierkrieg 
Daniel Mölle 
Dokumentation gilt gemeinhin...
Requirements 
Engineering 
Analysis 
& Design 
Implemen-tation 
Vision 
Document 
So!ware 
Architecture 
Document 
Impleme...
REPORT | SOFTWAREENTWICKLUNG 
verlockend bequem ein derart trivialer 
Erklärungsversuch auch scheinen mag. 
Sie ist die Fo...
erschlagen, die dokumentationswürdig 
sind. 
Weiterhin sollte mindestens ein kom-mentiertes 
Beispieldokument, das als 
Pr...
REPORT | SOFTWAREENTWICKLUNG 
Au"raggeber Dienstleister 
Product Projektleiter 
Owner 
Anforderungs-dokument 
Architekt 
g...
Nächste SlideShare
Wird geladen in …5
×

Software-Dokumentation (iX Magazin 9/2014)

927 Aufrufe

Veröffentlicht am

Über das erfolgreiche Dokumentieren:
Dokumentation gilt gemeinhin als das ungeliebte Kind der
Softwareentwicklung. Viele Entwickler nehmen „clean code“ zwar als wertvolles Paradigma wahr, aber kaum jemand schwärmt von „clean spec“. Wer sich mit dieser Diskrepanz ernsthaft auseinandersetzt, wird auf überraschende Antworten stoßen – und die Chance erhalten, im nächsten Projekt wesentlich bessere Ergebnisse zu erzielen.

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
927
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
16
Aktionen
Geteilt
0
Downloads
7
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Software-Dokumentation (iX Magazin 9/2014)

  1. 1. REPORT | SOFTWAREENTWICKLUNG Über das erfolgreiche Dokumentieren Papierkrieg Daniel Mölle Dokumentation gilt gemeinhin als das ungeliebte Kind der Softwareentwicklung. Viele Entwickler nehmen „clean code“ zwar als wertvolles Paradigma wahr, aber kaum jemand schwärmt von „clean spec“. Wer sich mit dieser Diskrepanz ernsthaft auseinandersetzt, wird auf überraschende Antworten stoßen – und die Chance erhalten, im nächsten Projekt wesentlich bessere Ergebnisse zu erzielen. Dieser Artikel soll mit einem kurzen und – versprochen – einmaligen Ausflug in die Welt der Klischees beginnen: Frustriert schreitet der Projekt-leiter ins Entwicklerbüro, um zum zehn-ten Mal einzufordern, dass die Code-Än-derungen vom Vorjahr endlich auch in die Dokumentation einfließen. Die krea-tiv- chaotischen Entwickler allerdings haben offenbar mehr Freude daran, an ak-tuellen technischen Fragestellungen he-rumzutüfteln, und schieben die Dokumen-tenpflege auf. Die Dokumente bleiben unvollständig und veraltet. Schließlich scheitert eine geplante Übergabe der Software an ein anderes Team an der feh-lenden Nachvollziehbarkeit der zentralen Designentscheidungen. Natürlich ist diese Darstellung von Vorurteilen geprägt. Es gibt sowohl Pro-jekte, die in der Dokumentation ein aus-gezeichnetes Qualitätsniveau aufweisen, als auch Entwickler, die Freude daran haben, systematisch und sogar ästhetisch zu dokumentieren. Wahr ist aber, dass Dokumentationsaufgaben weniger Ak-zeptanz genießen als beispielsweise Im-plementierungs- oder Testaufgaben. Wa-rum das so ist – und wie sich dieser Missstand beheben lässt –, erörtert dieser Artikel. Die Gründe für die allgemein geringe Akzeptanz gegenüber Dokumentations-aufgaben sind vielschichtig. Allerdings lassen sich bestimmte Ursachen immer wieder feststellen. Dazu zählen die fol-genden. Das Stiefkind der Softwareentwicklung Allgemein schlechte Dokumentationskul-tur: Man stelle sich einen Entwickler vor, der mit einem unzureichend dokumen - tierten Build-System Software erstellen muss, die unzureichend dokumentierten Architekturvorgaben gehorcht und un - zureichend dokumentierte Anforderun-gen erfüllt, – und der seine Arbeitszeiten dabei nach mündlich übermittelten, wö-chentlich wechselnden Vorgaben erfas-sen soll. Es ist offensichtlich, dass solche Rahmen bedingungen kein Nährboden für exzellente Softwaredokumentation sein können. Wenn Projektleiter, Architekt und Requirements Engineer fundamen - tales Desinteresse an der Dokumentation ihrer Entscheidungen zeigen, überträgt sich dies zwangsweise auf das gesamte Team. Unklare Zielsetzung: In ähnlicher Weise ist es wenig verwunderlich, dass Dokumentieren keinen hohen Stellenwert zugemessen bekommt, wenn es als Selbst-zweck empfunden wird. Arbeitet der Au-tor eines Dokuments unter der Prämisse, dass seine Ausführungen lediglich dem Füllen von Aktenordnern dienen, kann er selbstredend keine Leidenschaft für die Erfüllung seiner Aufgabe empfinden. Das Resultat sind typischerweise Dokumente, die Trivialitäten akribisch ausführen und zentrale Aspekte der betroffenen Soft-warekomponente verschweigen (Stich-wort: „and then a miracle occurs“). Unklare Vorgaben: Ein weiteres ver-breitetes Problem sind unklare oder gar ungeeignete Vorgaben zur Struktur von Software-Designspezifikationen. Unter derartigen Voraussetzungen bleibt den Autoren schleierhaft, welche Fragen sie in den einzelnen Abschnitten zu beant-worten haben oder wo sie bestimmte Informationen platzieren sollen, die sie für wichtig halten. Die Folge sind unter-einander inkonsistente Dokumente, die nicht nur wichtige Informationen ver-missen lassen, sondern aufgrund des unterschiedlichen Umgangs mit der vor-definierten Gliederungsstruktur auch schwierig zu lesen sind. !" iX #/$%&" © Copyright by Heise Zeitschriften Verlag
  2. 2. Requirements Engineering Analysis & Design Implemen-tation Vision Document So!ware Architecture Document Implementation Model Test Plan Release Notes Risk List Use-Case Model Design Model Test Cases Deployment Unit Bei einer allgemein guten Dokumentationskultur werden alle Projektartefakte sauber dokumentiert und die Ergebnisse von der Ziel-gruppe durch Reviews auf die Erfüllung des jeweiligen Zwecks überprüft (Abb.ˇ1). Unzureichende Unterstützung: Pro-jektmitarbeiter empfinden es zu Recht als völlig normal, wenn ein Entwickler den Architekten zu Rate zieht, um eine zen-trale Designentscheidung zu bewerten oder eine fundamentale Code-Änderung zu kontrollieren – solche Vorgänge ent-sprechen geradezu den Definitionen die-ser Projektrollen. Erstaunlicherweise gilt dies aber nicht für die Dokumentation einer solchen Designentscheidung oder für fundamentale Änderungen an der De-signspezifikation. Vielmehr ist es gängige Praxis, den Entwickler gerade bei der Dokumentation komplexer Sachverhalte alleinzulassen. Unterstützen, statt nur zu fordern Doppelmoral: Die oben genannte Wert-schätzungsfrage betrifft auch den Projekt-leiter. Es ist eine Sache, die Erledigung von Dokumentationsaufgaben einzufor-dern, und eine andere, diese Aufgaben im Zweifelsfall entsprechend zu priorisieren. Ein Projektleiter etwa, der sich bei hohem Test Deployment Project Management So!ware Development Defect List Iteration Plans Project Iteration Assessments Druck im Zweifelsfall immer gegen eine Bevorzugung der Dokumentation ent-scheidet, darf nicht erwarten, dass die Entwickler dies als Beweis für die Wich-tigkeit einer soliden Dokumentation in-terpretieren. Kein Belohnungssystem: Bahnbrechen-de Anpassungen am Code – etwa der Einbau eines langersehnten Features oder die Behebung eines komplizierten Fehlers – erhalten oft Anerkennung. Das gilt sogar dann, wenn der entstandene Code schlecht ist, weil die Beobachter nur das äußere Ergebnis wahrnehmen. Besondere Leistungen in der Dokumen-tation hingegen werden eher selten her-vorgehoben. Noch schwieriger ist es in Projekten, bei denen Reviews die einzi-gen Quellen von Rückmeldungen zur Dokumentation sind – denn Reviews ten-dieren dazu, negatives Feedback in den Vordergrund zu rücken. Schlechte Infrastruktur: Viele Unter-nehmen zwingen interne oder externe Softwareteams dazu, ihre Dokumenta - tion mit dafür besonders ungeeigneten Werkzeugen zu pflegen. Diese Unart nimmt in der Praxis viele Ausprägungen Con!guration & Change Management Environment Con"guration Management Plan Development Case Plan Change Request Programming Guidelines Repository an, von denen hier nur drei erwähnt wer-den sollen. Das Team verwendet WYSIWYG-Edi-toren, sodass die Autoren zum Teil selbst für Textsatz und Layout zuständig sind (beispielsweise für das einheitliche Aus-sehen von Tabellen und Abbildungen oder für das Reparieren verstellter Formatie-rungsvorgaben). Dieser Umstand wiegt umso schwerer, als gerade Softwaredoku-mentation dazu neigt, bestimmte Textele-mente oft zu wieder holen. Handgeschriebene und generierte Text-elemente werden in einem Textverar - beitungssystem kombiniert, das keine Drucklegung kennt. Dies ist deshalb pro-blematisch, weil ein Dokument in derar-tigen Systemen zu jedem Zeitpunkt, nach jedem Tastendruck „gültig“ ist. Die Ak-tualisierung der generierten Elemente, die eigentlich zum Zeitpunkt der Druckle-gung zu erfolgen hat, muss der Verant-wortliche in solchen Systemen manuell auslösen, was extrem fehleranfällig ist. Man nimmt den Autoren die Möglich-keit, lokal zu arbeiten. Ein solches Setup geht meistens mit einer komplexen Infra-struktur einher, die sich schwer bändigen lässt und die Arbeitsprozesse künstlich verlangsamt. Unter derartigen Bedingungen können Autoren das Dokumentieren nur als hoch-gradig unangenehm empfinden. Zusammenfassend lässt sich feststel-len, dass die Gründe für eine geringe Wertschätzung gegenüber Dokumenta - tionsaufgaben im Regelfall hausgemacht sind. Das an dieser Stelle oft gesehene „Entwickler-Bashing“ jedenfalls hilft we-nig: Schlechte Dokumentation ist keine Folge von Persönlichkeitsmängeln einer ganzen Gattung von Mitarbeitern – so !"TRACT ( Trotz zahlreicher Plädoyers aus der gesamten Fachwelt wird das Thema Doku-mentation in der Softwareentwicklung noch oft vernachlässigt. ( Die Gründe dafür sind vielfältig und reichen von ungenügenden Vorgaben über inadäquate Arbeitsbedingungen bis hin zu fehlender Wertschätzung. ( Projektverantwortliche, die derartige Missstände nicht nur erkennen, sondern ihnen mit geeigneten Maßnahmen begegnen, können entscheidende Verbesse-rungen in der Dokumentationsqualität erzielen – von denen alle profitieren. iX #/$%&" !' © Copyright by Heise Zeitschriften Verlag
  3. 3. REPORT | SOFTWAREENTWICKLUNG verlockend bequem ein derart trivialer Erklärungsversuch auch scheinen mag. Sie ist die Folge von Arbeits- und Rand-bedingungen, die das Dokumentieren nicht belohnen, sondern bestrafen. Folglich liegt die Lösung darin, diese Bedingungen zu verbessern. Dies wie-derum setzt voraus, dass sich gerade die Teammitglieder mit größeren Einfluss-möglichkeiten für diese Sache einsetzen. Ein derartiges Engagement ist allerdings sowieso geboten, wie sich leicht herlei-ten lässt. Erst erkennen, dann verändern Zu den Hauptaufgaben von Projektleitern gehört es sicherzustellen, dass ihre Mit-arbeiter formale Vorgaben einhalten; dazu zählen selbstverständlich die Vorgaben bezüglich der Dokumentation. Zu den Hauptaufgaben von Architekten zählt die Sicherung der technischen Qualität; das schließt natürlich die Qualität der Doku-mentation technischer Sachverhalte ein. Nehmen die betroffenen Personen diese Verantwortungen umfänglich wahr, kann gar keine dauerhaft schlechte Doku-mentation entstehen. Die folgenden Ausführungen konkre-tisieren die etwas abstrakte Forderung nach starkem Engagement für eine gute Dokumentation. Zu diesem Zweck sollen die oben aufgeführten Ursachen für schlechte Dokumentation einzeln aufge-löst werden. Allgemein gute Dokumentationskul-tur: Im Idealfall weiß jedes Teammitglied genau, dass alle wichtigen Entscheidun-gen und Tatsachen zu dokumentieren sind. In der Praxis allerdings verlangt dies viel Disziplin – jeder, der eine Tat - sache schafft, hat sie sofort für alle zu-gänglich festzuhalten – und Aufmerksam-keit – sobald auffällt, dass irgendjemand Herrschaftswissen oder Geheimdoku-mente hortet, muss man eine Offenlegung anmahnen. Hierbei geht es keineswegs nur um die Spezifikation, die sowieso offiziell gefordert ist, sondern auch um zusätz - liche Begleitdokumente. Als besonders hilfreich stellen sich oft „Zwischendoku-mente“ heraus: Schriftstücke, die Details aus verschiedenen offiziellen Dokumen-ten im Hinblick auf häufige Anwen-dungsfälle wie Inbetriebnahme, Wartung, Testauswertung oder Fehleranalyse zu-sammentragen. Weiterhin empfiehlt es sich allein aufgrund der Vorbildfunktion dringend, neue Teammitglieder bei der Einführung ins Projekt mit hilfreichen, ganz beson-ders gut gemachten Dokumenten zu überraschen – etwa zur Umsetzung des Entwicklungsprozesses in der täglichen Arbeit. Klare Zielsetzung: Die Wertschätzung gegenüber Softwaredokumentation er-höht sich spürbar, wenn man den Autoren bewusst macht, wie viele Personen und Bedürfnisse mit dem jeweiligen Doku-ment verbunden sind. Für die Designspe-zifikation einer Softwarekomponente las-sen sich hier unter anderem die folgenden Punkte festhalten: –ˇEin Tester, der die Komponente prüfen soll, muss aus der Dokumentation erse-hen können, wann sich die Komponente wie verhalten soll. –ˇEin Entwickler, der die Komponente verwenden soll, muss aus der Dokumen-tation ableiten können, was ihre Funktio-nen leisten und wie sie sich verwenden lassen. –ˇEin Entwickler, der die Komponente übernehmen soll, muss in der Dokumen-tation zusätzlich die zentralen Designent-scheidungen erkennen sowie ersehen können, wie die Komponente intern auf-gebaut ist. Dies betrifft auch Urlaubsver-tretungen und gilt somit immer, für jedes Projekt und für jede Komponente. –ˇEin Code-Reviewer muss aus der Do-kumentation ableiten können, wie sich die Komponente verhalten soll, um dieses Soll-Verhalten im Review dem Ist-Ver-halten des tatsächlichen Codes gegen-überstellen zu können. –ˇEin Dokumenten-Reviewer, der typi-scherweise mit geringen technischen Kenntnissen auf das Dokument zugeht, ist auf eine Top-down-Struktur angewie-sen, die systematisch von allgemeinen Rahmenbedingungen und Lösungsansät-zen zu konkreten Design- und Implemen-tierungsdetails führt. Klare Vorgaben machen und alles berücksichtigen Teammitglieder in führenden Rollen tun gut daran, sich diese „reader stories“ (analog zum bekannten Konzept der „user stories“) regelmäßig in Erinnerung zu rufen. Klare Vorgaben: Eine Dokumenten-vorlage, deren gesamte Leistung darin besteht, eine Kapitelstruktur vorzuschrei-ben, kann als Vorgabe niemals ausrei-chen. Wer eine hohe Qualität und Konsis-tenz der zu erstellenden Dokumente anstrebt, muss den angehenden Autoren ein Template mit ausführlich kommen-tierten Abschnitten an die Hand geben, die jeweils alle relevanten Fragen beant-worten: –ˇWelche Themen soll dieses Kapitel be-handeln? –ˇWie hoch ist der gewünschte Abstrak - tionsgrad? –ˇWie bettet sich der Abschnitt ins Ge-samtdokument ein (Lesefluss)? –ˇFür welche Leser/Rollen ist dieser Ab-schnitt wichtig (Publikum)? –ˇWelche Aspekte verdienen hier beson-dere Erwähnung? –ˇWelche Aspekte verdienen hier insbe-sondere keine Erwähnung? Wichtig ist natürlich auch, dass die Abschnitte zusammen alle Aspekte Grobe Gliederungsvor-gaben zu Designspezi-fikationen (hier etwa basierend auf Kruch-tens Modell der 4 + 1 Sichten) reichen nicht aus: Sie führen zwangs - läufig zu inkonsisten-ten Interpretationen durch die verschiede-nen Autoren (Abb.ˇ2). Was leistet die Komponente (abstrakte Kernaufgaben)? Warum wird das benötigt (z. B. Benutzeranforderungen)? Welche Randbedingungen gelten (z. B. Systemanforderungen)? Wie bettet sich die Komponente in das Gesamtsystem ein? Wo läu! sie? Welche Funktion bietet die Komponente im Einzelnen an; was sind zentrale Abläufe? Wie wurde diese Funktion konkret intern umgesetzt? Was waren wichtige Trade-o#s? Welche Ausführungskonzepte gibt es (z. B. bei nebenläu"ger Umsetzung)? Sind Besonderheiten zu beachten? Szenarios Deployment-Sicht logische Sicht Entwicklungssicht Prozesssicht Detaillierungsgrad !) iX #/$%&" © Copyright by Heise Zeitschriften Verlag
  4. 4. erschlagen, die dokumentationswürdig sind. Weiterhin sollte mindestens ein kom-mentiertes Beispieldokument, das als Prototyp dienen kann, das Template er-gänzen. Die zusätzlichen Kommentare müssen vor allem die wesentlichen Ent-scheidungen des Autors nachvollziehbar machen. Missverständnisse rechtzeitig verhindern Derart konkrete Vorgaben helfen in vie-lerlei Hinsicht. Sie bieten nicht nur Ori-entierung beim Erstellen und Pflegen des Dokuments, sondern auch bei allen folgenden Reviews: Der Reviewer kann das Schriftstück systematisch auf Ein-haltung der Vorgaben prüfen, während der Autor vor willkürlichen Befunden geschützt wird. Ausreichende Unterstützung: Die Wertschätzung für gute Dokumente spie-gelt sich auch darin wider, welche For-men von Support die Autoren erhalten. Beachtenswert ist in diesem Zusammen-hang die Daumenregel, dass späte Unter-stützung deutlich teurer ist als frühzeitige (analog zu Fehlerkosten im Software-Le-benszyklus). Im Idealfall bieten die Verantwort - lichen dem Autor schon vor dem Erstel-len oder Aktualisieren eines Dokuments einen Ansprechpartner an, mit dem er diskutieren kann, welche Aspekte er in welchem Umfang und an welcher Stelle zu beschreiben hat. Derartige Vorbespre-chungen verringern das Risiko, dass er nicht das Wesentliche dokumentiert (fal-scher Fokus), deutlich. Ähnlich wertvoll sind kurzfristige, in-formelle Reviews – idealerweise durch Leser, die tatsächlich „Kunden“ des be-troffenen Dokuments sein werden (zum Beispiel Entwickler oder Tester, die bald mit den frisch spezifizierten Neuerungen umgehen müssen). Solche Reviews verringern das Risiko, dass der Autor die Neuerungen nicht rich-tig dokumentiert (zum Beispiel durch missverständliche Formulierungen), eben-falls drastisch. Ferner sollte jedem formalen Review durch organisationsexterne Gutachter ein interner Review vorangehen – nicht nur aus pragmatischen, sondern auch aus psy-chologischen Gründen: Der interne Re-view gibt dem Autor mehr Sicherheit und entlastet ihn von einer Art Alleinverant-wortung. Authentizität: Es reicht nicht aus, den hohen Stellenwert von Dokumentation nur zu deklarieren. Vielmehr müssen die Teammitglieder, die von Anfang an am Projekt beteiligt sind, schon dort das vor-leben, was sie später von anderen einfor-dern wollen. Personen in führenden Rollen sollten außerdem den Mut aufbringen, sich aus der bequemen „Du schreibst, ich be - werte“-Position herauszubewegen. Ein wesentliches Qualitätsmerkmal von Ar-chitekturdokumenten etwa ist die Brauch-barkeit für Entwickler – eine Eigenschaft also, die sich am besten per Review durch einen oder mehrere Entwickler nachweisen lässt. Anforderungsspezifikation unter die Lupe nehmen Ähnliches gilt für alle anderen Input-Do-kumente, die in der täglichen Entwick-lungsarbeit relevant sind. Besonders er-iX #/$%&" !! © Copyright by Heise Zeitschriften Verlag
  5. 5. REPORT | SOFTWAREENTWICKLUNG Au"raggeber Dienstleister Product Projektleiter Owner Anforderungs-dokument Architekt gottgegeben gottgegeben Architektur-dokument gottgegeben So nicht: Die Review-Pflicht für Dokumente soll nicht der Aufrechterhaltung der „Hack-ordnung“ dienen, sondern der Qualitätssicherung. Wer sich Reviews unter Berufung auf seine Rolle entzieht, handelt fahrlässig (Abb.ˇ3). wähnenswert ist in diesem Kontext die so immens wichtige Anforderungsspezi-fikation: Ausgerechnet sie wird häufig keinen Reviews durch technisch orien-tierte Personen unterzogen, weil sie eine Organisationsgrenze überschreitet (vom fachlich orientierten Auftraggeber zur Entwicklungsabteilung), die nur eine Review-Richtung kennt. Dabei können derartige Reviews nicht nur kritische Mängel aufdecken, die sonst kostspieli-ge Folgen hätten, sondern auch ein star-kes Signal setzen, was die allgemeinen Ansprüche an die Dokumentenqualität angeht. Konstruktivität statt willkürlicher Kritik Belohnungssysteme: Gute Dokumentation ist bescheiden. Sie schreit nicht nach Auf-merksamkeit und zeigt sich nur dem, der sich die Mühe macht, sie näher zu betrach-ten. Es liegt deshalb an den beteiligten Personen selbst, eine Kultur zu schaffen, die gutes Dokumentieren belohnt. –ˇProjektleiter und Architekt sollten sich angewöhnen, Leistungen in der Doku-mentenarbeit ausdrücklich anzuerken-nen. –ˇDas Team sollte Momente, in denen gu-te Dokumentation besonders hilfreich war, bei den üblichen Gelegenheiten Arbeits- und Prozessvorgaben Entwickler Tester Design-spezi "kation Test-spezi "kation zweifelha! zweifelha! (Stand-ups, Retrospektiven et cetera) her-vorheben. –ˇReview-Moderatoren sollten dafür Sor-ge tragen, dass die Sitzungen in Umge-bungen stattfinden, die die Teilnehmer nicht schon selbst als Strafe empfinden. –ˇReview-Gutachter sollten sich nicht in die Rolle des „Befundgenerators“ bege-ben („bogus findings“ vermitteln dem be-troffenen Autor das Gefühl, einer willkür-lichen Kritik ausgesetzt zu sein, die von der Qualität des Dokuments unabhängig ist), sondern sich der Konstruktivität ver-pflichten. Gute Infrastruktur: Der Aspekt Infra-struktur unterliegt der Besonderheit, dass er häufig nicht vom Softwareteam zu be-einflussen ist. In Großunternehmen bei-spielsweise gehört es oftmals zu den Aufgaben einer eigenen Qualitätsmana-gement- Abteilung, die bei der Dokumen-tation zu verwendenden Werkzeuge fest-zulegen. Der Projektleiter allerdings hat immerhin die Möglichkeit, auf die Aus-wirkungen einer Entscheidung für eine besonders ungeeignete Infrastruktur hin-zuweisen. Für den Fall, dass ein Team aufgrund unantastbarer Vorgaben mit behäbigen, fehleranfälligen Werkzeugen arbeiten muss, lässt sich immerhin noch Schadens-begrenzung betreiben – etwa durch Anlei-tungen, Unterstützung bei der Einführung oder klar definierte Arbeitsabläufe. Dies gilt insbesondere für manuelle Tätigkeiten, die sich über viele Doku-mente hinweg ständig wiederholen: Es ist im Allgemeinen wesentlich besser, derar-tige Arbeiten bei einer Person zu konzen-trieren. Negativ formuliert: Crowdsour-cing ist ein besonders schlechter Ansatz, wenn es darum geht, über viele Artefak-te hinweg konsistente Ergebnisse zu er-zielen. Fazit Die abstrakte Forderung nach hoher Do-kumentationsqualität ist in der Praxis wesentlich häufiger anzutreffen als Rah-menbedingungen, die diese Qualität be-günstigen. Schlimmer noch: Häufig zeigen gerade diejenigen, die diese Forderung stellen, Defizite beim Dokumentieren ih-rer Entscheidungen und der daraus resul-tierenden Artefakte. Diese Vernachlässigung zeigt sich so-gar in der Fachliteratur: Es gibt Aber - tausende von Büchern über das konkrete Implementieren von Software, aber prak-tisch kein einziges über Softwaredoku-mentation auf Detailebenen der Archi-tektur – und selbst dort ist die Auswahl vergleichsweise spärlich [1, 2, 3]. Der wichtigste Wegbereiter in Rich-tung gute Dokumentation ist und bleibt eine vom gesamten Team getragene Kul-tur, in der es selbstverständlich ist, alle wichtigen Informationen schriftlich und bedürfnisgerecht festzuhalten. Für die Herstellung einer solchen Kultur sind vor allem diejenigen verantwortlich, die schon zu einem frühen Zeitpunkt im Pro-jekt damit beginnen, derartige Informatio-nen zu generieren: Projektleiter, Require - ments Engineer, Architekt, Toolsmith und so weiter. (ka) Dr. Daniel Mölle arbeitet als Softwarearchitekt bei der Zühlke Engineering GmbH. Literatur [1]ˇPaul Clements et al.; Documenting Software Architectures; Views and Beyond; Addison-Wesley Professional, 2010. [2]ˇGernot Starke; Effektive Software-Ar-chitekturen; Ein praktischer Leitfaden; Hanser, 2011. [3]ˇStefan Zörner; Software-Architekturen dokumentieren und kommunizieren: Entwürfe, Entscheidungen und Lösun-gen nachvollziehbar und wirkungsvoll festhalten; Hanser, 2012. * !+ iX #/$%&" © Copyright by Heise Zeitschriften Verlag

×