links 74

D ieser Artikel soll mit einem kurzenund – versprochen – einmaligenAusflug 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 indie 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 bleibenunvollständig und veraltet. Schließlich

scheitert eine geplante Übergabe derSoftware an ein anderes Team an der feh-lenden Nachvollziehbarkeit der zentralenDesignentscheidungen.

Natürlich ist diese Darstellung vonVorurteilen geprägt. Es gibt sowohl Pro-jekte, die in der Dokumentation ein aus-gezeichnetes Qualitätsniveau aufweisen,als auch Entwickler, die Freude daranhaben, systematisch und sogar ästhetischzu dokumentieren. Wahr ist aber, dassDokumentationsaufgaben weniger Ak-zeptanz genießen als beispielsweise Im-plementierungs- oder Testaufgaben. Wa-

rum das so ist – und wie sich dieserMissstand beheben lässt –, erörtert dieserArtikel.

Die Gründe für die allgemein geringeAkzeptanz gegenüber Dokumentations-aufgaben sind vielschichtig. Allerdingslassen sich bestimmte Ursachen immerwieder feststellen. Dazu zählen die fol-genden.

Das Stiefkind der SoftwareentwicklungAllgemein schlechte Dokumentationskul-tur: Man stelle sich einen Entwickler vor,der mit einem unzureichend dokumen -tierten Build-System Software erstellenmuss, die unzureichend dokumentiertenArchitekturvorgaben gehorcht und un -zureichend dokumentierte Anforderun-gen erfüllt, – und der seine Arbeitszeitendabei nach mündlich übermittelten, wö-chentlich wechselnden Vorgaben erfas-sen soll. Es ist offensichtlich, dass solcheRahmen bedingungen kein Nährboden fürexzellente Softwaredokumentation seinkönnen. Wenn Projektleiter, Architektund Requirements Engineer fundamen -tales Desinteresse an der Dokumentationihrer Entscheidungen zeigen, überträgtsich dies zwangsweise auf das gesamteTeam.

Unklare Zielsetzung: In ähnlicherWeise ist es wenig verwunderlich, dassDokumentieren keinen hohen Stellenwertzugemessen bekommt, wenn es als Selbst-zweck empfunden wird. Arbeitet der Au-tor eines Dokuments unter der Prämisse,dass seine Ausführungen lediglich demFüllen von Aktenordnern dienen, kann erselbstredend keine Leidenschaft für dieErfüllung seiner Aufgabe empfinden. DasResultat sind typischerweise Dokumente,die Trivialitäten akribisch ausführen undzentrale Aspekte der betroffenen Soft-warekomponente verschweigen (Stich-wort: „and then a miracle occurs“).

Unklare Vorgaben: Ein weiteres ver-breitetes Problem sind unklare oder garungeeignete Vorgaben zur Struktur vonSoftware-Designspezifikationen. Unterderartigen Voraussetzungen bleibt denAutoren schleierhaft, welche Fragen siein den einzelnen Abschnitten zu beant-worten haben oder wo sie bestimmte Informationen platzieren sollen, die siefür wichtig halten. Die Folge sind unter-einander inkonsistente Dokumente, dienicht nur wichtige Informationen ver-missen lassen, sondern aufgrund des unterschiedlichen Umgangs mit der vor-definierten Gliederungsstruktur auchschwierig zu lesen sind.

!" iX #/$%&"

REPORT | SOFTWAREENTWICKLUNG

Über das erfolgreiche Dokumentieren

PapierkriegDaniel Mölle

Dokumentation gilt gemeinhin als das ungeliebte Kind derSoftwareentwicklung. Viele Entwickler nehmen „clean code“zwar als wertvolles Paradigma wahr, aber kaum jemandschwärmt von „clean spec“. Wer sich mit dieser Diskrepanzernsthaft auseinandersetzt, wird auf überraschende Antwortenstoßen – und die Chance erhalten, im nächsten Projekt wesentlich bessere Ergebnisse zu erzielen.

ix.0914.074-078 18.08.14 14:26 Seite 74

© Copyright by Heise Zeitschriften Verlag

75 rechts

