• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Optimale systemdokumentation-mit-agilen-prinzipien
 

Optimale systemdokumentation-mit-agilen-prinzipien

on

  • 2,048 views

 

Statistics

Views

Total Views
2,048
Views on SlideShare
2,048
Embed Views
0

Actions

Likes
0
Downloads
16
Comments
1

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • hahahahahahha einfach n foto von nem Zeitungsartikel machen und dann hier Posten und 500 Views abstauben.

    LoL
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Optimale systemdokumentation-mit-agilen-prinzipien Optimale systemdokumentation-mit-agilen-prinzipien Document Transcript

    • ÜR KF schwerpunkt der autor UC ERDR mehr zum thema: ND http://blog.codecentric.de/SO WAS MUSS, WAS KANN UND WAS GEHT GAR NICHT? Uwe Friedrichsen OPTIMALE SYSTEMDOKUMEN- (E-Mail: uwe.friedrichsen@codecentric.de) hat langjährige Erfahrungen als Architekt, TATION MIT AGILEN PRINZIPIEN Projektleiter und Berater. Aktuell ist er bei der codecentric AG für die strategische Entwicklung neuer Paradigmen und Technologien verantwort- Die Diskussion ist fast so alt wie die IT: Wie viel Dokumentation benötigt ein System? Während lich und beschäftigt sich in diesem Kontext ins- es für den Kunden oft nicht genug sein kann, möchte der typische Entwickler am liebsten aus- besondere mit agilen Verfahren und neuen schließlich Code erzeugen. Eine leicht falsch interpretierbare Aussage aus dem Agilen Manifest Architekturansätzen. zum Thema Dokumentation hat die Diskussion noch weiter aufgeheizt. Guter Rat scheint teuer. Aber so schwierig ist es letztlich gar nicht und ein wenig Systematik bei den Dokumentationsarten sowie gerade die agilen Prinzipien helfen, Inhalt und Umfang einer guten Systemdokumentation zu optimieren. In diesem Artikel werden zwei einfache Werkzeuge vor- gestellt, die helfen, Dokumentation nicht mehr „auf Verdacht” zu erstellen, sondern zielgerichtet nach Sinn und Wert zu optimieren. Zum Thema Systemdokumentation gibt es wir die Dinge auf der rechten Seite durch- wertvolle Impulse auch außerhalb der agilen immer wieder lange und leidenschaftlich aus als wertvoll ansehen, finden wir die Bewegung. In der Agilität geht es also nicht geführte Debatten. Von den Vertretern aus- Dinge auf der linken Seite wertvoller”), der um eine pauschale Dokumenta- ufernder, viele hundert und tausend Seiten den vier Werten im Manifest folgt, wird tionsvermeidung, sondern um eine wertba- langer Dokumentationen bis hin zu den dabei meist geflissentlich überlesen. sierte Abwägung, die ich im weiteren radikalen „Code-only”-Verfechtern findet An dieser Stelle hilft vielleicht noch ein- Verlauf dieses Artikels noch nutzen werde, man in der IT alle Abstufungen, die ihre mal eine kleine Klarstellung zu der um die benötigte Dokumentation zu opti- Positionen vehement vertreten. Gerade im Motivation hinter dem Wert aus dem mieren. Verhältnis Kunde-Dienstleister scheinen die Manifest: Dokumentation hat auch in der Gegensätze häufig aufeinanderzuprallen: Agilität ihren festen Platz und kein seriöser Dokumentation ist wichtig Während der Kunde eine umfassende Befürworter von agiler Softwareentwick- Um uns einer optimalen Systemdoku- Dokumentation des zu liefernden Systems lung würde Dokumentation pauschal als mentation anzunähern, sollten wir viel- fordert – häufig basierend auf ausführ- unnötig bezeichnen. Der Wert an sich ist leicht am besten mit der Frage beginnen, lichen Dokumentations-Templates, die Teil am besten zu verstehen, wenn man das wie wichtig Dokumentation tatsächlich ist. des kundeneigenen Softwareentwicklungs- Agile Manifest im Kontext seiner Ent- Schauen wir uns dafür zwei Beispiele an: prozesses sind –, würden viele Dienstleister stehungszeit betrachtet: Die späten 90er am liebsten nur die Software ohne jede Jahre waren geprägt von großen, eher ■ Als Administratoren sollen wir eine Dokumentation ausliefern. Schließlich ist schwergewichtigen Prozessen, die häufig große, mehrere Dutzend Personenjahre der Code doch die einzig zuverlässige Unmengen an Dokumentation jedweder schwere Individualsoftware in Betrieb Informationsquelle, oder? Art produzierten. Die eigentliche Software nehmen. Leider gibt es keine Zeile wurde darin zur minder wichtigen Rand- Dokumentation dazu und es ist auch Das agile Missverständnis erscheinung degradiert. Der Prozess und niemand zu finden, der uns etwas zu Zu zusätzlichen Irritationen führte ein Wert die ganzen Dokumente drohten zum der Software sagen kann. Wir haben aus dem agilen Manifest (vgl. [Cun01]): Selbstzweck zu verkommen. nur eine CD – leider ohne irgendeinen „[...] we have come to value: Working soft- Davon distanzierte sich die agile Bewe- Installer – und das wars. ware over comprehensive documentation” gung ganz klar. Sie stellte die Wertschöpfung ■ Wir sind ein Projektteam, das seinen (etwa: „Funktionierende Software ist uns in das Zentrum ihres Interesses – und der Projektstatus komplett transparent im wichtiger als umfassende Dokumenta- primäre Wert in der Softwareentwicklung ist Unternehmens-Wiki verwaltet. Anhand tion”). Dieser Wert wurde sowohl von eine lauffähige und qualitativ hochwertige einer einfachen Darstellung kann man Befürwortern als auch von Gegnern der Software. Konsequenterweise wurde die zu jedem Zeitpunkt sehen, was wie weit Agilität häufig dahingehend (miss)interpre- Software an sich wieder zurück in den Fokus ist und ob der nächste Termin gefährdet tiert, dass die agile Softwareentwicklung gerückt und erhielt so ihren verdienten ist. Außerdem arbeiten wir mit kurzen nur noch lauffähige Software ausliefert und Stellenwert zurück. Dokumentation hinge- Iterationen von zwei Wochen und zei- überhaupt keine Dokumentation mehr. Der gen wurde nur als wichtig erachtet, wenn sie gen am Ende jeder Iteration die fertig relativierende Satz, „That is, while there is einen erkennbaren Mehrwert für das gestellte Software auf dem Zielsystem. value in the items on the right, we value the Gesamtergebnis beisteuert. Dieser Schritt Trotzdem will unser Management, dass items on the left more” (etwa: „Während war zu seiner Zeit sehr wichtig und lieferte wir jede Woche einen Projekt-Status-22 23
    • schwerpunkt bericht auf Basis einer 15-seitigen Vorlage anfertigen, damit es den Status des Projekts bewerten kann. Mit diesen – zugegebenermaßen recht extremen – Beispielen haben wir die Band- breite der Wichtigkeit von Dokumentation recht weit ausgelotet. Während die Dokumentation im ersten Beispiel essen- ziell ist (ohne sie wird der arme Administrator seine Aufgabe wohl nicht erfüllen können), ist sie im zweiten Fall eher ärgerlich und ohne erkennbaren Mehrwert. Andererseits kann man bei einem einfa- chen Dienstprogramm, das mit einem ferti- Abb. 1: Der Zusammenhang zwischen Stakeholdern, ihren Fragen und gen Installer kommt, vielleicht komplett Dokumentation (nach [IEEE]). auf Dokumentation verzichten, während es sicherlich auch Projekte gibt, bei denen ein regelmäßiger Statusbericht die einzige Dokumentation zutreffend: Stakeholder von Klassen und Methoden außerhalb des Chance für das Management ist, sich einen haben Fragestellungen, die für sie wichtig Quellcodes, wenn diese Information aus- rudimentären Einblick in den Status des sind und auf die sie gerne Antworten haben schließlich für die Entwickler des Systems Projekts zu verschaffen. Die Wichtigkeit möchten bzw. haben müssen. Die Aufgabe von Interesse ist, was meistens der Fall ist. von bestimmten Dokumenten kann man der Dokumentation ist es, diese Fragen zu Diese Informationen können sich die also nicht pauschal beantworten, sondern beantworten. Das ist die Kernaussage. Entwickler auch direkt aus dem Quellcode muss sie individuell bewerten. Aber wie Ergänzend empfiehlt der Standard noch, beschaffen. In Abbildung 2 ist das noch kommen wir zu einer individuellen Bewer- die Fragestellungen in Sichtweisen zu bün- einmal bildlich zusammengefasst. tung der Wichtigkeit von Dokumentation? deln und die Dokumentation anhand dieser Auf dem Weg dahin fehlen noch zwei Sichtweisen zu strukturieren. Das ist eine Bausteine: nützliche Empfehlung, weil sie hilft, die Projekt- und System - Dokumentation zielgruppen- und fragestel- dokumentation ■ Die Aufgabe von Dokumentation: lungsgerecht zu organisieren. Kommen wir zu dem zweiten Baustein: den Wofür benötigen wir überhaupt Doku- Die Aufgabe der Dokumentation ist Arten von Dokumentation. Als minimale mentation? damit klar. Wie sieht es aber mit dem Systematik können wir zwei grundlegende ■ Die Arten von Dokumentation: Wie Umkehrschluss aus: Wenn Dokumentation Arten von Dokumentation im Kontext der sieht eine minimale Systematik aus? die Fragen von Stakeholdern beantwortet, meisten Softwareentwicklungsprojekte muss ich dann für jede mögliche Frage unterscheiden: Der erste Baustein hilft uns, die eines Stakeholders ein Stück Dokumen- Werthaltigkeit eines Dokuments zu ermit- tation schreiben? Nein, natürlich nicht. ■ Projekt- bzw. Prozessdokumentation teln. Wenn ich den Zweck von Doku- Zum einen kann es in vielen Fällen hin- ■ Produkt- bzw. Systemdokumentation mentation im Allgemeinen verstanden reichend (und häufig auch effektiver) sein, habe, kann ich bewerten, inwieweit ein Fragen direkt im Dialog zu klären, anstatt Die Projekt- bzw. Prozessdokumentation bestimmtes Dokument zu diesem Zweck dafür ein Stück Dokumentation zu schrei- umfasst Dokumente, die an das jeweilige beiträgt. Den zweiten Baustein benötigen ben. Wenn etwa der Sicherheitsbeauftragte Projekt und sein Vorgehensmodell (den wir, da es je nach Dokumentationsart un- eines Unternehmens Fragen zu der neu ein- Prozess) gebunden sind. Das sind die terschiedliche Herangehensweisen und zuführenden Software hat, dann ist es häu- Artefakte, die die typischen Vorgehens- Handlungsmöglichkeiten gibt. fig für beide Seiten wesentlich effizienter, modelle an den Übergabepunkten zwischen sich einmal zusammenzusetzen und die verschiedenen Rollen oder Aktivitäten vor- Ziele von Dokumentation Fragen im Gespräch zu klären, als dafür ein schreiben: beispielsweise Anforderungsspe- Beginnen wir mit dem ersten Baustein: großes Dokument zu schreiben, das in der zifikationen, Konzepte und Modelle, aber Wofür benötigen wir Dokumentation über- Regel dann doch nicht alle Fragen klärt. auch Projektpläne, Projektstatusberichte haupt? Was ist ihre Aufgabe? Auf diese Wenn dieser Weg also sinnvoll ist, dann und Meeting-Protokolle. All diesen Doku- Frage gibt der IEEE-Standard 1471–2000 sollte man ihn bevorzugen. menten ist eines gemeinsam: Ist das Projekt (vgl. [IEEE]) eine sehr gute Antwort. Zum anderen kann auch das Produkt beendet, sind sie üblicherweise nicht mehr Eigentlich bezieht sich dieser Standard selbst diverse Fragen direkt beantworten. relevant. zwar auf die Dokumentation von Dafür muss dann keine redundante Doku- Die Produkt- bzw. Systemdokumentation Architekturen, aber der hieraus relevante mentation geschaffen werden. So brauche hingegen beschreibt Dokumente, die direkt Teil (siehe Abbildung 1) ist für jede Art von ich z. B. in der Regel keine Dokumentation zum fertigen System gehören. Das sind z. B.3 / 2 011
    • schwerpunkt bar. Die Systemdokumentation sollte daher mindestens alle Informationen umfassen, die benötigt werden, um das System auch ohne die bei der Erstellung verfügbaren Personen betreiben, nutzen und warten zu können. Nebenbei unterstreicht das Verhältnis zwischen Erstellungsphase sowie Betriebs- und Wartungsphase eindrucksvoll die Wichtigkeit der Systemdokumentation – und die relative Unwichtigkeit der Projektdokumentation (siehe Abbildung 3). Eine etwas andere Situation liegt vor, wenn das System über seinen ganzen Lebens- zyklus von einem festen Team entwickelt und gewartet wird, wir es also zumindest inhaltlich (kommerziell kann das anders geregelt sein) nicht mehr mit abgeschlosse- nen Projekten zu tun haben, sondern einer kontinuierlichen Systementwicklung. Hier stünden prinzipiell Ansprechpartner über den gesamten Lebenszyklus zur Verfügung, Abb. 2: Verschiedene Quellen zur Beantwortung von Stakeholder-Fragen. womit sich die zuvor beschriebene Wich- tigkeit von Systemdokumentation wieder etwas relativieren würde. Allerdings sind – Installationsanleitungen, Betriebs- und Ad- bezüglich Zeit und Aufwand im Schnitt min- insbesondere in Kunde/Dienstleister- ministrationshandbücher, eventuell recht- destens um den Faktor 5 größer ist als die Beziehungen – abgeschlossene Projekte der lich vorgeschriebene Zertifikate oder auch Erstellungsphase (Tendenz steigend). In agi- Regelfall und eine durchgängige Begleitung Benutzerhandbücher. Alle Dokumente sind len Projekten dürfte der Faktor noch deut- eines Systems durch ein festes Team über integraler Bestandteil des finalen Produkts, lich größer sein, weil diese Projekte übli- den gesamten Lebenszyklus ist eher die d. h. ohne sie ist das Produkt nicht voll- cherweise sehr früh in Produktion gehen. Ausnahme. ständig. Die lauffähige Software ist natür- Die Projektdokumentation bezieht sich Der zweite Aspekt bezieht sich auf das lich der Kern des Produkts, aber ohne die auf die Erstellungsphase. Das ist die Verhältnis Kunde-Dienstleister: Viele Kun- zugehörige Systemdokumentation ist die Dokumentation, die man zur ordnungsge- den bestehen auf einer ganzen Menge an Software in der Regel nicht einsetzbar – mäßen Abwicklung dieser Phase benötigt. Dokumentation, die sie zusammen mit gerade im Bereich der Individual- Die Systemdokumentation benötigt man einem Softwaresystem geliefert haben wol- Softwareentwicklung. insbesondere für die Zeit nach dem Projekt, len und ohne die sie das System nicht abneh- Bei dieser Unterscheidung sind noch zwei d. h. für die Betriebs- und Wartungsphase. men. Hier muss man genauer hinschauen: weitere Aspekte von Interesse. Der erste In dieser Zeit existiert das Projektteam in Handelt es sich dabei wirklich immer um Aspekt betrifft den Produkt-Lebenszyklus: der Regel nicht mehr und auch viele andere Systemdokumentation gemäß der obigen In der Regel kann man die Erstellungsphase Ansprechpartner sind nicht mehr verfüg- Definition oder besteht der Kunde auf dem einer Software und ihre Betriebs- und Wartungsphase unterscheiden. Das ist nicht immer ganz einfach, z. B. in agilen Projekten, in denen die Software häufig schon produktiv gesetzt wird, während parallel dazu noch die initial geplante Funktionalität weiterentwickelt wird. Aber auch in diesen Fällen kann man die beiden Phasen zumindest inhaltlich unterscheiden, wenn auch nicht zeitlich. Das eigentliche Projekt, in dem eine Software entwickelt wird (Erstellungsphase), ist üblicherweise bezüglich Zeit und Aufwand im Verhältnis zur Betriebs- und Wartungsphase sehr klein. Hierzu gibt es verschiedene Untersu- chungen (eine Übersicht findet sich z. B. in [Kos03]). Man kann heute davon ausgehen, Abb. 3: Relevanz der Projekt- und Systemdokumentation im Lebenszyklus eines dass die Betriebs- und Wartungsphase Systems.24 25
    • schwerpunkt Dokument, weil es Teil seines Prozessmodells ist bzw. er es aus schwer möglich. Auch hier steigt die Notwendigkeit, mehr anderen projekttechnischen Gründen haben will? Dokumentation zur Kommunikation zu nutzen. Das muss man genauer hinterfragen, weil es häufig nicht diffe- ■ Hohes Risiko: Ein riskantes Projekt erfordert Maßnahmen, um renziert wird. Nicht jeder vom Prozessmodell vorgeschriebene das Risiko beherrschbar zu halten. Das erfordert in der Regel Artefakt ist automatisch Projektdokumentation, sondern kann auch mehr Dokumentation von Beschlüssen und Aktivitäten, sehr wohl ein Systemdokument beschreiben. Und nicht jedes um Transparenz und Nachvollziehbarkeit sicherzustellen. gemäß Prozessmodell abnahmerelevante Dokument ist automa- ■ Gesetzliche Anforderungen: In verschiedenen Umfeldern gibt es tisch Teil der Systemdokumentation. Für diese Unterscheidung gesetzliche Anforderungen, die die Dokumentation von sollte man die zuvor beschriebenen Definitionen heranziehen und Projektaktivitäten und Beschlüssen erforderlich machen, auch jedes der geforderten Dokumente daraufhin hinterfragen. Dieses wenn sie ansonsten keinen weiteren Wertbeitrag liefern, als die Hinterfragen kann bei der Bestimmung der optimalen System- gesetzlichen Vorgaben zu erfüllen (vgl. Beitrag von Engler et. al. dokumentation sehr hilfreich sein, wie wir gleich sehen werden. in dieser Ausgabe von OBJEKTspektrum auf Seite 44). Optimale Systemdokumentation Aber auch, wenn wir es wahrscheinlich in der Regel nicht schaf- Damit haben wir alle Informationen, die wir benötigen, um uns fen werden, komplett ohne Projektdokumentation auszukom- Gedanken über eine optimale Systemdokumentation zu machen: men, sollten wir doch immer den Wertbeitrag kritisch hinterfra- Wir kennen die Aufgabe von Dokumentation und können gen und prüfen, ob es nicht auch ohne das jeweilige Dokument Projekt- und Systemdokumentation voneinander unterscheiden. geht oder zumindest mit einem reduzierten Dokument. Hier ein Für die Bewertung der Dokumentation ziehen wir den agilen paar Beispiele: Mehrwert-Gedanken heran: Wir prüfen den Wertbeitrag der Dokumentation, bezogen auf ihre Aufgabenstellung und ihren ■ Brauchen wir eine detaillierte Spezifikation? Reichen nicht Kontext (Projekt- oder Systemdokumentation), und vermeiden auch User-Storys und eine Just-in-Time-Abstimmung zwi- Dokumentation mit geringem Wert. Das Prinzip lautet also schen Entwickler und Fachanwender aus? nicht, was möglich ist, sondern was nötig ist. Dafür möchte ich ■ Benötigen wir regelmäßig den erwähnten 15-seitigen zwei einfache, aber bewährte Vorgehensweisen anbieten: Statusreport? Reicht nicht auch eine wöchentliche Telefon- konferenz aus? ■ Vermeidung von Projekt- bzw. Prozessdokumentation ■ Hätte eine Vorführung lauffähiger Software alle zwei, drei ■ Produkt- bzw. Systemdokumentation – stakeholder-basierte oder vier Wochen nicht wesentlich mehr Aussagekraft (und Analyse würde für mehr Vertrauen bei den Projektsponsoren sorgen) als jeder noch so detaillierte Statusreport? Beginnen wir mit der Projektdokumentation: Diese ist keine Systemdokumentation. Streng genommen gehört dieser Teil Ergänzend hilft es, regelmäßig zu prüfen, ob ein Dokument noch daher gar nicht in diesen Artikel. Da hier aber erfahrungsgemäß werthaltig ist. So kann eine Architekturskizze zu Beginn des eine Menge Optimierungspotenzial vorhanden ist, möchte ich Projekts sehr wertvoll gewesen, mittlerweile aber überholt sein. trotzdem darauf eingehen. Anstatt die Skizze nachzupflegen, ist es häufig sinnvoller, sie als „veraltet” zu kennzeichnen und in ein Archiv zu verschieben. Dokumentationsvermeidung Mit diesen Empfehlungen sollte es möglich sein, ein gutes Maß Im Projektkontext ist es wichtig, die Fragestellungen der ver- an Projektdokumentation festzulegen. Hier besteht bei traditio- schiedenen beteiligten Stakeholder aktiv zu managen. Welche nellen Vorgehensmodellen häufig das größte Einsparpotenzial – Fragen und Sorgen haben sie und was brauchen sie, damit sie und genau das wurde auch primär im agilen Manifest adressiert. diese Sorgen nicht mehr haben? Sofern es sinnvoll möglich ist, Das geht nicht von allein und Sie werden – je nach Umgebung – sollte man immer versuchen, hierfür die direkte Kommunikation sicherlich eine Menge Überzeugungskraft aufbringen müssen, und keine Dokumentation zu nutzen. Erstens ist das fast immer um lieb gewonnene, aber eigentlich wertlose Projektdokumente mit weniger Aufwand für alle beteiligten Parteien verbunden, loszuwerden, aber den Aufwand ist es aus meiner Erfahrung zweitens ist es fast immer schneller und drittens ist eine direkte wert. Außerdem ist überflüssige Dokumentation sehr teuer: Sie Kommunikation deutlich weniger fehleranfällig (im Sinne von kostet (häufig viel) Geld, ohne einen Nutzen zu bringen. Deshalb Missverständnissen und Fehlinterpretationen) als ein Dokument. ist allein schon aus wirtschaftlichen Gründen ein „im Nur wenn der Weg der direkten Kommunikation nicht mög- Zweifelsfall gegen die Dokumentation” angebracht. lich ist, sollte Dokumentation eingesetzt werden. Dafür, dass Soviel als Empfehlung zur Behandlung von Projektdoku- eine direkte Kommunikation nicht möglich ist, kann es ver- mentation. Wie sieht es mit der Produkt- bzw. Systemdoku- schiedene Gründe geben: mentation aus? Wie viel benötigen wir da? ■ Großes Projekt: Je größer das Projekt ist, desto mehr forma- Stakeholder-basierte Analyse le Kommunikationsstrukturen benötigt man, da die direkte Ganz so einfach geht es für die Systemdokumentation nicht, weil Kommunikation nicht gut skaliert. Das umfasst dann auch wir ja insbesondere die Zeit nach dem Projekt betrachten müs- einen verstärkten Einsatz von schriftlicher Kommunikation, sen. Wie finden wir dafür einen optimalen Dokumentations- insbesondere auch Dokumentation. umfang, der auf der einen Seite alle relevanten Informationen ■ Verteiltes Projekt: In einem über mehrere Standorte verteil- enthält, auf der anderen Seite aber vom Umfang her so gering ten Projekt ist direkte Kommunikation häufig nur sehr wie möglich ist?3 / 2 011
    • schwerpunkt Abb. 4: Schematisches Ergebnis einer stakeholder-basierten Analyse. Meine Empfehlung dafür ist eine stake- 4. Bündle die Themengebiete nach Inhal- mit ihnen! Zum einen werden Sie häufig holder-basierte Analyse. Diese orientiert ten und Zielgruppen in Dokumenten feststellen, dass die Fragestellungen andere sich ebenfalls am agilen Mehrwertprinzip, (Stichwort „Sichtweisen”). sind, als Sie angenommen haben. Zum indem sie den tatsächlichen Informations- 5. Halte die Inhalte der Dokumente als anderen lässt sich so häufig eine Dif- bedarf systematisch erfasst und damit die Verzeichnisstruktur mit kurzen Erläu- ferenzierung zwischen wirklich wichtigen minimal notwendige Dokumentations- terungen je Kapitel fest („In diesem Informationen und „Nice to have”- menge zu einem System definiert. Die sta- Kapitel steht …”). Informationen herausarbeiten und damit keholder-basierte Analyse orientiert sich an 6. Gib die Dokumente mit den Ver- viel Aufwand einsparen. Und drittens kann dem zuvor beschriebenen IEEE-Standard zeichnisstrukturen und Inhalten den man so manche Frage auch direkt bei der und funktioniert folgendermaßen: Stakeholdern zum Review. Abstimmung beantworten und muss dafür dann gar nichts schreiben – wiederum 1. Identifiziere alle für die Inbetriebsetzung Wichtig ist hierbei, dass das es sich um kei- gesparter Aufwand. Wichtig ist es auch, die sowie für Betrieb und Wartung relevanten ne Veranstaltung im stillen Kämmerlein erarbeiteten Dokumenten-Templates den Stakeholder. (Ich betrachte die Inbetrieb- handelt, sondern dass diese sehr interaktiv Stakeholdern zum Review zu geben, um setzung ebenfalls, weil es häufig Doku- erfolgt. Sprechen Sie mit möglichst vielen frühzeitig Feedback zu erhalten und so mente gibt, die notwendig sind, damit das Parteien, um die relevanten Stakeholder zu unangenehme Überraschungen kurz vor System eine Betriebsfreigabe erhält, z. B. ermitteln. Es ist erstaunlich, wie häufig der der Inbetriebsetzung zu vermeiden. im Sicherheits- oder Datenschutzumfeld.) Fachbereich oder die IT-Entwicklung Ihres Sieht das nach viel Aufwand für ein sol- 2. Identifiziere die Fragestellungen dieser Auftraggebers nicht wissen, wer alles in ches Thema aus? Aus meiner Erfahrung, Stakeholder. Dabei sollte nicht jede Betrieb und Wartung des beauftragten nein. Natürlich bekommt man die notwen- Einzelfrage erfasst werden, sondern die Systems involviert ist. Nicht selten werden digen Informationen in der Regel nicht auf Themenfelder. Als Faustregel tut es in Sie regelrechte Aha-Erlebnisse bei Ihren einem Silbertablett serviert, sondern man der Regel eine einstellige Zahl Frage- Auftraggebern auslösen, wenn Sie die muss einen gewissen Klärungs- und stellungen pro Stakeholder. Stakeholder transparent machen. Abstimmungsaufwand betreiben, wenn 3. Leite aus den Fragestellungen Themen- Raten Sie nicht, welche Fragen die man ein gemeinsames Verständnis herstel- gebiete für die Dokumentation ab. Stakeholder haben könnten. Sprechen Sie len will. Das gleiche gilt für die Anfor-26 27
    • schwerpunkt derungen und alle anderen Informationen. Literatur & Links Aber der Aufwand ist trotzdem recht über- schaubar: einige Gespräche, der Entwurf einiger Dokumenten-Templates und noch [Cun01] W. Cunningham et. al., 2001, Manifesto for Agile Software Development, siehe: ein paar Abstimmungen. Das alles lässt sich http://www.agilemanifesto.org/ in der Regel recht zügig erledigen. [IEEE] IEEE Std. 1471-2000, IEEE Recommended Practice for Architectural Description of Der Nutzen hingegen ist ungemein Software-Intensive Systems, siehe: http://standards.ieee.org/findstds/standard/1471-2000.html höher: Zum einen haben Sie Transparenz [Kos03] J. Koskinen, Software Maintenance Cost, 2003, siehe http://www.cs.jyu.fi/~koskinen/smcosts.htm und ein gemeinsames Verständnis bezüglich der benötigten Systemdokumentation her- gestellt – an einer Stelle, die häufig nur von Annahmen und Halbwissen geprägt ist. erforderliche Dokumentation deutlich etwas, was man eigentlich sowieso machen Das führt auch schon zum zweiten Punkt: reduziert werden und aufgrund der sollte, ausgerichtet an ein wenig agilem Durch das Eliminieren der Unsicherheit bei geschaffenen Transparenz war das auch für Gedankengut. Dennoch habe ich immer den benötigten Informationen können Sie alle Beteiligten nachvollziehbar. Der wieder überrascht feststellen müssen, wie den Umfang der geforderten Dokumen- Zeitaufwand für die Analyse war im selten es in der Praxis so gemacht wird. tation stark reduzieren, weil häufig keiner Verhältnis vernachlässigbar. Deshalb kann ich Sie nur dazu ermutigen, so genau weiß, welche Informationen es in Ihrem nächsten Projekt zu versuchen benötigt werden, und deshalb sicherheits- und Ihre Erfahrungen damit zu sammeln. halber alles dokumentieren lässt. Statt- Zusammenfassung Wie in fast allen Fällen gibt es auch für dessen dokumentieren Sie jetzt nur noch Damit haben Sie zwei einfache, agile gute Systemdokumentation kein Patent- die wirklich benötigten Aspekte, die einen Werkzeuge an der Hand, um eine für Sie rezept, weshalb ich Ihnen hier auch keine echten Mehrwert für Betrieb und Wartung und Ihr Projekt optimale Systemdoku- fertige Dokumentationsmenge anbieten liefern. Allein die hier möglichen Ein- mentation zu schaffen: Dokumentations- konnte. Es kommt immer auf Ihren genau- sparungen rechtfertigen den Aufwand für vermeidung für die Projektdokumentation en Projektkontext an, aber allein durch die- die initiale Analyse. und stakeholder-basierte Analyse für die se einfachen Werkzeuge haben Sie die Auch wenn Ihr Auftraggeber Ihnen Systemdokumentation. Man kann jetzt Möglichkeit, wesentlich näher an Ihre opti- schon – meist recht umfangreiche – bemängeln, dass das in Summe nicht male Systemdokumentation heranzukom- Templates für die Systemdokumentation sonderlich spektakulär ist, sondern nur men. ■ auf Basis seines Prozessmodells vorgibt, lohnt sich die Analyse in der Regel. So hat- te ich die Analyse in einem Projekt durch- geführt und es ergab sich daraus ein Bild, das dem Beispiel in Abbildung 4 recht ähn- lich war. Die Fragen einiger Stakeholder OBJEKTspektrum ist eine Fachpublikation des Verlags: konnten direkt geklärt werden, so z. B. die SIGS DATACOM GmbH · Lindlaustraße 2c · 53842 Troisdorf der Systemplanung und des Sicherheits- Tel.: 0 22 41 / 23 41-100 · Fax: 0 22 41 / 23 41-199 beauftragten. Andere hatten gar nicht so E-mail: info@sigs-datacom.de hohe Dokumentationsanforderungen, wie www.objektspektrum.de initial angenommen. Auf Basis der Analyse www.sigs.de/publications/aboservice.htm konnte die gemäß Prozessmodell eigentlich3 / 2 011