Systembeschreibungs Methodologie

Jan Burse, erstellt 29. Mär 2009 In Zürich findet man ein Jugendstil Haus mit der Inschrift „Erst besinn's, dann beginn's“. Einen guten Rat an den ich mich während des Anschlussprojektes halten möchte, schliesslich handelt es sich hier nicht um einen x-beliebigen Versuchsballon sondern ein Projekt das prägend für die Zukunft der Firma sein soll. Ein erstes Zugeständnis an den Rat war schon die Erstellung eines Businessplanes. Wie soll nun die Entwicklung des Verkaufssystems vorangetrieben werden, mit Besinnung bis zur Besinnungslosigkeit? Gerade die Informatik ist reich an Verfahren um das Unvermeidbare zu vermeiden, nämlich das Schreiben von Code hinauszuzögern. Es würde sich also anbieten das Anschlussprojekt wie das ursprüngliche HTA Projekt in einem mehrstufigen Verfahren zu entwickeln. Zu einem mehrstufigen Verfahren gehört dass ein Projekt mehrere Phasen durchläuft was diesem Vorgehensmodell den Spitznamen „Wasserfall-Modell“ eingebracht hat. Die klassischen Phasen sind Vorstudie, Hauptstudie, Realisierung, Einführung und Betrieb. Den Gegenpol zu mehrstufigen Verfahren bilden inkrementelle auf Prototypen aufbauende Verfahren. Durch den Einbezug von Prototypen wird schon relativ früh Code produziert der dann so weit zur Reife gebracht wird, dass eingeführt werden kann. Das vorliegende Projekt schliesst diesen Ansatz leider aus. Problematisch ist die Forderung produktiver Inkrements, da die Funktionalität des Verkaufssystems sehr verwoben ist. Also auch wenn wir hier auf der Website sukzessive Entwicklungsergebnisse probehalber aufschalten werden, so sind wir doch dem Wasserfallmodell verpflichtet. Unser Wasserfall hat schon eine Stufe hinter sich. Nämlich das im Rahmen der Vorstudie erstellte Grobkonzept mit dem Ergebnis dass „Schritte“ identifiziert wurden. Eine kleine Herausforderung waren die Richtlinien nach denen diese „Schritte“ identifiziert werden sollten. Uns schwebte vor dass diese „Schritte“ nicht nur einzelne Interaktionen von Benutzer mit System oder von System mit System aufzeigen, sondern in gewisser Weise auch schon die gewünschten Abläufe repräsentieren. Und dies alles bitte in luftiger Höhe ohne Referenz auf Datenmodelle, Bildschirmmasken, etc.. Diese Artefakte sollen erst in der Hauptstudie identifiziert werden. Die „Schritte“ bilden das Rohmaterial an Anforderungen aus denen diese Artefakte später weiter entworfen werden. Da sich die „Schritte“ also nicht mit den niedrigen Artefakten abgeben müssen, konnte ein sehr einfacher Dokumentationsstandard herangezogen werden. Wir benutzen Text der nicht mit Tabellen unterteilt ist und es gibt auch keinen Regelkatalog. Ein Beispiel einer solchen Beschreibung sieht man hier. Es hat sich gezeigt, dass obwohl die „Schritte“ sehr abstrakt sind, sie genügend Anleitung geben, um ohne Umweg über reichere Beschreibungen zum Code zu gelangen. Verfahrenstechnisch bedeutet das, dass wir beschlossen haben die Phase der Hauptstudie und die Phase der Realisierung zusammenzulegen. Eine Massnahme die hier nur durchführbar ist, weil wir praktisch keine Entscheidungswege haben und die deshalb in der Praxis kaum zu finden ist. Oder um in dem Bild von Alistair Cockburn zu sprechen, wir wagen den direkten Sprung von der Wolke zur Muschel.

Kommentare