Das folgende Kapitel entstammt dem Buch "Change Management bei Software Projekten", erschienen im Springer Verlag. Herr Salomon ist neben Gerhard Versteegen und Rainer Heinold Autor des Werkes und stellt sein Kapitel der modulo3 GmbH zur Veröffentlichung zur Verfügung.
Für weitere Informationen zu diesem Titel folgen Sie dem nebenstehenden Link.

Knut Salomon

Nachdem in dem vorherigen Kapitel die methodische Vorgehensweise beim Anforderungsmanagement dargestellt wurde, soll jetzt noch die Frage nach einer eventuellen Werkzeugunterstützung beantwortet werden.

Die von den Autoren mit Bezug auf das Anforderungsmanagement bisher in diesem Buch gewählte Reihenfolge

1. Erläuterung der theoretischen Grundlagen,
2. Einführung in einen konkreten Prozess, und
3. Betrachtung einer Werkzeugunterstützung

erscheint Ihnen sicherlich logisch. Erst nachdem die theoretischen und methodischen Grundlagen geschaffen sind, kann über einen eventuellen Einsatz eines Werkzeuges nachgedacht werden.

Soviel vorerst zum logischen Vorgehen. Nun wenden wir uns zunächst der Realität zu, und um Ihnen diese näher zu bringen, erzähle ich Ihnen eine kleine Geschichte.

