Century-Support Teil 2: Wie man nicht starten sollte
Dieser Gastartikel von Carsten Pitz ist der zweite Teil zum Thema Langzeitunterstützung. Im ersten Teil schildert Carsten die Entwicklung eines Dokumentationssystems. Ohne dass es anfangs so konzipiert wurde, kristallisierte es sich über die Zeit heraus, dass das System wohl über Jahrzehnte verfügbar sein musste.
Viel Spaß beim Lesen des zweiten Teils.
Viel Papier, keine Langzeitunterstützung
Unser ursprünglicher Entwicklungsansatz war eher konservativ: Wir haben die Anwendungsarchitektur im Detail dokumentiert, uns Konventionen für Design, Entwicklung und Qualitätssicherung ausgedacht und eine als Krönung eine Roadmap entworfen. All dies ohne irgendeine Berücksichtigung der Lebensdauer des Projekts. Was das für die Langzeitunterstützung bedeutet, darauf gehe ich am Ende noch mal ein.
Die Anwendungsarchitektur wurde gemäß des NATO Architecture Framework in Version 3 (NAF v3) dokumentiert. Das NAV v3 definiert die Sichten, von denen der größte Teil umgesetzt wurde. Allein das Tayloring hat fünf Personen nahezu ein halbes Jahr beschäftigt. Dabei haben wir etliche 100 Seiten Papier geschwärzt.
Bei den Konventionen haben wir uns auf etablierte, als best-practices anerkannte de-facto Standards gestützt. Die Konvention für das Design war das von uns adaptierte NAF v3. Das Anforderungsmanagement sollte nach IREB erfolgen. Für die Entwicklung wurden die Guidelines von SUN Microsystems für Java Coding und JavaDoc Documentation vorgeschrieben. Die Qualitätssicherung sollte gemäß ISTQB ablaufen. Da all diese Konventionen als best-practices angesehen waren, gab es keinerlei Komplikationen bei der Abstimmung mit unserem Auftraggeber. Wir stellten vor, der Kunde nickte ab, keinerlei Diskussion.
Da die Konventionen als Best Practices angesehen wurden, nickte der Kunde diese ohne Diskussion ab.
Twittern
Die Roadmap war ebenfalls viel Arbeit. Unser Kunde stellte uns zahlreiche Studien namhafter Beratungshäuser zur Verfügung. Diese analysierten wir und bauten ein Rechenblatt auf um eine statistische Auswertung durchzuführen. Hiermit sortierten wir Voraussagen die nur von einzelnen gemacht wurden oder umstritten waren aus. Aus dem so ermittelten Konsenz entwarfen wir die Roadmap.
Das Ergebnis
Nachdem die erste Version der Software auf Basis dieser Arbeit erstellt wurde, gab es einen Review, bei dem bis auf die Roadmap alles als akzeptabel bewertet wurde. Dass die Roadmap nicht gut bewertet wurde ist nachvollziehbar, da in der schnelllebigen Zeit viele der ausgewählten Technologien aus der Mode gekommen waren. Durch den wasserfallbasierten Prozess konnten wir nicht mehr klärend eingreifen. Und so nahm die Gruppendynamik ihren Lauf und die Roadmap wurde außer Kraft gesetzt. Wobei die Architektur zum Glück erhalten blieb.
Auf Basis der Konventionen für Anforderungsmanagement (IREB) und Qualitätssicherung (ISTQB) organisierte unser Kunde mit Ausbildungsmaßnahmen mitsamt Zertifizierungen. Dies hat hat sich ausgezahlt. Insbesondere die vereinheitlichte Nomenklatur war ein deutlicher Gewinn.
Rückblick aus der Gegenwart
100 Jahre Lebenszyklus: Was bedeuten 4 Generationen? Diese Fragestellung ist nicht betrachtet worden. Entsprechend wurden auch keine Antworten hierauf gegeben. Wir haben versucht, die technische Entwicklung vorauszusehen. Und sind damit, wie nahezu alle vorher und nachher gescheitert.
Wir haben viele Fragestellungen nicht betrachtet. Trotzdem: Der Kunde war zufrieden.
Auch Änderungen sozialer Art haben wir nicht betrachtet. Trotzdem: Der Kunde war zufrieden. Ja, der Kunde war äußerst zufrieden und hat uns später für ähnliche Aufgabenstellungen wiederholt beauftragt. Aber wir haben – zumindest aus meiner heutigen Sicht – die Aufgabenstellung nicht erfüllt.
Wie geht es besser?
Für Ihre Antwort auf diese Frage gebe ich Ihnen wieder einmal etwas Zeit. Also Danke bis zum nächsten mal!
Bild: Bigstock
