Wieso "Tailoring" (dt.: Maßschneidern)? Gibt es doch keinen Standard, den man direkt anwenden kann? Wir haben doch eben erst Standardmodelle für die Vorgehensweise bei der Softwareentwicklung betrachtet, die ständig weiter verbessert werden. Warum muss ich dann eine Maßschneiderung vornehmen? Weil die Softwareentwicklungsprojekte sehr unterschiedlich sind! Weil die Kunden unterschiedliche Ansprüche bei der Abwicklung der Projekte geltend machen! Weil eine deutsche Behörde andere Rahmenbedingungen stellt als eine moderne kleine AG! Weil Software sehr nah an Hardwareentwicklungen sein kann (z.B. bei Embedded Software) oder auch reine Verwaltungsprozesse unterstützten kann. Deshalb sollte der gewählte Standard an das individuelle Projekt angepasst werden, um die Bedürfnisse des Projekts möglichst gut zu treffen (s. auch SPICE).

Wenn Sie das Projekt iterativ inkrementell entwickeln wollen, aber zum Festpreis anbieten müssen, kann es beispielsweise absolut sinnvoll sein, einen großen Teil der Analysen der einzelnen Iterationen nach vorne zu verlegen und in Summe zum Festpreis anzubieten. Diese Analysephase können Sie dann nämlich recht sicher abschätzen und danach auch den Rest des Projekts, so dass Sie danach den Rest des Projekts ebenfalls zum Festpreis anbieten können. Nach diesem Verfahren habe ich mehrere Projekte erfolgreich abgewickelt und es mittlerweile sogar zu meiner Wunschvorgehensweise gemacht:

Wenn Sie hingegen einen absoluten Endtermin bei einem unternehmenskritischen Projekt haben und der Zeitrahmen allen Beteiligten spontan als unrealistisch erscheint, werden Sie diese Vorgehensweise vergessen können. Dann werden Sie eher schauen, wie viele Leute Sie freischaufeln können, diese Zahl mit den Arbeitstagen bis zum Endtermin multiplizieren und kommen somit zum Volumen des Angebots. Dann werden Sie massiv parallel durch den Projektplan laufen, so dass alles, was gerade analysiert wurde, sofort ins Design geht und alles, was gerade aus dem Design herauskommt, sofort in die Implementierung geht, etc. Das gleicht dann eher mehreren zusammengeschobenen Wasserfällen und stinkt gewaltig nach einem weiteren Heldenprojekt (also eins, das nur von einer Handvoll Helden durchgezogen werden kann, s. [B28]):

Wenn Sie in dem Projekt so innovativ unterwegs sind, dass Sie neues Terrain aufstoßen, also beispielsweise im Rahmen einer Forschung softwaregestützte Lösungen suchen, dann werden Sie auch keine andere Chance haben, als zu Beginn der Iterationen ausschließlich die jeweils vor Ihnen liegende Iteration zu analysieren. Sie werden dann nämlich eher Gordon Moores "Prinzip der minimalen Information" folgen und heuristisch vorgehen: Sobald man eine scheinbare Lösung gefunden hat, versucht man diese umzusetzen; irrt man, so geht man zurück und beginnt zu lernen - bis man etwas Neues zum Ausprobieren findet. Diese Vorgehensweise hat sich auch unter dem Slogan "Trial and Error" (dt.: Versuch und Irrtum) verbreitet, beschreibt aber nicht die systematische Vorgehensweise, die ich primär in dieser Abhandlung darstellen möchte.

In solchen Projekten empfiehlt sich eher der XP-Ansatz (Extreme Programming) von Beck/Fowler, bei dem extrem iterativ gearbeitet wird und entgegen vieler Behauptungen sehr wohl planerisch vorgegangen werden kann, wie die beiden in ihrem Buch [B34] zeigen. XP empfiehlt sich bei kleineren Teams in eher kleineren Projekten mit ungenauen und sich ständig ändernden Anforderungen, denn es wird immer nur ein ganz kleiner Satz von Anforderungen in einer ganz kleinen Iteration von möglichst nur wenigen Tagen implementiert. Lange Projekte werden dabei in viele Mini-Projekte von wenigen Wochen zerteilt, die möglichst unabhängig voneinander sein sollten. Nach einer Zeit der "Übermethodisierung" in einigen großen Häusern und ebenso großen Projekten versucht XP eine recht radikale Reduzierung auf das Minimum. XP wird gerne mit Autofahren verglichen: dort schlägt man auch nicht einmal eine Richtung ein und lässt die Kiste fahren (wie beim Fliegen mit Autopilot), sondern vielmehr besteht das Lenken aus einer permanenten Richtungskorrektur in möglichst kleinen Schritten während der Fahrt. Ich bestätige ausdrücklich aus eigener Erfahrung, dass der Kunde dabei in der Lage sein muss, permanent zu steuern und Verantwortung zu übernehmen, denn die Entwickler oder Analytiker können Anforderungen zwar vorschlagen, aber allein der Kunde entscheidet, wann was gemacht wird! Und dies in extrem kurzen Abständen, so dass er eigentlich permanent als Mitglied im Entwicklerteam sitzt - schließlich muss er mangels Analysephase ja auch obendrein noch spontan und direkt alle Fragen der Entwickler beantworten. Damit sind viele Fachleute der Kunden gnadenlos überfordert.