Unzureichende Unterstützung: Pro-jektmitarbeiter empfinden es zu Recht alsvöllig normal, wenn ein Entwickler denArchitekten zu Rate zieht, um eine zen-trale Designentscheidung zu bewertenoder eine fundamentale Code-Änderungzu kontrollieren – solche Vorgänge ent-sprechen geradezu den Definitionen die-ser Projektrollen. Erstaunlicherweise giltdies aber nicht für die Dokumentation einer solchen Designentscheidung oderfür fundamentale Änderungen an der De-signspezifikation. Vielmehr ist es gängigePraxis, den Entwickler gerade bei derDokumentation komplexer Sachverhaltealleinzulassen.

Unterstützen, statt nur zu fordernDoppelmoral: Die oben genannte Wert-schätzungsfrage betrifft auch den Projekt-leiter. Es ist eine Sache, die Erledigungvon Dokumentationsaufgaben einzufor-dern, und eine andere, diese Aufgaben imZweifelsfall entsprechend zu priorisieren.Ein Projektleiter etwa, der sich bei hohem

Druck im Zweifelsfall immer gegen eineBevorzugung der Dokumentation ent-scheidet, darf nicht erwarten, dass dieEntwickler dies als Beweis für die Wich-tigkeit einer soliden Dokumentation in-terpretieren.

Kein Belohnungssystem: Bahnbrechen-de Anpassungen am Code – etwa derEinbau eines langersehnten Featuresoder die Behebung eines kompliziertenFehlers – erhalten oft Anerkennung. Dasgilt sogar dann, wenn der entstandeneCode schlecht ist, weil die Beobachternur das äußere Ergebnis wahrnehmen.Besondere Leistungen in der Dokumen-tation hingegen werden eher selten her-vorgehoben. Noch schwieriger ist es inProjekten, bei denen Reviews die einzi-gen Quellen von Rückmeldungen zurDokumentation sind – denn Reviews ten-dieren dazu, negatives Feedback in denVordergrund zu rücken.

Schlechte Infrastruktur: Viele Unter-nehmen zwingen interne oder externeSoftwareteams dazu, ihre Dokumenta -tion mit dafür besonders ungeeignetenWerkzeugen zu pflegen. Diese Unartnimmt in der Praxis viele Ausprägungen

an, von denen hier nur drei erwähnt wer-den sollen.

Das Team verwendet WYSIWYG-Edi-toren, sodass die Autoren zum Teil selbstfür Textsatz und Layout zuständig sind(beispielsweise für das einheitliche Aus-sehen von Tabellen und Abbildungen oderfür das Reparieren verstellter Formatie-rungsvorgaben). Dieser Umstand wiegtumso 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 keineDrucklegung kennt. Dies ist deshalb pro-blematisch, weil ein Dokument in derar-tigen Systemen zu jedem Zeitpunkt, nachjedem Tastendruck „gültig“ ist. Die Ak-tualisierung der generierten Elemente, dieeigentlich zum Zeitpunkt der Druckle-gung zu erfolgen hat, muss der Verant-wortliche in solchen Systemen manuellauslösen, was extrem fehleranfällig ist.

Man nimmt den Autoren die Möglich-keit, lokal zu arbeiten. Ein solches Setupgeht meistens mit einer komplexen Infra-struktur einher, die sich schwer bändigenlässt und die Arbeitsprozesse künstlichverlangsamt.

Unter derartigen Bedingungen könnenAutoren das Dokumentieren nur als hoch-gradig unangenehm empfinden.

Zusammenfassend lässt sich feststel-len, dass die Gründe für eine geringeWertschätzung gegenüber Dokumenta -tionsaufgaben im Regelfall hausgemachtsind. Das an dieser Stelle oft gesehene„Entwickler-Bashing“ jedenfalls hilft we-nig: Schlechte Dokumentation ist keineFolge von Persönlichkeitsmängeln einerganzen Gattung von Mitarbeitern – so

iX #/$%&" !'

!"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 überinadä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.

RequirementsEngineering

Analysis & Design

Implemen-tation Test Deployment Project

ManagementCon!guration

& ChangeManagement

Environment

Vision Document

So!wareArchitectureDocument

ImplementationModel Test Plan Release Notes Risk List

Con"gurationManagement

PlanDevelopment

Case

Use-Case Model Design Model Test Cases Deployment UnitSo!ware

DevelopmentPlan

Change Request ProgrammingGuidelines

Defect List Iteration Plans ProjectRepository

IterationAssessments

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).

ix.0914.074-078 18.08.14 14:26 Seite 75

© Copyright by Heise Zeitschriften Verlag

links 76

