Anwendungsentwicklung in zeitrestriktiven dynamischen Projekten

1 Einleitung

Bei der klassischen gesch�ftsorientiertenEntwicklung von IT-L�sungen steht derlangfristige Gesch�ftsnutzen im Fokus.Die entstehenden IT-Systeme sind einge-bettet in die Erfordernisse des Marktesund den daraus abgeleiteten Gesch�ftszie-len einerseits und die jeweiligen Technolo-gien andererseits (siehe Bild 1). Die Filte-rung durch eine Gesch�ftsanalyse, das sichdaraus ergebende IT-Projekt und die Ein-f�hrung und Weiterentwicklung des Sys-tems im Betrieb bilden insgesamt einenkontinuierlichen Verbesserungsprozess.Nach der Einf�hrung des Systems unter-st�tzt sein Betrieb das Gesch�ft und f�hrtunter Umst�nden zur Festlegung neuer IT-Projekte.

Die Projekte in diesem klassischenKontext zeichnen sich durch hohe Pla-nungssicherheit und Qualit�t aus, setzenaber weitgehend stabile und bekannte An-forderungen voraus.

Im Gegensatz zu den bisherigen Pro-jekten der Anwendungsentwicklungzeichnen sich heutige Projekte oft durchenge Zeitrestriktionen und unklare bzw.sich �ndernde Anforderungen aus. Diewichtigste Forderung ist oft eine kurzfris-tige Verf�gbarkeit des Systems f�r die Er-langung eines nachhaltigen Vorteils amMarkt und im Wettbewerb (Time to Mar-ket). Kann diese Forderung nicht erf�lltwerden, ist unter Umst�nden das gesamteGesch�ft hinf�llig. Diese Projekte k�nnenmit klassischen Vorgehensmodellen nicht

abgewickelt werden. Deshalb ist ein Vor-gehensmodell erforderlich, das die Beson-derheiten von zeitrestriktiven Projektenber�cksichtigt und den Erstellungsprozesshinsichtlich Nutzen des Systems undQua-lit�tsanforderungen optimal unterst�tzt.

Im Weiteren beschreiben wir ein Vor-gehensmodell f�r zeitrestriktive Projekte.Es wurde entwickelt von Bertelsmann me-diaSystems, dem IT-Systemhaus der Ber-telsmann AG. Zun�chst stellen wir einklassisches Vorgehensmodell vor, welchesals Basismodell dient. Danach erl�uternwir die Wesensmerkmale zeitrestriktiverProjekte. Anschließend beschreiben wirausf�hrlich das vorgeschlagene Modellund setzen uns dabei auch mit konkurrie-renden Ans�tzen auseinander. Im Ab-schnitt 5 schildern wir ein Beispiel aus derPraxis, bevor der Artikel zusammengefasstwird.

2 Basismodell

Das vorgeschlagene Vorgehensmodell f�rzeitrestriktive Projekte basiert auf einemerprobten Modell zur prozessorientiertenEntwicklung von IT-Systemen (siehe[Stei00]). Dieses Modell strukturiert den

IT-Entwicklungsprozess in den Kernpro-zess, den F�hrungsprozess und in die un-terst�tzenden Prozesse, die so genanntenSupportprozesse (siehe Bild 2).

2.1 Kernprozess

Der Kernprozess der Systementwicklunggliedert sich in die folgenden sechs Phasen.

Gesch�ftsanalyse: Die Aufgabe der Ge-sch�ftsanalyse ist nach der Analyse der Ge-sch�ftsfelder, der St�rken und Schw�chendes Gesch�fts und der Gesch�ftsziele dieAbleitung von Anforderungen an die Or-ganisation. Dazu geh�rt die Strukturierungund Optimierung der Gesch�ftsprozesse.Auf dieser Grundlage werden notwendigeIT-Projekte – oder auch Projekte zur Or-

Dr. Hans Brandt-Pook, Dr. BerndKorzen, Privatdozent Dr. JoachimBoidol, Bertelsmann media Systems,An der Autobahn, D-33311G�tersloh,E-Mail: {Hans.Brandt-Pook|Bernd.Korzen|Joachim.Boidol}@Bertelsmann.de;Hauke Peyn, e-trendMedia ConsultingGmbH,Herforder Str. 74, D-33602 Bie-lefeld, E-Mail: [email protected]

Anwendungsentwicklungin zei t rest r ik t i ven

dynamischen Projek ten

Hans Brandt-Pook, Bernd Korzen,Joachim Boidol, Hauke Peyn

IT-Projekt

FilterEin-

führung

Markt

Technologie

Ges

chäf

tsan

alys

e

Betrieb

Geschäft

Kontinuierlicher

Verbesserungsprozess

Bild 1 IT-Entwicklung im Gesch�ftskontext

WI – Aufsatz

WIRTSCHAFTSINFORMATIK 43 (2001) 3, S. 247–254 247

ganisationsentwicklung – identifiziert undbewertet. Den Abschluss bildet ein Con-trolling, welches �ber die Durchf�hrungder notwendigen Projekte entscheidet.

Konzeption: Das erstrangige Ziel derKonzeptionsphase besteht in der Defini-tion des Leistungsumfangs des IT-Sys-tems. In [Stei00] werden vor allem Pro-zesshierarchiediagramme, Prozesskettennach Allen [Alle98] und die aus der Uni-fied Modeling Language UML [Booc99]bekannten Use Cases als methodischeVerfahren zur Vereinbarung des fachli-chen Konzeptes vorgeschlagen. Davonausgehend werden m�gliche L�sungs-alternativen f�r das IT-System (bspw. In-dividualentwicklung vs. L�sung mit Stan-dardsoftware) erarbeitet, bewertet undschließlich eine L�sungsvariante aus-gew�hlt. Die exakte Definition des Leis-tungsumfangs und der Abnahmekriterienbilden letztlich die Grundlage f�r die Er-teilung des Entwicklungsauftrags, die denAbschluss dieser Phase markiert.