Reines XP mag oft genial sein, oft aber auch unmöglich. Bei einer Ausschreibung einer guten deutschen Behörde muss die Leistung fest definiert sein, denn Sie werden selten von einer Behörde einen Auftrag für 8 Monate "Wir schauen mal, wann wir was machen und was überhaupt" bekommen. Und Sie werden auch kaum so viele kleine Einzelbeauftragungen bekommen, ohne in einen Kettenauftrag zu rasseln. Wenn hingegen in einem Wirtschaftsunternehmen ein Softwareentwicklungsprojekt vor die Wand läuft, ist XP ideal zur Rettung (besser als noch mehr Leute ins Projekt zu pumpen, s. [B10]). Dann wird nämlich erstmal das Wichtigste rausgesucht und das zum Laufen gebracht - und bei den meisten Projekten, die aus dem Ruder laufen, geschieht dies nun mal wegen mangelnder Fokussierung! XP benötigt nämlich übrigens extrem viel Disziplinierung, Konsequenz und Erfahrung und ist nicht - wie die meisten fälschlicherweise meinen - das Vorgehensmodell, bei dem das Drauflosprogrammieren von früher endlich zur Methode gemacht wird!

Also ich setze gerne bereits im Vertriebsgespräch mit einer ersten Diskussion der strategischen Ziele an und biete dem Kunden eine kurze kostenpflichtige Pre-Analyse im Sinne einer Geschäftsprozessanalyse an. Diese ergibt vorab (deshalb "Pre"-Analyse) ein grobes Bild über den zu betreibenden Aufwand, liefert mir einen ersten Einblick in das Unternehmen des Kunden und führt zu der Entscheidung über die Machbarkeiten. Am Ende dieser kurzen Phase steht eine Grobspezifikation (früher "Lastenheft" genannt) des zu erstellenden Systems, inkl. Interessensgruppen- und Akteur-Listen sowie einem Zweck- und Tragweiten-Diagramm. Insbesondere aber steht am Ende der Pre-Analyse das für dieses Projekt maßgeschneiderte Vorgehensmodell, in der Regel ein Kompromiss zwischen den beiden oben dargestellten Extremen.

Ferner werden meistens bereits in dieser Phase alle Hauptanforderungen an das System gesammelt und dokumentiert - diese Liste wird in mehreren Iterationen erstellt und überarbeitet und in der folgenden eigentlichen Analysephase mit Teilanforderungen weiter gefüllt und präzisiert. Hier besteht ein gewisser Spielraum beim Übergang zwischen der Geschäftsprozessanalyse und der folgenden Anforderungsanalyse.

Auch die Anforderungsanalyse biete ich in aller Regel zum Festpreis an, so dass sich der Kunde über seine Aufwände möglichst klar ist. Diese eigentliche Analyse ist typischerweise per Definition unvollständig, schafft aber genug Sicherheit für ein präzises Realisierungsangebot, für eine Zeitabschätzung, für einen Releaseplan der Funktionsblöcke (Iterationen) und für die Skizzierung des geplanten Produkts (Storyboard). Häufig soll am Ende der Analysephase auch eine vollständige Feinspezifikation (früher "Pflichtenheft" genannt) des zu erstellenden Systems stehen, also eine Beschreibung darüber, was es genau leisten wird (Anwendungsfallmodell) und wie es das exakt tun wird (Prototypenmodell). Diese verschiedenen Detaillierungsgrade werden typischerweise innerhalb mehrerer Analyseiterationen erreicht. Oft macht übrigens eine vorläufige Aufwandsabschätzung nach der Hälfte der Analysezeit Sinn, um bei Nichtmachbarkeit das Projekt hier schon abzubrechen. Nach der Analysephase kenne ich jedenfalls definitiv die Fachlichkeit des Kunden und kann die Widerspruchsfreiheit der Anforderungen gewährleisten. Dadurch, dass der Kunde bei der Analyse sehr viel Zeit für Interviews zur Verfügung stellt, kann auch die Vollständigkeit und fachliche Fehlerfreiheit gewährleistet werden.