verlockend bequem ein derart trivialerErklärungsversuch auch scheinen mag.Sie ist die Folge von Arbeits- und Rand-bedingungen, die das Dokumentierennicht belohnen, sondern bestrafen.

Folglich liegt die Lösung darin, dieseBedingungen zu verbessern. Dies wie-derum setzt voraus, dass sich gerade dieTeammitglieder mit größeren Einfluss-möglichkeiten für diese Sache einsetzen.Ein derartiges Engagement ist allerdingssowieso geboten, wie sich leicht herlei-ten lässt.

Erst erkennen, dann verändernZu den Hauptaufgaben von Projektleiterngehört es sicherzustellen, dass ihre Mit-arbeiter formale Vorgaben einhalten; dazuzählen selbstverständlich die Vorgabenbezüglich der Dokumentation. Zu denHauptaufgaben von Architekten zählt dieSicherung der technischen Qualität; dasschließ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 Forderungnach starkem Engagement für eine guteDokumentation. Zu diesem Zweck sollendie oben aufgeführten Ursachen fürschlechte Dokumentation einzeln aufge-löst werden.

Allgemein gute Dokumentationskul-tur: Im Idealfall weiß jedes Teammitglied

genau, dass alle wichtigen Entscheidun-gen und Tatsachen zu dokumentierensind. In der Praxis allerdings verlangtdies 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 irgendjemandHerrschaftswissen oder Geheimdoku-mente hortet, muss man eine Offenlegunganmahnen.

Hierbei geht es keineswegs nur umdie Spezifikation, die sowieso offiziellgefordert ist, sondern auch um zusätz -liche Begleitdokumente. Als besondershilfreich stellen sich oft „Zwischendoku-mente“ heraus: Schriftstücke, die Detailsaus verschiedenen offiziellen Dokumen-ten im Hinblick auf häufige Anwen-dungsfälle wie Inbetriebnahme, Wartung,Testauswertung oder Fehleranalyse zu-sammentragen.

Weiterhin empfiehlt es sich alleinaufgrund der Vorbildfunktion dringend,neue Teammitglieder bei der Einführungins Projekt mit hilfreichen, ganz beson-ders gut gemachten Dokumenten zuüberraschen – etwa zur Umsetzung desEntwicklungsprozesses in der täglichenArbeit.

Klare Zielsetzung: Die Wertschätzunggegenüber Softwaredokumentation er-höht sich spürbar, wenn man den Autorenbewusst macht, wie viele Personen undBedürfnisse mit dem jeweiligen Doku-ment verbunden sind. Für die Designspe-zifikation einer Softwarekomponente las-sen sich hier unter anderem die folgendenPunkte festhalten:–ˇEin Tester, der die Komponente prüfensoll, muss aus der Dokumentation erse-

hen können, wann sich die Komponentewie verhalten soll.–ˇEin Entwickler, der die Komponenteverwenden soll, muss aus der Dokumen-tation ableiten können, was ihre Funktio-nen leisten und wie sie sich verwendenlassen.–ˇEin Entwickler, der die Komponenteübernehmen soll, muss in der Dokumen-tation zusätzlich die zentralen Designent-scheidungen erkennen sowie ersehenkönnen, wie die Komponente intern auf-gebaut ist. Dies betrifft auch Urlaubsver-tretungen und gilt somit immer, für jedesProjekt und für jede Komponente.–ˇEin Code-Reviewer muss aus der Do-kumentation ableiten können, wie sichdie Komponente verhalten soll, um diesesSoll-Verhalten im Review dem Ist-Ver-halten des tatsächlichen Codes gegen-überstellen zu können.–ˇEin Dokumenten-Reviewer, der typi-scherweise mit geringen technischenKenntnissen auf das Dokument zugeht,ist auf eine Top-down-Struktur angewie-sen, die systematisch von allgemeinenRahmenbedingungen und Lösungsansät-zen zu konkreten Design- und Implemen-tierungsdetails führt.

Klare Vorgaben machen und alles berücksichtigenTeammitglieder in führenden Rollen tungut daran, sich diese „reader stories“(analog zum bekannten Konzept der„user stories“) regelmäßig in Erinnerungzu rufen.

Klare Vorgaben: Eine Dokumenten-vorlage, deren gesamte Leistung darinbesteht, eine Kapitelstruktur vorzuschrei-ben, kann als Vorgabe niemals ausrei-chen. Wer eine hohe Qualität und Konsis-tenz der zu erstellenden Dokumenteanstrebt, muss den angehenden Autorenein 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 dieAbschnitte zusammen alle Aspekte