Design: In der Designphase werden dieSoft- und Hardwarearchitektur des Sys-tems detailliert spezifiziert. Es wird dieEntwicklung einer modernen, komponen-tenorientierten Mehrschichtenarchitekturvorgeschlagen. Methodisch werden die inder Konzeptionsphase erarbeiteten UseCases verfeinert und um Sequenzdiagram-me erg�nzt. Darauf aufbauend werden dieben�tigten Komponenten identifiziert undspezifiziert. Es wird eine Wiederverwen-dung bestehender Komponenten ange-strebt. Die neu zu entwickelnden Kom-ponenten sind in ihrer Struktur und Archi-

tektur zu entwerfen. Dabei m�ssen sowohlfachliche als auch technische Aspekte be-r�cksichtigt werden.

Design- und Konzeptionsphase stehenin einem engen Zusammenhang. Oft erge-ben sich w�hrend des Designs Fragen, dieeine �berarbeitung der Konzeption erfor-derlich machen. Das Basismodell ist alsonicht strikt dem Wasserfallmodell nachBoehm angelehnt [Boeh76], sondern hatiterativen Charakter.

Realisierung: Die Phase Realisierungumfasst die Implementierung der Kom-ponenten und deren Integration zuTeilsys-temen, die ihrerseits zu demGesamtsystemaggregiert werden. ImErgebnis dieser Pha-se liegt ein lauff�higes und getestetes Sys-tem in vollemFunktionsumfang vor.

Einf�hrung:Die n�chste Phase beinhal-tet die Abnahme und Einf�hrung des IT-Systems beim Auftraggeber. Zun�chst istdas abgelieferte System anhand der defi-nierten Abnahmekriterien zu �berpr�fen.Dazu bedarf es einer Testumgebung, dieTests zur fachlichen Korrektheit des Sys-tems aus der Auftraggebersicht erm�gli-chen. Der Abnahme des Systems folgt dieEinf�hrung in engeren Sinn, die mit einerumfassenden Planung der Ressourcen ver-bunden ist. Zur Phase Einf�hrung geh�rtauch das Training der Anwenderinnen undAnwender, deren Sicherheit im Umgangmit dem System f�r eine allgemeine Ak-zeptanz unumg�nglich ist.

Betrieb: Aus Sicht der Anwendungs-entwicklung stellt die Wartung und Wei-terentwicklung des Systems die Hauptauf-gabe w�hrend des Betriebs des IT-Sys-

tems. Dazu ist eine Betriebs- und War-tungsumgebung zu erstellen, die u. a. einVersions- und Konfigurationsmanage-ment sowie ein Releasekonzept unter-st�tzt.

2.2 F�hrungsprozess

Zum F�hrungsprozess geh�rt die Abwick-lung des Projektes durch das Projektmana-gement. Er vollzieht sich in den vier Tei-laufgaben Projektinitialisierung, Projekt-planung, Projektf�hrung und -steuerungund Projektabschluss. Die Projektinitiali-sierung legt den Rahmen des Projektesfest, z. B. Ziele, Organisation und Meilen-steine. Auf dieser Basis wird die Durch-f�hrung des Projektes vorgenommen, inder die Projektplanung, Initialisierung vonAktivit�ten, �berpr�fung der Ergebnisseund anschließende Neuplanung einen Re-gelkreislauf bilden.

Das Projektmanagement wird begleitetvomQualit�tsmanagement, in dem die we-sentlichen Qualit�tsziele definiert und�berwacht werden. Es stellt innerhalb desF�hrungsprozesses Hilfsmittel f�r die�berpr�fung des Prozessverlaufes und dererzielten Ergebnisse zur Verf�gung. Dazugeh�rt die Definition der Qualit�tsvor-gaben sowie die Bereitstellung der Metho-den zur �berpr�fung der Qualit�t. Einwesentlicher Aspekt ist die Sicherstellungder Qualit�t des Gesamtprozesses, sodassKern-, F�hrungs- und Supportprozessevorab definierten Qualit�tskriterien gen�-gen.

2.3 Supportprozesse

Supportprozesse sind unterst�tzende T�-tigkeiten in den jeweiligen Projekten, f�rdie oftmals von außerhalb der Projekt-organisation Ressourcen zur Verf�gunggestellt werden. Vielf�ltige Kompetenzenstehen in der eigenen Organisation oderamMarkt zur Verf�gung und k�nnen nachBedarf des Projektes eingesetzt werden.Dazu z�hlen insbesondere

, die methodische Unterst�tzung zurFestlegung einer einheitlichen Vor-gehensweise aller Beteiligten im Pro-jekt,

, die Bereitstellung eines Versions- undKonfigurationsmanagements zur Absi-cherung einer kontrollierten Entwick-lung des Systems,

Support-

prozesseSupportprozesse

Führungs-

prozessProjektmanagement / Qualitätsmanagement

Kern-

prozess

Geschäfts-

analyseKonzeption Design

Reali-

sierungEinführung Betrieb

Methoden und

Verfahren

Trainings-

organisation

Versions- und

Konfigurations-

management

Qualitäts- und

Testorganisation

Bild 2 IT-Projektprozesse im Basis-Vorgehensmodell

Hans Brandt-Pook, Bernd Korzen, Joachim Boidol, Hauke Peyn

248

, die Unterst�tzung des Testens in allenPhasen der Anwendungsentwicklungsowie

, das Training der Anwender.

Das in [Stei00] vorgestellte Verfahren stelltein generelles Vorgehensmodell f�r die ge-sch�ftsorientierte Anwendungsentwick-lung dar. Es stellt die prozessorientierteGestaltung bei der IT-Systementwicklungin den Vordergrund. In klassischen Projek-ten wird dadurch die Teamorganisationh�ufig durch die Struktur der Aktivit�tenbestimmt sein. Es entstehen Teams zu deneinzelnen Phasen. Dadurch wird schritt-weises, systematisches Arbeiten unter-st�tzt und Spezialistentum gef�rdert. Al-lerdings entsteht trotz einer durchg�ngigenMethodik an den Phasen�berg�ngen Ab-stimmungs- und Koordinationsaufwand,der den Fortgang des Projektes zeitlichverz�gern kann. R�ckspr�nge bei sich �n-dernden Anforderungen sind aufwendig,eine inkrementelle und parallelisierte Ent-wicklungsarbeit wird nur eingeschr�nktunterst�tzt. Aus diesem Grund muss dasVorgehensmodell auch in besonderer Wei-se angepasst werden f�r solche Projekte, indenen der Zeitfaktor und die Reaktions-f�higkeit das entscheidende Kriterium f�rErfolg oder Misserfolg des Projektes sind.Bevor wir das angepasste Vorgehens-modell vorstellen, m�chten wir noch etwasn�her auf die Wesensmerkmale zeitrestrik-tiver Projekte eingehen.