Ein Unternehmen, dass sich mit der Softwareentwicklung beschäftigte, erhielt von einem Kunden den Auftrag, eine auf den Kunden zugeschnittene Anwendung zu entwickeln. Nachdem die Anforderungen des Kunden für alle beteiligten feststanden, wurde ein Projektleiter ernannt, ein Projektteam zur Implementierung dieser Anforderungen zusammengestellt und das Projekt gestartet.
  Zu Beginn des Projektes lief alles problemlos. Etwas später stellte sich allerdings heraus, dass es nicht möglich war, einfach ein paar Versionen des Quellcodes zurückzugehen, wenn die Entwickler in der Weiterentwicklung in die falsche Richtung gegangen waren. Teilweise überschrieben die Entwickler sogar beim Speichern Ihrer Änderungen den Quellcode ihrer Kollegen. Nun kannte der Projektleiter ein Werkzeug zur Versionskontrolle, dass genau bei diesen Problemen Lösungen versprach. Da in diesem Stadium des Projektes keinerlei Zeitdruck herrschte, hatte der Projektleiter Zeit, sich einige vergleichbare Werkzeuge anzusehen. Schließlich entschied er sich für das des Marktführers. Die Entwickler erkannten schnell, dass damit Ihre Sorgen kleiner wurden und begannen das Werkzeug im Projekt mit Begeisterung zu verwenden.
  Nachdem dem Kunden die ersten Prototypen der Anwendung vorgestellt wurden und dieser damit nicht zufrieden war, begannen die Entwickler, über die Art und Weise wie Sie mit den Anforderungen des Kunden umgingen nachzudenken. Es schien Ihnen, als ob der Kunde sie nicht recht verstehe. Da das geschriebene Wort je nach Sichtweise unterschiedlich interpretiert werden konnte, versuchten die Entwickler dem Problem der Missverständnisse durch den bewussten und konsequente Einsatz der Visualisierung zu begegnen. Dazu verwendeten Sie ER-Diagramme (Entity Relationship-Diagramme) und die UML zur Modellierung von Use Cases . Da das Projekt mittlerweile durch die teilweise falsche Umsetzung der Kundenanforderungen in Verzug geraten war, machten die Entwickler dem Projektleiter den Vorschlag, je ein Werkzeug zur ER- und Use Case-Modellierung zu beschaffen. Da der Projektleiter hoffte, mit dem Einsatz dieser Werkzeuge den Zeitverzug aufzuholen, gab er dem Drängen der Entwickler nach. Nachdem die Werkzeuge angeschafft worden waren, waren die Entwickler zunächst eifrig damit beschäftigt, die neuen Werkzeuge zu verwenden. Nach einiger Zeit stellten Sie jedoch fest, dass die ständige Pflege der Diagramme und der Use Cases zu zeitaufwendig war und ließen hier die Zügel schleifen. Letztlich war es viel einfacher und schneller, direkt die Datenbankobjekte in der Datenbank und die Klassen im Quellcode zu bearbeiten, so dass die Diagramme, die mit den Werkzeugen erzeugt worden waren, bald nicht mehr dem aktuellen Stand entsprachen. Damit waren Sie zur Dokumentation und als Grundlage zur Diskussion mit dem Kunden nicht mehr geeignet.
  Auch das permanente Verwenden des Werkzeuges zur Versionskontrolle war mittlerweile zu einer Belastung der Entwickler geworden, da diese nun doch erheblich unter Zeitdruck gerieten und keine Idee hatten, wie Sie den Auslieferungstermin der Anwendung einhalten sollten. Der Projektleiter verlangte nun, dass auf Teufel komm raus entwickelt werden sollte. Ein 12 Stunden Tag wurde normal und selbst die Wochenenden waren nicht mehr tabu. Kurzum, die Entwickler implementierten was das Zeug hielt. Jede andere Tätigkeit (z.B. die Anwendung der teuer gekauften Werkzeuge) lehnten Sie kategorisch ab.
  Da der Kunde alles andere als erfreut war als der Projektleiter ihm mitteilte, dass er den Auslieferungstermin für die gewünschte Anwendung nicht einhalten kann, wurde beschlossen, zumindest den derzeitigen Stand an den Endanwender auszuliefern, um schon mal mit der Einarbeitung in die Anwendung beginnen zu können. Schließlich sind nach Aussage des Projektteams alle unbedingt notwendigen Anforderungen implementiert und funktionstüchtig. Der Rest würde in den nächsten Tagen folgen.
  Nachdem die Endanwender eine gewisse Zeit mit der tollen neuen Anwendung gearbeitet hatten und feststellten, dass Fehler, die Sie bereits vor Wochen angemahnt hatten, nicht behoben waren, drohten Sie damit, die neue Anwendung nicht länger zu verwenden. Dies rief den Kunden auf den Plan, der nun beim Projektleiter die mangelhafte Qualität der Anwendung massiv anmahnte. Das gesamte Projektteam hatte mittlerweile keine Ahnung mehr, wie Sie auch nur halbwegs aus dem Ganzen mit heiler Haut herauskommen sollten. Letztlich sah der Kunde in einer Präsentation ein Werkzeug, mit dem die Qualität einer Anwendung automatisch getestet werden konnte. Diesen Tipp gab er dem Projektleiter, der daraufhin nach kurzer Überlegung den Rettungsanker, der sich im Anbot, ergriff und das Werkzeug beschaffte.
  Was soll ich sagen. Auch dieses Werkzeug wurde zu Beginn mit großem Enthusiasmus aufgenommen und kurze Zeit später für nicht brauchbar erachtet. Auch der Einsatz von teuren Beratern brachte nur einen temporären Erfolg.
  Schließlich wurde die Anwendung mit erheblichem Zeitverzug fertiggestellt. Der Kunde musste auf einen Teil der geforderten Anforderungen verzichten und bezahlte letztlich wesentlich mehr für die Anwendung als ursprünglich angenommen. Auch das Softwareunternehmen hatte Federn lassen müssen. Neben einem dicken Verlust wollte keiner des Projektteams ein weiteres Projekt wie das Letzte erleben und somit kündigte das gesamte Team. Den Kunden hatte das Softwareunternehmen natürlich auch verloren.

