Prozessmodelle - Software Engineering - JKU

Kurzcharakteristik ausgewählter Software-Prozessmodelle [JHF, 20.1.2004] 1 

Kurzcharakteristik ausgewählter Software-Prozessmodelle 

Vorbemerkungen 

Joachim Fröhlich 

joachim.froehlich@jku.at 

Komplexe Softwareprodukte müssen systematisch entwickelt werden. Das ist jedoch alles andere als 

einfach: Die Komplexität der Entwicklungsprozesse widerspiegelt die Komplexität der Softwareprodukte. 

Daher kann das inzwischen beträchtliche Angebot an Software-Prozessmodellen nicht überraschen. 

Hier seien nur einige Prozessmodelle aufgezählt: XP, Scrum, OPEN, V-Modell, RUP, MSF, 

ROOM, OORAM, Octopus und FDD. Die große Zahl von zum Teil konkurrierenden Prozessmodellen 

weist darauf hin, dass über die Systematik der Softwareentwicklung keine Einigkeit besteht. Diese 

Vermutung stützen auch die vielen, oft emotional geführten Diskussionen zwischen Anhängern der 

verschiedenen Prozessmodelle. Die Diskussionen verlieren jedoch an Schärfe, wenn man charakteristische 

Aussagen der verschiedenen Prozessmodelle nicht absolut auffasst sondern den Gehalt der 

Aussagen in Bezug setzt zu den Annahmen, auf denen die Modelle beruhen, und Einflussfaktoren 

(Parameter), die die Modelle berücksichtigen. 

In der Praxis beeinflussen zahlreiche Faktoren Software-Entwicklungsprozesse. Diese Faktoren 

haben oft ganz unterschiedliche Ausprägungen. Erneut seien hier einige Faktoren beispielgebend genannt: 

Fertigkeiten und Fähigkeiten von Mitarbeitern in Bezug auf Anwendungsbereiche, Lösungsbereiche 

(eingesetzte Technologien) und Arbeitsweisen, Programmtypen (interaktive Programme, Batch- 

Programme, datenzentrierte Programme, verteilte Systeme, Echtzeitsysteme etc.), Entwicklungstechnologien 

(Paradigmen, Sprachen, Bibliotheken, Werkzeuge etc.), Kritikalität der Programme 1 , Umfang, 

Dauer und Budget von Projekten, Unternehmenskulturen, Branchen, Märkte sowie verschiedene 

Anforderungen verschiedener Produktinteressenten und deren Verteilung über die Laufzeit von Projekten. 

Dieser Aufsatz soll den Ausgangspunkt bilden für eine einheitliche Beschreibung und einen systematischen 

Vergleich von typischen Prozessmodellen, um situationsbedingt geeignete Vorgehensweisen 

auswählen und anwenden zu können. Dazu braucht man eine systematische Darstellung von 

Prozessmodellen. Eine Systematisierung stößt jedoch auf einige Schwierigkeiten, weil die Modelle 

mit verschiedenen oder verschieden interpretierbaren Begriffen beschrieben werden und Annahmen 

und Einflussfaktoren nicht ausdrücklich oder nicht systematisch offen legen. Bei einigen in der Praxis 

entstandenen Prozessmodellen stehen dahinter wirtschaftliche Erwägungen, da die Beherrschung von 

Entwicklungsprozessen selbstredend Wettbewerbsvorteile sichert. 2 

Der Aufsatz liefert Überblicke über einzelne Prozessmodelle, statt eines Überblicks über mehrere 

Modelle. Naturgemäß erleichtert ein Überblick die Orientierung oder unterstützt die Erinnerung, ersetzt 

jedoch nicht die gründliche Auseinandersetzung, die insbesondere vor der Anwendung (vor der 

Operationalisierung) eines Prozessmodells angebracht ist. Der Aufsatz versucht im gegenwärtigen 

Zustand insbesondere nicht, Prozessmodelle zu systematisieren, etwa durch Bestimmung von Prozessmerkmalen, 

gemeinsamen und unterscheidenden Merkmalsausprägungen und einer darauf aufbauenden 

Klassifikation. Da eine Klassifikation fehlt, werden die Prozessmodelle auch nicht beurteilt. 

1 Unter Kritikalität ist hier die Bedeutung zu verstehen, die einem Programm (Softwareprodukt) in einer bestimmten 

Umgebung für einen bestimmten Verwendungszweck beigemessen wird. 

2 Ein prominentes Beispiel dafür ist das vom Object Technology Center (OTC) der Firma IBM entwickelte Prozessmodell, 

das auf die Entwicklung objektorientierter Programme spezialisiert ist. Nach Auskunft eines leitenden IBM-Mitarbeiters 

im März 2003 stammt die letzte ausführliche Publikation zu diesem Modell [OTC97] aus dem Jahr 1997. Seitdem hat IBM 

das Prozessmodell ausschließlich firmenintern weiter entwickelt. Es ist inzwischen so reif, dass ein Werkzeug die Planung 

und Abwicklung von Prozessen auf der Basis des Prozessmodells unterstützt.


Der Aufsatz widmet jedem der Prozessmodelle RUP, V-Modell, XP, Scrum und MSF ein eigenes 

Kapitel. Diese Modelle wurden ausgewählt, primär weil über sie bis Heute auffallend viel gesprochen 

wird. Zu Beginn eines Kapitels werden die Gründe genannt, die zur Entwicklung des jeweiligen Modells 

geführt haben. Das erleichtert das Verständnis charakteristischer Modelleigenschaften, die nach 

den Gründen angeführt werden. Abgesehen von dieser einheitlichen Struktur folgen die einzelnen Modellbeschreibungen 

mehr der Logik des jeweiligen Modells als der Logik eines einheitlichen Beschreibungsschemas. 

Die Modellbeschreibungen gehen auf Aussagen von Modellentwicklern oder Modellexperten 

zurück; die Informationsquellen werden so genau wie möglich angeführt. 

Der Aufsatz ist eine Sammlung von Modellbeschreibungen, deren Reihenfolge keiner besonderen 

Ordnung unterliegt. Bei der sequentiellen Durcharbeitung der Materialsammlung begegnen dem Leser 

Gemeinsamkeiten und auch Unterschiede, ohne dass der Aufsatz diese ausdrücklich heraus arbeitet 

und etwa in einen eigenständigen Abschnitt ausklammert. Die Materialsammlung ist aus der Sicht des 

Autors vor einer Systematisierung zunächst mit Beschreibungen weiterer, interessanter Modelle zu ergänzen. 

Auf der Warteliste ganz oben stehen OPEN (Akronym für Object-Oriented Process, Environment 

and Notation) [GrHY98], FDD (Akronym für Feature-Driven Development) [PaFe02], Architecture-Centric 

Project Management [Pauli02] und Process Patterns [Ambl98] [Ambl99]. 

Inhalt 

RUP [Rational, 1998]................................................................................................................. 3 

Dynamikelemente................................................................................................................... 4 

Statikelemente........................................................................................................................ 5 

V-Modell 97 [IABG Ottobrunn, 1997].......................................................................................... 6 

XP [K.Beck, 2000] ..................................................................................................................... 8 

Scrum [K.Schwaber, J.Sutherland, M.Beedle, 1996].....................................................................12 

MSF [Microsoft, v1:1991, v2:1998, v3:2003] ..............................................................................15 

MSF-Modelle ........................................................................................................................17 

MSF-Disziplinen...................................................................................................................20 

Referenzen ...............................................................................................................................22


RUP [Rational, 1998 3 ] 

Quellen: [Kruc00][Jaco00] 

Der RUP (Akronym für Rational Unified Process) beruht⎯nach den Aussagen von Rational⎯auf 6 

bewährten Praktiken, die erfolgreichen, professionellen Entwicklungsprozessen zugrunde liegen (engl. 

best practices 4 ) [Kruc00, 6ff]: 

1. Entwickle Software iterativ. 

2. Verwalte (engl. manage) Anforderungen (engl. requirements). 

3. Verwende komponentenbasierte Softwarearchitekturen. 

4. Modelliere Software visuell. 

5. Prüfe Software kontinuierlich. 

6. Ändere Software kontrolliert. 

Besonderes Gewicht legt RUP auf Modelle zum Verstehen und Gestalten von Anwendungs- und Lösungsbereichen, 

insbesondere auf Softwarearchitekturen. 6 Verschiedene Produktinteressenten (engl. 

stakeholder 7 ) haben verschiedene Sichten auf ein Softwareprodukt. Dessen Softwarearchitektur dient 

der Integration der verschiedenen Sichten und steuert dabei den iterativen und inkrementellen Entwicklungsprozess 

während des gesamten Produkt-Lebenszyklusses [Kruc00, 9]. 

Mit Hilfe der zuvor genannten 6 Praktiken soll RUP typische Probleme bei der Entwicklung von 

Software meistern helfen. Die Probleme äußern sich wie folgt [Kruc00, 4]: 

• Ungenügendes Verständnis der Anforderungen von Anwendern. 

• Ungeeigneter Umgang mit neuen oder sich ändernden Anforderungen. 

• Softwareteile, die nicht zusammen passen. 

• Software, die schwer zu pflegen ist oder kaum weiter entwickelt werden kann. 

• Späte Entdeckung von schwerwiegenden Fehlern. 

• Schlechte Softwarequalität. 

• Unzureichende Leistungsfähigkeit (Performance) der Software. 

• Sich gegenseitig behindernde Projektmitarbeiter. 

• Unzuverlässige Build-Prozesse und Release-Prozesse. 

Diese Symptome gehen auf folgende Probleme zurück [Kruc00, 5]: 

• Ungeplante (ad hoc) Verwaltung von Anforderungen. 

• Mehrdeutige und unpräzise Kommunikation. 

• Instabile Softwarearchitekturen. 

• Ausufernde Komplexität der Software. 

• Versteckte Inkonsistenzen zwischen Anforderungen, Entwürfen und Implementierungen. 

• Unzureichende Tests. 

• Subjektive Einschätzung des Projektzustands. 

• Unzureichender Umgang mit Risiken. 