3 Wesensmerkmalezeitrestriktiver Projekte

Wir sehen folgende wesentliche Merkmalezeitrestriktiver Projekte, die sie deutlichvon klassischen Projekten unterscheiden:

Sehr kurze Entwicklungszeit: Zeitres-triktive Projekte sind durch einen Ge-sch�ftserfolg motiviert, der ausschließlichkurzfristig zu erzielen ist. Der Zeitpunktder Einf�hrung des Systems entscheidetdar�ber, ob die Gesch�ftsidee �berhauptrealisiert werden kann. Insbesondere imE-Business ist es ein unsch�tzbarer Vorteil,als erster Anbieter eine Idee umgesetzt zuhaben. Es ergibt sich also als erstes We-sensmerkmal zeitrestriktiver Projekte dieAnforderung an eine sehr kurze Entwick-lungszeit (drei bis vier Monate) und einstriktes Time-Box-Planing.

Variierende Anforderungen: Wir erle-ben heutzutage das Entstehen von Bedar-fen, die sich so schnell entwickeln, dass miteinem klassischen Herangehen an die An-wendungsentwicklung nach Fertigstellungdes Systems der Bedarf schon wieder eineg�nzlich andere Gestalt angenommen hat.W�hrend also bei klassischen Projektendie Anforderungsanalyse vergleichsweisestatisch ist, ist es f�r zeitrestriktive Projek-te typisch, dass sich die Anforderungen andas IT-System im Laufe des Projektesmehrfach �ndern.

Zyklische Weiterentwicklung: Die sich�ndernden Anforderungen setzen sichauch w�hrend des Betriebs des Systemsfort. Somit ergibt sich die Herausforde-rung des online engineering, also der steti-gen Weiterentwicklung und Erg�nzungdes Systems. Das System wird zyklisch�berarbeitet und reinstalliert, um den neu-en Erfordernissen gerecht zu werden. Oftmuss dies in einem weltweit laufenden24-Stunden-Betrieb des Systems gesche-hen – ohne die fr�her �blichen Wartungs-fenster.

Wegen der strengen zeitlichen Vor-gaben k�nnen zentrale Elemente der klas-sischen Anwendungsentwicklung wiegrundlegende Gesch�ftsmodellierung,Optimierung der Gesch�ftsabl�ufe und�nderung derOrganisation nicht Bestand-teil des Projektes im engeren Sinne sein.Vielmehr m�ssen diese wichtigen Grund-lagen bereits im Vorhinein explizit ge-schaffen werden oder im Zuge einer kon-

tinuierlichen Weiterentwicklung der Ge-sch�ftsstrategie pr�sent sein. Das gleichegilt f�r die methodischen und technischenRahmenbedingungen. Sie k�nnen nichtw�hrend des Projektes erarbeitet werden,sondern m�ssen im Vorfeld entwickeltworden sein und geben dem Projekt somiteinen organisatorischenHalt.

Zeitkritische Projekte sind dynamischeProjekte, die ein �ußerst flexibles Zeit- undZielmanagement aber auch einen festenRahmen, bestehend aus einer strategischenGesch�ftsmodellierung und soliden Me-thoden und Techniken, ben�tigen, um denProjekterfolg sicher zu stellen. Das Fehleneines solchen Rahmens l�sst offen, ob einProjekt zum Erfolg des Gesch�fts beitr�gtoder das Projekt durch seine eigene Dyna-mik ins Abseits treibt und somit f�r denErfolg des Gesamtgesch�fts bedeutungslosbleibt. Innerhalb dieses Rahmens jedochmuss eine hohe Flexibilit�t und Reaktions-f�higkeit gew�hrleistet sein, um den dyna-mischen Projektanforderungen zu gen�-gen.

4 Vorgehensmodellf�r zeitrestriktive Projekte

Die Aufgabe von Vorgehensmodellen be-steht darin, ein abgestimmtes Vorgehen al-ler Beteiligten zu sichern und dadurch denProzess der Softwareentwicklung optimal

Kernpunkte f�r dasManagement

Es wird ein Vorgehensmodell f�r die Fertigstellung eines IT-Systems zu einemgesch�ftskritischen Termin vorgestellt. Es basiert auf einem bereits etabliertenVorgehensmodell., Es erfolgt die Erg�nzung einer prozessorientierten Sichtweise auf die

Anwendungsentwicklung um eine produktorientierte Entwicklung., Zeitrestriktive Projekte k�nnen schnell, flexibel aber dennoch kontrolliert

abgewickelt werden. Eine Variation des Ergebnisses und der Systemleistungist stets m�glich.

, Risiken und Herausforderungen an das Projektmanagement werdenbenannt.

, Ein umfangreiches Beispiel aus der Praxis belegt das Modell.

Stichworte: Vorgehensmodell, zeitrestriktive Projekte, Anwendungsentwick-lung, dynamische Projekte

Anwendungsentwicklung in zeitrestriktiven dynamischen Projekten

249

zu unterst�tzen. Es ist stets ein Konsens�ber Ziele und Ergebnisse sowie Aufgabenund Verfahren herzustellen. Das Modellsollte dynamisch anpassbar, aber dennochstrukturell stabil sein. Diese Anforderun-gen gelten in gleichemMaße f�r große undkleine, klassische und zeitrestriktive Pro-jekte, wenn auch nach Art des Projektes je-weils andereModelle vorzuziehen sind.

4.1 Extreme Programming undRapid Application DevelopmentSpeziell f�r solche Projekte, die auch We-sensmerkmale zeitrestriktiver Projekte tra-gen, wurde Extreme Programming (XP)entwickelt [Beck99]. Durch die Konzen-tration auf einige (im Grunde bekannte)Techniken und deren extreme Optimie-rung kann insbesondere wechselnden An-forderungen an das Projekt gut begegnetwerden. XP formuliert eine Reihe von Vo-raussetzungen an seinen Einsatz, u. a. dieFolgenden:

, Das Entwicklerteam sollte aus maximal15 Personen bestehen. Es ist an einemOrt zu zentrieren und die Arbeitszeitenm�ssen synchronisiert sein.

, Ein qualifizierter Mitarbeiter des Auf-traggebers des Projektes ist voll f�r dasEntwicklerteam abzustellen.

, Das Testverfahren muss automatisiertund stets unmittelbar durchf�hrbar sein.

In [Reiß00] wird u. a. auf folgende Nach-teile von XP verwiesen:

, Das Fehlen einer expliziten Spezifika-tion und Entwurfsdokumentation desProjektes.

, Die mangelnde Dokumentation derMethode XP selbst.

In unserer Praxis kann insbesondere dasKriterium der lokalen und synchronenVerf�gbarkeit aller Entwicklerinnen undEntwickler immer weniger gew�hrleistetwerden. Wir m�ssen vielmehr h�ufig dieErgebnisse verteilt arbeitender Teams zu-sammenf�hren. Als weiterenMangel sehenwir, dass XP nicht skalierbar oder an beste-hende Vorgehensmodelle angebunden ist.Da XP nicht f�r alle Projekttypen geeignetist, m�ssten in einem Unternehmen folg-lich mehrere Vorgehensmodelle einge-f�hrt, geschult und gepflegt werden. InZuge eines einheitlichen Herangehens andie Softwareentwicklung erscheint es unseher sinnvoll, nur ein Basis-Vorgehens-modell zu etablieren und durch die Ent-wicklung verschiedener Auspr�gungen alleProjektarten abzudecken. Dies erleichtertauch die Rotation von Mitarbeitern zwi-schen den verschiedenen Projekten undstellt von vornherein einen Grundkonsenszwischen den Mitliedern der oft sehr hete-rogen und dynamisch zusammengesetztenProjektteams sicher.

Mit dem Begriff Rapid Application De-velopment (RAD), der auf Martin[Mart91] zur�ckgeht, wird im Allgemei-nen nicht ein geschlossenes Modell ver-bunden. Vielmehr werden darunter ver-schiedene Techniken wie Time-Box-Sche-duling, Rapid Prototyping, inkrementelleEntwicklung usw. zusammengefasst, wel-che die Entwicklung eines Vorgehens-modells f�r zeitrestriktive Projekte zwarbefruchten, aber nicht ersetzen k�nnen.

4.2 Vorgehensmodellbasierend auf Steinweg

�hnlich wie beim Extreme Progammingk�nnen auch bei dem vorgeschlagenenModell die Voraussetzungen f�r seine Ein-setzbarkeit exakt benannt werden:

, Der Auftragnehmer muss Kenntnisseund Erfahrungen auf dem zu bearbei-tenden Gebiet, sowohl aus Gesch�fts-als auch aus technologischer Sicht besit-zen. Eine lange Einarbeitungszeit in diegrundlegende Aufgabenstellung, dieBranche oder in die Technologie ist ineinem kurzlebigen Projekt unm�glich.

, Es muss L�sungen oder sogar fertigeKomponenten, insbesondere fachlicheBasiskomponenten, mindestens zu eini-gen der Problemstellungen geben. Da-r�ber hinaus m�ssen eine Entwick-lungsumgebung sowie klare, erprobteund akzeptierte Regeln zur Umsetzung(Designregeln) beim Auftragnehmeretabliert sein.

, Eine intensive Interaktion mit demAuftraggeber ist unabdingbar, um eineschnelle und qualifizierte Kommunika-tion der Anforderungs�nderungen si-cher zu stellen. Es muss stets ein Kon-sens erzielbar sein �ber eine Ergebnis-variation unter den Restriktionsdimen-sionen Zeit, Kosten und gesch�ftskriti-scher Leistungsumfang des Systems.Allerdings werden im Unterschied zumExtreme Programming keine Restrik-tionen bez�glich der konkreten Aus-gestaltung der Interaktion gemacht.

, Es muss einen Konsens zwischen Auf-traggeber und -nehmer �ber die An-wendung des Vorgehensmodells undder zu erbringenden Qualit�t geben,um einen Verfahrensstreit w�hrend derknappen Entwicklungszeit zu vermei-den.

Sollten diese Voraussetzungen nicht gege-ben sein, birgt die Anwendung des Mo-dells entsprechend hohe Risiken.

Das Vorgehensmodell (siehe Bild 3) ba-siert auf der Phaseneinteilung des Basis-modells. F�r den kritischen Projektstartwerden die notwendigen Aufgaben aus derPhase Konzeption und des F�hrungspro-zesses in einem Block zusammengefasstund erg�nzt um grundlegende Resultateaus der Gesch�ftsanalyse. Dieser Auf-gabenblock dient dazu, ein gemeinsamesBild aller Beteiligten �ber das zu realisie-

Gemeinsames Bild

über das System, seine

Struktur und

den Projektverlauf

erarbeiten

S

Y

S

T

E

M

K 5

K 4

K 3

K 1

K 2

K 6

R 1

V 3 R 3

R 6

R 4

V 1

Auftrag

KickOff

Konzeptio

n

Scoping

Visualis

ierung

Realisieru

ng

Einführung

Bild 3 �bersicht zum Vorgehensmodell f�r zeitrestriktive Projekte


250

rende Gesamtsystem herzustellen und des-sen Struktur zu verstehen.

Bei der initialen Kl�rung des Auftragsdes Projektes werden die Ziele, Rahmen-bedingungen und eine grobe Organisationf�r das Projekt zwischen Auftraggeberund Auftragnehmer vereinbart. Dazu z�h-len typischerweise die Benennung einesStart- und Endtermins, der konkretenAufgabenstellung und des Budgets. Es istwichtig, eine Priorisierung bzgl. der Zieleeinzuf�hren, um nach der Strukturierungdes Gesamtsystems aufgrund der striktenzeitlichen Begrenzung ggf. eine inkremen-telle Entwicklung zu erm�glichen unddennoch das System rechtzeitig in Produk-tion nehmen zu k�nnen, selbst wenn nochnicht alle gew�nschten Leistungen reali-siert sind.