Nun werden Sie unter Umständen einwenden, dass ich in der Geschichte sehr schwarz gemalt habe und dass dies in Ihren Projekten komplett anders läuft.   Dann seien Sie froh. Sicherlich habe ich an der ein oder anderen Stelle etwas übertrieben, aber meine Erfahrung als "Feuerwehrmann" in IT-Projekten lehrte mich, dass die Geschichte bzgl. des Einsatzes von Werkzeugen nicht allzu weit von der Wahrheit entfernt ist.   Was können wir also für Schlussfolgerungen aus der obigen Geschichte in Hinblick auf eine Werkzeugunterstützung im allgemeinen und für eine solche für das Anforderungsmanagement im speziellen ziehen?   Es scheint als ob das Projektteam zwar der grundlegenden Projektmethodik Analyse, Design und Implementierung gefolgt ist, aber z.B. keinerlei Tests eingeplant hatte, den Kunden nicht genügend mit in das Projekt involvierte und erst Recht kein Anforderungsmanagement durchführte. Kurz um: Es fehlte ein übergreifender, allen bekannten und aus Best Practices bestehender, moderner, und iterativer Prozess - wie dem Rational Unified Process .   Ein weiterer "Erfahrungswert" ist, dass nahezu alle Projektmitarbeiter zwar im Grundsatz nach der gleichen Vorgehensweise arbeiten. Aber eben nur im Grundsatz und nicht im Detail. Dies deutet ebenfalls auf das Fehlen einer gemeinsamen Methode, die allen in Fleisch und Blut übergegangen ist, hin.   Mit Hinblick auf die Werkzeugunterstützung bedeutet dies in der Regel, dass zwar der Sinn und Zweck der Werkzeuge klar ist, deren Nutzen allerdings nicht korrekt erkannt wird. Denn würde dieser von allen korrekt erkannt, gäbe es keine Diskussion mehr über das Verwenden der Werkzeuge in zeitkritischen Situationen. Man würde Sie schlicht und einfach verwenden. Vielmehr noch, zeitkritische Situationen können durch den geplanten, gekonnten und konsequenten Einsatz von Werkzeugen teilweise vermieden werden. Als Beispiel kann hier das "Unterlaufen" der ER- und Use Case-Werkzeuge in der Geschichte dienen. Wäre deren realer Nutzen den Entwicklern bekannt gewesen, hätten diese nicht eine Sekunde daran gedacht, die Datenbankobjekt direkt in der Datenbank und ie Klassen direkt um Quellcode zu ändern. Hätte der Projektleiter diese Werkzeuge bereits frühzeitig eingesetzt, wären die Abstimmung der Anforderungen mit dem Kunden besser gelaufen und somit die Richtung der Entwicklung von vorne herein besser gewesen. D.h. der Zeitverzug wäre wahrscheinlich ausgeblieben.   Zusammenfassend kann festgehalten werden, dass in der Realität die Reihenfolge bei der Werkzeugunterstützung wie folgt aussieht:

1. Erkennen einer Problemstellung,
2. Einführung eines Werkzeuges zur Problemlösung,
3. Feststellen, dass das Werkzeug alleine nicht viel bringt, und
4. schließlich nach längerer Zeit die Erkenntnis, dass die Probleme eher methodischer als technischer Art sind.

Dieser Ansatz steht im krassen Gegensatz zu dem logisch erscheinenden Ansatz des Buches (s. 4.1).

Heißt das nun für Sie evtl. auf alle Ihre Werkzeuge zu verzichten? Auf keinen Fall!
  Um in der heutigen schnelllebigen Welt der IT auf Dauer als Unternehmen erfolgreich zu sein, benötigen wir schnelle und qualitativ hochwertige Prozesse. Dies gilt auch für den Softwareentwicklungsprozess.
  Das heißt auch, das ohne die Verwendung von Werkzeugen, die geforderte Geschwindigkeit und Qualität in größeren Projekten kaum zu erreichen sein wird.
  Demzufolge sind wir auf die Hilfe von Werkzeugen angewiesen. Aber diese müssen in den Gesamtkontext eines modernen Prozesses eingebettetet sein und aufeinander abgestimmt sein. Jeweils das Werkzeug mit der größten Funktionsfülle oder immer das neueste am Markt zu beschaffen, reicht eben nicht aus.
  Worauf muss nun speziell beim Anforderungsmanagement in diesem Zusammenhang geachtet werden? Die Antworten finden sie auf den folgenden Seiten.