• Unkontrollierte Softwareänderungen. 

• Unzureichende Automatisierung. 

3 [Kruc00, 33]. Die Jahreszahlen geben das Jahr der ersten Nennung des Prozessmodells an. 

4 Für Begriffe, die in der deutschen Übersetzung ungewohnt klingen, werden die englischen (engl.) Originalbezeichner 

angeführt. 

5 Für Begriffe, die in der deutschen Übersetzung ungewohnt klingen, werden die englischen (engl.) Originalbezeichner 

angeführt. 

6 Zum Beispiel ist im Buch The Rational Unified Process. An Introduction ein ganzes Kapitel dem Thema “An 

Architecture-centric Process“ gewidmet [Kruc00, 81-96]. 

7 Ein Stakeholder ist eine Person, die ein berechtigtes Interesse an einem (Software-) Produkt hat, z. B. Endbenutzer, Softwareentwickler, 

Tester, technische Schreiber, Projektmanager. Verschiedene Stakeholder haben i. Allg. verschiedene 

Interessen. Oder: „A stakeholder is anyone who is materially affected by the outcome of the project.“ [Kruc00, 265]


Zur Meisterung dieser Probleme gliedert RUP Entwicklungsprozesse in 2 Dimensionen (siehe Abb. 1) 

[Kruc00, 22]: 

• Dynamische Dimension: Gliederung von Aktivitäten nach der Zeit. 

Zeigt die schrittweise Entwicklung des Produkt-Lebenszyklusses in Form von projekttypischen, 

situationsbedingten—und insofern dynamischen—Verläufen von Phasen, 

Iterationen und Zyklen. 

• Statische Dimension: Gliederung von Aktivitäten nach dem Inhalt. 

Zeigt logische und zweckdienliche Zusammenhänge zwischen Aktivitäten, Rollen und 

Artifakten. Diese Zusammenhänge gelten weitgehend unabhängig von der konkreten 

Entwicklung eines Produkt-Lebenszyklusses und sind insofern statisch. 

Dynamikelemente 

In der dynamischen Dimension werden Prozesse strukturiert hinsichtlich Phasen, Zyklen, Iterationen 

und Meilensteine [Kruc00, 61-66]: 

• Phasen: 

1. Ideenphase (I, engl. inception) mit den Schwerpunkten: Produktziele und –umfang abstecken, 

allgemeine und hauptsächliche Anforderungen verstehen, Risiken identifizieren, 

Projektbudget und –plan grob festlegen. 

2. Ausarbeitungsphase (E, engl. elaboration) mit den Schwerpunkten: Anforderungen im Detail 

erheben, Architektur prototypisch entwickeln, Lösungsansätze ausprobieren, Kenntnisse 

über Techniken und Werkzeuge des Lösungsbereichs vertiefen. 

3. Konstruktionsphase (C, engl. construction) mit dem Schwerpunkt, ausgehend vom Prototypen 

ein lauffähiges Produkt (erstes Beta-Release [Kruc00, 64, Fig. 4-6]) zu entwickeln. 

4. Übergangsphase (T, engl. Transition) mit den Schwerpunkten: Produktqualität in Bezug auf 

die gesteckten Ziele stabilisieren, Produktfähigkeiten (engl. features) anpassen, Anwender 

trainieren, finale Produktversion erstellen und ausliefern. 

• Zyklen: 

Die genannten Phasen bilden einen Entwicklungszyklus (I-E-C-T) und führen zu einer neuen 

Generation (Version, u. U. auch Variante) eines Softwareprodukts. 

Organization along Content 

Core Workflows 

Support 

Workflows 

Business Modeling 

Requirements 

Analysis & Design 

Implementation 

Test / Assessment 

Deployment 

Configuration & 

Change Management 

Project Management 

Environment 

Inception Elaboration Construction Transition 

Preliminary 

Iteration 

Organization along Time 

LO LA OC PR 

Iteration 

#1 

Iteration 

#2 ... 

Iteration 

#n 

Iteration 

#n+1 ... 

Iteration 

#m ... 

Time


Abb. 1: RUP gliedert Prozesse in 2 Dimensionen [Kruc00, 23, 46, 62]. 

Meilensteine: LO (Lifecycle Objective), LA (Lifecycle Architecture),OC (Initial Operational Capability), PR 

(Product Release). Die Dauer der Phasen (z. B. Inception, Elaboration) hängt von den Projektumständen ab. 

• Iterationen: 

Zur Verringerung von Risiken werden pro Zyklus lediglich ein Teil der Anforderungen 

bearbeitet (I), die dazu notwendigen Entwürfe erstellt (E), implementiert und getestet (C) und 

dem Auftraggeber übergeben (T). Jede Iteration folgt einem Muster ähnlich dem des Wasserfall-Modells 

mit den Besonderheiten, dass sich die Workflows (z. B. Anforderungsanalyse 

(Requirements), Design und Implementierung, siehe Abb. 1) überlagern und die Aktivitätsschwerpunkte 

von Phase zu Phase und von Iteration zu Iteration verschieben [Kruch00, 64-65]. 

• Meilensteine: 

Meilensteine sind Punkte am Ende von Phasen, an denen anhand von Evaluationskriterien 

entschieden wird über die Weiterführung, die Änderung oder den Abbruch eines Prozesses. 

Meilensteine sind (siehe Abb. 1): 

1. LO (Lifecycle Objective) u. a. mit den Kriterien: Produktinteressenten haben Übereinkunft 

erzielt über allgemeine und hauptsächliche Anforderungen, Ressourceplan ist plausibel, Architekturprototyp 

deckt kritische Bereiche ab. 

2. LA (Lifecycle Architecture) u. a. mit den Kriterien: Produktvision ist stabil, Architektur ist 

stabil, Plan für die Konstruktionsphase ist plausibel nachvollziehbar, der aktuelle Ressourcenverbrauch 

ist gegenüber dem geplanten vertretbar. 

3. OC (Initial Operational Capability) u.a. mit den Kriterien: Produkt ist reif und stabil genug 

für ein Beta-Release, der aktuelle Ressourcenverbrauch ist gegenüber dem geplanten vertretbar. 

4. PR (Product Release) u.a. mit den Kriterien: Benutzer sind mit dem Produkt zufrieden, der 

aktuelle Ressourcenverbrauch ist gegenüber dem geplanten vertretbar. 

Statikelemente 

In der statischen Dimension werden Prozesse gegliedert hinsichtlich Rollen, Aktivitäten, Artifakten 

und Arbeitsabläufen [Kruc00, 36ff]: 

• Rollen (engl. Worker): Wer führt eine Aktivität aus? 

Eine Rolle definiert zusammenhängende Aktivitäten und die damit verbundene Verantwortung 

einer Person (oder eine Gruppe von Personen), für gewöhnlich ausgedrückt in Beziehung auf 

bestimmte Artifakte. Beispiele [Kruch00, 263-265]: Project Manager, Architekt, Architekt 

Reviewer, User-Interface-Designer, System Analysator, Test Designer, Tester, Configuration 

Manager 9 , Change Control Manager. 

• Aktivität (engl. activity): Wie ist etwas auszuführen? 

Eine Aktivität ist eine sachlogisch zusammenhängende, zweckmäßige Aufgabe einer Rolle, für 

gewöhnlich eine Form der Erzeugung, Verwendung oder Aktualisierung von Artifakten. Eine 

Aktivität ist ein Planungsinstrument. Beispiele: Plane eine Iteration (Project Manager), Ermittle 

Anwendungsfälle (System Analysator). 

• Artifakte (engl. artifact): Was sind die Gegenstände von Aktivitäten? 

Ein Artifakt ist eine Information [Kruc00, 40], die im Laufe einer Aktivität oder eines Prozesses 

erzeugt, verwendet oder aktualisiert wird. Dokumente sind nur eine spezielle Form von 

Artifakten. Artifakte bilden eine Einheit zusammen mit den Werkzeugen (z. B. Datenbank- 

Systeme, Web-Publishing-Systeme, Bug-Tracking-Systeme), die zu ihrer Erzeugung und Verwaltung 

eingesetzt werden. Artifakte fallen in eine der folgenden Bereiche: Mana-gement, Anforderungen, 

Entwurf, Implementierung und Deployment. Geschäftlich verwertbare Ergeb- 

8 Bearbeiter ist hier im Sinne eines Konzeptes gebraucht. 

9 Der Configuration Manager entspricht dem SEU-Betreuer (SEU=Softwareentwicklungsumgebung) im V-Modell 97.


nisse bilden eine Teilmenge der Artifakte. Beispiele: Anwendungsfall-Modelle (engl. use case 

models), Source Code, Projektpläne, Datenbank mit Systemanforderungen, Fehlermeldungen. 

• Arbeitsabläufe (engl. workflows): Wann ist etwas auszuführen? 

Ein Arbeitsablauf ist eine Folge von Aktivitäten, die zu geschäftlich verwertbaren Ergebnissen 

führen. Arbeitsabläufe gruppieren (und ordnen) logisch zusammengehörende Aktivitäten, 

Artifakte und Rollen. Beispiele: Geschäftprozess-Modellierung, Analyse und Design (siehe 

Abb. 1). 

Statikelemente und Dynamikelemente bilden zusammen mit 

1. Richtlinien für die Gestaltung von Aktivitäten und Artifakten, 

2. Schablonen (engl. templates; hier im Sinn von Dokumentvorlagen, Modellen und Prototypen) 

für Artifakte sowie 

3. Werkzeug-Mentoren 

ein Prozess-Framework [Kruc00, 50], in dem Sinn, dass Rollen, Artifakte, Aktivitäten (Statikelemente 

allgemein) situationsbedingt kombiniert, hinzugefügt, ersetzt oder gestrichen werden. Das führt 

zu verschiedenen, anpassbaren Abläufen, die RUP mit Phasen, Iterationen und Meilensteinen (Dynamikelementen) 

beschreibt. 10 

V-Modell 97 [IABG Ottobrunn, 1997 11 ] 

Quellen: [HaNe01] [Vers00] [Stra03][WWW1] 