Auf dem KickOff-Workshop legen dieProjektbeteiligten den Projektverlauf(Vorgehen, Meilensteine) und die internenKommunikationsregeln f�r das Projektfest. Auf Grundlage der im Auftrag fest-gehaltenen Ziele werden die wichtigstenRollen und Gremien benannt und besetzt,wie bspw. Auftraggeber, Auftragnehmer,Controlboard, Projektleiter und soweitwie m�glich auch schon das Projektteam.Eine Analyse der kritischen Erfolgsfak-toren des Projektes dient dazu, die gr�ßtenRisiken zu erkennen und Maßnahmen zuihrer Begrenzung einzuplanen (siehe z. B.[Schl00]).

Das Scoping vervollst�ndigt schließlichdie Erarbeitung einer gemeinsamen Sichtauf das System. Die z�gige Erarbeitung ei-nes – in der Regel sehr engen – Fokus desProjektes durch Auftragnehmer und Auf-traggeber ist eine obligatorische Voraus-setzung, um einen kurzfristigenGesch�fts-erfolg herbeizuf�hren. Im Scoping werdenmit Hilfe einer groben Prozessbeschrei-bung und von Kontextdiagrammen [De-Ma76] die wesentlichen fachlichen Aspek-te der Problemstellung bzw. des Systemsabgebildet. Dadurch erfolgt eine klare Ab-grenzung dessen, was zum Leistungs-umfang des Systems geh�rt und welcheAnforderungen nicht unterst�tzt werden.

In der Konzeption erfolgt dann dieGliederung des zu erstellenden Systems inTeilsysteme bzw. Komponenten, in Bild 3mit K1 bis K6 symbolisiert. Ziel diesermodularen Architektur ist es, das Systemderart zu zerlegen, dass eine weitgehendunabh�ngige Realisierung je Komponentebzw. Wiederverwendung existierenderKomponenten erm�glicht wird. Mit der

Konzeption dieser Einzelbausteine k�n-nen die funktionalen und nichtfunktiona-len Anforderungen weitgehend unabh�n-gig voneinander weiter detailliert und ver-standen werden. Falls erforderlich werdendabei dieselben Techniken wie im Basis-modell verwandt (Prozesshierarchien,Prozessketten, Use Cases). Die zweite we-sentliche Aufgabe dieser Phase ist die Ent-wicklung einer der Komponentenstrukturentsprechenden Systemkonfiguration so-wie deren �berpr�fung auf MachbarkeitundWirtschaftlichkeit.

F�r den Erfolg des methodischen An-satzes ist die Modularisierung in der kon-zeptionellen Phase entscheidend. NachAbschluss der Konzeption ist die Produkt-struktur des Systems identifiziert. Die an-schließenden Phasen werden nicht strengaufeinander abfolgend abgewickelt, son-dern k�nnen aufgrund der streng modula-ren Projektstruktur der Situation und denPriorit�ten entsprechend (z. B. zeitver-schoben oder parallel) je Thema durch-gef�hrt werden. Nach Absprache mit demKunden k�nnen auch einzelne Bausteineg�nzlich gestrichen und damit der Leis-tungsumfang des Systems w�hrend desProjektes kontrolliert eingeschr�nkt wer-den. Damit die Projektstrategie umgesetztwerden kann, muss auch die Software-architektur das Modularisierungsparadig-ma erf�llen. Das ist in diesem Zusammen-hang der Grund f�r die besondere Eignungkomponentenbasierter Ans�tze.

Die Visualisierung, bspw. in Form einesPrototyping, wird f�r solche Komponen-ten eingesetzt, f�r die es abschließendenKl�rungsbedarf zwischen Auftraggeberund Auftragnehmer bez�glich der Funk-tionalit�t und deren Ausgestaltung gibt.Die Anforderungen werden erst durch dieUmsetzung erkannt – im Bild 3 ist die Vi-sualisierung zweier Komponenten durchV1 und V3 abgebildet.

Die einzelnen Einheiten werden – jenach ihrer Abh�ngigkeit untereinanderund ihrer Priorisierung – parallel oder suk-zessive in der Realisierung umgesetzt, ge-testet und dokumentiert. Als Ganzesgleichzeitig oder auch stufenweise werdensie abgenommen und f�r die Einf�hrungfreigegeben. Bild 3 deutet an, dass es auchm�glich – sogar sehr erstrebenswert ist –bereits realisierte Komponenten zu ver-wenden. Daher finden sich f�r K2 und K5keine Realisierungsaktivit�ten, sonderndiese k�nnen sofort integriert werden.Gleichzeitig verdeutlicht Bild 3, dass die

Modularit�t des Systems sich bis auf dietechnische Realisierung niederschl�gt.

In der Einf�hrung werden die Kompo-nenten zu einem Gesamtsystem integriertund die Integrationstests durchgef�hrt.Durch die fr�hzeitige Einbeziehung dersp�teren Anwender in die Testphase kanneine zeitnahe Ausbildung und ein schnellerProduktivstart erreicht werden. Die Inte-gration in bestehende Altsysteme kann jenach Projekt eine anspruchsvolle und auf-wendige T�tigkeit sein, die in dieser ab-schließenden Phase zu erledigen ist.

Das vorgestellte Vorgehensmodell f�rzeitrestriktive Projekte ist eine spezielleAuspr�gung des in [Stei00] erarbeitetenModells. Durch die bedarfsweise Nutzungder dort etablierten Methoden und Tech-niken und eine leichte Umstrukturierungder Phasen kann den strikten Anforderun-gen an die Entwicklungszeit und der Dy-namik der Anforderungen angemessen be-gegnet werden. Eine schnelle, flexible aberdennoch kontrollierte Abwicklung einesProjektes wird unterst�tzt. Durch die�berschaubarkeit des Verfahrens l�sst essich auf der Grundlage des Basismodellsleicht kommunizieren.

In der von Mellis dargelegten Kategori-sierung (siehe [Mell00]) vollzieht sich mitder vorgestellten Auspr�gung des Basis-modells die Ver�nderung eines prozessori-entierten Modells zu einer produktorien-tierten Entwicklungsweise.