In der Entwurfsphase erfolgt das technische Design der Architektur der Software, d.h. das Klassenmodell (iterativ in der konzeptionellen, spezifizierenden und implementierenden Sicht), das Datenmodell, die Verteilung der Komponenten innerhalb der Server-Farm (n-tier-Modell) und schließlich auch die Struktur der Clients. Der Designer gewährleistet die Implementierbarkeit der Ergebnisse der Anforderungsanalyse.

Die Konstruktion (Implementierung) ist schließlich die Umsetzung in die physikalische Technik, d.h. die Generierung des Schemas in der Datenbank, die Programmierung in der gewählten Umgebung und die Realisierung des GUI (Graphical User Interface, deutsch: Graphische Benutzerschnittstelle). Insbesondere diese Implementierung erfolgt iterativ inkrementell, weil die Funktionalität immer "häppchenweise" umgesetzt wird; vor der Umsetzung eines solchen Arbeitspakets wird nämlich auch sicherlich nochmals eine ganz kurze Analyse- und Designphase stehen, um Gelegenheit zum Review und zum Einarbeiten von Änderungsanforderungen zu haben.

Tests erfolgen immer, wirklich andauernd, um die geforderte Qualität ständig gewährleisten zu können! Bereits mit dem Zielsatz kann der Name der Software auf seinen Bezug getestet werden, in der Pre-Analyse wird das Fachkonzept getestet, in der Analyse werden die Hauptanforderungen aus der Pre-Analyse getestet, etc. Der letzte Test erfolgt nach dem Übergang der Software in das Echtsystem des Kunden durch die Anwender. Die bei der Abnahme anhand der Anforderungen festgestellten und auch später im Laufe des Betriebs auftretenden Mängel werden in der Wartungsphase unverzüglich behoben. Hier werden auch in Folgeversionen die aufgeschobenen Wünsche (Änderungsanforderungen) realisiert.

Bei fehlgeschlagenen Tests wird natürlich immer wieder so weit zurück gegangen, bis die Ursache gefunden und angepasst wurde. Danach werden die Veränderungen genauso eingearbeitet wie die ursprünglichen Anforderungen. Auch auftretende Änderungsanforderungen werden (wenn sie denn überhaupt im laufenden Projekt einfließen sollen) durch das gesamte Vorgehensmodell geschoben - genau wie eine ursprüngliche Anforderung. Ein wesentlicher Vorteil dieser iterativ inkrementellen Arbeitsweise wird von Siebel in [B19] sehr schön mit diesem Spruch ausgedrückt: "Get it in the water now - launch and learn; it's better to float something than to have a perfect vessel in drydock" (dt. "Bring es nun ins Wasser - starte und lerne; es ist besser irgendwas zu fluten als ein perfektes Schiff im Trockendock zu haben"). Das soll nicht heißen, dass man jeden Quark ungetestet auf den Markt werfen soll, denn das sind dann "banana products" (Produkte, die beim Kunden reifen), aber man soll auch nicht warten, bis das Produkt zwar ganz fertig und perfekt, aber dafür veraltet ist und die Firma zwischendurch vielleicht schon ausgehungert ist.

Ein Prozess oder Teilprozess setzt sich dabei immer aus Vorgängen zusammen, die das System von einem Zustand in einen anderen bringen. Ein Zustand kann dabei immer dokumentiert, d.h. präzise in einer geeigneten Form beschrieben werden. Dieses Dokument stellt damit zugleich das Ergebnis des vorherigen Vorgangs und die Basis eines nachfolgenden Vorgangs dar. Jeder Vorgang verfolgt also ein Ziel, das an einen bestimmten Systemzustand und damit an ein bestimmtes Dokument gekoppelt ist. Damit ist jeder Zustand und jedes Dokument gleichzeitig auch Schnittstelle zwischen zwei Vorgängen.

Das Diagramm rechts oben kann also so gelesen werden: Die Anforderungen an das zu erstellende Softwaresystem liegen vor und der Vorgang der "Pre-Analyse" führt zu einer groben Darstellung des Systems (z.B. in Form einer Grobspezifikation als Prosatext in einer Textverarbeitung). Der weiter führende Vorgang der "Analyse" zielt auf eine detaillierte Sicht und führt den Analytiker deshalb zu einer Feinspezifikation, die vielleicht durch Prototypen noch präziser dokumentiert wird. Über den Design-Vorgang kann ein Systemarchitekt auf Basis der Feinspezifikation die Architektur festlegen, die vielleicht anhand verschiedener Modelle dokumentiert wird. Und so weiter.