Das V-Modell 97 (im weiteren abgekürzt mit VM97) soll den sogenannten Teufelskreis des Software- 

Engineering [Vers00, 3] durchbrechen: 

• Mangelhafte Entwicklung führt zu 

• schlechter Produktqualität, die zu 

• erhöhtem Pflegeaufwand führt, was wiederum zu 

• Personalengpässen führt, was zu 

• mangelhafter Entwicklung führt 

• ... 

Die Ziele des VM97 sind [HaNe01, 212]: 

• Bessere Kommunikation der Projektbeteiligten. 

• Einheitliches Vorgehen bei Behörden und beauftragten Firmen. 

• Höhere Produktqualität. 

• Weniger Wartungsausfälle. 

• Geringerer Wartungsaufwand durch besseres Verständnis und einheitliche Dokumentation. 

• Höhere Entwicklungsproduktivität durch geringere Einarbeitungs- und Schulungszeiten. 

• Bessere Kalkulation von Neuprojekten durch standardisiertes Vorgehen. 

• Geringere Abhängigkeit von Personen und beauftragten Firmen. 

Das VM97 wird vor allem im öffentlichen Bereich, sowie im Banken- und Versicherungswesen eingesetzt 

[Vers00, 5]. Das VM97 dient als [Stra03, 10] 

• Vertragsgrundlage 

• Arbeitsanleitung 

• Kommunikationsbasis 

• Materialsammlung 

Das VM97 ist in 3 Ebenen gegliedert [Vers00, 6][HaNe01, 212]: 

1. Vorgehensmodell: Was ist zu tun? 

Beschreibt Aktivitäten und Produkte (Ergebnisse). 

10 Zur Bedeutung des Begriffs Prozess-Framework im Umfeld von RUP siehe z. B. auch Kapitel “Building your own process 

by specializing a process framework” von Jacobson [Jaco00, 155-164], einem maßgebenden Entwickler von RUP. 

11 [Vers00, 6], siehe auch http://www.v-modell.iabg.de, zitiert am 25.6.2003


2. Methodenstandard: Wie ist es zu tun? 

Beschreibt grundlegende (elementare und komplexe) Methoden, die die genannten Aktivitäten 

unterstützen. 

3. Werkzeuganforderungen: Womit ist es zu tun? 

Beschreibt funktionale Anforderungen an Werkzeuge, die die Verwendung der festgelegten 

Methoden unterstützen. 

Jede dieser Ebenen durchzieht die Tätigkeitsbereiche (Teilmodelle, siehe Abb. 2): 

• Softwareerstellung: Teilmodell SE. 

• Qualitätssicherung: Teilmodell QS. 

• Konfigurationsmanagement: Teilmodell KM. 

• Projektmanagement: Teilmodell PM. 

Konfigurationsmanagement 

Qualitätssicherung 

Softwareerstellung 

Projektmanagement 

Vorgehensmodell 

Methodenstandard 

Werkzeuganforderungen 

Abb. 2: Ebenen und Tätigkeitsbereiche (Teilmodelle) des VM97 [HaNe01, 212]. 

Die Softwareerstellung ist der zentrale Tätigkeitsbereich; andere Tätigkeitsbereiche begleiten die Softwareerstellung. 

Das VM97 gibt für die Softwareerstellung Aktivitäten und deren Ergebnisse (Produkte, 

Artifakte) einheitlich und verbindlich vor [HaNe01, 213]. Jede Aktivität wird durch eine Aktivitätenbeschreibung 

(Aktivitätsanleitung) in Form einer Produktflusstabelle beschrieben (siehe Abb. 

3). 

Von Aktivität Zustand Produkt Nach Aktivität Zustand 

Extern - Rahmenbedingungen - - 

Extern - Externe Vorgaben (AG) - - 

SE 2 akzeptiert Systemarchitektur - - 

- - Systemanforderungen SE 2, SE 3, SE 

4-SW, SE 5-SW 

vorgelegt 

- - SWPÄ-Konzept SE 9, PM 5 vorgelegt 

Protokoll PM 6 - 

Abb. 3: Produktflusstabelle für die Aktivität SE 1 „System-Anforderungsanalyse“ (Hauptaktivität des Teilmodells 

SE). SWPÄ = Software Pflege- und –Änderung. SE 4 „Grobentwurf“ gib es in 2 Varianten (1) für Software: SE 4- 

SW und (2) für Hardware: SE 4-HW. AG = Auftraggeber. 

SE 1 ist eine Hauptaktivität. Hauptaktivitäten werden in Subaktivitäten (SE 1.1 „Ist-Aufnahme/-Analyse 

durchführen“, SE 1.2 „Anwendungssystem beschreiben“ ...) untergliedert. Aktivitäten ändern 

Produktzustände (siehe Abb. 4). 

geplant in Bearbeitung vorgelegt akzeptiert 

Abb. 4: Produktzustände und Zustandsübergänge. 

Die 4 Teilmodelle (SE, QS, KM, PM) von VM97 sind miteinander verknüpft und beeinflussen sich 

über den Austausch von Produkten (siehe Abb. 5).


SE 

QS 

KM 

PM 

A2 P2 A5 P6 A7 

A3 

P3 

A4 P4 

A1 P1 A6 P5 

Abb. 5: Schematische Darstellung eines Aktivitäten- und Produktflusses über die 4 Teilmodelle (SE, QS, KM, PM) 

des VM97 [HaNe01, 217] [Vers00, 12]. Ai = Aktivitäten, Pi = Produkte. 

Das VM97 ist ein organisationstunabhängiges Modell [Vers00, 55]. Daher werden Aufgabenträger 

in Form von Rollen beschrieben. Eine Rollenbeschreibung legt fest: 

• Aktivitäten, an denen die Rolle beteiligt ist. 

• Aufgaben und Tätigkeiten, die die Rolle wahrnehmen muss. 

• Kenntnisse, die für die Ausübung der Aufgaben und Tätigkeiten notwendig sind. 

Beispiele für Rollen im Teilmodell SE [Vers00, 56] sind: Systemanalytiker, Systemdesigner, 

Softwareentwickler, Hardwareentwickler, Technischer Autor, Systembetreuer, SEU 12 -Betreuer. 

Rollen und Aktivitäten bilden eine Matrix. Dabei werden die Beteilungsformen verantwortlich, 

mitwirkend und beratend unterschieden (siehe Abb. 6). 

SE 1: „Systemanforderungsanalyse 

SE 1.1: Ist-Aufnahme/-Analyse durchführen 

SE 1.2: Anwendungssystem beschreiben 

… 

SE 2: System-Entwurf 

SE 2.3: Realisierbarkeit untersuchen 

. 

Systemanalytiker 

. 

verantwortlich 

verantwortlich 

. 

. 

mitwirkend 

. 

Abb. 6: Ausschnitt aus der Aktivitäten/Rollen-Matrix am Beispiel eines Systemanalytikers. 

VM97 kann an projektspezifische Gegebenheiten angepasst werden (Tailoring) [Vers00, 14]. Dabei ist 

zu prüfen, welche Aktivitäten und Produkte notwendig sind. VM97 unterscheidet 2 Formen von Anpassungen: 

1. Ausschreibungsrelevante Anpassungen: Anpassungen vor Beginn des Projekts. 

2. Technische Anpassungen: Anpassungen während des Projekts. 

Das angepasste VM97 (1. Form) und/oder die Rahmenbedingungen, unter denen bestimmte Aktivitäten 

ausgeführt oder Produkte erzeugt bzw. verwendet werden (2. Form), sind im Projekthandbuch 

festzuhalten. 

XP [K.Beck, 2000 13 ] 

Quellen: [Beck00] [WWW2] [ASRW02] 

Softwareentwicklung ist verschiedenen Risiken ausgesetzt [Beck00, 3], z. B. 

• Terminverschiebungen. 

• Komplizierte, zunehmend schwerer wartbare Programme. 

• Un- oder Missverständnis des Anwendungsbereichs. 

• Änderungen des Anwendungsbereichs. 

• Funktional überladene Programme (engl. false feature richness). 

Zum Umgang mit den Risiken stehen grundsätzlich vier Optionen zur Verfügung [Beck00, 12]: 

• Abbrechen: Streichen von Features. 

12 SEU = (S)oftware(e)ntwicklungs(u)mgebung 

13 [High02, 297]


• Wechseln: Ändern der Projektrichtung oder Ändern von Features. 

• Verschieben: Warten bis die Situation überschaubarer ist. 

• Skalieren: Anpassen an Projektgröße und –dynamik. 

Diese Optionen stehen dem Auftraggeber unter XP (Extreme 14 Programming) während der Abwicklung 

eines Projekts kontinuierlich zur Verfügung. 

XP ist besonders auf die Abwicklung von Projekten mit vagen oder sich häufig ändernden 

Anforderungen ausgerichtet [Beck00, 13]. Wage oder sich häufig ändernde Anforderungen führen 

üblicherweise im Laufe der Zeit zu hohen Änderungskosten. Mit XP sollen diese Kosten nachhaltig 

gesenkt werden (siehe Abb. 7). 

Cost of Change 

Requirements Analysis Design Implementation Testing Production 

Time 

Abb. 7: Üblicherweise steigen die Änderungskosten exponentiell mit der Zeit (7a) [Beck00, 21]. XP soll 

Änderungskosten konstant halten (7b) [Beck00, 23]. 

Um das ökonomische Ziel (annähernd konstante Änderungskosten) zu erreichen, werden XP-Projekte 

etwa so gesteuert wie Fahrzeuge [Beck00, 28]: „Driving is not about getting the car going in the right 

direction. Driving is about constantly paying attention, making a little correction this way, a little correction 

that way. This is the paradigm of XP.” Dabei ist der Steuermann des Projekts der Kunde (der 

Auftraggeber) [Beck00, 28]. Die Projektmitarbeiter (Softwareentwickler) geben dem Kunden kontinuierlich 

Feedback über den aktuellen Stand des Projektes. 