4.3 Vorteile, Risikenund eine neue Sichtauf das Projektmanagement

Die Eigenschaften und Vorgehensweisendes vorgeschlagenen Verfahrens, die seinenpraktischen Einsatz in zeitrestriktiven unddynamischen Projekten empfehlen, k�n-nen wie folgt zusammengefasst werden:

, Das Modell hat einen bew�hrten Hin-tergrund. Es ist abgeleitet aus einemumfassenden Basismodell, das ein klarprozess- und ergebnisorientiertes Pha-senmodell sowie einen erprobten Fun-dus an Modellierungstechniken bein-haltet.

, Die modulare Architektur erm�glichtein sehr flexibles Zeitmanagement desProjektes, was zu einer Beschleunigungdes Entwicklungsprozesses f�hrt.

, Wechselnde Kundenanforderungen las-sen sich durch die produktorientierte


251

Entwicklungsweise unmittelbar in denEntwicklungsprozess einf�gen undk�nnen somit optimal unterst�tzt wer-den.

Das Verfahren birgt einige Risikofaktoren,die bei einer Entscheidung �ber seinenEinsatz ber�cksichtigt werdenm�ssen:

, Wird das Verfahren trotz nicht gegebe-ner Voraussetzungen angewendet, be-steht die akute Gefahr des Scheiterns.Dies gilt insbesondere bei mangelnderErfahrung des Auftragnehmers in demProblemfeld oder fehlender Entwick-lungsumgebungen und -methoden.Schließlich wird mangelhafte Koope-ration unter den Beteiligten das Verfah-ren scheitern lassen.

, Kritischer Faktor ist die fachgerechteStrukturierung des Systems in Kom-ponenten. Hierzu ist sowohl die Kennt-nis �ber das zu unterst�tzende Gesch�ftals auch technologisches Know-howunabdingbar, wie sie typischerweise inder Rolle eines Softwarearchitektenvereint ist. Es muss insbesondere sicher-gestellt sein, dass eine durchg�ngigeUnterst�tzung der Gesch�ftsprozessegew�hrleistet ist.

, Durch die Zuspitzung auf das jeweiligeProjekt wird die Entwicklung von wie-derverwendbaren Komponenten nichtexplizit unterst�tzt. F�hrt man alsoausschließlich solche Projekte durch,wird man nicht zu einem Fundus vonwieder einsetzbaren Komponentenkommen. Auch der Designprozess wirdimplizit abgewickelt und liefert daherselten wiederverwendbare Ergebnisse.

, Es besteht die Gefahr von Insell�sun-gen, wenn das erarbeitete System nichtin eine Gesch�ftsstrategie und dazuge-h�rige IT-Strategie eingebettet ist. ImExtremfall kann sogar eine m�glicher-weise dringend anstehende umfassendeGesch�ftsanalyse mit einer einher-gehenden Gesch�ftsprozessoptimie-rung durch eine schnelle L�sung hi-nausgez�gert werden.

Wird der Gedanke der dynamischen Pro-jekte konsequent weitergef�hrt, ergibt sicheine v�llig neue Sichtweise auf das Wesenvon Projekten. Sie haben in diesem Bildkein festes Ziel mehr, sondern einen Ziel-raum, der zu Beginn des Projektes nur grobumrissen werden kann. Fixe Gr�ßen sinddagegen das Budget und der Zeitrahmen.Erst im Laufe des Projektes sch�lt sich im

Konsens zwischen Auftraggeber und Auf-tragnehmer das Ziel klarer heraus. Dabeinavigieren sie im Zielraum. Der eigentlicheZielpunkt und Nutzen des Projektes f�rdas Gesch�ft kann daher auch erst nachAbschluss des Projektes pr�zise bestimmtwerden.W�hrend des Projektes stehen denBeteiligten einerseits bekannte Methodenzur Verf�gung, die dynamisch ausgew�hltund eingesetzt werden, um den offenenProjektprozess optimal zu unterst�tzen.Anderseits haben sie durch die produktori-entierte Struktur eine Leitlinie, welche dieAuswahl der Methoden unterst�tzt undein sinnvollesNavigieren erm�glicht.

Große Herausforderungen stellt dasvorgestellte Modell – insbesondere in dersoeben vorgestellten extremen Betrach-tungsweise – an das Projektmanagement.Im Unterschied zum Basismodell, in demw�hrend des Entwicklungsprozesses aufdie jeweiligen Phasen fokussiert wird, isthier stets der ganze Entwicklungszyklusim Auge zu behalten. Die Teamstruktur imProjekt bildet eher die Systemstruktur undnicht die Aufgabenstruktur ab: w�hrendim Basismodell die Aufgaben Konzeption,Design usw. von separaten Teams bew�l-tigt werden k�nnen, bilden sich in zeitres-triktiven Projekten tendenziell Experten-teams zur Bereitstellung eines Systemteilsvon Entwurf bis zur Abnahme. Dadurchwird zwar �ber ganzheitliche Beitr�ge eineh�here Motivation der Mitarbeiter er-reicht, es ist jedoch ein intensiver Kom-munikationsaufwand zwischen den Teamsbez�glich des Zusammenspiels der Kom-ponenten notwendig. Dies kann nur �berkurze Synchronisationszyklen seitens desProjektmanagements erreicht werden. Da-mit wird Projektleitung zu einer echtenF�hrungsaufgabe, da kontinuierlich Ent-scheidungen zu treffen und �bergangs-situationen zumanagen sind. Dies hat auchnachhaltige Auswirkungen auf BerufsbildundQualifizierung des Projektleiters.

International operierende Unterneh-men wie Bertelsmann mediaSystems ste-hen zunehmend vor der Herausforderungverteilter zeitrestriktiver Projekte. DieAnforderungen an das Projektmanage-ment werden dadurch versch�rft, dass diebeteiligten Entwicklerteams an unter-schiedlichen Orten und in der Regel nichtidentischen Entwicklungsumgebungen t�-tig sind. Dadurch wird sowohl die Organi-sation der Kommunikation unter den Pro-jektmitgliedern also auch zwischen dentechnischen Bausteinen erschwert.

