Keine Sorge, es geht hier nicht um Viren und Würmer, die elektronisch gespeicherte Daten kaputt machen. Es geht vielmehr um die Frage, was mit der Qualität von Dokumenten passiert, die wir in einer irgendwie gearteten Ablage für eine gewisse Zeit speichern und zu einem späteren Zeitpunkt wieder hervorholen.

06 Können Dokumente verderben

Ausgangssituation

Ich erinnere mich an die Zeit phasen-orientierten Vorgehensmodelle. Zu dieser Zeit versuchten Analysten in der Analysephase herauszufinden, was die Fachabteilungen im nächsten Release haben wollen. Diese Änderungskonzepte wurden themenweise geschrieben mit dem vorrangigen Ziel, den Auftraggeber zu bewegen, die vorgeschlagenen Änderungen an der Software zu genehmigen.

  • Anwendungsfälle waren lösungsorientierte lange Abfolgen von “Essenzschritten”. Die Beschreibung der eigentlichen fachlichen Auslöser oder Probleme kam dabei oft zu kurz.
  • Sonderfälle betrachtete man sehr selten, weil die Darstellung des “Normalfalles” dann zu komplex geworden wäre (O-Ton: “Die behandeln wir später”).
  • Fehlersituationen hat man einfach als nicht-funktionale Anforderung erledigt (O-Ton: “Das System muss robust sein”).
  • Benutzeroberflächen wurden sehr häufig direkt aus anderen Anwendungen übernommen (Screenshots), obwohl sie optisch nicht immer zum Stil der Anwendung passten. Meist wurde auch das Verhalten aus der anderen Anwendung übernommen (O-Ton: “Genau wie in Lotus Notes”).
  • Auch Fachklassenmodelle benutzte man häufig dazu, fachliche Zusammenhänge darzustellen, ohne Rücksicht auf möglicherweise existierende konkrete technische Modelle der Anwendung.

Änderungskonzepte waren im Falle eines Auftrages häufig Vertragsbestandteil. Darum wurden Konzepte in diesen Fällen sehr detailliert beschrieben, was nicht selten zu Dokumenten mit mehreren 100 Seiten Text und Bildern führte.

Mehr als einmal habe ich in meiner Rolle als Entwickler einen Analysten gebeten, doch mehr Rücksicht auf die “Realität” in der existierenden Software zu nehmen. Wiederholt habe ich im Verlauf der Konzeption auf bestehende Anwendungsfälle, Fenster oder Dialoge hingewiesen. Ich bekam aber immer die gleiche Antwort:

Die Fachabteilungen müssen die fachliche Lösung verstehen und freigeben, wir (Anm.: die Analysten) müssen die Lösungen so detailliert beschreiben. Die Entwickler machen später eh ihr technisches Design.

Das war praktisch eine selbsterfüllende Prophezeiung. Natürlich haben wir später unsere eigenen technischen Dokumente geschrieben.

Änderungskonzepte

Änderungskonzepte haben die Aufgabe, eine Veränderung einer Software von Zustand A nach Zustand B zu beschreiben. Oft legten die Analysten den Schwerpunkt auf die Lösungsbeschreibung.  Die Probleme, für die diese Lösung entworfen wurden, kamen in den Beschreibungen viel zu kurz oder waren nur als Workshop-Unterlage dokumentiert. Diese Unterlagen waren aber nicht Teil der Ergebnisdokumente!

In der Erstellung von Änderungskonzepten steckt viel Arbeit. In phasen-orientierten Projekten passierte es regelmäßig, dass bereits fertig ausgearbeitete Änderungskonzepte nicht zur Umsetzung kamen. Kein Projektleiter konnte ein “teures” Arbeitsergebnis einfach entsorgen. Sie wurden “zurückgestellt”. Konnte der Auftraggeber oder der Fachbereich zu einem späteren Zeitpunkt neues Geld beschaffen, wurden diese Änderungskonzepte aus der Schublade gezogen und für die Realisierung freigegeben. Leider hatte sich in der Zwischenzeit die Software aufgrund anderer funktionaler oder nicht-funktionaler Anforderungen bereits stark weiterentwickelt. Ausgelöst durch

  • Änderungen in der Geschäftsprozessen des Auftraggebers,
  • Änderungen in den Zielen für das Produkt,
  • andere oder zusätzliche Stakeholder oder
  • die Behebung von technischen Schulden im Produkt,

waren die Änderungskonzepte zum großen Teil nicht mehr vollständig oder sogar widersprüchlich.

Dieser Effekt führt dazu, dass Dokumente sprichwörtlich “verderben”: Ein Dokument verliert immer mehr Qualität, je länger es unverändert liegen bleibt, während sich das Produkt weiterentwickelt.

Fachklassen

Fachklassenmodelle waren ein beliebtes Mittel, um Informationsobjekte sehr detailliert zu beschreiben. Sie sollten es einem Stakeholder ermöglichen, die Lösung im Änderungskonzept leichter zu verstehen, ohne Software-Experte zu sein. Analysten steckten oft sehr viel Arbeit in die exakte Beschreibung von Attributen und Relationen. Sie versuchten, weitgehend unabhängig von Entwicklern und meistens ohne ausreichende Kenntnis der Software-Architektur ein technisches Modell zu entwerfen.

Der erste Entwurf der Software orientierte sich am Fachklassenmodell, mit dem Effekt, dass Entwickler sich zu Beginn der Umsetzung keine eigenen Gedanken zu den Informationsobjekten machten. Damit ging aber die Chance verloren, dass Entwickler mit dem wesentlich besseren Verständnis der Software-Architektur ein möglicherweise besseres technisches Modell finden.