Diese Art der Projektsteuerung birgt die Gefahr in sich, dass durch zahlreiche, kurzfristige Änderungen 

langfristige Ziele und bewährte Arbeitstechniken (Praktiken, siehe weiter unten) vergessen 

werden. Konflikte zwischen kurzfristigen, meist individuellen Zielen und langfristigen, gemeinschaftlichen 

Zielen werden in sozialen Gruppen auf der Basis gemeinsamer Wertvorstellungen ausgetragen. 

In diesem Sinn werden im Kontext von XP Projektmitarbeiter eingeschworen auf die folgenden vier 

grundlegenden Werte [Beck00, 29-35]: 

1. Kommunikation: Probleme, kritischen Änderungen, Lösungsalternativen etc. werden kontinuierlich 

besprochen. 

2. Einfachheit: Einfache Programme, die aktuelle Aufgaben lösen, können zukünftig leichter geändert 

werden, als komplizierte Programme, die nicht nur aktuelle Aufgaben lösen sondern 

auch zukünftige Aufgaben, die jedoch für das Programm möglicherweise nie relevant sind. 

3. Feedback: Kontinuierliche Rückmeldungen über den Zustand eines Systems oder des Projektes 

ersetzt selbsttrügerischen Optimismus, z. B. kontinuierliche Unit-Tests und unmittelbare 

Aufwandsschätzungen durch Softwareentwickler für Anforderungen von Kunden. 

4. Mut (Courage): Mut ist notwendig, um (1) die Programmarchitektur umzubauen, wenn das 

(aufwendige) Änderungen von zahlreichen Unit-Tests nach sich zieht, (2) um überflüssigen 

Code aus der Codebasis zu entfernen, oder (3) um Fehler in Programmteilen anderer Softwareentwickler 

auszubessern. Diese Anpassungen sind notwendig, z. B. um gemäß dem Wert 

Einfachheit die Programmstruktur immer so einfach als möglich zu halten. 

Da diese Werte zu abstrakt sind, um auf deren Grundlage in konkreten Situationen Entscheidungen zu 

treffen, postuliert XP die folgenden, aus den genannten Werten abgeleitete, zentrale Prinzipien 

[Beck00, 37-38]: 

• Hole Feedback, interpretiere es, ziehe schnell Konsequenzen (engl. rapid feedback). 

14 “Why the ‘extreme’ in the name? XP takes commonsense principles and practices to extreme levels.” [Beck00, xv] 

7a 

7b


• Gehe davon aus, dass es eine einfache Lösung gibt (engl. assume simplicity). 

• Löse Probleme schrittweise (engl. incremental change). 

• Löse das dringenste Problem zuerst, bewahre weitere Optionen (engl. embracing change). 

• Strebe ständig nach qualitativ hochwertigen Arbeitsergebnissen (engl. quality work). 

Weitere Prinzipien sind [Beck00, 39-42]: 

• Lehre lernen 15 , statt doktrinäre Anweisungen zu geben und zu befolgen (engl. teach learning). 

• Investiere schrittweise, beginne mit einer geringen Investition (engl. small initial investment). 

• Suche den Erfolg (engl. play to win). 

• Teste Entscheidungen mit Experimenten (engl. concrete experiments). 

• Kommuniziere offen und redlich (engl. open, honest communication). 

• Arbeite mit den Instinkten statt gegen sie (engl. work with people’s instincts, not against them). 

• Übernehme Verantwortung auf eigene Initiative (engl. accepted responsibility). 

• Passe XP an lokale und aktuelle Gegebenheiten an (engl. local adaption). 

• Erstelle wenige, einfache und nützliche (Zwischen-)Produkte / Artifakte (engl. travel light). 

• Kontrolliere und steure den Prozess mit nützlichen statt technisch möglichen Maßen (engl. 

honest measurement). 

Ein Projekt soll auch bei häufigen Änderungen auf Kurs gehalten werden, dabei den grundlegenden 

Werten und Prinzipien folgen und gleichzeitig die Änderungskosten niedrig halten. Zur Erreichung 

dieser Ziele muss sich ein Entwicklungsprozess auf wesentliche Aktivitäten konzentrieren. Wesentlich 

sind jene Aktivitäten, auf die während der Entwicklung qualitativ hochwertiger, langlebiger Programme 

nicht verzichtet werden kann. Das sind [Beck00, 43ff]: 

• Programmieren: Ohne Programmieren gibt es kein Programm. 

• Testen: Ohne Testen ist nicht klar, ob die Programmierung abgeschlossen ist. 

• Zuhören: Ohne Zuhören ist nicht klar, was programmiert und getestet werden soll. 

• Entwerfen: Ohne Entwerfen kann nicht langfristig programmiert und getestet werden. 

Auf Dokumentation (Systemdokumentation) verzichtet XP vollständig. Dokumentation ist für 

typische XP-Projekte keine wesentliche Entwicklungstätigkeit. Dokumentation kann durch Praktiken 

ersetzt werden, die auf zuvor genannten Prinzipien zurückgehen, insbesondere auf intensive Kommunikation, 

kontinuierliches Feedback, einfache Programme, einfache Entwürfe (einfache Metaphern) 

und zahlreiche, automatisierte Testtreiber. Im Einzelnen konzentriert sich XP auf die folgenden 12 

Praktiken [Beck00, 54]: 

• Das Planungsspiel (engl. the planning game): Der Inhalt des nächsten Release (der nächsten 

Produktfreigabe) wird mit Story Cards (Beschreibungen von Produktfähigkeiten, engl. 

features) [Beck00, 88] bestimmt. Das soll einfach und schnell gehen. Dabei werden Geschäftsziele 

(des Kunden) und Aufwandsschätzungen der Softwareentwickler abgeglichen. Der Plan 

kann während der Entwicklung an sich ändernde Situationen angepasst werden. 

• Kurze Release-Zyklen (engl. small releases): Funktional begrenzte Produktversionen werden in 

kurzen Zyklen freigegeben. 

• Metapher (engl. methaphor): Ein einfaches Konzept über Aufbau und Arbeitsweise des Programms 

steuert die Softwarentwicklung. 

• Einfacher Entwurf (engl. simple design): Das Programm soll immer so einfach als möglich 

implementiert werden. Unnötige Komplexität ist zu beseitigen, sobald sie entdeckt wird. 

• Testen (engl. testing): Softwareentwickler erstellen kontinuierlich Unit-Tests. Unit-Tests sollen 

vor dem Testgegenstand entwickelt werden und müssen vor dem nächsten Entwicklungsschritt 

abgeschlossen werden. Kunden entwickeln Systemtests zur Überprüfung der im Planungsspiel 

(siehe oben) festgelegten Produktfähigkeiten (engl. features). 

15 Man könnte ergänzen: Lerne lehren [A.d.V.]


• Umbau (engl. refactoring): Softwareentwickler restrukturieren das Programm ohne dessen 

Funktionen zu ändern, um überflüssigen Code zu entfernen, um das Programm zu vereinfachen 

oder um es, wenn notwendig, flexibler zu gestalten. 

• Programmieren in Paaren (engl. pair programming): Zwei Softwareentwickler entwickeln 

Quellcode gemeinsam. Ein Enwickler gibt dem anderen kontinuierlich Feedback. Die Zusammensetzung 

der Paar wechselt in bestimmten Abständen. 

• Gemeinsame Verantwortung (engl. collective ownership): Jeder Softwareentwickler kann jede 

Codezeile (im gesamten Projekt) zu jedem Zeitpunkt ändern. 

• Kontinuierliche Integration (engl. continuous integration): Das System wird integriert, sobald 

eine neue Einwicklungsaufgabe (engl. task 16 ) implementiert wurde. 

• 40-Stunden Woche (engl. 40-hour week): Pro Woche sollen in der Regel nicht mehr als 40 

Stunden gearbeitet werden. Die Wochenarbeitszeit soll höchstens 1 Woche (keine 2 Wochen 

hintereinander) überschritten werden. 

• Kunde vor Ort (engl. on-site customer): In die Projektgruppe soll ein Kunde integriert werden. 

Der Kunde soll für die Entwickler immer verfügbar sein, um jederzeit Fragen beantworten zu 

können. 

• Programmierstandards (engl. coding standards): Softwareentwickler erstellen Programme 

nach einheitlichen Richtlinien zur der Kommunikation direkt durch den Quellcode. Das erleichtert 

z. B. den kontinuierlichen Programmumbau und fördert einen einfachen Programmentwurf. 

XP verlangt den Einsatz aller Praktiken, da alle Praktiken direkt oder indirekt zusammenhängen. 

XP kann in Projekten mit bis zu ca. 10 Softwareentwicklern eingesetzt werden. Die Softwareentwickler 

müssen fachlich ähnlich qualifiziert sein und kommunizieren können. Zur Förderung der 

Kommunikation sollen alle Softwareentwickler in einem Raum sitzen. Übliche XP-Projekte dauern 

zwischen 1 und 6 Monaten; ein Entwicklungszyklus (eine Iteration) dauert zwischen 1 und 3 Wochen 

[Beck00, 91]. Eine Übersicht über den Verlauf typischer XP-Projekte gibt Abb. 8. 

Abb. 8: Übersicht über ein XP-Projekt [WWW2]. 

Wichtige Rollen in XP-Projekten sind [ASRW02, 21f]: 

• Softwareentwickler: entwickelt Programme und Unit-Tests. 

• Kunde: beschreibt Anwendungsfälle (mit Story Cards) und entscheidet, wann eine 

Anforderung implementiert ist. 

16 Stories werden auf Story Cards während des Planungsspiels fest gehalten. Später werden die Stories in mehrere Programmieraufgaben 

(engl. tasks) zerlegt. Daraus entstehen Task Cards [Beck00, 91].


• Tester: hilft dem Kunden, Testfälle zu schreiben, testet regelmäßig das System und informiert 

die Produktinteressenten über die Testergebnisse. 

• Tracker: sammelt Daten und gibt Softwareentwicklern und Managern Feedback zum 

Projektfortschritt. 

• Coach: verantwortlich für den Gesamtprozess und die Einhaltung der XP-Regeln. 