!) iX #/$%&"

REPORT | SOFTWAREENTWICKLUNG

Grobe Gliederungsvor-gaben zu Designspezi-fikationen (hier etwabasierend auf Kruch-tens Modell der 4 + 1Sichten) reichen nichtaus: Sie führen zwangs -läufig zu inkonsisten-ten Interpretationendurch 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 dieKomponente 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

Deta

illier

ungs

grad

ix.0914.074-078 18.08.14 14:26 Seite 76

© Copyright by Heise Zeitschriften Verlag

77 rechts

erschlagen, die dokumentationswürdigsind.

Weiterhin sollte mindestens ein kom-mentiertes Beispieldokument, das alsPrototyp dienen kann, das Template er-gänzen. Die zusätzlichen Kommentaremüssen vor allem die wesentlichen Ent-scheidungen des Autors nachvollziehbarmachen.

Missverständnisse rechtzeitig verhindernDerart konkrete Vorgaben helfen in vie-lerlei Hinsicht. Sie bieten nicht nur Ori-entierung beim Erstellen und Pflegendes Dokuments, sondern auch bei allenfolgenden Reviews: Der Reviewer kanndas Schriftstück systematisch auf Ein-haltung der Vorgaben prüfen, währendder Autor vor willkürlichen Befundengeschützt wird.

Ausreichende Unterstützung: DieWertschä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 Dokumentseinen Ansprechpartner an, mit dem erdiskutieren kann, welche Aspekte er inwelchem Umfang und an welcher Stellezu beschreiben hat. Derartige Vorbespre-chungen verringern das Risiko, dass ernicht das Wesentliche dokumentiert (fal-scher Fokus), deutlich.

Ähnlich wertvoll sind kurzfristige, in-formelle Reviews – idealerweise durchLeser, die tatsächlich „Kunden“ des be-troffenen Dokuments sein werden (zumBeispiel Entwickler oder Tester, die baldmit den frisch spezifizierten Neuerungenumgehen müssen).

Solche Reviews verringern das Risiko,dass der Autor die Neuerungen nicht rich-tig dokumentiert (zum Beispiel durchmissverständliche Formulierungen), eben-falls drastisch.

Ferner sollte jedem formalen Reviewdurch organisationsexterne Gutachter eininterner Review vorangehen – nicht nuraus pragmatischen, sondern auch aus psy-

chologischen Gründen: Der interne Re-view gibt dem Autor mehr Sicherheit undentlastet ihn von einer Art Alleinverant-wortung.

Authentizität: Es reicht nicht aus, denhohen Stellenwert von Dokumentationnur zu deklarieren. Vielmehr müssen dieTeammitglieder, die von Anfang an amProjekt beteiligt sind, schon dort das vor-leben, was sie später von anderen einfor-dern wollen.

Personen in führenden Rollen solltenaußerdem den Mut aufbringen, sich ausder bequemen „Du schreibst, ich be -werte“-Position herauszubewegen. Einwesentliches Qualitätsmerkmal von Ar-chitekturdokumenten etwa ist die Brauch-barkeit für Entwickler – eine Eigenschaftalso, die sich am besten per Reviewdurch einen oder mehrere Entwicklernachweisen lässt.

Anforderungsspezifikationunter die Lupe nehmenÄhnliches gilt für alle anderen Input-Do-kumente, die in der täglichen Entwick-lungsarbeit relevant sind. Besonders er-

iX #/$%&" !!

ix.0914.074-078 18.08.14 14:26 Seite 77

© Copyright by Heise Zeitschriften Verlag

links 78

wähnenswert ist in diesem Kontext dieso immens wichtige Anforderungsspezi-fikation: Ausgerechnet sie wird häufigkeinen Reviews durch technisch orien-tierte Personen unterzogen, weil sie eineOrganisationsgrenze überschreitet (vomfachlich orientierten Auftraggeber zurEntwicklungsabteilung), die nur eineReview-Richtung kennt. Dabei könnenderartige Reviews nicht nur kritischeMängel aufdecken, die sonst kostspieli-ge Folgen hätten, sondern auch ein star-kes Signal setzen, was die allgemeinenAnsprüche an die Dokumentenqualitätangeht.