Bei der Umsetzung weiterer Änderungskonzepte an bestehender Software, spätestens bei Optimierungen in der Software weicht ein so detailliertes Fachklassenmodell von dem technischen Modell ab. So verdirbt eine Fachklasse.

Ein konkretes Beispiel aus meinem Projekt ist die Verwendung der Fachklasse Zug, die eine Zugfahrt mit einem Laufweg mit Halten und Durchfahrten repräsentiert. Ein Zug kann fachlich aber unterschiedliche Rollen haben: Geplante Zugfahrt, abweichende Zugfahrt durch Haltausfall oder Umleitung, Ersatzzug, Sonderzug, Entlastungszug, Betriebsfahrt, Leerfahrt, u.s.w.

Die Analysten verwendeten in der Vergangenheit gerne spezielle Fachklassenmodelle, in denen sie beispielsweise eine Klasse Ersatzzug modellierten, mit dem Ziel, die Darstellung für die Stakeholder verständlicher zu gestalten.

Nach der Freigabe der Konzepte mit diesen speziellen Fachklassenmodellen mussten die Entwickler die Konzepte erst auf die Realität, also auf die “echten” Fachklassen übertragen. Das führte aber oft zu unerwartet aufwändigen Lösungen, die Gründe dafür sind vielfältig:

  • Unterschiedliche Verwendung der Begriffe; das Objekt Ersatzzug ist einfach was anderes als die Rolle Ersatzzug, besonders in der technischen Umsetzung.
  • Höherer Aufwand wegen Seiteneffekten in der Umsetzung, die erst bei der Realisierung erkannt werden. Beispielsweise kann eine Rolle als Aufzählung implementiert sein. Zusätzliche Attribute können nur durch ein geeignetes Refactoring ermöglicht werden.
  • Wenn eine spezielle Klasse wie Ersatzzug dann tatsächlich notwendig ist, musste in der technischen Umsetzung in machen Fällen eine Hierarchie eingeführt werden. Auch hier erkennt man die Auswirkungen erst bei der Umsetzung der Lösung.

Alle diese Probleme hat der Analyst durch das “Erfinden” von neuen Klassen wie Ersatzzug elegant ausgeschlossen – und damit auch nicht weiter analysiert.

Schätzungen

Auch Schätzungen verderben. Die Änderungskonzepte wurden vom Auftraggeber in vielen Fällen abgelehnt, weil eine Expertenschätzungen gezeigt hat, dass der Aufwand so groß ist, dass es im geplanten Release einfach nicht mehr umgesetzt werden kann. Diese releasebezogene Schätzung war dann aber sehr oft der Maßstab, wenn das Änderungskonzept aus der Schublade gezogen und für ein späteres Release eingeplant wurde. Und regelmäßig war der Auftraggeber überrascht, dass die neue Expertenschätzung noch etwas größer war als die alte. Die Gründe für den erhöhten Aufwand sind

  • neue technische Schulden (→ gestiegene Komplexität),
  • entfernte technische Schulden (→ anderer Lösungsansatz durch Refactoring),
  • neue, komplexe Anforderung (→ Seiteneffekte),
  • neue nicht-funktionale Anforderungen (z.B. erhöhtes Mengengerüst),

die zum Zeitpunkt der Erstellung des Änderungskonzeptes nicht berücksichtigt werden konnten.

Fazit

Mein Ziel beim Entwurf der neuen Dokumentenstruktur ist die Vermeidung von Änderungskonzepten. Es wird wohl nie möglich sein, ganz auf Dokumente zu verzichten, die eine Änderung beschreiben. Es ist aber möglich, diese Dokumente so zu verwenden, dass sie am Ende eines Releases entsorgt werden können, ohne dabei wertvolle Informationen zu verlieren. Dokumente, die die Probleme der Stakeholder beschreiben, verderben niemals, sie sind immer richtig, auch wenn sich natürlich die Wichtigkeit der Probleme über die Zeit verschieben kann. Aber das liegt in der Natur der Änderung.

Schlimm an den verdorbenen Dokumenten und Schätzungen ist, dass wir nicht erkennen, dass sie verdorben sind:

  • Sie erfüllen alle Vorgaben und Richtlinien, wenn sich die Vorgaben und Richtlinien in der Zwischenzeit nicht geändert haben.
  • Sie erscheinen vollständig, es gibt keine offenen Punkte oder Fragen.
  • Sie sind in vielen Fällen vom Auftraggeber abgenommen und damit formal gültig.
  • Sie basieren auf Annahmen, die immer noch zutreffen.

Besonders schlimm ist, dass wir nicht wissen, wo die “faulen Stellen” in den verdorbenen Dokumenten sind. Beim Lesen und Verwenden verdorbener Dokumente müssen wir laufend prüfen, ob der Inhalt noch stimmt, ob etwas fehlt, ob Annahmen falsch oder Lösungen so wie beschrieben überhaupt noch möglich sind. Wir stecken viel Arbeit in die Evaluierung und Korrektur eines verdorbenes Dokumentes.

Scrum ermutigt uns sowieso, laufend zu hinterfragen, was zum Erfolg des Produktes beiträgt. Ich denke, es ist ein guter Beitrag zum Erfolg des Produktes, wenn wir versuchen, verdorbene Dokumente nicht zu verwenden. Meiner Ansicht nach ist es in vielen Fällen besser, verdorbene Dokumente einfach nur als zusätzliche, aber unsichere Quelle für Informationen anzusehen, das Produkt aber auf Basis aktuell ermittelter Informationen und mithilfe der verfügbaren Stakeholder zu entwickeln.