• Technik-Berater: bringt spezielles technisches Know-how in die Projektgruppe. 

• Manager: trifft finale Entscheidungen und koordiniert sich dazu mit der Projektgruppe. 

Scrum [K.Schwaber, J.Sutherland, M.Beedle, 1996 18 ] 

Quellen: [High02] [ScBe02] [ASRW02] 

Softwareentwicklung ist kein definierbarer Prozess sondern ein auf Erfahrung beruhender und nur mit 

dem Wachsen der Erfahrung sich verbessernder Prozess (mit den Worten von K.Schwaber: ein empirischer 

Prozess) [High02, 241]. Jedes Projekt ist einmalig: Technology, Anforderungen und Mitarbeiter 

variieren von Projekt zu Projekt und oft auch während der Abwicklung eines Projekts [ScBe02, 23]. 

Detaillierte Vorschriften zu Phasen, Aktivitäten und Aufgaben und überladene (schwergewichtige) 

Prozessmodelle können die Entwicklung eines Softwareprodukts in dynamischen Umgebungen nicht 

beschreiben, da ein definierter Prozess das Verständnis jedes einzelnen Schrittes voraussetzt [ScBe02, 

25]. Unter dynamischen, z.T. nicht vorhersehbaren Umständen können jedoch weder das Ergebnis 

noch einzelne Schritte oder deren Folge zur Erzielung des Ergebnisses genau vorgeschrieben (geplant) 

werden. 

Scrum 19 geht davon aus, dass solche Prozesse „am Rande des Chaos“ kontinuierlich überwacht 

und mit Feedback-Techniken gesteuert werden. Das Management konzentriert sich dabei auf der 

Verbesserung der Umstände eines Projekts, um optimale Rahmenbedingungen für die Entwicklungstätigkeiten 

(Analysieren, Entwerfen, Implementieren und Testen) und damit für die Softwareentwickler 

zu schaffen. Innerhalb dieser Rahmenbedingungen können Softwareentwickler selbständig geeignete 

Prozessmodelle für die Softwareentwicklung (im engeren Sinn) auswählen und einsetzen, z. B. 

XP und RUP [High02, 242-243] [ScBe02, 128]. Einen Überblick über Scrum gibt Abb. 9. 

Scrum besteht aus drei Phasen, die wiederholt (iterativ) angewendet werden: 

1. Pre-Sprint: Planung (Vorwärtsregelung, Steuerung, Feedforward). 

2. Sprint: Softwareentwicklung und Überwachung der Softwareentwicklung. 

3. Post-Sprint: Review (Rückkopplung, Feedback). 

In der Pre-Sprint-Phase wird das Softwareprodukt geplant [High02, 244] [ASRW02, 29]: 

• Festlegung von Ziel und Zweck (engl. sprint goal, business purpose) der nächsten Iteration. 

• Extrahierung der Anforderungen aus der Auftragbestandsliste (siehe folgenden Absatz) in die 

Produktfreigabeliste (siehe folgenden Absatz). 

• Ableitung einer Aufgabenliste (siehe folgenden Absatz) zur Realisierung der Anforderungen in 

der Produktfreigabeliste. 

• Entwurf und Review einer Produktarchitektur, die zur Realisierung der Anforderungen in der 

Produktfreigabeliste geeignet ist. 

17 Ein Stakeholder ist eine Person, die ein berechtigtes Interesse an einem (Software-) Produkt hat, z. B. ein Kunde, ein 

Softwareentwickler, ein Manager. Verschiedene Stakeholder haben i. Allg. verschiedene Interessen. 

18 [ScBe02, 2] 

19 “Scrum refers to the strategy used in rugby for getting an out-of-play ball back into play. The name Scrum stuck because 

of the similarities between the game of rugby and the type of of product development proscribed by Scrum. Both are 

adaptive, quick, self-organizing, and have few rests” [ScBe02, 1].


Abb. 9: Überblick über Scrum [High02, 243]. 

Die Auftragbestandsliste (engl. product backlog) enthält alle Anforderungen an das Softwareprodukt 

(funktionale A., nichtfunktionale A. / Anforderungen an die Technologie). Die Anforderungen 

stammen z. B. von Kunden, Verkäufern, der Marketing-Abteilung, dem Kunden-Support oder von den 

Softwareentwicklern und können zu einem beliebigen Zeitpunkt während der Projektabwicklung 

eingebracht werden. Die Produktfreigabeliste (engl. release backlog) enthält jenen Teil von Anforderungen 

der Auftragbestandsliste, der im nächsten Zyklus entwickelt werden soll. Aus der Produktfreigabeliste 

wird unter Berücksichtigung der Wichtigkeit (Priorität) der Anforderungen und für die 

Entwicklung zur Verfügung stehenden Ressourcen eine Aufgabenliste (engl. sprint backlog) erstellt, 

möglicherweise in mehreren Iterationen. Die Aufgabenliste übersetzt Anforderungen an das Produkt 

in Aufgaben für die Softwareentwickler. 

Für die Sprint-Phase schreibt Scrum keine speziellen Entwicklungspläne vor [High02, 245f]. 

Scrum sichert lediglich, dass die Anforderungen (in der Produktfreigabeliste) und die daraus 

abgeleiteten Aufgaben (in der Aufgabenliste) während eines Sprints (ca. 30 Tage) unverändert 

bleiben. 20 Das soll die Fragmentierung der Arbeitszeit verringern und sich häufig ändernde Prioritäten 

verhindern. Die Softwareentwickler verpflichten sich für die Dauer eines Sprints, Aufgaben aus der 

Aufgaben-Liste zu realisieren. Dabei koordinieren sie ihre Arbeit ihrem Wissen, ihrer Erfahrung und 

ihren Talenten entsprechend u.U. auf der Grundlage eines anderen Prozessmodells [ScBe02, 128]. 

Die Softwareentwickler können tun, was sie für nötig halten, um das Ziel des Sprints zu erreichen 

[ScBe02, 45]. Der Kunde (oder Produkteigentümer / Produktmanager, siehe unten) kann erst am Ende 

eines Sprints 

• die Ergebnisse übernehmen, 

• im nächsten Sprint überarbeiten lassen oder 

• auf die Ergebnisse vollständig verzichten. 

Während eines Sprints nehmen alle Projektmitarbeiter an täglichen Treffen (engl. Scrum meetings) 

von ca. 15 Minuten teil. In diesen Treffen nehmen die Projektmitarbeiter kurz zu folgenden Fragen 

Stellung [ScBe02, 40]: 

• Was wurde seit dem letzten Treffen erreicht (welche Aufgaben wurden erledigt)? 

20 Die Auftragbestandliste kann in dieser Zeit weiterentwicklet werden.


• Was (welche Aufgabe) soll bis zum nächsten Treffen erreicht (bearbeitet) werden? 

• Welche Probleme gilt es bis dahin (bis zum nächsten Treffen) zu überwinden? 

Die täglichen Treffen sind informativer, nicht fachlicher Natur. Sie dienen der Überwachung (engl. 

monitoring) des Projektes und geben dem Management die Möglichkeit, Probleme schnell zu erkennen 

und Maßnahmen zur Überwindung der Probleme zu ergreifen. Komplexes fachliche Aufgaben 

werden in gesonderten Fachtreffen (engl. follow-up meetings [ScBe02, 46]) zwischen betroffenen 

Projektmitarbeitern erörtert. Diese täglichen, rein informativen Gruppentreffen sind für alle Projektmitarbeiter 

wenig aufwendig und nützlicher als (diskontinuierliche weil nicht interaktive) Kommunikation 

durch Schreiben und Lesen von missverständlichen Reports [ScBe02, 40]. Erledigte Aufgaben 

der Aufgabenliste können für alle sichtbar in Hinsicht auf noch offene Aufgaben visualisiert werden 

(engl. sprint backlog graph). Die Treffen finden zur selben Zeit im selben Raum statt; das beseitigt 

Koordinationsaufwand und macht die Treffen zu einer Selbstverständlichkeit. Auch andere Produktinteressenten 

können an diesen Treffen als Zuhörer teilnehmen. Sprints dauern sehr kurz, können aber 

in außergewöhnlichen Fällen (gravierende Änderung von Projektumständen) vorzeitig beendet werden 

[ScBe02, 53]. 

In der Post-Sprint-Phase, am Ende einer Projektiteration, werden in einem informativen 

Arbeitstreffen [High02,247] [ScBe02, 54-56] 

• der Projektfortschritt analysiert, 

• Ergebnisse dem Kunden präsentiert und 

• ein Review des Projekts (und Produkts) aus technischer Sicht durchgeführt. 

Ergebnisse dieses Treffens fließen in die nächste Projektiteration ein. 

Wichtige Rollen in Scrum-Projekten sind [ASRW02, 30f]: 

• Scrum-Master: Methoden-Berater und Coach; ist verantwortlich dafür, dass das Projekt nach 

den Scrum-Regeln abläuft und sorgt für optimale Arbeitsbedingungen für das Scrum-Team. 

• Produkteigentümer (Produktmanager): Ist für das (nach den Scrum-Regeln) zu erstellende 

Softwareprodukt verantwortlich, z. B. für die Pflege der Auftragbestandsliste, für die 

Umwandlung von Produktfreigabelisten in Aufgabenlisten, für Schätzung von Aufwänden und 

für die Dokumentation des Projektforschritts (engl. sprint backlog graph). 

• Projektmitarbeiter (Scrum-Team): Softwareentwickler, die sich den gegebenen Rahmenbedingungen 

entsprechend selbst organisieren. 

• Kunde 

• Management: Nimmt an der Zielsetzung und Anforderungsdefinition teil und trifft finale 

Entscheidungen in Übereinstimmung mit den grundlegenden Scrum-Praktiken. 

Mit Scrum kann nicht nur die Arbeit einzelner Projektgruppen mit bis zu ca. 10 Mitarbeitern 

organisiert werden⎯wie im Fall von XP⎯sondern auch die Arbeit mehrerer, zusammenhängender 

Projektgruppen, die z. B. verantwortlich sind für 