Konstruktivität statt willkürlicher KritikBelohnungssysteme: Gute Dokumentationist bescheiden. Sie schreit nicht nach Auf-merksamkeit und zeigt sich nur dem, dersich die Mühe macht, sie näher zu betrach-ten. Es liegt deshalb an den beteiligtenPersonen selbst, eine Kultur zu schaffen,die gutes Dokumentieren belohnt.–ˇProjektleiter und Architekt sollten sichangewöhnen, Leistungen in der Doku-mentenarbeit ausdrücklich anzuerken-nen.–ˇDas Team sollte Momente, in denen gu-te Dokumentation besonders hilfreichwar, bei den üblichen Gelegenheiten

(Stand-ups, Retrospektiven et cetera) her-vorheben.–ˇReview-Moderatoren sollten dafür Sor-ge tragen, dass die Sitzungen in Umge-bungen stattfinden, die die Teilnehmernicht schon selbst als Strafe empfinden.–ˇReview-Gutachter sollten sich nicht indie Rolle des „Befundgenerators“ bege-ben („bogus findings“ vermitteln dem be-troffenen Autor das Gefühl, einer willkür-lichen Kritik ausgesetzt zu sein, die vonder Qualität des Dokuments unabhängigist), sondern sich der Konstruktivität ver-pflichten.

Gute Infrastruktur: Der Aspekt Infra-struktur unterliegt der Besonderheit, dasser häufig nicht vom Softwareteam zu be-einflussen ist. In Großunternehmen bei-spielsweise gehört es oftmals zu denAufgaben einer eigenen Qualitätsmana-gement-Abteilung, die bei der Dokumen-tation zu verwendenden Werkzeuge fest-zulegen. Der Projektleiter allerdings hatimmerhin die Möglichkeit, auf die Aus-wirkungen einer Entscheidung für einebesonders ungeeignete Infrastruktur hin-zuweisen.

Für den Fall, dass ein Team aufgrundunantastbarer Vorgaben mit behäbigen,fehleranfälligen Werkzeugen arbeitenmuss, lässt sich immerhin noch Schadens-begrenzung betreiben – etwa durch Anlei-tungen, Unterstützung bei der Einführungoder klar definierte Arbeitsabläufe.

Dies gilt insbesondere für manuelleTätigkeiten, die sich über viele Doku-mente hinweg ständig wiederholen: Es istim 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 Praxiswesentlich häufiger anzutreffen als Rah-menbedingungen, die diese Qualität be-günstigen. Schlimmer noch: Häufig zeigengerade diejenigen, die diese Forderungstellen, 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 konkreteImplementieren von Software, aber prak-tisch kein einziges über Softwaredoku-mentation auf Detailebenen der Archi-tektur – und selbst dort ist die Auswahlvergleichsweise 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, allewichtigen Informationen schriftlich undbedürfnisgerecht festzuhalten. Für dieHerstellung einer solchen Kultur sind vorallem diejenigen verantwortlich, dieschon zu einem frühen Zeitpunkt im Pro-jekt damit beginnen, derartige Informatio-nen zu generieren: Projektleiter, Require -ments Engineer, Architekt, Toolsmith undso weiter. (ka)

Dr. Daniel Mölle arbeitet als Softwarearchitekt bei derZühlke Engineering GmbH.

Literatur[1]ˇPaul Clements et al.; Documenting

Software Architectures; Views andBeyond; Addison-Wesley Professional,2010.

[2]ˇGernot Starke; Effektive Software-Ar-chitekturen; Ein praktischer Leitfaden;Hanser, 2011.

[3]ˇStefan Zörner; Software-Architekturendokumentieren und kommunizieren:Entwürfe, Entscheidungen und Lösun-gen nachvollziehbar und wirkungsvollfesthalten; Hanser, 2012. *

!+ iX #/$%&"

REPORT | SOFTWAREENTWICKLUNG

Au"raggeber Dienstleister

ProjektleiterProductOwner

Anforderungs-dokument Architekt

Arbeits- undProzessvorgaben

gottgegeben gottgegeben

gottgegeben

Architektur-dokument Entwickler Tester

Design-spezi"kation

Test-spezi"kation

zweifelha! zweifelha!

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 aufseine Rolle entzieht, handelt fahrlässig (Abb.ˇ3).

ix.0914.074-078 18.08.14 14:26 Seite 78

© Copyright by Heise Zeitschriften Verlag