In der Erarbeitung von Projektmanage-mentstrategien ergeben sich u. a. Ankn�p-fungspunkte zudemvonHesse vorgeschla-genen Projektmanagement [Hess98]. Dortwird einerseits eine große Flexibilit�t beider Baustein-orientierten Entwicklung un-terst�tzt, andererseits aber stets eine Zu-sammenf�hrung des Projektes an so ge-nannten Revisionspunkten erreicht. Die�berlegungen von Hesse zum Projektma-nagement belegen exemplarisch, dass dieseFrage theoretisch sehr gut verstanden ist.Allerdings fehlt es an praktischen Erfah-rungen. Eine geschlossene praxisnahe L�-sung f�r das Projektmanagement dyna-mischer Projekte sowie deren tats�chlicherund signifikanter �berpr�fung und Wei-terentwicklung in der Praxis ist daher eineAufgabe, die noch zu l�sen ist.

5 Ein Beispiel aus der Praxis:„Regionaler Online-Dienst“

5.1 Das ProjektDieHerausforderung bestand darin, f�r ei-ne Zeitungsgruppe mit elf Lokalausgabenund einer Auflage von ca. 1,4 Mio. Exem-plaren einen internetbasierten, regionalenOnline-Dienst im gesamten Verbreitungs-gebiet der Zeitung aufzusetzen. Die visio-n�re Grundidee „Das Leben spielt sich inder Stadt ab, nicht in der Welt“ definierteaus Gesch�ftssicht das Ziel der „Stadt imNetz“ mit lokalen Informationen rund umdie Uhr, lokalem Service ohne Laden-schluss und Kontakten in der Stadt undder Region. Zus�tzlich wurde damit deroffene Markt einer lokalen „Zeitungsaus-gabe im Internet“ final besetzt.

5.2 Wesensmerkmale

Die Wesensmerkmale von zeitrestriktivenProjekten fanden sich in diesem Projektfast idealtypisch wieder. So wurde vomAuftraggeber eine Projektlaufzeit von nurvier Monaten zugestanden, um das Ziel,der erste imMarkt zu sein, nicht zu gef�hr-den. Variierende Anforderungen ergabensich fast von selbst, da das Internet mit sei-nem M�glichkeiten nur punktuell erfasstwurde und tiefere Erkenntnisse sofortneue Ideen nachzogen. Eine zyklischeWei-terentwicklung ergab sich allein aus der


252

Vielzahl der Anforderungen, die nicht inder ersten Version umzusetzen waren.

5.3 Anwendungdes Vorgehensmodell

Die Phase der Kl�rung des Auftrages warextrem kurz. Die vorhergehende Phase derProjektakquise betrug dagegen mehrereWochen, in denen seitens des Auftrag-gebers die Vision schrittweise Gestalt an-nahm und auf Seiten des AuftragnehmersRecherchen nach Modulen sowie Ana-lysen zur Machbarkeit durchgef�hrt wur-den. Am Ende stand ein Auftrag mit einemklaren Auftraggeber, personalisiert in derPerson des Gesch�ftsf�hrers, einem fest-stehenden Termin f�r den Launch und ei-nem Budgetrahmen. Der Auftragnehmerbeauftragte intern einen erfahrenen Pro-jektleiter mit der Projektsteuerung und-abwicklung. Das Ziel, einen geschlosse-nen Onlinedienst auf Internetbasis mit al-len Internetdiensten (Mail, News, Down-load) f�r das gesamte Verbreitungsgebietgleichzeitig aufzusetzen, erforderte einest�rkere Priorisierung. Die Anforderungeiner zentralen Redaktion mit Rund-um-die-Uhr-Betrieb sowie einem konkurrenz-losen Preismodell f�r einen offenen Zu-gang zum Internet stellten als Rahmenbe-dingungen hohe Anforderungen an die Zu-verl�ssigkeit des Systems.

Auf dem KickOff-Workshop wurdendie Teams miteinander bekannt gemacht.Neben der Aufregung an einem interes-santen Projekt mitzuarbeiten, existiertedie Spannung des Neuartigen. Als kriti-scher Erfolgsfaktor wurde u. a. die enge,intensive Kommunikation zwischen Auf-traggeber und Projektleiter erkannt. Nachdem Projektstart wuchs die Erkenntnisder Vielfalt der Aufgaben und der Kom-plexit�t des Projektes. Dies f�hrte zur Be-auftragung eines Coaches f�r den Projekt-leiter.

In einemWorkshop wurde mit Hilfe ei-nes Kontextdiagramms der Fokus des Pro-jektes gekl�rt und eingegrenzt. Eine Ein-teilung in Module und Komponenten er-schien nahezu nat�rlich. Dieser Workshopsorgte wegen der Begrenzung auf einenimmer noch großen Projektrahmen zu ei-ner st�rkeren Ausrichtung der Projektteil-nehmer auf ihre Aufgaben. Das Verst�nd-nis f�r die Situation des Kunden f�hrte zueiner hohen Identifikation der Projektmit-glieder mit dem Projekt.

F�r die Konzeption wurde das Projektin neun Arbeitspakete aufgeteilt (ContentManagement, Redaktionssystem der inter-nen Redaktion, Customer Care inklusiveAbrechnung, Integration der Print-Redak-tionen, Internetdienste, Kommunikations-und Netzwerktechnik, Nutzerverwaltungund Registrierung, Server und Rechenzen-trum, Zugangssoftware). Diese Paketekonnten weitgehend unabh�ngig von-einander und damit parallel bearbeitetwerden (siehe Bild 4). �bergeordnet wur-den der Projektmanagement- und einCoachingprozess aufgesetzt. Bei der Ein-teilung der Arbeitspakete wurden vorhan-dene Komponenten aus dem Bereich Cus-tomer Care, Server und Rechenzentrum,Kommunikations- und Netzwerktechniksowie der Zugangssoftware mit leichterModifikation wieder eingesetzt – im Bild 4sind die Realisierungen dieser Komponen-ten daher grau unterlegt. F�r einzelneKomponenten wurden Machbarkeitsstu-dien vorgenommen (Content Manage-ment, Internetdienste). Im ArbeitspaketRedaktionssystem wurden f�r die Kon-zeption Prozessketten und Use Cases ein-gesetzt. F�r die Bereiche Content Ma-nagement, Redaktionssystem und Print-Redaktion wurden Visualisierungen alsKommunikationsmittel zwischen demProjektteam und den Mitarbeitern desAuftraggebers verwendet; eine formaleSpezifikation einer Datenbank ist geradeim Bereich von Redakteuren nicht das ge-