• gemeinsam benutzte Ressourcen (wiederverwendbare Komponenten und 

Entwicklungswerkzeuge), 

• für die Sicherung der Qualität (Testen) des gemeinsam erstellten Produkts oder 

• für die Unterstützung von Produktvarianten, die bereits produktiv eingesetzt werden. 

Wenn mit Scrum mehrere Projekte organisiert werden, dann treffen sich während eines Sprints die 

Scrum-Master der Teilprojekte; die Treffen müssen nicht mehr täglich stattfinden. Statt dessen finden 

in größeren Abständen aber regelmäßig statt (engl. scrum of scrums meetings) [ScBe02, 128].


MSF [Microsoft, v1:1991, v2:1998, v3:2003] 

Quellen: [Luka03] [Stat99] [Micr99] [Micr03a] [Micr03b] [Micr03c] 

Entwicklung und Einsatz (Deployment) von Softwareprodukten sind komplex und damit schwer zu 

beherrschen. Der Einsatz fortschrittlicher Technologien alleine sichert nicht den Erfolg eines Softwareprojektes. 

Die entscheidenden Erfolgsfaktoren sind Produktinteressenten (engl. stakeholer) und 

Prozesse. Werden diese nicht genügend berücksichtigt, dann kranken Projekte an folgenden Symptomen 

[Micr03a]: 

• Unkoordinierte Produktinteressenten. 

• Unzureichend beschriebene, zufällige Anforderungen; für den Projekterfolg kritische 

Anforderungen werden nicht gebührend und nicht rechtzeitig berücksichtigt. 

• Projektgruppen, die gestellte Aufgaben und Anwendungsbereiche nicht verstehen. 

• Anforderungen, die die Wünsche der Kunden nicht widerspiegeln. 

• Anforderungen, die (unter gegebenen Rahmenbedingungen) nicht implementierbar sind. 

• Entwicklungsprozesse, die nicht verstanden und nicht beherrscht werden und damit unter den 

Beteiligten zu Verwirrung, zu doppelter Arbeit und zu Versäumnissen führen. 

• Mangelhafter Übergang eines Projekts von der Entwicklungsphase in die Einsatzphase. Das 

kann zu nachträglichem Flickwerk (engl. workarounds) führen, um doch noch die Anforderungen 

des Kunden zu erfüllen, oder zu Zeitverzögerungen. 

Projekte scheitern, wenn Produktinteressenten einander nicht verstehen und sich auf einen Entwicklungsprozess 

nicht einigen kann. 

Zur Überwindung der Probleme setzt MSF (Microsoft Solution Framework) auf ein Prozess- 

Framework, dessen Elemente (Prinzipien, Prozess- und Teammodelle, Praktiken etc.) situationsbedingt 

eingesetzt und angepasst werden können [Luka03, 8]. Ausgangspunkt für MSF sind folgende 

bewährten Praktiken (engl. best practices) [Stat99, 3ff]: 

1. Integriere Software täglich (engl. build software daily). 

2. Stelle jedem Entwickler einen Tester bei (engl. use buddy testers). 

3. Bilde kleine Projektgruppen mit funktionalen Schwerpunkten (engl. form feature teams). 

4. Entwickle Software iterativ, plane Zeitpuffer ein (engl. use multiple cycles, with buffers). 

5. Fixiere die Produktfreigabe zu Projektbeginn, um sicher zu stellen, dass sich die Projektgruppe 

auf die Entwicklung der wesentlichen Produktfähigkeiten (engl. features) konzentriert (engl. 

constrain resources and schedule at the start of a project). 

6. Entwickle Software inkrementell (engl. grow software by prototyping and evolving a feature). 

7. Tauche Projekterfahrungen mit Anderen aus (engl. share lessons learned by project postmortems, 

process audits etc.) 

Microsoft setzt nicht auf ein alle Einzelheiten vorschreibendes Prozessmodell, da keine Organisationsstruktur 

und kein Entwicklungsprozess die Anforderungen aller Projekte unter allen Bedingungen 

erfüllen kann [Micr03a] 24 . Trotzdem sind gewisse, grundlegende Richtlinien für die Abwicklung von 

Projekten verschiedener Typen notwendig [Micr03a]. MSF unterstützt insbesondere die Abwicklung 

folgender Projekttypen [Micr03a]: 

• Neuentwicklungen (engl. software development projects), u. a. von mobilen, Web- und 

E-Commerce Programmen. 

21 [Meye96, 59] Ich konnte nicht eindeutig die erste Nennung des Cluster-Modells ermitteln. 

22 Die Zeit hat für eine Ausformulierung des Cluster-Modells nicht ganz gereicht. Sorry! 

23 Deployment ist wesentlich mehr als die Installation von Produkten (oder Produktkomponenten). Deployment umfasst in 

etwa folgende Aktivitäten: Verpacken, ankündigen, konfigurieren, hinzufügen (installieren), aktivieren, deaktivieren, 

entfernen (deinstallieren) [CFH+98, 5] 

24 “The MSF philosophy holds that there is no single structure or process that optimally applies to the requirements and 

