1 Einführung eines iterativen und inkrementellen ...

1
(LQI KUXQJHLQHVLWHUDWLYHQXQGLQNUHPHQWHOOHQ(QWZLFNOXQJVSUR]HVVHVLQ*UR‰XQWHUQHKPHQ
YHU|IIHQWOLFKWLQ2%-(.7VSHNWUXP
3HWHU6W|FNO(0DLOSV#FRUWH[EUDLQZDUHGHDUEHLWHWDOV%HUDWHUEHLGHU&RUWH[%UDLQZDUH&RQVXOWLQJ 7UDLQLQJ
*PE+(UEHVFKlIWLJWVLFKVHLWHLQLJHQ-DKUHQPLWGHQ7KHPHQ6RIWZDUHHQWZLFNOXQJVSUR]HVVHXQG5HTXLUHPHQWV
0DQDJHPHQW
Die Einführung neuer Entwicklungsprozesse ist eine vielschichtige Aufgabe. Gerade in Großunternehmen reicht es
nicht aus nur softwaretechnische Aspekte zu betrachten. Die geplanten Änderungen haben Auswirkungen auf
zahlreiche Organisationseinheiten und auf jeden einzelnen der betroffenen Mitarbeiter. Der Artikel beschreibt typische
Probleme bei der Einführung von neuen Entwicklungsprozessen und mögliche Lösungen.
Iterative und inkrementelle objektorientierte Entwicklungsprozesse (im Folgenden 223UR]HVVHgenannt) haben ihre
Überlegenheit gegenüber Prozessen, die auf dem Wasserfall-Modell basieren, inzwischen auf breiter Front bewiesen.
Ihre wichtigsten Vorteile sind:
• geringeres Entwicklungsrisiko
• schnellere Reaktionszeiten bei geänderten Anforderungen
• früheres Feedback der Anwender bzw. Auftraggeber
Bekannte OO-Prozesse sind beispielsweise
der 2EMHFW(QJLQHHULQJ3URFHVV2(3 (vgl. [Oes99]),
der 2EMHFWRULHQWHG3URFHVV(QYLURQPHQWDQG1RWDWLRQ23(13URFHVV(vgl. [Gra97]),
der 2EMHFW2ULHQWHG6RIWZDUH3URFHVV2263 (vgl. [Amb98]) und
der 5DWLRQDO8QLILHG3URFHVV583 (vgl. [Kru99]).
Für die meisten Unternehmen stellt sich daher nicht mehr die Frage, ob sie einen OO-Prozess einsetzen sollen, sondern
wie er am besten eingeführt werden kann. Bei einer Prozesseinführung sind einige fachliche Aufgaben zu erledigen.
Der Prozess muss an die speziellen Bedürfnisse des Unternehmens angepasst werden, eine sinnvolle Dauer der
einzelnen Iterationen muss festgelegt werden und einiges mehr. Diese Aktivitäten sind inzwischen in etlichen Artikeln
und Büchern ausführlich beschrieben.
Das Erledigen dieser fachlichen "Hausaufgaben" reicht aber nicht aus, um einen OO-Prozess erfolgreich in einem
Unternehmen einzuführen. Sein Einsatz zieht nämlich Änderungen in der Organisation nach sich und hat
Auswirkungen auf die einzelnen Mitarbeiter. Wird dies nicht berücksichtigt, ist die Gefahr groß, dass die Einführung
eines OO-Prozesses trotz seiner fachlichen Vorzüge scheitert.
Dieser Artikel richtet sich nicht nur an Softwareentwickler, sondern auch an Projektmanager und Führungskräfte. Er
beschreibt die Erfahrungen, die der Autor in den letzten zwei Jahren bei der Einführung von OO-Prozessen in
Unternehmen gemacht hat, die zuvor nach dem Wasserfall-Modell gearbeitet haben. Dabei wird vor allem auf die
organisatorischen und psychologischen Aspekte eingegangen.
$NWXHOOH6LWXDWLRQLQ*UR‰XQWHUQHKPHQ
Heutige Großunternehmen sind in der Regel seit einigen Jahren ISO-9000-zertifiziert und arbeiten daher nach einem
definierten Entwicklungsprozess, der üblicherweise auf dem Wasserfall-Modell basiert. Zuerst wird ein Fachkonzept
erstellt, danach ein DV-Grobkonzept und ein DV-Feinkonzept. Anschließend wird die Software codiert und zum
Schluss getestet. Dieses Vorgehen hat den Vorteil, dass es sich einfach planen lässt und eine Arbeitsteilung gut
unterstützt.
Die Strukturen in den Unternehmen sind daher auf das Wasserfall-Modell abgestimmt. Die Aufgaben Spezifikation,
Softwarearchitektur, Implementierung und Test sind organisatorisch getrennt, häufig als Profitcenter, die an einer
gleichmäßigen Auslastung interessiert sind. Die Richtlinien zur Vertragsgestaltung mit Kunden und mit
Unterauftragnehmern setzen das Wasserfall-Modell und seine Meilensteine voraus. Abbildung 1 veranschaulicht dies.

2
$EE2UJDQLVDWLRQVVWUXNWXULP:DVVHUIDOO0RGHOO
In der Praxis wurden mit dem Wasserfall-Modell jedoch nur bei kleinen Projekten gute Erfahrungen gemacht. Bei
größeren Projekten konnte man regelmäßig feststellen, dass zwischen den einzelnen Phasen relativ unkontrolliert
gewechselt wurde. Während der Realisierungsphase wurden Anforderungen geändert, während der Testphase das
Softwaredesign usw. Dies verursachte natürlich auch organisatorische Probleme. In der Realisierungsphase waren
beispielsweise die Fachdesigner nicht mehr verfügbar, obwohl neue Anforderungen auftauchten. Diese Probleme
wurden aber nicht dem Prozess angelastet, sondern den Projekten bzw. den jeweiligen Projektbeteiligten. Daher wurde
der Sinn der oben beschriebenen organisatorischen Strukturen nie in Frage gestellt.
Die Mitarbeiter in den Unternehmern, vor allem die Erfahrungsträger, arbeiten häufig seit vielen Jahren nach dem alten
Vorgehen und sind mit diesem bestens vertraut. Dieses Wissen ist ein Teil ihres Kapitals. Sie haben meist kein großes
Interesse an Veränderungen.
Diese Situation muss bei der Umstellung auf einen OO-Prozess berücksichtigt werden. Andernfalls kann es sehr schnell
zum Scheitern des gesamten Vorhabens kommen. Es ist daher sinnvoll bei der Prozesseinführung folgende Reihenfolge
einzuhalten:
1. Auswahl eines Pilotprojekts und der Projektmitarbeiter
2. Definition des Entwicklungsprozesses
3. Anpassen des betroffenen organisatorischen Umfelds
4. Durchführung des Pilotprojekts
Im Folgenden wird auf jeden dieser Punkte genauer eingegangen.
$XVZDKOHLQHV3LORWSURMHNWV
Es ist praktisch nie der Fall, dass ein Unternehmen den gesamten unternehmensweiten Entwicklungsprozess auf einen
Schlag umstellt. Normalerweise wird der neue Prozess in einem Pilotprojekt erprobt. Die Auswahl eines geeigneten
Pilotprojekts ist entsprechend wichtig. Das Projekt muss nämlich beweisen, dass der neue Prozess besser ist als der
bisherige. Daher ist es wichtig, dass es folgende Kriterien erfüllt:
• 'DV3LORWSURMHNWVROOWHNHLQHWULYLDOH$XIJDEHQVWHOOXQJEHVLW]HQ Triviale Aufgaben lassen sich mit jedem Prozess,
notfalls sogar ohne Prozess lösen. Damit gezeigt werden kann, dass ein iteratives Vorgehen besser ist als ein
Vorgehen nach dem Wasserfall-Modell, ist also eine gewisse Komplexität erforderlich.

3
• 'DV3LORWSURMHNWGDUI]HLWOLFKQLFKWNULWLVFKVHLQ. Es darf also keinen festen Termin und keine knappen zeitlichen
Vorgaben besitzen. Für die Projektmitarbeiter wird die neue Vorgehensweise so ungewohnt sein, dass
Verzögerungen unvermeidbar sind.
• 'DV3LORWSURMHNWPXVVGLH$QZHQGXQJGHVQHXHQ3UR]HVVHVHUODXEHQ Das ist immer der Fall, wenn das System,
das entstehen soll, "auf der grünen Wiese" entwickelt werden kann. Etwas problematischer ist es, wenn das
Pilotprojekt mit bestehenden anderen Projekten koordiniert werden muss, die nach einem herkömmlichen Prozess
durchgeführt werden. Es ist zum Beispiel schwierig Schnittstellen zwischen zwei Systemen festzulegen, wenn das
eine System nach dem Wasserfall-Modell entwickelt wird und das andere gleichzeitig iterativ. Die Informationen,
die für die Schnittstellenspezifikation nötig sind, müssen nämlich zu unterschiedlichen Zeitpunkten erstellt werden
bzw. verfügbar sein. In einem iterativen Vorgehen werden zuerst die architekturrelevanten Anforderungen
detailliert beschrieben und realisiert. Schnittstellen gehören oft nicht zu diesen Anforderungen. Das Wasserfall-
Modell erfordert es, alle Schnittstellen genau festzulegen, bevor die Spezifikationsphase abgeschlossen werden
kann. Die Erweiterung eines bestehenden Systems ist oft kein geeignetes Pilotprojekt. In einem solchen Fall liegen
meist Entwicklungsdokumente vor, die für eine Weiterverwendung in einem iterativen Prozess nicht geeignet sind.
Häufig ist eine Softwarearchitektur vorhanden, die kein inkrementelles Vorgehen erlaubt, da kleine Ergänzungen
der Funktionalität Änderungen in weiten Teilen des Systems erfordern. Häufig wird jedoch der Wunsch bestehen,
gerade solche Aufgaben als Pilotprojekt durchzuführen, da mit der bestehenden Software und den
Entwicklungszeiten bei der Einbringung von neuen Leistungsmerkmalen in der Vergangenheit schlechte
Erfahrungen gemacht wurden. Der neue Entwicklungsprozess soll nun eine Verbesserung dieser Situation bringen.
Die Motive sind also durchaus nachvollziehbar, richtig wird die Wahl dadurch aber nicht.
Dem Gesamtverantwortlichen für das Pilotprojekt muss klar sein,
• dass Mitarbeiter irritiert und verunsichert sein werden,
• dass Organisationseinheiten, mit denen zusammengearbeitet werden muss, möglicherweise mit dem neuen
Vorgehen nicht zurechtkommen und
• dass ein Termindruck für das Projekt fatal sein kann. Der neue Prozess sollte wenigstens im Pilotprojekt in voller
Breite durchlebt werden. Es ist gefährlich, wegen eines aggressiven Endtermins Abstriche bei den vorgesehenen
Arbeiten zu machen. Wenn nämlich noch keine Erfahrungen im neuen Vorgehen vorhanden sind, kann nicht
entschieden werden, auf welche Arbeiten verzichtet werden kann und welche absolut notwendig sind.
Der Verantwortliche wird die oben genannten Schwierigkeiten nur dann akzeptieren, wenn ihm gezeigt wird, was er
durch den neuen Prozess in Zukunft gewinnen kann: bessere Kontrolle über die Projekte, geringere Risiken und
zufriedenere Kunden.
$XVZDKOGHU3URMHNWPLWDUEHLWHU
Nachdem ein geeignetes Pilotprojekt gefunden ist, kann mit der Auswahl der Projektmitarbeiter begonnen werden.
Durch das Thema des Projekts und seine zeitliche Terminierung ist der mögliche Mitarbeiterkreis bereits
eingeschränkt. Geeignete Kandidaten müssen die benötigten Erfahrungen besitzen und für die Laufzeit des Projekts
verfügbar sein. Um so wichtiger ist es, dass aus dem verbleibenden Personenkreis frei ausgewählt werden darf. Es ist
absolut entscheidend für den Erfolg des Pilotprojekts und der gesamten Prozesseinführung, dass das Projektteam den
neuen Prozess unterstützt. Bei der Zusammenstellung des Teams müssen also auch psychologische Aspekte
berücksichtigt werden.

4
$EE5HDNWLRQHQDXI9HUlQGHUXQJHQ
Die Einführung eines neuen Prozesses bedeutet zunächst einmal für jeden einzelnen Mitarbeiter eine Veränderung. Wie
Menschen mit Veränderungen umgehen, hängt von ihrer Persönlichkeit ab. Die Reaktionen reichen von totaler
Begeisterung bis zu völliger Ablehnung. Die Häufigkeit der jeweiligen Reaktion besitzt die Form einer Gaußschen
Glockenkurve, wie in Abbildung 2 dargestellt. Extreme Ablehnung oder Begeisterung trifft man eher selten, eine
Indifferenz am häufigsten an. Bei der Analyse der Reaktionen ist eine Einteilung der Personen in vier Gruppen
hilfreich:
• Die meist recht kleine Gruppe derIU KHQ8QWHUVW W]HU Sie sind von allem Neuen begeistert, einfach weil es neu
ist. Sie stellen für die Einführung eines neuen Entwicklungsprozesses kein Problem dar, helfen aber auch nicht, da
ihre Begeisterung für neue Dinge bei den Kollegen bekannt ist und daher nicht ernst genommen wird.
• Die ebenfalls recht kleine Gruppe der SULQ]LSLHOOHQ*HJQHU Sie fühlen sich nur in vertrauter Umgebung wohl und
lehnen daher alles Neue ab. Jeder Versuch, solche Personen von Neuem zu überzeugen, ist verschwendete Mühe.
Sie müssen sich einfach langsam an Neuerungen gewöhnen. Glücklicherweise wird dieser Personenkreis von
seinen Kollegen ebenso wenig ernst genommen wie der erste.
• Die relativ große Gruppe der ]XU FNKDOWHQG=XVWLPPHQGHQ Sie sind Änderungen gegenüber prinzipiell positiv
eingestellt, bleiben aber kritisch.
• Die ebenfalls große Gruppe der ]XU FNKDOWHQG$EOHKQHQGHQ Sie sind eher skeptisch, setzen sich aber mit
Neuerungen auseinander und können durch gute Argumente überzeugt werden.
Für das Pilotprojekt ist es wichtig, keine prinzipiellen Gegner im Projektteam zu haben und möglichst mehr
zurückhaltend Zustimmende als zurückhaltend Ablehnende. Der letzten Gruppe muss die größte Aufmerksamkeit
geschenkt werden. Wenn es gelingt, genügend viele aus dieser Gruppe vom neuen Vorgehen zu überzeugen, setzt ein
gruppendynamischer Prozess innerhalb des Teams ein, in dessen Verlauf das gesamte Team die neue Methode
befürwortet.
Neben diesen eher theoretischen Überlegungen darf nicht vergessen werden, dass es bei jeder Neuerung Gewinner und
Verlierer gibt. Oft betrachten sich gerade erfahrene Mitarbeiter als Verlierer bei der Einführung eines neuen Prozesses,
weil sie das Gefühl haben, dass ihre erworbenen Erfahrungen wertlos werden und relativ neue Leute mit entsprechend
neuem Wissen im Wert steigen. In diesem Fall werden sie unter Umständen versuchen, den Erfolg des Pilotprojekts zu
verhindern. Da auf ihr Wissen häufig nicht verzichtet werden kann und da sie meist gute Verbindungen zum
Management besitzen, sind ihre Chancen groß, dies auch zu erreichen. Solche Mitarbeiter lassen sich an folgenden
Verhaltensweisen erkennen:
• Offene Ablehnung.

5
• Scheinbare Auseinandersetzung mit dem neuen Thema. Diese darf nicht mit echtem Interesse verwechselt werden.
Hierbei werden oft endlose, nicht konstruktiv geführte Diskussionen über die richtige Umsetzung der neuen
Vorgehensweise gestartet.
• Stille Verweigerung, zum Beispiel durch Dienst nach Vorschrift. Der Mitarbeiter wird in diesem Fall
argumentieren, dass der schlechte Fortschritt der Arbeiten am neuen Vorgehen liegt. Wenn er wie früher arbeiten
dürfte, wären seine Leistungen auch besser.
Mit solchen Personen im Projektteam ist das Pilotprojekt zum Scheitern verurteilt. Daher ist es in diesem Fall besser,
ein Pilotprojekt zu suchen, in dem auf die entsprechenden Mitarbeiter verzichtet werden kann.
Eine besondere Rolle im Pilotprojekt spielt auch der Projektleiter. Er muss im Vorfeld des Projekts gründlich geschult
werden, was in der Praxis häufig erstaunlich schwierig ist, da diese Personen meist einen vollen Terminkalender haben
und außerdem die typischen Standardschulungen eher auf Entwickler als auf Projektleiter ausgerichtet sind.
'HILQLWLRQGHV3UR]HVVHV
Die Qualitätsnorm ISO 9000 verlangt, dass in einem Unternehmen ein verbindlicher Entwicklungsprozess vorhanden
und dokumentiert ist und dass alle Projekte nach diesem Prozess durchgeführt werden. Da die vorhandenen
Prozessrichtlinien normalerweise nicht mit einem modernen OO-Prozess übereinstimmen, gibt es nur zwei
Möglichkeiten, das Pilotprojekt ISO-9000-konform durchzuführen:
• Die Prozessrichtlinien werden so geändert, dass sie auch den neuen Prozess als Vorgehensmodell zulassen. Das ist
normalerweise nicht durchsetzbar, da die dafür zuständigen Mitarbeiter meist auch die Schöpfer der bestehenden
Richtlinien und für ihre Einhaltung verantwortlich sind. Sie werden nicht ohne triftige Gründe "bewährte"
Vorgehensweisen durch neue und unbekannte ersetzen.
• Es wird eine Erlaubnis erteilt, ein Pilotprojekt nach dem neuen Entwicklungsprozess durchzuführen. Diese
Erlaubnis muss normalerweise vom Entwicklungsleiter oder einem ähnlichen Funktionsträger gegeben werden.
Auch an dieser Stelle ist also Überzeugungsarbeit zu leisten. Außerdem sind eigene Prozessrichtlinien erforderlich,
in denen das neue Vorgehen im Detail beschrieben wird.
Die Erstellung der Prozessrichtlinien ist eine Gradwanderung. Sind sie nicht detailliert und formal genug, entsprechen
sie nicht den Anforderungen von ISO 9000. Sind sie zu formal, werden sie nicht gelesen und schon gar nicht befolgt
und sind damit wertlos. Folgende Fragen sollten mindestens geklärt werden:
• Welche Rollen gibt es im Prozess?
• Welche Ergebnisse müssen wann und von wem erbracht werden?
• Welche Organisationseinheiten sind zu welchen Zeitpunkten am Projektgeschehen beteiligt?
• Welche Planungsdokumente werden zu welchen Zeitpunkten benötigt?
Dabei ist es wichtig, für die einzelnen Planungsdokumente entsprechende Vorlagen zu erstellen. Das Erstellen dieser
Vorlagen ist sehr zeitintensiv, da dabei viele Regeln und Vorschriften beachtet werden müssen, die in einem großen
Unternehmen normalerweise vorhanden sind.
Die Prozessrichtlinien sollten bereits vor dem Start des Pilotprojekts bereits fertig sein. Wenn das nicht der Fall ist, ist
die Gefahr groß, dass die Anfangsphase des Projekts unkoordiniert abläuft.
$QSDVVHQGHVEHWURIIHQHQRUJDQLVDWRULVFKHQ8PIHOGV
Der neue Prozess wird es erfordern, einige Regelungen und Gewohnheiten innerhalb des Unternehmens zu ändern.
Diese Änderungen können nur in Zusammenarbeit mit den jeweiligen Entscheidungsträgern durchgeführt werden. Am
häufigsten sind die folgenden Gebiete betroffen.
&RQWUROOLQJ
Es gehört zu den Aufgaben eines Projektleiters, sein Projekt zu überwachen. Dabei wird er bestimmte Metriken
erheben und Kennzahlen ermitteln. Einen Teil dieser Kennzahlen muss er an die Controlling-Abteilung weitergeben,
deren Aufgabe es ist, die Wirtschaftlichkeit der einzelnen Entwicklungsabteilungen zu prüfen. Die Kennzahlen sind
üblicherweise genau festgelegt und auf das Wasserfall-Modell abgestimmt. Zum Beispiel werden an den jeweiligen
Meilensteinen das noch zur Verfügung stehende Budget und die verbrauchte Zeit ermittelt oder zu Projektbeginn muss
mit Hilfe der )XQFWLRQ3RLQWAnalyse eine Aufwandsabschätzung abgegeben werden.
In Projekten, die nach einem OO-Prozess durchgeführt werden, stehen dem Projektleiter wesentlich genauere
Kennzahlen zur Verfügung, als dies beim Wasserfall-Modell der Fall ist. Die Kennzahlen werden aber anders und zu
anderen Zeitpunkten erhoben. Daher muss in Zusammenarbeit mit der Controlling-Abteilung festgelegt werden,

6
• ob die einzelnen Kennzahlen anders ermittelt werden müssen,
• ob sie anders interpretiert werden müssen oder
• ob komplett neue Kennzahlen benötigt werden.
=XVDPPHQDUEHLWÃYRQÃ2UJDQLVDWLRQVHLQKHLWHQ
Falls im Unternehmen eine sehr starke Arbeitsteilung herrscht, sind auch die Verantwortlichen der einzelnen
Organisationseinheiten vom neuen Entwicklungsprozess betroffen. In vielen Unternehmen werden folgende
Tätigkeiten von eigenen Organisationseinheiten vorgenommen: Spezifikation des Systems, Erstellen einer
Softwarearchitektur, Realisieren der Software, Testen und Einführen der Software (vgl. Abb. 1). Jede dieser
Organisationseinheiten ist an einer gleichmäßigen Auslastung ihrer Mitarbeiter interessiert.
Das Wasserfall-Modell macht dies in der Theorie einfach. Zuerst kommt eine relativ lange Phase, in der das
Fachkonzept erstellt wird. Danach kommt eine Phase der Erstellung des DV-Konzepts, anschließend wird realisiert und
danach getestet. Mit dieser Vorgehensweise kann der Personaleinsatz leicht geplant werden.
In einem iterativen Prozess stellt der schnelle Wechsel zwischen den einzelnen Aktivitäten eine echte Herausforderung
für stark arbeitsteilige Organisationen dar. Die Überlappung der einzelnen Iterationen so zu gestalten, dass alle
Beteiligten gleichmäßig ausgelastet sind, ist nicht sinnvoll. Dies würde zu einer so starken Überlappung führen, dass
keine Erfahrungen aus früheren Iterationen in den darauffolgenden Iterationen berücksichtigt werden können. Das
Lernen aus früheren Iterationen ist jedoch einer der Hauptvorteile einer iterativen Vorgehensweise.
$EE,WHUDWLRQVSODQXQJ

7
Im Pilotprojekt muss daher gelegentlich in Kauf genommen werden, dass für einzelne Mitarbeiter Zeiten entstehen, in
denen sie im Projekt nicht benötigt werden (siehe Abb. 3). Das bedeutet unter Umständen einen Umsatzverlust für die
betroffene Organisationseinheit, der von jemandem bezahlt werden muss: entweder vom Projekt oder von der
Organisationseinheit. Dieser Punkt sollte vor Beginn des Pilotprojekts geklärt werden. An dieser Stelle muss erwähnt
werden, dass die gleichmäßige Auslastung der Mitarbeiter im Wasserfall-Modell nur in der Theorie funktioniert. Die
Praxis zeigt, dass die einzelnen Aktivitäten nicht mit dem Ende der entsprechenden Phase abgeschlossen sind.
Gefundene Fehler und geänderte Anforderungen oder Randbedingungen machen die Wiederaufnahme von eigentlich
abgeschlossenen Aktivitäten erforderlich. Falls die erforderlichen Personen bereits in anderen Projekten eingesetzt sind,
muss das restliche Team warten, bis diese Mitarbeiter wieder Zeit haben.
Wenn der iterative Entwicklungsprozess im ganzen Unternehmen eingesetzt wird, ist es meist möglich, die Mitarbeiter
in den Wartezeiten in anderen Projekten einzusetzen. Besser wäre es natürlich, wenn man sich dazu entschließt,
langfristig auf eine derart starke Arbeitsteilung zu verzichten. Das hat folgende Vorteile:
• Die Arbeit wird für die einzelnen Mitarbeiter abwechslungsreicher und damit interessanter. Die Mitarbeiter sind
daher besser motiviert.
• Die Mitarbeiter machen wertvolle Erfahrungen. Wer seine entwickelten Architekturen auch selbst realisieren kann,
erlebt Fehler in der Architektur viel unmittelbarer. Entsprechend größer ist auch der Lerneffekt. Wer seine
Software auch testen muss, erfährt, welche Vorteile es hat, bei der Erstellung der Software auf Testbarkeit zu
achten. Mitarbeiter mit solchen Erfahrungen sind sehr wertvoll in zukünftigen Projekten.
• Es wird verhindert, dass gerade die besten Mitarbeiter den Bezug zur Praxis verlieren, weil sie nur noch Konzepte
erstellen müssen und nicht mehr realisieren dürfen.
Hier kann man sich ein Beispiel an anderen Branchen nehmen, wie etwa der Automobilindustrie, in denen die ehemals
vorhandene starke Arbeitsteilung inzwischen wieder aufgehoben wird.
9HUWUDJVPDQDJHPHQW
Die Gestaltung der Verträge mit Kunden und/oder Unterauftragnehmern ist ebenfalls von der Einführung eines
iterativen Vorgehens betroffen. Auch hier ist die Welt des Wasserfall-Modells scheinbar einfacher:
• Eine Firma, die nicht selbst realisiert, kann nach der Erstellung des Fachkonzepts verschiedene Angebote einholen
und das attraktivste annehmen.
• Ein Softwarehersteller wartet üblicherweise, bis das Fachkonzept fertig ist, bevor er ein Angebot abgibt oder mit
der eigentlichen Arbeit beginnt.
• Sollen Teile der Entwicklung ausgelagert werden, wird gewartet, bis das DV-Grobkonzept fertig ist. Danach sind
alle Informationen vorhanden, die ein Unterauftragnehmer benötigt, um ein Angebot abgeben zu können.
Ein OO-Prozess erkennt die Tatsache an, dass es bei einem komplexen System nicht sinnvoll ist, eine detaillierte
Spezifikation des gesamten Systems zu erstellen, bevor mit der Architektur begonnen wird. Die Vollständigkeit und
Widerspruchsfreiheit einer solchen Spezifikation kann nämlich nicht geprüft werden, solange nur Dokumente
existieren.
Dies macht die Gestaltung der Verträge allerdings komplizierter. Eine gute und faire Vertragsform wäre zum Beispiel,
die Entwurfsphase nach Aufwand abzurechnen und nach der Entwurfsphase ein Festpreisangebot zu erstellen, da zu
diesem Zeitpunkt bereits sehr viele Informationen vorliegen und eine Aufwandsabschätzung entsprechend genau sein
kann. Ein solcher Vertrag ist zwar aufwändiger, aber die Wahrscheinlichkeit, dass der Vertrag eingehalten werden
kann, ist größer.
Gelegentlich ist es schwierig, dies in die Praxis umzusetzen. Öffentliche Institutionen haben beispielsweise oft
gesetzlich geregelte Ausschreibungsverfahren, die ein detailliertes Fachkonzept zwingend erfordern. Auch hier kann
eine Lösung nur in Zusammenarbeit mit den jeweiligen Spezialisten erfolgen.
Der Aufwand lohnt sich dennoch. Gerade langfristig ausgelegte Geschäftsbeziehungen profitieren von einem OO-
Prozess. Kostenabschätzungen werden genauer und nachvollziehbarer und das Vertrauen zwischen den
Vertragspartnern wächst. In den herkömmlichen Vertragsbeziehungen kommt es dagegen oft vor, dass eine
Entwicklungsfirma genötigt wird, zu einem Zeitpunkt Preise zu nennen, zu dem dies eigentlich noch nicht möglich ist.
Hat sie sich verkalkuliert, wird versucht, die restlichen Kosten bei Änderungswünschen hereinzuholen, was wiederum
zu entsprechenden Irritationen beim Auftraggeber führt.
'XUFKI KUXQJGHV3LORWSURMHNWV
Nach diesen Vorbereitungen kann das Pilotprojekt endlich gestartet werden. In der ersten Zeit sind die
Projektmitarbeiter und der Projektleiter häufig sehr verunsichert. Besonders das Gefühl, mit einer Softwarearchitektur

8
beginnen zu müssen, bevor das System in allen Details spezifiziert ist, kann Entwicklern Probleme bereiten, die
jahrelang nach dem Wasserfall-Modell gearbeitet haben. Eine entsprechend enge Betreuung durch Personen mit
Erfahrung in der neuen Vorgehensweise, zum Beispiel durch externe Berater, ist daher erforderlich. Ein Pilotprojekt
ohne eine solche Begleitung hat kaum eine Chance, erfolgreich abgeschlossen zu werden. Die dafür notwendigen
Kosten müssen also rechtzeitig im Projektbudget eingeplant werden.
Eine vielfach unterschätzte Rolle im Pilotprojekt spielt die Informationspolitik. Pilotprojekte sollen beweisen, dass der
neue Entwicklungsprozess funktioniert. Daher werden sie meist von außenstehenden Mitarbeitern genau verfolgt. Die
Informationen, die dabei über den "kleinen Dienstweg" ausgetauscht werden, führen bei den restlichen Kollegen zu
einem ersten Eindruck von der neuen Methode. Ist der Eindruck positiv, bekommt sie einen wichtigen
Vertrauensvorschuss, ist er negativ, ist es schwer die Methode allgemein einzuführen. Ebenso wichtig ist es, dass die
direkten Vorgesetzten der Projektmitarbeiter über die neue Methode informiert sind. Nur dann werden sie die Berichte
ihrer Mitarbeiter richtig einordnen können und sich eine objektive Meinung über das Projekt bilden.
In vielen Unternehmen gibt es eine Mitarbeiterzeitung. Die Macher dieser Zeitung sind meistens dankbar, wenn sie
interessante Themen bekommen. Ihre Fähigkeiten und Erfahrungen sollten genutzt werden, um der neuen Methode und
dem Pilotprojekt eine gute Publicity zu verschaffen. Der Idealfall ist dann erreicht, wenn die Mitarbeiter, die nicht am
Pilotprojekt beteiligt sind, das Gefühl haben, dass ihnen dadurch wichtige Qualifikationsmöglichkeiten vorenthalten
werden.
Falls das Pilotprojekt scheitern sollte, was nie ausgeschlossen werden kann, wird die weitere Zukunft des neuen
Entwicklungsprozesses ganz entscheidend davon abhängen, ob die "Öffentlichkeitsarbeit" gut war oder nicht. Sogar
wenn das Projekt erfolgreich war, kann das Projektteam oder das Management unzufrieden sein, weil eine noch bessere
Qualität oder noch kürzere Entwicklungszeiten erwartet wurden. In diesem Fall wurde versäumt überzogene
Erwartungen rechtzeitig zu korrigieren. Die neue Methode ist eben kein Allheilmittel. Unrealistische Terminvorgaben,
unklare Projektziele und ständig wechselnde Anforderungen können nach wie vor zum Scheitern eines Projekts führen.
Die Produktivität wird durch einen OO-Prozess zwar deutlich steigen, aber sie wird sich nicht gleich im ersten Projekt
verdoppeln oder verdreifachen.
Eine wichtige Rolle für die erfolgreiche Einführung eines OO-Prozesses spielen die Anwender der Software oder --
falls kommerzielle Software entwickelt wird -- die Marketingabteilung. Ein OO-Prozess erlaubt es ungleich besser, die
Anwender frühzeitig in die Entwicklung einzubeziehen und mit ihnen in einer Sprache zu kommunizieren, die sie auch
verstehen können. Daher werden diese Personen den neuen Prozess entsprechend unterstützen.
Abbildung 4 zeigt noch einmal die wichtigsten externen Einflussfaktoren auf das Pilotprojekt.

9
$EE([WHUQH(LQIOXVVIDNWRUHQ
=XVDPPHQIDVVXQJ
Viele Unternehmen stellen sich nicht mehr die Frage, ob sie einen iterativen und inkrementellen Entwicklungsprozess
einsetzen sollen. Sie haben sich längst dafür entschieden und überlegen nun, wie man ihn am besten einführt. Dabei
muss beachtet werden, dass diese Aufgabe nicht nur ein fachliches Problem für Softwarespezialisten ist. Es gibt eine
Reihe anderer Personen, die davon betroffen sind, und es gibt etliche, eher unerwartete Probleme, auf die man stoßen
wird. Für diese Probleme gibt es keine universellen Lösungen. Wer sich von ihnen überraschen lässt, läuft Gefahr zu
scheitern. Wer sie kennt, kann sie bewältigen und die Vorteile eines modernen und leistungsfähigen
Entwicklungsprozesses ausnutzen.
/LWHUDWXU
>$PE@ S.W. Ambler, Process Patterns, Cambridge University Press / SIGS Books, 1998
>*UD@ I. Graham, B. Henderson-Sellers, H. Younessi, The OPEN Process Specification, Addison-Wesley, 1997
>.UX@ P. Kruchten, The Rational Unified Process, Addison-Wesley, 1999
>2HV@ B. Oestereich, P. Hruschka, N. Josutti, H. Kocher, H. Krasemann, M.Reinhold, Erfolgreich mit
Objektorientierung, Oldenbourg Wissenschaftsverlag, 1999