eignete Mittel, um eine Abnahme zu erzie-len.

W�hrend der Realisierung stellte sichf�r ein Arbeitspaket (Abrechnung) heraus,dass die Test- und Integrationsphase l�ngerwar als urspr�nglich geplant. Aus diesemGrund wurde diese Komponenten erstsp�ter in das Gesamtsystem integriert.Dies war m�glich, da die vorgelagerteKomponente der Nutzerverwaltung undRegistrierung zeitgerecht fertig war.

5.4 Risiken und ErfolgsfaktorenDie Projektleitung und das Projektteamsah sich einer Vielzahl von Herausforde-rungen gegen�ber. So herrschte neben demhohen Zeitdruck eine hohe Dynamik f�rden Bereich der Kundenanforderungenund der technischen M�glichkeiten. Vieleswas konzipierbar war, zeigte in der tech-nischen Realisierung gerade bei der Perfor-mance Schwierigkeiten. Permanent muss-ten Qualit�t und Zeit gegeneinander abge-wogen werden; der Einsatz eines Coacheswar dabei deutlich von Vorteil. Die �ber-f�hrung in den Normalbetrieb dauerteschließlich l�nger als geplant und war erstnach der Integration der letzten Kom-ponenten schrittweise m�glich.

Die allgemeinen Vorz�ge des Verfah-rens (siehe Abschnitt 4.3) kamen auch indiesem Projekt zur Geltung. Dar�ber hi-naus gab es u. a. folgende projektspezi-fische Erfolgsfaktoren:

O

N

L

I

N

E

K 5

K 4

K 3

K 1

K 2

R 1

V 2

R 3

K 6 R 6

R 4

V 1

K 7 R 7

K 8 R 8

K 9 R 9

R 2

R 5

V 4

Content Management

Redaktionssystem

Customer Care & Abrechnung

Print - Redaktion

Internetdienste

Nutzerverwaltung

Kommunikation & Netzwerke

Server & Rechenzentrum

Zugangs - Software

Bild 4 Vorgehensmodell im Online-Projekt


253

, der Einsatz eines erfahrenen Projektlei-ters inklusive Projektcoach („Projekt-doppelspitze“),

, das eigenverantwortliche Handeln derTeilprojektleiter innerhalb ihres Ar-beitspaketes inklusive interner und ex-terne Personalf�hrung mit dem Resul-tat von hoher Motivation und Identifi-kation,

, das Verst�ndnis der beteiligten Per-sonen f�r Internetstandards sowie dieausschließliche Anwendung von Stan-dards,

, das Vertrauen des Kunden in die F�hig-keiten und methodischen Fertigkeitendes Projektteams,

, eine permanente, zielgerichtete Kom-munikation zwischen Projektleiter undAuftraggeber mit kurzfristiger Kl�rungoffener Punkte.

6 Zusammenfassung

Ein erprobtes, prozessorientiertes Vor-gehensmodell wird einer �nderung der

Sichtweise unterzogen, um die Anwen-dungsentwicklung in zeitrestriktiven dy-namischen Projekten optimal zu unterst�t-zen. Die reine prozessorientierte Strukturwird um eine produktorientierte Strukturerg�nzt. Dies f�hrt zu erheblich mehr Fle-xibilit�t im Zeit- und Zielmanagement desProjektes. Bew�hrte Methoden in den ini-tialen Phasen sichern das Gesamtsystem abund erm�glichen eine angemessene Pla-nungssicherheit und Qualit�t. Die fr�hzei-tige Definition von unabh�ngig handhab-baren Arbeitseinheiten und die damit ver-bundene Parallelisierung erm�glichen eineVerk�rzung der Entwicklungszeit undf�hren zu einer erh�hten Flexibilit�t beisich �ndernden Anforderungen.

Literatur

[Alle98] Allen, Paul; Frost, Stuart: Component-Based Development for Enterprise Systems.Cambridge University Press, 1998.

[Beck99] Beck, Kent: Extreme Programming Em-brace Change. Addison-Wesley, Reading/MA1999.

[Boeh76] Boehm, Barry W.: Software Engineer-ing. In: IEEE Transactions on Computers,C-25.12, 1976, S. 1216–1241.

[Booc99] Booch, Grady; Rumbaugh, Jim; Jacob-son, Ivar: The Unified Modeling LanguageUser Guide. Addison-Wesley, Amsterdam1999.

[DeMa76] DeMarco, Tom: Structured Analysisand System Specification. Prentice Hall, 1979.

[Hess98]Hesse, Wolfgang: Vorgehensmodelle f�robjektorientierte Softwareentwicklung. In:Kneuper, Ralf; M�ller-Luschnat, G�nter;Oberweis, Andreas (Hrsg.): Vorgehensmodellef�r die betriebliche Anwendungsentwicklung.Teubner, Reihe Wirtschaftsinformatik, Stutt-gart 1998, S. 110–135.

[Mell00] Mellis, Werner: Process and ProductOrientation in Software Development andtheir Effect on Software Quality Management.In: Wieczorek, M. J.; Meyerhoff, D. B. (Hrsg.):Software Quality – State of the Art in Manage-ment, Testing, and Tools. Springer, Berlin 2000.

[Mart91] Martin, James: Rapid Application De-velopment. Prentice Hall, 1991.

[Reiß00] Reißling, Ralf: Extremes Programmie-ren. In: Informatik Spektrum 23 (2000) 2, S.118–121.

[Schl00] Schl�ter, Egbert: Guideline for Riskma-nagement. Interner Leitfaden Bertelsmann me-diaSystems, Rheda-Wiedenbr�ck 2000.

[Stei00] Carl Steinweg: Projektkompass Soft-wareentwicklung. Vieweg,Wiesbaden 2000.


254

Documents

Anwendungsentwicklung in zeitrestriktiven dynamischen Projekten