environments for all projects.” [http://msdn.microsoft.com/vstudio/productinfo/enterprise/msf/, zitiert am 20.1.2004]


• Projekte zum Deployment 25 von Infrastruktur (engl. infrastruktur deployment projects), z. B. 

Deployment von Desktop-Software und Aktualisierungen (engl. updates) von Betriebssystemen. 

• Projekte zur Integration von Softwarepakten (engl. packaged application integration projects), 

z. B. zur Integration von Komponenten (Paketen) von Warenwirtschaftssystemen. 

• Kombinationen der oben genannten Projekttypen. 

MSF ist abgestimmt mit MOF (Microsoft Operations Framework). MSF und MOF unterstützen verschiedene 

Tätigkeiten in Bezug auf die Entwickung (MSF) und den Einsatz (MOF) eines Softwareprodukts 

(einer auf Software basierenden Dienstleistung) [Micr03b]: 

• MSF unterstützt die Bedarfs-, Anwendungsbereich- und Problemanalyse und die Entwicklung 

einer Problemlösung (die Entwicklung eines Softwareprodukts bzw. einer Dienstleistung) 

• MOF unterstützt den Einsatz eines anpassbaren Softwareprodukts in verschiedenen, sich 

ändernden Umgebungen. 

MOF unterstützt insbesondere den Betrieb (Anwendung und Hilfeleistung), die Änderung und die 

Optimierung von Softwareprodukten in verschiedenen Einsatzumgebungen, um vereinbarte Dienstleistungsniveaus 

(engl. service-level agreements, SLAs) zu gewährleisten. Gemeinsam decken MSF 

und MOF den gesamten Produkt-Lebenszyklus ab von der Ideenfindung, über Auslieferung und 

Einsatz bis zum Auslaufen eines Softwareprodukts [Micr03a] (siehe Abb. 12). 

Einsatzsicht 

Einsetzen 

MOF 

Planen 

Produkt 

Deployment 

Entwickeln 

MSF 

Entwicklungssicht 

Abb. 12: IT Lifecycle und dessen Abdeckung durch MSF (Microsoft Solutions Framework) und MOF 

(Microsofts Operation Framework) [Luka03, 5]. 

Dieser Aufsatz konzentriert sich im Folgenden auf MSF 27 . MSF enthält folgende Komponenten, die 

einzeln angewendet oder situationsbedingt kombiniert 28 werden können: 

A. Prinzipien: Grundlegende Werte und Standards, auf denen das gesamte Framework beruht 29 : 

1. Fördere die offene Kommunikation (engl. foster open communications) 

2. Konzentriere Arbeiten auf eine gemeinsame Vision (engl. work toward a shared vision) 

3. Fördere Gruppenmitglieder (engl. empower team members) 

25 Deployment ist wesentlich mehr als die Installation von Produkten (oder Produktkomponenten). Deployment umfasst in 

etwa folgende Aktivitäten: Verpacken, ankündigen, konfigurieren, hinzufügen (installieren), aktivieren, deaktivieren, 

entfernen (deinstallieren) [CFH+98, 5] 

26 Softwareprodukte können relativ zur sich vor allem technologisch weiter entwickelnden Umgebung altern. 

27 MOF setzt das Prozessmodell von Microsoft deutlich ab von anderen Prozessmodellen. Dieser Aufsatz konzentriert sich 

jedoch auf den klassischen Teil von Prozessmodellen⎯auf den Analyse- und Entwicklungsprozess aus der Sicht der Produktentwicklung⎯und 

daher auf MSF. 

28 “As a framework, MSF contains multiple components that can be used individually or adopted as an integrated whole” 

[Micr03a]. Dass die Komponenten des Prozess-Frameworks auch einzeln angewendet werden können deutet an, dass 

Microsoft den Begriff Framework in diesem Kontext (Prozessmodellierung) gebraucht im Sinne einer Sammlung lose 

gekoppelter (Prozess-) Komponenten, etwa in Form einer Checkliste. Im Kontext der Softwareentwicklung macht ein 

Framework jedoch das definierte Zusammenspiel von stark gekoppelten, anpassbaren Komponenten aus. 

29 Interpretierbar als die Microsoft-Philosophie oder Verfassung.


4. Etabliere die Pflicht zur Rechenschaft gegenüber Kunden und Kollegen [Micr03c] und ein 

gemeinsames Verantwortungsgefühl für das gesamte Produkt (engl. establish clear 

accountability and shared responsibility) 

5. Bewahre Flexibilität, sei bereit für Veränderungen (engl. stay agile, expect change) 

6. Investiere in Qualität (engl. invest in quality) 

7. Lerne aus Erfahrungen (engl. learn from all experiences) 

B. Modelle: Schematische Beschreibungen der Struktur von Projektgruppen und von Prozessen: 

das (B1) Teammodell und das (B2) Prozessmodell. 

C. Disziplinen: Die Projektabwicklung unterstützende Prozesse: (C1) Projekt-Management, (C2) 

Risiko-Management, (C3) Readiness-Management. 

D. Konzepte: Ideen, die den grundlegenden Prinzipien (A) folgen, Modelle (B) oder Disziplinen 

(C) unterstützen und sich in Form von bewährten Verfahren (E) äußern. 

E. Praktiken: Bewährte Verfahren, die sich als nützlich für die Abwicklung von Projekten herausgestellt 

haben. 

F. Empfehlungen: Optionale Verfahren und Richtlinien zur Unterstützung des Einsatzes der 

Modelle (B) und Disziplinen (C). 

Die folgende Tabelle zeigt an 2 Beispielen, wie die MSF-Komponenten zusammenhängen: 

Bsp A: Prinzipien B: Modelle / 

C: Disziplinen 

1 Lerne aus 

B1: Prozess- 

Erfahrungen modell 

2 Bleib flexibel, er- C2: Risikowarte 

Veränderungen Management 

MSF Komponenten 

D: Konzepte E: Praktiken F: Empfehlungen 

Bereitschaft 

zum Lernen 

Kontinuierliches 

Risiko- 

Management 

Reviews nach Externe Person mo- 

Meilensteinen deriert ein Review 

Definiere und Erstelle eine 

überwache Ri- unternehmensweite 

sikoauslöser Risiken-Datenbank 

Das erste Beispiel ist etwa wie folgt zu lesen: Um aus Erfahrungen lernen zu können, muss die Bereitschaft 

zum Lernen vorhanden sein. MSF empfiehlt dazu im Rahmen des Prozessmodells, abgeschlossene 

Phasen oder Entwicklungszyklen einem Review zu unterziehen. Es wird empfohlen, dass externe 

(an dem Entwicklungsabschnitt unbeteiligte) Personen die Reviews moderieren. 

MSF-Modelle 

Teammodell (B1) und Prozessmodell (B2) sind die Schlüsselkomponenten des MSF. Sie wenden die 

grundlegenden Prinzipien (A) auf die entscheidenden Erfolgsfaktoren eines Projekts an: auf Produktinteressenten 

und Prozesse. Die Modelle beschreiben die Organisation einer Projektgruppe anhand 

von Rollen und Aktivitäten. 

Teammodell 

Abb. 13 zeigt Rollen(gruppen) innerhalb eines vollständigen Teams und ordnet ihnen die jeweiligen 

Qualitätsziele im Rahmen eines Projektes zu.


Zufriedene Kunden. 

Kunde kann die Lösung 

effektiv nutzen. 

Lösungen innerhalb der Rahmenbedingungen eines Projektes. 

Produkt 

Manager 

Anwender 

Programm 

Manager 

Kommunikation 

Release 

Manager 

Entwickler 

Tester 

Einfaches Deployment und kontrollierter Einsatz der Lösungen. 

Abb. 13: Die Rollen(gruppen) des MSF Teammodell und deren Qualitätsziele. 

Lösungen auf der Grundlage 

einer Spezifikation. 

Bereitschaft zur Produktfreigabe 

nachdem alle 

Qualitätsanforderungen 

identifiziert und behandelt 

wurden. 

Jede Rolle ist gleichwertig (engl. team of peers). Wichtige Entscheidungen werden gemeinsam getroffen. 

Die Rollen vertreten dabei die Interessen verschiedener Produktinteressenten und bringen deren 

speziellen Anforderungen an die Produktqualität ein, weil die Entwicklung von Softwareprodukten 

nicht auf die Programmierung beschränkt ist. 

MSF ist skalierbar, indem entweder 

• funktionsorientierte Projektgruppen (engl. functional teams) oder 

• produktorientierte Projektgruppen (engl. feature teams) 

gebildet werden. In funktionsorientierte Projektgruppen übernehmen mehrere Personen eine Rolle, z. 

B. bilden mehrere Entwickler eine Entwicklergruppe und mehrere Release Manager bilden eine Release 

Management Gruppe. In produktorientierten Projektgruppen erstellen Projektgruppen gemeinsam 

komplette Produktfunktionen. Diese Projektgruppen besetzen mehrere, im Idealfall alle Rollen, z. 

B. eine Projektgruppe aus Entwicklern, Testern, Release Managern für separate Betriebssystem- und 

Infrastruktur-Komponenten (die Gruppe „Betriebsyssteme“), eine andere Projektgruppe realisiert die 

Kreditkarten-Funktionen eines Online-Warenhauses. Grundsätzlich kann eine Person mehrere Rollen 

übernehmen. Rollen mit gegensätzlichen Interessen sollten jedoch nicht von einer Person besetzt werden, 

z.B. Programm Management und Produkt Management. Mit der Entwicklerrolle sollte keine andere 

Rolle kombiniert werden. 

Prozessmodell 

MSF kombiniert die Phasen- und Meilenstein-basierte Vorgehensweise des Wasserfall-Modells mit 

der iterativen Vorgehensweise des Spiralmodells [Micr03a] [Micr99, 2] (siehe Abb. 14). 

Deploymentphase (diszipliniert) 

Bereitschaft des Produktes 

zur Freigabe ist bestätigt 

Stabilisierungsphase (zielstrebig) 

Implementation deckt Reichweite 

des Produktes ab 

Deployment des Produktes ist abgeschlossen 

Prozessmodell 

Ideenphase (erforschend) 

Vision und Reichweite des 

Produktes sind bestätigt 

Planungsphase (klärend) 

Projektpläne sind bestätigt 

Entwicklungsphase (kreativ) 

Abb. 14: Phasen und Meilensteine des MSF-Prozessmodells. Unterschiedliche Phasen haben den 

phasentypischen Aktivitäten entsprechendend unterschiedlichen Charakter (erforschend, klärend etc.).


Entwicklungsphasen bündeln Aktivitäten mit dem Ziel, zu den Meilensteinen geforderte Ergebnisse 

(im geforderten Zustand) vorzulegen. Von Phase zu Phase ändert sich die Sicht auf das Produkt und 

die Art (Charakter) der Tätigkeiten, z. B. überwiegen in der Entwicklungsphase kreative Tätigkeiten 

(kreative, ausgewogene Problemlösungen entwickeln) und in der Stabilisierungsphase überwiegen 

zielstrebige Tätigkeiten (zielstrebiges Finden und Beseitigen von Fehlern). 

Meilensteine dienen der Synchronisation und Überprüfung von Arbeitsergebnissen. Meilensteine 

sind Kontaktpunkte mit dem Auftraggeber: In Meilensteinsitzungen kann die Reichweite bzw. Ausrichtung 

(engl. scope) des Produkts an geänderte Kunden- oder Geschäfts- oder Technologieanforderungen 

angepasst werden. Meilensteine müssen vor einem Übergang zur nächsten Phase erfolgreich 

abgeschlossen sein. Ein Meilenstein ist erfolgreich absolviert, wenn greifbare Ergebnisse vorliegen 

und Produktinteressenten Einigkeit über das Qualitätsniveau der Ergebnisse erzielt haben. Meilensteine 

sind keine punktuellen Ereignisse sondern erstrecken sich über eine gewisse Zeitspanne. Die 

folgende Tabelle vermittelt einen Eindruck davon, welche Ergebnisse zu welchen Meilensteinen am 

Ende von Phasen vorliegen sollen: 

Phase Meilenstein Ergebnisse {Zustand} 

Ideen Vision und Produktvision, Risikoeinschätzung, Projektstruktur 

Umfang bestätigt 

Planung Projektpläne Spezifikation {baseline 

bestätigt 

30 }, Risikoeinschätzung {verfeinert}, 

Projektablauf 

Entwicklung Produkt 

implementiert 

Spezifikation {fixiert}, Umgang mit Risiken, Programmtexte, 

Ausführbare Programme, Performanz Support Elemente 31 , 

Testspezifikation und Testfälle, Produkt- und Projektlebenszyklus-Plan 

(engl. product / project master plan) 

Stabilisierung Freigabebereit- Auslieferbare Produktversion (engl. golden release), Freigabeschaft 

bestätigt dokument (engl. release notes), Performanz Support Elemente, 

Testdokumentation und Testwerkzeuge, die übrigen Projektdokumente, 

Meilenstein-Nachbetrachtung 

Deployment Deployment 

abgeschlossen 

⎯ 

Zur Sicherung der Qualität werden Softwareprodukte kontinuierlich entwickelt, integriert, getestet und 

stabilisiert (Fehler beseitigt). Dazu werden während der Entwicklungs- und Stabilisierungsphasen neben 

externen (d. h. für den Auftraggeber oder Kunden sichtbaren) Meilensteinen auch interne Meilensteine 

zum Zweck der Ergebnisüberprüfung und -synchronisation gesetzt (siehe Abb. 15 [Luka03, 

19]). 

30 Eine Baseline ist eine geprüfte (engl. reviewed) und angenomme Freigabe eines Artifaktes. Eine Baseline bildet den 

Ausgangspunkt für die weitere Entwicklung des Artifaktes. Das Artifakt kann nur kontrolliert weiter entwickelt werden; es 

steht für gewöhnlich unter Veränderungs- und Konfigurationskontrolle. 

31 Performance Support Elements sind Werkzeuge, z. B. Experten (engl. wizards), Assistenten und (online) Trainingsunterlagen 

[Mari03]. Diese Werkzeuge realisieren keine Hauptfunktionen (oder Schritte von Geschäftsrozessen) sondern 

erleichtern Anwendern den Umgang mit einem Softwareprodukt und verbessern damit die Benutzbarkeit (engl. usability, 

ein Qualitätsmerkmal).


Implementation deckt Reichweite des Produktes ab 

Testrelevante Ergebnisse: Testspezifikation u. Testfälle 

Alphas 

Markt- oder Kunden-Freigabe (RTM) 

Kandiaten für öffentliche Freigabe 

Nullfehler Freigabe 

interne Freigabe n (Pilot) 

interne Freigabe ... 

interne Freigabe2 

interne Freigabe1 

Bereitschaft des Produktes zur Freigabe ist bestätigt 

Testrelevantes Ergebnis: Produktfreigabe 

Betas 

Abb. 15: Qualitätssicherung in MSF. 

Stabilisierungsphase 

Produktstabilität 

Entwicklungsphase 

Projektpläne sind bestätigt 

Testrelevantes Ergebnis: Testplan 

Während der Entwicklungsphase wiederholen sich in Miniterationen Entwicklungs- und Stabilisierungsaktivitäten. 

Tägliche Integrationen (engl. daily builds) zusammen mit automatisierten Tests fördern 

diese Arbeitsweise (siehe Abb.16). 

interne 

Freigabe i 

tägliche Integration: 

Entwickeln von 

Produktfunktionen 

aktualisiere lokal: fremder Code 

reserviere lokal: eigener Code 

integriere und teste global: komplette 

Codebasis (eigener u. fremder Code) 

aktualisiere global: eigener Code 

Testen und 

Stabilisieren von 

Produktfunktionen 

Puffer 

entwickle/stabilisiere und 

teste lokal: eigener Code 

interne 

Freigabe i+1 

Abb. 16: Tägliche Integration (daily builds) und Miniiterationen von Entwicklungs- und Testaktiviäten 

während der Entwicklungsphase. Lokal bedeutet: auf der Maschine eines Entwicklers, global bedeutet: auf 

einer zentralen Maschine (Build-Maschine). 

MSF-Disziplinen 

Projektmanagement, Riskomanagement und Readiness Management unterstützen die Kerndisziplinen 

von MSF: das Teammodell und das Prozessmodell. Da MSF—und gleichermaßen MOF—Management-Disziplinen 

hauptsächlich (mit ein paar Anpassungen) wiederverwenden [Micr03a], werden die 

Disziplinen im Folgenden nur kurz vorgestellt. In der Zukunft könnten zusätzliche Disziplinen hinzukommen 

[Micr03a] (z. B. Technologie-Management [A.d.V.]).


Projektmanagement 

Das Projektmanagement soll die Erbringung abrechenbarer Leistungen (Rechenschaftspflicht) fördern 

und das Management verschieden großer (verschieden komplexer) Projekte ermöglichen. Dafür 

empfiehlt MSF Methoden des PMIBOK (Akronym für Project Management Institute Body of Knowledge) 

32 und Prince2 (Akronym für Projects in controlled environments) 33 an. Besonderheiten des 

Projekt-Managements (im weiteren abgekürzt mit PM) in MSF [Micr03a]: 

A. PM-Aktivitäten erstrecken sich i. Allg. auf eine Reihe von Gebieten und Tätigkeiten und sind 

daher nicht beschränkt auf eine Rolle. 

B. Alle Rollen sind gleichberechtigt und daher auch gleichberechtigt am PM beteiligt. Insbesondere 

treffen alle Rollen PM-relevante Entscheidungen gemeinsam. 

C. Die Rolle des Programm Managers nimmt die meisten PM-relevanten Aktivitäten und die 

meiste Verantwortung wahr. 

D. In großen Projekten findet PM auf verschiedenen Ebenen statt; u. U. ist eine eigene funktionsorientierte 

Projektgruppe (siehe MSF-Teammodell) für das PM zuständig. 

Das Projekt-Management folgt den weiter oben erwähnten Prinzipien insbesondere den Prinzipien A2 

(Konzentriere Arbeiten auf eine gemeinsame Vision) und A4 (Etabliere die Pflicht zur Rechenschaft 

und ein gemeinsames Verantwortungsgefühl). 

Risikomanagement 

Das Risikomanagement soll einen kontrollierten Umgang mit Risiken und Unsicherheiten ermöglichen. 

Die Entwicklung von komplexen Softwareprodukten für verschiedenen, oft wenig bekannte 

Einsatzumgebungen führt zu hohen Risiken und Unsicherheiten. MSF versucht Risiken durch aktives 

(statt reaktives) Management als Chancen zu begreifen, indem z. B. aus Risiken und dem Umgang mit 

ihnen in der Vergangenheit Rückschlüsse für das Management zukünftiger Iterationen, Phasen oder 

Projekte gezogen werden. Aktives Management von Risiken ist notwendig für fundierte Entscheidungsprozesse. 

Dazu sind Projektrisiken kontinuierlich zu 

1. identifizieren, analysieren und priorisieren: Unsicherheiten, die den Erfolg des Projektes 

gefährden können, sollen erkannt und, durch die Projektdynamik kontinuierlich neu bewertet 

werden in Bezug auf das Projekt selbst und seine Umgebung. 

2. planen: Ausweichende, abschwächende oder korrigierende Maßnahmen zum Umgang mit 

Risiken sollen vorausschauend festgelegt werden. 

3. überwachen: Installation eines Frühwarnsystems, z. B. auf der Grundlage von Maßzahlen wie 

etwa offene, neue, korrigierte Fehler bestimmter Kategorien pro Komponente und Teilsystem, 

Anzahl und Änderungsraten von Anforderungen und Überstunden. 

4. steuern: Einleiten korrigierender Maßnahmen beim Eintreten von Risiken. 

5. protokollieren: Verwalten von Informationen über Risiken in einer Datenbank. 

Das Risiko-Management folgt den weiter oben erwähnten Prinzipien insbesondere den Prinzipien A5 

(Bewahre Flexibilität), A6 (Investiere in Qualität) und A7 (Lerne aus Erfahrungen). 

Readiness Management 

Das Readiness Management soll sicher stellen, dass jeder Mitarbeiter einer Projektgruppe in der Lage 

ist, Tätigkeiten seiner Rolle(n) entsprechend fachgerecht auszuführen. Readiness (Bereitschaft oder 

Qualifikation) bezeichnet im Kontext von MSF den Unterschied zwischen gewünschtem und tatsächlichem 

Zuständen von Personen, Projektgruppen oder größeren Organisationseinheiten bezüglich 

Wissen, Fähigkeiten und Fertigkeiten (engl. KSA, Akronym für Knowledge, Skills and Abilities) zu 

verschieden Zeitpunkten während der Abwicklung von Softwareprojekten [Micr03a]. Defizite sollen 

rechtzeitig beseitigt werden insbesondere auf der Grundlage der weiter oben erwähnten Prinzipien A1 

32 Siehe www.pmi.org 

33 Siehe www.prince2.com


(Fördere die offene Kommunikation), A3 (Fördere Gruppenmitglieder), A6 (Investiere in Qualität) 

und A7 (Lerne aus Erfahrungen). 

Referenzen 

[Ambl98] S.W.Ambler: Process Patterns: Building Large-Scale Systems Using Object Technology. 

Sigs BooksCambridge, 1998. 

[Ambl99] S.W.Ambler: More Process Patterns: Delivering Large-Scale Systems Using Object 

Technology. Sigs BooksCambridge, 1999. 

[ASRW02] P.Abrahamson, O.Salo, J.Rankainen, J.Warsta: Agile Software Development Methods. 

VIT, 2002. 

[Beck00] K.Beck: Extreme Programming explained. Addison-Wesley, 2000. 

[CFH+98] A.Carzaniga, A.Fuggetta, R.S.Hall, D.Heimbigner, A.Hoek, A.Wolf: A Characterization 

Framework for Software Deployment Technologies. University of Colorado, DCS, 

Technical Report CU-CS-857-98, 1998. 

[GrHY98] I.Graham, B.Henderson-Sellers, H.Younessi: The OPEN Process Specification. Addison- 

Wesley, 1998. 

[HaNe01] H.R.Hansen, G.Neumann: Wirtschaftsinformatik I. UTB, 2001. 

[High02] J.Highsmith: Agile Software Development Ecosystems. Addison-Wesley, 2002. 

[Jaco00] I.Jacobson: The Road to the Unified Software Development Process. SIGS Reference 

Series, Cambridge University, 2000. 

[Kruc00] P.Kruchten: The Rational Unified Process. An Introduction. Addison-Wesley, 2000. 

[Luka03] R.Lukawiecki: A-to-Z of MSF v3 (Microsoft Solution Framework). DEV238, TechEd, 

Barcelona, 2003. 

[Micr99] Microsoft: Process Model for Application Development. Principles of Application Development 

Ressource Kit, 1999. 

[Micr03a] Microsoft TechNet: Microsoft Solutions Framework Version 3.0 Overview. 

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/tandp/inns 

ol/msfrl/msfovrvw.asp, zitiert am 15.9.2003. 

[Micr03b] Microsoft TechNet: MOF Executive Overview. 

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/tandp/ope 

x/mofrl/mofeo.asp, zitiert am 19.9.2003. 

[Micr03c] Microsoft TechNet: Microsoft Solutions Framework: MSF Project Management 

Discipline v1.1. 

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/tandp/inns 

ol/msfrl/MSFPMD11.asp, zitiert am 17.9.2003. 

[OTC97] Object Technology Center, IBM: Developing Object-Oriented Software: An Experience- 

Based Approach. Prentice Hall, 1997. 

[PaFe02] S.R.Palmer, J.M.Felsing: A Practical Guide to Feature-Driven Development. Prentice 

Hall, 2002. 

[Pauli02] D.J.Paulish: Architecture-Centric Software Project Management: A Practical Guide. 

Addison-Wesley, 2002. 

[ScBe02] K.Schwaber, M.Beedle: Agile Software Development with Scrum. Prentice Hall, 2002. 

[Stat99] J. Statz: Microsoft’s Solution Framework and the Capabilty Maturity Model. Principles of 

Application Development Ressource Kit, 1999. 

[Stra03] S.Strahringer: Wirtschaftsinformatik 3: Softwareprozess-Modelle. 

http://wwwfl.ebs.de/Lehrstuehle/Wirtschaftsinformatik/NEW/Courses/Semester3/BIS3/WI 

3Teil2.pdf, zitiert am 25.6.2003. 

[Vers00] G.Versteegen (Hrsg.): Das V-Modell in der Praxis. dpunkt 2000. 

[WWW1] http://www.informatik.uni-bremen.de/uniform/gdpa/vmodel/sd3_5.htm, zitiert am 

25.6.2003 

[WWW2] http://www.extremeprogramming.org/, zitiert am 26.6.2003

Prozessmodelle - Software Engineering - JKU

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?